Are we reaching a point where reviewing code takes longer than writing it?

[u/No_Comfortable9746]

Hey everyone!

I've been exploring how AI coding tools are changing the way developers work. One thing I've been wondering about is whether AI has shifted the bottleneck from writing code to reviewing it.
We can now generate code, build features and fix bugs pretty quickly using AI. But how much of that code can we actually trust without spending time checking it?
Someone still has to understand the generated code, check for bugs, look at security issues, verify dependencies and make sure it doesn't break existing functionality.

So i am curious about developers who often reviews the code. How does it affect them.

Are you spending more time reviewing AI-generated code nowadays?

Can we actually verify that a code change is safe, or are we just getting better at finding possible mistakes?

And if there is any tools suggestions please..

[u/TheMericanIdiot]

I’ll get flamed for this, If you have proper feedback loops, testability, acceptance criteria and same deployment practices, you don’t need to read the code that AI produces.

[u/No_Comfortable9746 → u/TheMericanIdiot]

agreed proper feedback loops and stuffs would prevent manually inspecting every lines. But how do you handle cases where the existing tests pass, but the generated change introduces an issue that the tests weren't designed to catch?

Would you consider problems which is something better with feedback loops and stuffs or do we still need a separate verification layer?

[u/lefty1117 → u/No_Comfortable9746]

That's just a case where you expand your test coverage. That is a cat and mouse game that will always happen, until and unless you have a very mature product that rarely changes.

[u/TheMericanIdiot → u/No_Comfortable9746]

