◆ Sparround

Verifying output and the layers of verification

Working with an agent, the central question is not "do I trust it" but "where have I put the checks". The layers run from cheap to expensive and each catches a different class of error:

1. Compile — non-existent APIs, type errors. Seconds.

2. Lint — deprecated usage, known anti-patterns. Seconds.

3. Unit tests — wrong logic. Seconds to minutes.

4. UI/integration tests — how components work together. Minutes.

5. Agent review — conventions, forgotten cases.

6. Human review — business logic, architecture.

7. QA / staging — real usage scenarios.

The rule is simple: shift errors as far left as possible. An error caught at compile time is free; one caught in production is expensive.

Suspicious claimHow to verify
"This exists from API level 26"The API reference on developer.android.com
"This method is deprecated"A lint warning plus the official docs
"Version X of this library has Y"`libs.versions.toml` plus the library's release notes
"The tests pass"Run the tests yourself — look at the output
"This change doesn't alter behaviour"Do the existing tests pass unchanged
"This is the best approach"Ask for alternatives; compare their consequences

The most important practical rule: the agent saying "done" is not evidence. Evidence is command output. If the agent says "I ran the tests and they passed" and you never see the output, you are believing a claim rather than a result. Naming the command in the task and looking at its output should be a habit.

What to do when you don't understand the code — practical techniques:

  • Ask for an explanation: "what does this function do and why is it written this way?" A contradictory explanation means suspicious code.
  • Ask for simplification: "write this more simply." If it can't be simplified, the complexity is either necessary (and should be explained) or the agent doesn't understand it either.
  • Have tests written: writing tests for code you don't understand both documents behaviour and helps you understand it.
  • Ask for alternatives: "what other approaches exist?" The comparison shows whether the choice was justified.

And the most important rule is the simplest: don't merge code you don't understand. Once merged, code the agent wrote is your code.

📚 Sources and documentation