The 3 Jobs of Code Review
First, it's a place to collaborate. This is where teams come together to make decisions about what belongs in the product. Is that code review at that point? It's a review of some sort, I don't even know if I like the moniker anymore.
Second, knowledge sharing: helping build shared context, both for people and for agents, in the changes happening to a code base and the underlying business needs. And third, verification: Is it correct? Will it work? What's the risk?
Fundamentally, the question is: how do people come to a conclusion that they're confident this is the right thing for their product? The answers are different for every project and every organization.
Code reviews were always about more than just "Is the code correct?" That's what people assume reviewers are doing, but in practice correctness is one small aspect. So much of the code review process is built around applying judgment: is this the right thing for my product? It happens to be expressed as code, but people use code reviews for all sorts of other business processes.
I looked at the the old mailing lists with Linus taking emails that said, Please include this in your software. He wasn't just reviewing for correctness. So much of what was happening there was just applying taste. Does this belong in the software? I don't think that's changed. That's really the question we're still trying to answer.
Upfront Planning Is Collapsing Into Code
As it becomes cheaper to write and rewrite code, a lot of the things we used to front-load, like PRDs, and architecture documents, are collapsing into the same space. We used to do all of that in advance because it was expensive if we didn't have the understanding up front. Now we can do it in the context of real code, where you can look at the genuine artifact and shape it until, as a team, you can decide this is what we want.
That collapse is likely to load up the review process even more, but it's fundamentally the same kind of decision-making.
Spec-Driven Development: Yes, With Caveats
Specifying software doesn't go away, it's a big part of being able to express what you're trying to get to. Where exactly it happens is what we're all figuring out right now. Does it happen way up front, and do you generate from it, regenerating the entire application as the spec evolves? That's one extreme. Or does the agent extract the spec back out from what it built? That's the other extreme.
I suspect specification will be a tool we use to provide guardrails for what we want to build, and you won't be able to say "I wrote that" or "the LLM wrote that." You'll say, through the process of getting to where we wanted to go, it came into existence.
Extracting Decisions Into Institutional Memory
There's a world where we are creating context and rules to check, in an automated way at the time code gets built, with rigor that would have been extraordinarily difficult for people to achieve. Keeping the entire set of rules in my head and making sure I applied them to every single API—that was hard enough. Having an LLM help with that is great.
You reviewed and made trade-offs, and made decisions. Can we extract those back into rules that become part of the institutional memory of the code base so that we do this more effectively over time?
The more that loop can take place where I'm already iterating, talking to people, and collaborating, the tighter and more effective it will get. My guess is it's going to trend toward happening in the process, not before or after.
A World With 20x More Unmerged PRs
I've been talking to folks at GitHub about whether we're headed toward a world where there are twenty times as many PRs that don't get merged. And maybe that's okay. Maybe that's part of how people build software going forward: We tried it, these ones we accepted, and those ones we rejected. That doesn't mean we weren't being productive in the process.
I'm an engineering manager. I don't write code day to day anymore. But I've quickly thrown together a draft PR just to express something I'm trying to help the team see or understand. Don't use it as the basis of what you're doing, but now you can see it in context, the real deal, and we can have a conversation about it. That's becoming cheaper and easier to do.
(Not) Reading Code
The question of whether to read every line of code is shifting. How far can these tools get in creating that kind of confidence? And what do we need to give them to create it?
More and more, my own mental model of this is: it's not "do I read or not read the code," it's "does my attention get directed to where it's actually useful?" Can I be pointed at the parts that are meaningful for me to apply my judgment and expertise, and the things that can be—with high confidence—removed from my attention set, can fall away over time.
That gives you a sliding scale. Different organizations are going to find themselves at different places on that line. It depends on the sensitivity of what you're building, the consequences of the change, and what happens if something goes awry.
Complexity Expands With Capability
The industry used to ship without code reviews, and to an extent that's true. But the size, sophistication, and complexity of the software we now build have increased dramatically. The practice of software engineering is how we got there.
What's happening now is a shift in how much and where our attention can be. We have to find the new practices that will allow us to build the even bigger things that are accessible with the new tools. There's a forward-pointing arrow here: how do we build up our practices to handle more and more sophisticated things?
I often use this analogy: Excel spreadsheets gave people the ability to build software in a way that was accessible to far more people. Nobody's doing code reviews on their Excel spreadsheet. But if you want to build something dramatically more sophisticated at a larger scale, we're going to need practices that create systems we can have confidence in.
The easier it gets to build complex systems, the more complex and sophisticated the systems that we try to build as organizations will get. That frontier is always going to be ahead of us.
Serving the Full Spectrum of Developers
Software engineering is changing so rapidly that it's difficult to know where it'll land. We're all inventing it as we go, and that's part of what's fun about it right now.
There's going to be an interesting problem for those of us building developer tools: how do we serve the full audience? These questions existed before, but they were easier to categorize—low-code/no-code versus systems development versus application development. Now it's on an individual basis: Where is this engineer on their journey? That's a much harder thing to solve for.
A huge part of what I'm thinking about is progressive enhancement of the experience, so that no matter how much or how little you're ready to bite off, you get value from it. Not an easy thing to figure out, but definitely ours to figure out.