Answer
Should a coding agent write the tests?
Yes, but not after the code it tests. A test written afterwards records what the code does rather than what was required.
Yes, provided the test comes from the requirement rather than from the finished code. A test written after the implementation encodes what the code does, defects included, and will pass forever without proving anything.
The objection to agent-written tests is usually stated as independence: the same party wrote both, so the test cannot judge the code. That is true in one specific configuration and avoidable in another. If the test is written from the finished implementation, it describes that implementation and will pass whatever the implementation does, including whatever it does wrong. If it is written from the requirement before the implementation exists, it is a statement about what should happen and can fail.
So the productive sequence is requirement, test, watch it fail, implement, watch it pass. Each step produces evidence: a test that fails for the right reason establishes that it is actually testing something, which is the property nobody checks and which is absent from a large share of tests in most codebases. This is ordinary test-first practice and it happens to be exactly the discipline that makes agent-written tests trustworthy.
Agents are good at the mechanical part of testing and this is worth using deliberately. Enumerating edge cases — empty, zero, negative, duplicate, boundary, unicode, concurrent — is tedious for people and reliably done by a machine. Producing the fixture, the setup, the teardown, the parameterised variations is the bulk of the writing effort and the least interesting part of it. Handing this over is a straightforward gain.
What agents do less well is deciding what is worth asserting. A generated test suite tends towards uniform coverage of everything the code does, including behaviour that is incidental, which produces a suite that breaks on every refactor and is then trusted less. Deciding which behaviours are the contract and which are implementation detail is judgement about what the system is for, and it stays with the person.
The characteristic defect to watch for is the test that asserts the implementation. Checking that a particular method was called, that an internal structure has a given shape, that a private step happened in a given order. These pass, they look thorough, and they turn every internal change into a test failure. Reviewing generated tests specifically for this is more valuable than reviewing them for coverage.
One practical note on the failing step. It has to be observed rather than asserted, for the same reason as everywhere else: an agent will report that a test fails before the change because that is the expected narrative. Running the test against the unchanged code takes a moment and is the difference between the sequence being a discipline and being a description of one.
A test written from the code is a photograph of the code, and photographs do not disagree with their subjects.
Siddharth Sharma, Context Theory
Related questions
Should someone else write the tests for AI-written code?
It helps where the tests come from the requirement rather than the code, and that is the property doing the work rather than the identity of the author. A person writing tests from the finished implementation reproduces the same problem. Where the requirement is written down first, either author can produce a test that means something.
Is generated test coverage worth having if the tests are weak?
Weak tests are worse than absent ones because they produce confident approval, so coverage alone is not the goal. A small number of tests that would actually fail on a real regression is worth more than a large suite asserting the current shape of everything, and the second is the default output when nobody specified what matters.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
2026 speed-to-lead benchmark · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | A test written from a finished implementation describes that implementation and passes regardless of its correctness, while a test written from a requirement before implementation is a statement about intended behaviour and can fail. | Applying a post-hoc test to a deliberately incorrect implementation of the same requirement. |
| Software | A test observed failing for the right reason before the change establishes that it exercises the behaviour it claims to, which is a property rarely checked and absent from a substantial share of existing tests. | Running an existing test against a reverted version of the code it covers to see whether it fails. |
| Response | Generated suites tend towards uniform coverage of all observable behaviour including the incidental, producing tests that fail on every refactor, because deciding which behaviours constitute the contract is judgement about the system's purpose. | Refactoring an internal implementation detail and counting how many generated tests fail. |
| Constraint | An agent will report a test as having failed before the change because that is the expected narrative, so the failing step must be observed by running the test against the unchanged code rather than accepted as reported. | Running the supplied test against the base revision before accepting the sequence. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one