Too much code to read

How do you manage AI agents generating code when there's more code than you can read?

A team lead has always had this problem to some degree: nobody reads every line a team of eight writes. But with agents it arrives much sooner, and much harder. A few agents running all day produce more code than a person can review, and if you insist on reading all of it, you become the thing that limits how fast the work goes. So the question becomes what you do instead of reading it.

How it changed

At the start of the year I inspected every piece of code the agents wrote. They were good at repetitive work, like reference documentation or a systematic change across a codebase, but anything larger I checked line by line, and fixed by hand.

Then I started reading less of the code and more of the plans. I would iterate on a plan with the agent until it was right, and then leave the coding to the machine, checking the result rather than each change. That went too far for a while, when the agents started making sweeping changes with scripts and breaking things they hadn't been asked to touch, and it took a set of firm rules to bring them back.

By the end of the year I've really put my foot down. For most work, even quite large projects, I rely on the agents to produce reliable code first time, and my job is to make that likely and to find out quickly when it hasn't happened. That's what the techniques below are for.

Techniques

Write the standards down

An agent only follows the standards it can see, so they live in files it reads at the start of every session: a style guide for each kind of work, and a short list of rules for the machine as a whole. The rules are mostly things that went wrong once and must never happen again:

Write code directly, no generator scripts
- Make code and file changes by editing the real files in place.
- Do not write throwaway scripts that generate, rewrite or patch code or content.
- If a change truly needs a script, stop and ask first, say why, and show the script.

Never kill processes by pattern
- Find the exact process, confirm it's the one you started, then stop only that one.

Each rule says why, as well as what. An agent that knows the reason applies it to cases the rule didn't spell out.

Plans you can read

If I'm not reading the code, I have to read something, and that's the plan. A plan is far shorter than the code it produces, and it's where the decisions are made, so that's where my attention goes. Plans are written as pages I can open in the browser, with links between them and diagrams in them, for the reasons in HTML is all you need.

One shape for everything

Code that always has the same shape can be checked at a glance without being read. If every module has the same directories, the same kinds of classes and the same rules about who can talk to whom, a wrong file or a wrong dependency stands out in a directory listing. The agents get the same benefit: with one obvious place for everything, there's much less room for them to invent something new. The structure I use for PHP is in Modular monoliths in PHP.

Check what it does, not what it says

The most reliable review is running the thing. An agent finishing a piece of work runs it and shows the evidence: the tests and their output, a log of what happened, a screenshot of the page in a real browser. When something is meant to work in a particular environment, it's built and tested in that environment, not assumed. A wrong result in a log is much easier to spot than a wrong line in a diff.

Keep the documentation in step

Documentation is how I, and the other agents, understand code nobody has read. So it has to change whenever the code does, and the agents are told so in the code itself, in comments above the functions, which point at the pages that document them and spread themselves to every function an agent touches.

Small, disposable tools

Some code doesn't need reading at all. A little tool made for one job, or a whole set of them, either does the job or it doesn't, and it can be thrown away and made again. Knowing which code is disposable, and which is the core that everything else depends on, decides where the reviewing time goes.

What I still read

I don't read everything, but I don't read nothing either. I read the plans, the interfaces between parts, anything to do with security or money, and anything an agent was unsure about. And whenever a result surprises me, I read the code behind it, because a surprise is usually where the agent and I understood the task differently.