Stop Your Agent Every 100 Lines to Test
Never let your coding agent write more than a hundred lines before you test. An agent that runs unsupervised for 500 lines feels productive — until you run it and something's broken. Now the bug could be anywhere in those 500 lines, and every slice built on top of a bad first slice inherits the flaw. You don't have one bug; you have a mountain.
Why 100 lines
The number isn't magic — it's a proxy for "small enough that a failure is easy to locate." When you test after ~100 lines and something breaks, the suspect region is tiny. When you test after 100 lines and it passes, you've locked in a known-good foundation before stacking more on it.
The alternative compounds. A subtle error in the data layer looks fine until the UI layer reads from it, which looks fine until validation runs against it. By the time the symptom surfaces, three layers of agent-written code assume the broken behavior is correct. Debugging that means unwinding all three.
Work in thin vertical slices
A vertical slice is one complete piece of functionality that cuts through every layer it needs — data, logic, interface — rather than building all the data code, then all the logic, then all the UI. Each slice leaves the system working and testable.
| Step | What you do | Why it matters |
|---|---|---|
| Implement | One narrow behavior, ~100 lines | Small enough to reason about |
| Test | Run it — automated test or manual check | Failure is local, not global |
| Verify | Confirm it does what you asked | Catches "works but wrong" |
| Commit | Save the known-good state | A cheap rollback point |
| Next slice | Repeat on the following piece | Build on solid ground |
The commit step is the safety net. If slice five goes sideways, git reset to slice four costs you seconds, not a debugging afternoon. Small commits also make the diff reviewable — you can actually read 100 lines and catch a mistake the tests didn't.
Make it the agent's job, not just yours
You don't have to count lines by hand. Bake the rhythm into how you drive the agent:
- Prompt for one slice at a time. Ask for a single behavior with its test, not "build the whole feature." Agents over-produce when the task is open-ended.
- Demand a passing test as the exit condition. "Implement X, add a test for X, run it, show me it's green" makes the agent stop and verify instead of barreling ahead.
- Commit between slices yourself. Keep the checkpoints under your control so a bad slice never contaminates a good one.
- Keep the context lean. A tightly scoped slice fits an agent's context window with room to spare, which improves accuracy — irrelevant files cost tokens and attention.
This is the same discipline behind self-testing code and continuous integration: frequent, small, verified steps beat one big leap. It predates AI agents by decades. Agents just make the temptation to skip it much stronger, because generating 500 lines is now effortless — and 500 lines of unverified code is a 500-line liability.
Resources
- Continuous Integration — Martin Fowler (self-testing code, frequent small commits)
- AI-Assisted Greenfield Development: Vertical Slices — CODE Magazine
- Incremental Implementation skill — addyosmani/agent-skills
- The Codebase Is the Prompt: Vertical Slices and AI-Assisted Development — Jeremy Miller
Shipping with AI agents? Yeda AI designs, audits, and ships production LLM systems and agent workflows.