Nobody Reads All the Code

"Bro, do you even look at the code?"

It's said with the confidence of someone who has just caught you cheating at cards.

There's a peculiar accusation that comes up whenever someone admits an app was built mostly by coding agents. Or simply "vibe coded." For a lot of experienced engineers, the honest answer is no, not all of it. Then again, we never did.

Anyone who's ever worked on a large engineering team knows this. Games are a good example. You have engine programmers, gameplay programmers, tools programmers, network specialists, and someone who quietly owns the audio pipeline and is the only person alive who understands why it works. Very few people, if any, on a team like that have read the whole codebase. Most know their own portion well, the neighboring systems reasonably, and everything else through whispers and the occasional nervous conversation at lunch. Nobody really questioned this. It was simply how software of a certain size got made.

Of course, there's a difference. In a traditional team, someone understood the code they wrote. With agents, that's no longer guaranteed. Which makes the responsibility of the person directing the work more important than ever. You don't need to read every line, but you do need a way to establish that it works, that it fits the architecture, and that somebody will know what to do when it doesn't.

What's changing with coding agents isn't entirely new, even if the scale of the change is. The engineer's role is moving away from writing most of the code and toward directing the work: defining the problem, making architectural decisions, setting standards, and judging the results. Before, much of this was up to senior engineers and technical leads, although there was always overlap between deciding what to build and actually building it. Now more people do the directing, and agents do a growing share of the executing. A setup may include a build agent implementing a well-scoped feature, a review agent evaluating for obvious flaws, a test agent trying to break it, and finally a human deciding whether any of it deserves to ship. It's a familiar org chart with fewer coffee breaks.

Of the responsibilities that stay human, the most important will be choosing which problems deserve attention in the first place. Agents are remarkably willing. They'll implement whatever you point them at, endlessly and without complaint, which is exactly what makes them dangerous. A team that can produce features three times as fast can also produce irrelevance three times as fast. Before, when building was relatively expensive, you had to think twice about whether it was worth building at all. Now it's tempting to just build it and see what happens. And when you do that often enough, you end up with an impressive amount of software that nobody really needs.

This is where I think a lot of the adoption goes wrong. The temptation is to treat agents as a wholesale replacement. To flip a switch and suddenly they write everything, create everything. That's a great way to end up frustrated and with a codebase nobody trusts, and a fresh conviction among the skeptics that the whole thing is a fad. Why would we expect anything else? You wouldn't hand a new hire the entire product on their first morning and then leave for lunch.

The more sensible approach is more focused and, admittedly, a bit boring. Give agents clearly defined chunks of work inside an existing codebase, where the boundaries are understood and the result can be checked. Or use them mainly for validation and testing initially, where the agents' tirelessness is an obvious asset and mistakes are cheap. Start where it makes sense, and expand when it keeps making sense.

With a reasonably streamlined setup, the gains in output are real. Features that took a week now take a day, sometimes less. But output is the easy metric, and that's the issue with it. Quality is another matter altogether, and it needs a lot more supervision, especially where the work calls for taste. An agent can build a settings screen that's technically correct in every respect, and it still looks like it was designed by a committee that has never met a human. Knowing the difference, and more importantly, caring about it, is still very much a human job.

Quality also means more than clean code and passing tests. There's maintainability, architectural coherence, and performance. Cheap execution doesn't make bad decisions any cheaper. If anything, it makes them easier to commit at scale.

Which brings me back to the accusation. "Do you even look at the code?" assumes the responsibility lives in reading the code. On any project of real size, responsibility has always been slightly higher up, in decisions about what to build, how it should fit together, and what counts as good enough. Agents haven't changed that. They've just made it harder to ignore. Essentially, it's the difference between not reading every line of code and not understanding what you're building.

The engineers who do well in this shift probably won't be the fastest typists, or the ones who refuse to touch the tools on principle. They'll be the ones who are clear about what matters and have the conviction to say no to the rest. Come to think of it, that was always the job. Most of us were just too busy typing to notice.