A shift I didn't expect
Before December 2025, I couldn't have imagined questioning whether I should read all the code I use. I thought I'd be discussing other things, maybe even the importance of continuing to write my own code.
At the time, code generated by AI models was inconsistent. My rough impression was a 60/40 split: around 60% was average, while the other 40% didn't even work. It was hard to imagine that I might one day consider not writing the code myself.
But that changed.
Gradually giving up control
My first step was to keep control of the foundations. I would define the interfaces, method signatures, and contracts, then let the model generate their contents. That felt like a reasonable balance. I could still read the result while controlling the important boundaries.
In the months after December, I noticed that the generated implementations were often good and very similar to what I would've written.
Eventually, I moved up one level of abstraction. Instead of describing specific methods, classes, or entities, I would explain the problem and the abstractions, concepts, or patterns that might solve it. Then I'd discuss the approach with the model in plan mode.
At first, planning felt like directing the model and correcting its suggestions. After the first few months of the year, as new models arrived, it started to feel more like a real conversation. We'd work through the problem together and decide which plan made the most sense.
That conversation then shaped the entire implementation.
The question is what happens in between
As I trusted the models more, I delegated more. Our discussions expanded beyond architecture to expected outputs, testing, and validation. What's the plan? How will we verify that the system works?
That leaves an important question: should we read everything between the plan and the validation? Should we review every generated line?
My answer has changed over time. At the beginning of the year, I would've said we should read 100% of the code because it could still fail unexpectedly. Later, I became more selective: read the critical parts.
My practical advice remains the same. If you have enough experience to identify the critical parts of a system, focus on those. If not, read the code with someone who can help you find them.
But I suspect that measuring how much code we read will, sadly, become outdated...
Reading is not the same as understanding
I think we're moving from a requirement to read the code to a requirement to understand it.
The distinction may sound minor, but it matters. We need to keep humans in the loop. You can keep prompting a model, feeding it issues, and hoping for the best. But eventually, nobody knows what's happening. Nobody understands the system anymore.
Understanding doesn't necessarily mean reading every line. But it also doesn't mean simply creating a good architecture, choosing the right patterns, approving a plan, and validating the outputs. Those things may prove that you understood the requirement and knew how to communicate it to an AI model. They don't prove that you understand the code it produced.
The plan isn't the system. The implementation is.
Understanding the system that actually exists
We need tools and practices that help us understand the current system. Not just the one we planned, but the reality of the code that's running.
That understanding lets an engineer explain to someone on the business side why a feature will be difficult. Maybe the current implementation was optimized for one need rather than another. Like almost everything in software, that decision involves a trade-off.
The critical skill is understanding where those trade-offs exist. The ones we planned may not be the same as the ones that emerged during implementation.
That may become the new form of review. Instead of reviewing individual lines, we'll need to understand what happened, describe the system's current state, and present it in a form the team can read and discuss.
The near future of code review
It's easy to focus on the immediate problem: AI models can produce more lines than we can reasonably review one by one. But the future may take us in a different direction.
In A Unified Workflow for AI-Driven Software Development, I wrote about the current reality of working with generated code. Here, I'm thinking about the near future, though predicting anything in this field is getting harder.
I believe tools that help engineers understand a codebase at any given moment will become essential. They won't just help us process more generated code. They'll let engineers remain meaningfully involved.
The goal is no longer just to read the code. It's to understand the system we actually have.