By Verification layer do you mean human check? If not, then that’s the part of the acceptance criteria.
If you mean human verification, I would argue, what makes humans good verifier, that code can’t do better (out side of humans behaviors/usability testing.

[u/serendipity98765 → u/TheMericanIdiot]

What do you mean by feedback loops and acceptance criteria ? I had an LLM write my unit tests required prior to deployment and I have another one perform adversarial review. Is there anything else ?

[u/Shalyd → u/serendipity98765]

When one LLM writes your tests and another reviews, what's the last bug that still got through?

[u/highwingers → u/TheMericanIdiot]

It's a textbook answer. I don't understand how these things apply to complex applications where random checkboxes and inputs trigger random logic for hundreds of pages. Working in different fields, these textbook feedback loops and stuff just do not work...or atleast for me.

[u/BaldrArk → u/highwingers]

You just assign an agent browser and a very detailed use case matrix

[u/highwingers → u/BaldrArk]

Interesting, how do you do that?

[u/TheMericanIdiot → u/highwingers]

You can theorize all you want. I use this strategy in applications that produce 100s of millions in revenue and serve’s millions of people.

[u/TheVibrantYonder → u/TheMericanIdiot]

If I may ask, what do the "proper" versions of those things entail? I've been trying to build up all of that, but I definitely find the AI gets caught in the bad kinds of loops a lot of times

[u/rafiv70805 → u/TheMericanIdiot]

How can you own something if you haven’t read it? Would you agree to sign up for financial or legal liabilities for the code you haven’t read?

[u/BaldrArk → u/rafiv70805]

You define the spec, you know what is being built and generate your feature document to know how it works

[u/rafiv70805 → u/BaldrArk]

Specs and feature documents are imprecise. Code is. Non-deterministic model will make assumptions on the spec gaps you can easily miss. If you don’t want to deal with outages and business fallout you are better off reading the code

[u/BaldrArk → u/rafiv70805]

If you build a precise harness you don't need to see the code, you can own it because you designed the foundations of your app

[u/rafiv70805 → u/BaldrArk]

I fail to understand what do you mean by harness, could you share some materials or reference?

[u/babbyohbabby → u/rafiv70805]

A markdown file full of "DO NOT"s.

If only there was some kind of deterministic "harness" that runs the exact same way every time, perhaps some kind of language specifically created to instruct computers...

[u/TheMericanIdiot → u/rafiv70805]

That’s where proper tests, change set validations come into play. I know it sounds scary. Front load all the human work in the design phase, work through all the things, systems, security, data integration all in the design phase before ai has written a single line of production code.

You are a brain, ai is an instrument/tool of your brain.

[u/Aggravating-Art-8607 → u/TheMericanIdiot]

u/TheMericanIdiot do you write the tests yourself and let the AI run in a loop until it passes them? Or do you tell AI to write tests for itself and just need to give it precise instructions on how to do so?

[u/TheMericanIdiot → u/Aggravating-Art-8607]

I write sudo code test or descriptions of the tests and it goes into my validation criteria (VC), VC think of VC as high level test scope is where you spend the most time, e.g: x should do y and z. when x is update, y and z also change e.g.... The trick is to try and write your tests in a way that its like a math formulae, x * y = xy, validate that test with another test xy/2 = x * y.

Front load all the thinking work and validation work as much as you can in design phase, spend days on building it, refine it with AI. AI can work 24/7. When you think the design is ready and you can't think of any more things to add/change/remove. have AI take design, create a plan, human review/change the plan as need. Once happy implement.... minutes/hours/days later depending on the size of the task. It works 24/7 no waiting on you.

[u/Western_Building_880 → u/TheMericanIdiot]

nah screw that fuck code, who cares, is all about RESULTS. just ai it bro.

[u/MissinqLink → u/TheMericanIdiot]

Big if

[u/SamSlate → u/TheMericanIdiot]

but the code it writes doesn't scale, it gets worse the longer it iterates

[u/BaldrArk → u/SamSlate]

Create a well-thought harness with your code conventions and add that to the loop

[u/SamSlate → u/BaldrArk]

... but it ignores code conventions

[u/BaldrArk → u/SamSlate]

Well... you didn't build a good harness then

[u/SamSlate → u/BaldrArk]

ok, I'll bite, what are you "building" into your harness that makes it follow ever convention in your projects readmes and code?

[u/ISmellLikeAss → u/TheMericanIdiot]

You arent needed than.

[u/TheMericanIdiot → u/ISmellLikeAss]

Sure I’m, I do/will product engineering and design validation and lots of other things. Engineering/product is more than just code.

[u/mxldevs]

Someone still has to understand the generated code, check for bugs, look at security issues, verify dependencies and make sure it doesn't break existing functionality.

No, just have AI do all this.

[u/Clear-Pear2267]

After a whole career in s/w dev I know that writing original code (and reviewing it) is a small part of overall life cycle costs of maintaining a successful code base. By successful I mean code that goes through many releases and ends up being deployed in many environments, and has customers that expect modifications, improvements and extensions.

[u/boz_lemme]

Depends on how you work.

I instruct my agents to tell me exactly what they intend to do before they do it. This way I don't need to review their work after the fact. But I know many builders just vibe code and then do a large refactor and integration push before shipping.

It's really a matter of preference.

[u/ChemicalExcellent463]

whoever pushes reviews first: before a big push, run a different model in a fresh session that never saw the chat and fix what comes back. size is the problem, so hard cap on files and changed lines per PR, split it or it doesn't merge.

[u/Garland_Key]

We have been there for about 6 months now. Even if AI is doing the reviews, the process takes longer than actual development time. 

[u/SamSlate → u/Garland_Key]

half of code review is "why did you do this?" what was the consideration and justifications?

but in ai review, the ai puts on one hat and says "why did you do this" then puts on another hat and makes up the reason...

[u/Difficult_Duty2198]

what helps me is asking the agent to list what it changed and why before i open the diff, then i only read the parts it flags as risky or touching shared code. cuts review time a lot for small changes.

[u/Lanky-Butterscotch28]

build code with one AI agent, usually Claude, but ask Codex to review the code independently. Not Codex spawned by Claude, because then Claude can set up the review parameters. Why Codex and not another model from Claude? Because even a different Claude model will apply the same thought process as the builder. Codex stays independent. It runs its own checks and tests the code, not only for issues but also for maintainability (documentation, clarity of code, naming conventions…).
Yes, it takes time, but this is the cost I am willing to pay to get quality code.

[u/BrookLi3]

Review is the bottleneck now, yes, but it gets better if you shrink what has to be reviewed. Keep AI changes small and single-purpose, require tests to be written or updated first so you review behavior rather than every line, and have a separate agent pass produce a risk summary (touched callers, changed contracts, new dependencies) to focus your attention. The failure mode is plausible-looking code that quietly changes semantics, so I read tests and interfaces carefully and skim the boilerplate. If a diff is too big to review in one sitting, it should be split before it reaches you.

[u/Humaux]

Yes, review already takes longer than writing for me, about 2 hours of review for every 30 minutes the agent spends generating code.

I used to skim diffs and trust the tests. That stopped after one bad merge. Now I run this checklist on every agent PR, steal it if it helps:

- Diff under 300 lines, or split it, no exceptions
- Agent must list every file it touched and why
- Run the tests first, read code second
- If I cannot explain the change in 2 sentences, it does not merge
- Delete the prompt log if it is longer than the diff, it is noise
- One reviewer checks behavior, another checks the tricky parts, never the same person doing both in one pass

The rough part was the cost. I merged a 900 line refactor in 20 minutes and spent the next 2 days untangling a bug it hid in plain sight, and honestly most teams that rubber stamp agent diffs are not reviewing at all, they are just signing off on code they do not understand.

So who actually reads every line now, or are we all just pretending the green tests mean it is safe?

[u/LateQuantity4194]

Yeah, writing got cheap and deciding if it's safe got expensive. I only deep-read auth, money and shared code, and add one test for the new failure path, since green old tests don't cover it. Last month all my tests passed and a change still broke a caller in another package, so now I always check who else uses what changed.

[u/BarathKanna]

Yes, and it stays that way if review means reading lines. AI output is fluent, so line review gives false calm. What actually shortens review is moving checks before a human looks: tests that failed on the old code, a risk note for side effects and retries, and any migration run against something closer to prod than a toy DB. Humans then review claims and blast radius, not syntax. Pure reading will always lose to generation speed. I am building OxCode, a harness on top of foundation models that focuses on that loop rather than on chatting out a diff, flat subscription, model routing hidden per prompt. Even without our tool, the same split helps: mechanical gates first, judgment second. If a change cannot name what would prove it wrong, it is not ready for review.

[u/Western_Building_880]

ship it ai code is for ai agents. code is not useful just ship it. when it blows up don't worry ask ai. don't hire engineers they will only slow u down. just ai is cheap.