Your coding agent finishes a feature, and the code looks right at a glance. Then a misspelled property or the wrong argument breaks the client’s app. Strict type checks can catch many of those mistakes before you run the feature.
Turn on strict checking for your TypeScript or Python code, give the errors back to the agent, and ask it to fix the underlying problems. Run the check after changes and in continuous integration (CI). Keep your tests: a type checker can tell you a value has the expected shape without knowing whether the feature does the right thing.
What a type checker catches
Types describe the values your code expects. A function might expect a customer object with an email property, or a name that must be a string. A type checker compares those expectations with how the code is written.
With useful type information, it can flag a misspelled property, an argument with the wrong shape, or a value that might be missing. For example, if an email can be absent, the agent should handle that case before treating it as a string.
The quality of the check depends on the types it can see. A loosely typed value can hide problems, and a type declaration can be wrong. Data arriving from an outside service still needs validation at runtime.
Types also don’t establish whether your business logic is correct. A function can return a valid number while calculating the wrong invoice total. Keep tests for behavior, including edge cases, and review changes that affect payments, permissions, or stored data.
If you’re choosing a workspace for this kind of loop, you can try the zcode agent harness free (our invite link). Whatever agent you use, the check is only useful if it actually runs.
Turn on strict checking in TypeScript
In a TypeScript project, find tsconfig.json and add strict inside the existing compilerOptions object:
{
"compilerOptions": {
"strict": true
}
}
This is a minimal example. In an existing file, add the setting without deleting the other options your project needs.
The TypeScript strict reference describes strict as enabling a family of stronger checks. These include noImplicitAny, which reports cases where TypeScript would otherwise infer any, and strictNullChecks, which helps catch unsafe uses of possibly absent values. Individual strict-family options can still be overridden, so inspect the effective configuration if you’re unsure what is active.
With TypeScript installed and tsc available in your project environment, run this from the project directory:
tsc --noEmit
The compiler options documentation explains that --noEmit prevents output files from being generated. Running tsc without input filenames uses the project configuration it finds; specifying filenames directly causes it to ignore tsconfig.json.
Give the agent the errors and ask it to correct the types or code, then rerun the command. A clean type check is evidence about the configured project, not proof that every file in the repository was checked.
Add type hints and check Python
For Python, add type hints that describe the inputs and return values your functions actually use. For example:
def greeting(name: str) -> str:
return "Hi, " + name
greeting(5) # Type-checking error: expected str
The example deliberately passes a number where the function expects a string. A checker can flag the mismatch before you rely on that call.
Install mypy in your project’s development environment, then point it at the code you want to check:
python -m pip install mypy
mypy --strict src/
Replace src/ with your project’s actual folder. The mypy command-line documentation explains how to choose files or directories and use --strict, which enables a collection of stricter checks. The exact collection can change between mypy releases, so use the version your project has agreed to install.
If mypy reports missing annotations, add hints that match the real behavior. If a function can return None, describe and handle that possibility rather than claiming it always returns a value.
Type hints don’t validate incoming data by themselves. An outside response can still contain unexpected values, so keep runtime checks at boundaries where your app receives data it doesn’t control.
Make checking part of the agent’s loop
Put a short instruction in the project file your agent reads. Replace the bracketed command with the one your project uses:
After every code change:
1. Run [type-check command] and the relevant tests.
2. Read the errors and fix their underlying causes.
3. Do not silence errors with any, type: ignore, or casts.
4. Do not weaken checks or delete tests to get a pass.
5. Report the commands, results, and remaining gaps.
If a fix would change intended behavior, stop and explain.
The rule against any, type: ignore, and casts is there to prevent the agent from hiding an error instead of understanding it. If the agent hits a case it can’t resolve, have it report the limitation for review rather than quietly adding a suppression.
Run the same check in CI alongside your tests. CI is the automated check attached to your repository changes; make sure the log shows the command and its result. Our guide to adding a CI check for your coding agent walks through the setup.
A passing check is still only as useful as its scope. If CI checks one folder while the change touches another, say so in the review. And if the agent edits the check configuration, inspect that diff before accepting its green result.
Introduce strict checks without drowning
An existing project may produce a long list of errors when you switch on strict mode. Start with a folder you’re actively changing, make that check pass, and expand the checked area as you fix the next part.
For TypeScript, you can create a separate strict configuration that extends the existing tsconfig.json and includes the chosen folder, then run tsc --noEmit --project path/to/strict-config.json. Imported files can still become part of the checked program, so inspect the actual errors and included files rather than assuming the folder is an absolute boundary.
For Python, start with mypy --strict path/to/folder. Mypy may follow imports as well, so treat the chosen folder as a starting scope, not a promise that other files will never appear in the results.
Keep the original project check and tests running during the rollout. Record which folders have strict coverage, fix real issues in small changes, and add the strict command to CI for the scope you’ve brought under control.
Running a type check after every change means more agent turns. If you’re paying for a plan to cover that, this link gets you 10% off GLM coding plans (it’s our referral link).
A checklist before you accept a change
BEFORE ACCEPTING A CHANGE
[ ] Strict check ran on the intended code
[ ] Errors were fixed, not suppressed
[ ] Relevant tests ran and passed
[ ] CI runs the check and shows its result
[ ] Config and test changes were reviewed
[ ] Unchecked areas are listed
If this helped you catch a mistake before delivery, a small WURK tip helps keep these guides coming. There’s more on our blog too.
Latest comments
0