Verify the work
Use tests as feedback
Turn expected behavior into executable checks that both you and the agent can run after every change.
8 minute lesson
When an agent writes code, it runs is not enough. A test is an executable claim about behavior that should remain true after the next change.
Suppose display names must contain 1–50 characters. Useful cases include:
- 1 character succeeds
- 50 characters succeeds
- an empty name fails
- 51 characters fails
- an existing valid profile update still succeeds
These examples define the boundary more clearly than validate the display name.
Run the new test before the fix
For a regression, the new test should fail for the expected reason before you change the implementation. This proves that the test reaches the missing behavior.
If it passes immediately, investigate. The behavior may already work, the reproduction may be wrong, or the test may not exercise the path you think it does.
After the fix, run the focused test again, then nearby tests that could catch a regression.
Test public behavior
A weak test might mock the validation helper and assert that the helper was called. The implementation can call the helper and still return the wrong HTTP status.
A stronger request-level test sends a 51-character name and checks the response and stored data. It describes what users and callers can observe, while allowing the internal helper to change later.
Use unit tests for isolated logic and broader tests for important integrations. The right level depends on the claim.
Tests can be wrong
A passing test is evidence only when the assertion expresses the real requirement. An agent can write a test that repeats the same mistaken assumption as its code.
Read the input, assertion, and failure output. Ask whether the test would fail if the bug were present. Include negative and boundary cases, not only the happy path.
Generated tests are especially valuable as drafts because models can quickly propose cases. You still decide which behavior is correct.
Try this
Find one test that asserts an internal function call. Rewrite the requirement in terms of observable input and output, then decide whether the test should move to a higher level.
Lesson completed