I Stopped Reviewing My Code

Two Hundred Thousand Lines

I've written over 200,000 lines of code in the last six weeks. "Written" in the loosest possible sense. My coding agents wrote most of it. I'm a solo technical founder at pre-seed, no employees, building a product called the Vera Guide. And I have not reviewed most of that code.

Six months ago, that sentence would have made me physically uncomfortable. I'm an engineer with twenty-plus years in the industry, a decade of that at Google. The instinct to read every line runs deep. It feels like muscle memory. It feels like responsibility.

I had to unlearn it.

The Work That Actually Matters

Here's what I spent most of my time on: domain modelling. Not writing code. Not reviewing code. Sitting with a spec, going back and forth with an AI agent, working out what the entities are, how they relate to each other, what the constraints should be. Getting the model right.

This was by far the most involved work of the entire build. More than 60% of my engineering time went into understanding the product, building a concrete domain model, and making sure the agent and I agreed on how everything fits together. We'd refine the model, argue about edge cases, revisit assumptions. Then I translated that into a database schema.

What happened next is the interesting part. I took that domain model, the schema, and the product requirements and started generating features. The code that came back was good. Not perfect, but good. The tests it produced were solid. With a strong foundation underneath, the instruction following was excellent.

The Diminishing Returns of Reading Every Line

If I had reviewed every piece of code my agents produced, I would still be building features I finished three weeks ago. The slowdown would have been enormous. And for what? When I did spot-check, my objections were minor: a stylistic choice I'd have done differently, some duplication, occasional rough edges. Nothing that affected whether the thing actually worked.

All of that can be refactored later. And refactoring with agentic tools is cheap now. That's the shift most people haven't internalised yet.

Traditional defensive software engineering rests on a simple economic argument: be careful now because the cost of fixing things later is very high. Don't introduce technical debt because paying it off is expensive. Keep code readable because the next engineer who touches it will need to understand it from scratch.

Every part of that argument assumed human-only maintenance. LLMs have changed the maths. Refactoring a messy module takes minutes, not days. Understanding unfamiliar code is trivial when you can ask an AI to summarise it and get a clear explanation in seconds. The cost of "fixing it later" has collapsed, and with it, the entire rationale for spending hours reading code that already works.

Defence in Depth

So if I'm not reading every line, what am I checking?

Think of it as defence in depth. Multiple layers, each catching different classes of problem.

Architecture and domain modelling. This is where I spend my brain. If the model is right, the generated code is almost always right too. Get this wrong and no amount of line-by-line review will save you.

Tests. Comprehensive test coverage, generated alongside the features. The machines check the machines. If the tests pass and they're testing the right things, I don't need to read the implementation to trust it. I wrote about why correctness matters more than determinism a few weeks ago, and that principle applies here too: validate that the code is correct, not that it looks the way you would have written it.

Observability in production. Good logging, monitoring, alerting. When something goes wrong, I find out fast and fix it fast.

Cheap refactoring. The safety net under the safety net. If code has duplication or rough edges, I clean it up in a fraction of the time it would have taken a year ago. Technical debt becomes less frightening when the interest rate drops to near zero.

None of these layers is new. Engineers have always wanted good architecture, good tests, and good monitoring. The difference is that these layers are now sufficient. You don't also need a human squinting at every function body.

The Front-End Test

One question keeps coming back to me: does it make sense to read through pages of front-end component code when the feature works exactly as specified? An API endpoint that handles its errors, passes its tests, and does what the product requires. Should I spend twenty minutes reading the implementation line by line?

Six months ago I would have said yes. Today the answer is obviously no. The tools produce too much solid code, too fast, for a human to keep up by reading all of it. And the attempt to keep up comes at a real cost: product velocity. At early stages especially, velocity is the thing that matters most. The companies that understand this, including the ones on our AI-friendly directory, are giving their engineers room to work at the right level of abstraction rather than burning hours on manual review of working code.

A Means to an End

Code review was always a means to an end. The end was never "having read the code." It was having a system that is secure, reliable, and actually solves user needs. We reviewed code because that was the best available way to catch problems before they reached production.

We have better ways now. A strong domain model. Comprehensive tests. Production observability. The ability to refactor cheaply when something needs cleaning up. Together, these give me more confidence than a line-by-line read-through ever did.

I know this is uncomfortable. It was uncomfortable for me. The instinct to review everything is one of the deepest habits in software engineering, and letting go of it felt reckless at first. But 200,000 lines and six weeks later, I'm building faster than I ever have, and the quality is holding up. The shift isn't about being less careful. It's about putting that care where it actually counts.