My current strategy is to not read any of the code written by my agents

TL;DR Highlight

Uncle Bob skips reading agent code and verifies it with tests and constraints

Who Should Read

A backend developer worn out from line-by-line reviews of coding-agent output who wants an automated verification setup instead

Core Mechanics

Not reading the code is the strategy
- Uncle Bob says he started coding in the late 60s.
- He says not reading agent-written code is the only way to benefit from their productivity.
Surround agents with constraints instead
- He puts extreme constraints around the agents.
- These include unit tests, gherkin tests, QA procedures, quality metrics, mutation testing, and test coverage.
The list doesn't end there
- The post says there is a plethora of other constraints.
- It names no specific tools or configuration.
Trust comes from running the gauntlet
- Agent code must pass every constraint and test.
- That is why he says he has very high confidence in the result.
What he was replying to
- A user said they don't feel comfortable letting Claude edit their files and need to understand code they're responsible for.

Community Reactions

Tests written by the agent proved nothing
- One commenter had an agent implement a feature completely backwards and write many passing tests for it.
- They argued formal verification would have just proven the backwards feature correct.
Does he read the tests and constraints?
- One commenter said that level of confidence needs a huge number of tests.
- They cited SQLite's 500+ lines of tests per line of code and said at that point you may as well read the code.
Reviewing found nothing about 95% of the time
- One commenter reported that about 95% of the time manual review of agent code turns up nothing to change.
- They said humans should still decide architecture and read the agent's end-of-task notes.
Expensive bugs are spec gaps
- One commenter said the costly bugs are usually gaps in the spec itself.
- Another said human effort should shift to specs, design, and test scenarios.

How to Apply

Run mutation testing on agent output
- Pick one module an agent wrote recently, today.
- Run a mutation testing tool for your language and look at surviving mutants.
- Treat survivors as weak tests and strengthen them.
Write tests before implementation, separately
- Confirm the spec yourself, then write gherkin scenarios first.
- Hand implementation to the agent afterward.
- Don't let one agent write both tests and implementation at once.
Put the gauntlet in the agent's done criteria
- In your agent instruction file, require tests, coverage, and quality metrics to pass.
- Forbid reporting completion if any check fails.
Spend review time on specs
- Shift time from code review to checking specs and scenarios.
- Verify the requirements yourself to catch backwards implementations.

Try It

copy & run

# Paste into Claude Code or ChatGPT (simplified version of the idea: verify code via constraints)

You are an agent implementing code. Before implementing the feature below, set up constraints first.

Feature description: {{feature description}}
Language/framework: {{language}}

Steps:
1. First write the feature as gherkin (Given/When/Then) scenarios and show them. Include normal, edge, and failure cases.
2. Write a unit test for each scenario. Do not write implementation code yet.
3. Implement so the tests pass.
4. Assuming mutation testing will run, predict 5 mutants likely to survive and add tests that catch them.
5. At the end, list "parts of the spec I interpreted" and "parts that could differ from the spec".

Next: have a human read the list from step 5 to confirm the spec, then run a real mutation testing tool.

Terminology

gherkin testsHuman-readable scenario tests in Given/When/Then form. Requirements written as sentences double as verification items.

mutation testingDeliberately breaking code in small ways to see if tests catch it. It's testing whether your tests are any good.

test coverageA metric showing what percent of code the tests execute. Executed doesn't mean verified.

gauntletA series of checks that must be passed one after another. Here, code has to pass every constraint in turn.