4 MIN READ
Picture the standard code review. A developer pushes 200 lines across two files, the reviewer reads the diff in twenty minutes, leaves a few comments, approves. The whole thing fits inside a coffee break. That workflow is the one the engineering org has been running on for fifteen years. Then vibe coding arrived. The AI now produces a 5,000 line PR touching forty files in twenty minutes. The developer clicks merge, the reviewer is staring at a wall of generated code with no realistic path to reading it. The workflow did not evolve. The PR did.
The math is unforgiving. Vibe coding generates 500 to 5,000 lines per PR, often 10 to 50 files at a time, in 20 to 30 minutes. The code review that worked at 200 lines a session was never going to scale to 5,000. The rubber stamp is not laziness on anyone’s part. It sits as the only realistic outcome of asking a human to do a job the input has outgrown.
What the meeting looks like
Three patterns show up in most engineering orgs right now, and they are roughly predictable. The rubber stamp leads the pack. Reviewer opens the PR, sees the diff size, realises they cannot read 5,000 lines in the time they have, and approves anyway. Bugs reach production, the developer finds them later, the cycle repeats. The bottleneck pattern shows up with senior reviewers who actually try. They spend four to eight hours on a single PR, the author is blocked the whole time, the feedback sits stale by the time it lands, and the velocity claim of vibe coding quietly dies. The abandonment pattern runs the most dangerous. Reviewer gives up on AI generated code entirely, the author pushes without review, and security loses visibility. AI generated code reaches production with nobody having read it.
What the options are
Three options have been tried seriously, and each one carries a real trade off. Smaller PRs sit as the cleanest fix. The engineering lead requires the AI to break the work into 200 line chunks, the reviewer can actually read those, velocity drops but quality holds. AI on the first pass is the second option. The same model flags the obvious issues, the human focuses on architecture and design, both sides doing what they are good at. The third option, and the deliberate one, is making review the bottleneck. Treat the review as the gate AI cannot push past, accept the slowdown, stop pretending AI can self review its own output at the level production code requires. None of these are free. Each one assumes the team is willing to give up something they thought they had already won.
What to actually do
Run all three, in this order. Smaller PRs first, because the rubber stamp will keep happening until the input stops being unreadable. Then AI reviews the AI as a first pass, because the obvious bugs the human wastes the most time on are the ones it can catch in seconds. Then the deliberate bottleneck, the one that turns the review from a checkbox into a gate. The engineering lead who runs all three is the one who actually gets the velocity that was promised, instead of the velocity the AI produced on paper.
The bottom line
Smaller PRs, AI first pass review, then the human review as a deliberate gate. That sequence is what makes the meeting work. The lead who skips the first step ends up rubber stamping AI generated code into production. The lead who skips the second wastes the human on syntax errors. The lead who skips the third watches the AI ship code that nobody has read.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
