When our CTO, Ameya Kanitkar, suggested to a room full of engineering executives that human code review might eventually stop being the default, he got a visible reaction. Then he brought up compilers, and the conversation changed.
He explained his thinking on LinkedIn:
Ameya Kanitkar, co-founder and CTO of Larridin, on LinkedIn:
I was recently talking to a room full of engineering executives about code review.
When I suggested that human code review may eventually stop being the default, there was a visible reaction.
That makes sense. Code review is deeply embedded in how engineering organizations think about quality.
But there is a growing problem.
As coding gets faster, code review is becoming one of the first bottlenecks.
Agents can produce changes much faster than humans can inspect them. Automated review helps, but the basic asymmetry remains: machines are generating more code, while humans are still reading it line by line.
The analogy that changed the discussion was compilers.
Nobody reviews the assembly generated by a compiler.
We review the source code because that is where the programmer’s intent lives. The assembly is too verbose, too low-level, and we trust the compiler to translate the intent correctly.
I think something similar is starting to happen with coding agents.
The artifact humans should spend more time reviewing is the spec.
What are we trying to build?
What behavior do we expect?
What constraints matter?
What should never happen?That is where engineering judgment is most valuable.
The generated code still needs verification. Security checks, tests, static analysis, policy enforcement, and automated code review become even more important.
But humans reading every generated diff may not scale with the amount of code agents can produce.
The role of review is not disappearing.
It is moving upstream.
In an AI-native SDLC, humans review the intent. Machines increasingly verify the implementation.
Why This Matters if You Run an Engineering Org
Code review sits at the heart of how most engineering teams think about quality. But coding agents now produce changes faster than people can read them. Automated review helps, yet the imbalance stays the same: machines are writing more code while humans are still reading it line by line.
That makes review one of the first real bottlenecks in an AI-assisted development process.
The Compiler Analogy
Nobody reviews the assembly a compiler spits out. We review the source code because that's where the programmer's intent lives. The assembly is too verbose and too low-level, and we trust the compiler to translate faithfully.
Ameya thinks coding agents are heading the same way, with the spec playing the part of source code.
What Reviewing the Spec Looks Like
If the spec becomes the thing humans review most closely, the review comes down to four questions:
- What are we trying to build?
- What behavior do we expect?
- What constraints matter?
- What should never happen?
That's where engineering judgment adds the most value.
The Code Still Gets Checked
None of this means skipping verification. If anything, security checks, tests, static analysis, policy enforcement, and automated code review all matter more. Humans spend more of their time on intent, and machines take on more of the job of checking the implementation.
A Real-World Example: Shopify
In a separate post, Ameya pointed to Shopify's decision to move its mobile apps back to native development. Shopify rebuilt its Shop app in 12 weeks and is now using its Helix system to migrate the larger Shopify app.
Helix breaks the work into small checkpoints. Each must pass tests, match the existing app visually, and survive two adversarial code reviews. Human approval is required by default, although Helix can also run autonomously.
Code review is still very much there. It just looks different: a continuous verification loop where agents do more of the work and humans stay accountable for the result.
Ameya has a personal angle on this one. He was at Coinbase when it moved the other way, from native to React Native. The app migration went well; the organizational one was harder since native engineers had to become JavaScript engineers and some chose to leave. React Native's big win was fewer implementations to build and maintain.
Going back should be even harder. But agents change the math: they can use one platform as a reference to build features on the other, translate code, keep the two in parity, write tests, and review their own output. As Ameya put it, AI is changing which code organizations can afford to own.
Closing Thought
This one got people talking, with almost as many comments as reactions on LinkedIn. Whether or not you agree that human code review stops being the default, it's worth asking where your reviewers spend their time today. Are they reading generated diffs line by line, or checking that the right thing was built in the first place?
Ameya's short version: in an AI-native SDLC, humans review the intent, and machines increasingly verify the implementation.
Ameya shares this kind of practical, opinionated stuff on LinkedIn pretty regularly. If you want more of it in your feed, follow Ameya Kanitkar on LinkedIn. He's co-founder and CTO of Larridin.
Related Reading
On larridin.com:
- How to Measure AI Coding Tool ROI for Engineering Leaders: netting recovered developer time against rework and full usage-based spend.
Elsewhere:
- Helix: The Internal Tool Powering Our Shopify App's Native Migration: Shopify's write-up on its move back to native.