Human Code Review Is Not the Last Frontier
Source: Dev.to
The Self‑Driving Codebase vs. “Kill the Code Review”
I found these two articles very interesting: The Self‑Driving Codebase and How to Kill the Code Review.
I don’t think they are totally wrong – they’re pointing in the right direction – but they jump too fast from “this is where things are going” to “we are almost there.” That part I don’t buy.
Why the Real‑World Situation Is Harder
I’m not anti‑AI and I don’t think agents are just hype either. I try tools, I use them, I see what works and what doesn’t. The progress is honestly better than many people think.
But software engineering in the real world is harder than the clean version of the story, and that’s my problem with a lot of this conversation.
When people talk about autonomous agents writing software, they often act as if the main thing left is removing the human from code review. As if once agents take care of that and humans stop reviewing every diff, software development becomes mostly an automation problem.
I don’t think that is true. Human code review is not the last frontier; it is just the last visible step in a much bigger mess, because most real codebases are a mess.
What “Messy” Really Means
Big codebases are full of technical debt. They have different coding styles because hundreds of people touched them over the years, lots of “temporary changes” that were supposed to be improved later and became permanent, dead code because the business changed direction three times, bad abstractions because someone tried to generalize too early, weird edge cases because one big customer needed something five years ago and the company never removed it, missing tests, outdated docs, unclear ownership…
In short, the everyday reality for anyone with enough years in software looks a lot like the above.
Code Review Does More Than Check Quality
When I read ideas like “review the spec, not the code” or “kill the code review,” I get the point: the current review process does not scale well if agents start producing much more code than humans can read. That part is fair.
But in many teams, code review is doing more than checking code quality; it is where people bring context back into the change.
- The reviewer knows that this ugly part of the system exists for a reason.
- Another team depends on a strange behavior that nobody documented.
- A small‑looking refactor touches something fragile.
- Some code is annoying but harmless; other code looks harmless but can break production.
That knowledge is often not written down anywhere – not in tickets, not in docs, not in tests, not in the spec.
Engineering Is Often About Discovering the Real Idea
A lot of engineering work is not just implementing a clear idea, but discovering what the idea actually means while building it. You start with a requirement and then you find out:
- it was incomplete
- it ignored an old system
- it breaks an edge case
- it creates a performance problem
- it conflicts with another team’s flow
- it sounds simple at the product level but is messy at the data level
So some of these arguments assume a cleaner world than the one most engineers actually live in. If we consider that AI currently amplifies any existing structure, we are not in the best of scenarios, and this is where I separate the future from the hype.
The Real Frontier Is Not Code Review
Yes, agents will keep getting better, and human code review as we know it will probably matter less over time.
But that doesn’t mean we are close to autonomous software engineering, especially in environments where software is hardest:
- large companies
- old systems
- regulated industries
- critical user‑facing products
- codebases with years of debt and weak ownership
That is a different game.
What works inside a frontier‑AI company does not automatically work inside a financial institution.
It doesn’t mean the frontier companies are faking it; it means their environment is different. They are building the models, shaping the tools, and creating workflows around this new way of working.
Most companies are not in that position. They are still trying to survive their own complexity.
What Makes Software Engineering Hard
- Messy systems with incomplete context
- Unclear requirements and old decisions
- Conflicting constraints and real consequences if something goes wrong
The hard part is working inside those messes, not just writing code.
The deeper frontier is judgment, context, and knowing what matters in a given codebase at a given moment:
- When a change is technically correct but still wrong for the system
- What to ignore, what to clean up, what to leave alone
- What risk is acceptable
That, my friends, is what software engineering really is. This point gets lost when the discussion becomes too abstract. Once you leave the world of demos, MVPs, benchmarks, and green‑field projects, software is not just a code problem. It is a history problem, a people problem, a maintenance problem, a trade‑off problem, and we haven’t even mentioned scalability, maintainability, security, and many other important topics.
Bottom Line
I’m not arguing for a conservative view where nothing changes – a lot is already changing. I just think we should be honest about where we really are.
- We are getting better at automating code production.
- We are not yet equally good at automating the deep context that real software engineering depends on.
That is why I don’t believe human code review is the last frontier. It’s the last place where human judgment shows up before the code lands. A deeper frontier is whether that judgment can be made clear enough, structured enough, and trusted enough that the system no longer depends on humans carrying it in their heads.
Maybe we’ll get there – I don’t know. But for now, the real frontier lies beyond code review.
Cleaned Markdown Segment
know, or how we’ll address the problems I mentioned.
But from where most of the industry stands today, we may be on the way, but we certainly are not there yet; it’s not the same thing and it makes a big difference.