You might not have to read that code

There’s a lot of debate right now about if developers doing agentic programming need to review their code. Most sane and sober voices are loudly proclaiming that, yes, you need to read it. But, and go with me for a moment, do they really?

Every programmer working today has shipped production software using a mountain of code they’ve never read or even understand. The operating system, the programming language, the web framework, the database, the message queue, the cache, the libraries, the dependencies… how much of it have you read? How much of that could you really give detailed explanations about how the individual parts of them work?

I’ve been at this long enough that I’ve probably forgotten as much as I currently know. I’ve forgotten the individual specific details of code I myself wrote, by hand, like a computer science pesant. I’ve even had that experience when developing in a large code base, I’ve come across some specific bit of code and thought, that’s dumb, who did this? Only to find out after a git blame that it was me, I was the one that put that stupid line of code into the code base. And guess what? It passed code review.

I think most projects and enterprise applicatinos in particular are still doing human code review like they were a year ago. We certainly are at InfluxDB. And every bug those enterprises (and us) have shipped has passed human code review. So maybe human code review isn’t as good as we like to think it is?

Of course, the other argument for it is for knowledge sharing. Sure, knowledge sharing is important, but you actually don’t need line-by-line code review to achieve that. A short doc, or presentation with visualizations can give another programmer the details of how the system works, without the specific lines.

Although there is the sloppocalypse. I’ve experienced it firsthand. You let an agent run hog wild and go a little too long before checking in on it and you find that you’ve created a slop palace. But I’ve spotted this without even loking at the code. If the agent’s explanations of how things work and what’s going on get sufficiently absurd or untethered, you know something’s up. And then you look at the code.

The bigger point is not that you need to know every line of code, every subsystem, but you need to have knowledge and expertise about how systems and applications you ship are designed. How they’re put together. What the dependencies and moving parts are. And, depending on the importance of each of those dependencies and their familiarity or maturity, the level of detail you need to understand for their implementations. None of this requires knowing line by line code.

Now, you may like getting intimate with all the individual lines of code. And producing what you view as a code palace. But all of that is subjective. If I give you a piece of working software that solves your problem, and does it with fewer CPU cycles, less RAM, less storage, and less network bandwidth, does it really matter what the code under there looks like?

I posit that it doesn’t. What matters is verifiability. All those software systems you shipped on and didn’t understand before, you took as safe since they were mature, used far and wide, and had a set of trusted committers driving them forward. For the most part we use social proof and then first-hand experience to vet large software packages that we don’t know the real internals of. And that’s ok, trying to know everything about everything doesn’t scale.

All of this wouldn’t really matter if it weren’t for one harsh reality: requiring human line-by-line code review severely limits your ability to ship in August of 2026. The AIs have gotten good enough that if you send Fable or Sol on a task to deevelop a feature, they will not only develop it, they will code review it, they’ll fix bugs, and they’ll even test it end to end. Blackbox style, not silly unit tests that they’ll just make up.

If you don’t believe me and haven’t yet experienced it, I suggest you try the following. Using Fable as the supervisor with Opus 5 subagents (gotta manage that weekly allotment) or GPT 5.6 Sol xhigh, pursue a project. Some entire server system or application that you’d like to have them build. Give yourself an hour a day, for 10 days. You’re not allowed to direct the agent outside of that time (although it can work). You can think about your project while walking around, but your constraint is that you only get to interface with the agent and review their work for an hour.

Most importantly, you are not allowed to look at the code. If there’s user experience that is an API or CLI, by all means review that closely as it’s part of the user facing product. But you’re not allowed to look at the underlying implementation. You can talk to the agent about it and ask it questions, but that’s it. Although you are definiteluy allowed to tell the agent how to structure code and the project.

Your goal is to get the agent to do as much as possible after you leave your keyboard at the hour. In the hour you’ll review their work and set them down a path of pursuing the next bit of work. You may be able to get themn to churn for hours without you, that’s the ideal. This will require you focusing a bit on how to get the software verified so that the agent can loop on it.

What you’ll find is that if you only review the architeture design and the user experience, you’ll move much faster. And I mean MUCH FASTER. You will be shocked how far you can get implementing working, usable software.

The obvious objection will be: so what? Everyone has vibe coded some nonsense, they still can’t ship it. They can’t support it. It’s just toy software for a single user.

But does it have to be? If it works and you’ve verified it works, what then? Worried about supporting it? Ask the agent to add a feature. Ask it to do something difficult. Or ask it how something in the program works. Then go look at the code and see if it can explain it to you and if it makes sense.

What matters is that you’ve built the engineering process to validate, QA, verify, and confirm with the customer that the provided software gets the job done. You do that, it doesn’t matter if an agent or a human wrote the code, or if a human reviewed every line in detail.

Now I’m not proposing that all code should be ignored. I’m just saying that there is a large portion that can be safely skimmed over, or even ignored. It doesn’t require the level of care and scrutiny that it once did. Because we have AIs to help make sure the details stay correct.

The frontier AI of August 2026 (Fable 5, GPT 5.6 Sol xhigh) are not the frontier AI of December 2025. They are signficantly better. And their code review is, at this point, mostly better than human code review. And they’re about to be even better.

Humans need to add value where larger context matters. Archietcture, overall system design, user experience, and how the system should work. And of course building out software and a process to verify that everything works as expected.

Right now most of us have severe speed regulators affixed to our entire SDLC. We are not set up to take advatage of what’s possible today, let alone what will be possible in 2027. And it’s because we’re trying to put agents into the same old human driven SDLC we’ve developed over the last 50 years.

There’s another way, but it requires a commplete rethinking of how the SDLC should work. At least, that’s what I’m thinking while I’m still in the SDLC of two years ago. I’m dipping my toes into the new world on a few things, and it’s shocking how much I can get done.

I wake up most mornings eager to jump straight to my computer to see what new gifts the AIs have brought to me overnight while I was asleep. It’s aboslutely incredible.