Tests written by a machine: when they help and when they lie
A generated test suite arrives with the feature and every test is green. That tells you less than it appears, and sometimes nothing at all.
A feature arrives with thirty-four tests attached, all green, none of them requested. The instinct is relief. The correct reaction is one minute of reading, because generated tests split cleanly into two kinds and only one of them is worth having.
The test that restates the code
Take a function that returns total * 1.2 and a test asserting that it returns total * 1.2. It passes. It will pass tomorrow. It will pass after someone changes the tax rate to 1.1, because a suite regenerated alongside the change agrees with the change.
This is the dominant failure of automatic test generation: the test is derived from the implementation, so it can only confirm what the implementation does. It measures agreement with the code. Coverage goes up while protection stays where it was.
The test that pins behaviour
A useful test comes from the requirement. For the same function it asserts that a twenty percent rate applied to a hundred euros gives a hundred and twenty, with the numbers written out. Now changing the rate breaks the test, and breaking is exactly what you want: someone has to look, and either fix the code or update the expectation on purpose.
Three questions tell the two apart, and they take a minute:
- If the implementation were wrong in an obvious way, would this test fail?
- Are the expected values written literally, or recomputed by the same formula?
- Does anything cover empty input, the boundary value, and the value one past it?
Where generation earns its place
Volume, on the cases a human skips. Nobody writes forty variations of a date parser by hand: leap years, month ends, the night the clocks change, a timezone offset with minutes in it. A machine writes all forty without getting bored, and boredom is the actual reason those cases are missing from most suites.
Same for regression tests after a bug. The behaviour is known, the fix is known, and writing the test that locks it down is mechanical work worth handing off.
The rule we apply
Tests are generated, then read against the requirement. StrucTime Code hands back the test run alongside the software, and the report says what was checked rather than asserting that everything is fine. A green suite is evidence to weigh, and that matters most on the day it is wrong.
Related reading: reviewing code you did not write.
Reviewing code you did not write: what catches problems
The bottleneck moved. Writing code stopped being the slow part around 2025; reading it never got faster, and that is where the hours go now.
Why coding agents get worse as the codebase gets bigger
Agents demo well on a new project and disappoint on a real one. The gap comes from what the model was shown before it started writing.
Running several coding agents at once without them colliding
Four agents on one working copy give you four processes overwriting each other's files, with no record of who won.