How do you handle code reviews when 1 dev uses AI to build a massive feature but needs peer feedback

Hey everyone,

My engineering team is having an intense argument about how to adapt our code review and Scrum workflows now that we are heavily using AI assistants (Cursor, Claude Code, Copilot, etc.). We need an outside reality check on what actually works.

The Situation: A single developer uses AI to build a massive, end-to-end feature (DB changes, backend API, frontend components) from A to Z. Because of the AI, the code is generated incredibly fast, resulting in huge branches (e.g., 10,000+ lines across 50+ files) in a single day.

To be clear: There is only ONE code owner for that task. Only one person is writing the prompts, managing the agent, and fixing the bugs.

The Argument: We are completely split down the middle on when and how the rest of the team should join this single owner to review and test the work, and it's creating a massive bottleneck—what the industry is starting to call "AI Comprehension Debt" (where code is written faster than humans can comprehend it).

- Side A (Solo Local Validation First): Belongs to the mindset that the single developer must act as the "Editor-in-Chief" entirely on their own first regardless how big the work is. They must do full local reviews, debugging, and run complete local test suites to clean up the AI’s work. The team should only step in at the final PR stage to review the finished product. They argue this preserves the pure velocity of AI development.

- Side B (Parallel Review with Early Feedback): Belongs to the mindset that because the feature is large, waiting until the end to start the full review creates a bottleneck and makes the PR harder to review. The developer still owns the feature from A to Z and uses AI for the first implementation. Before publishing the MR, they perform smoke testing and a lightweight review to catch obvious issues. Once the MR is published, the review work happens in parallel: the owner performs full testing and self-review while 1 or 2 peers independently perform full testing and code review. Their feedback then comes together through comments and discussions, with the owner remaining responsible for making the fixes before the MR is merged.

Our Dilemma & The Scrum Crisis: Traditional Scrum is breaking for us. A 5-point story can now be generated via "vibe coding" in a few hours, forcing us to rethink estimation around "Attention-Based Sizing" (estimating tasks by how much human review attention they need, rather than coding effort).

Side A argues that Side B completely kills development velocity by turning peer reviewers into expensive, full-time, line-by-line syntax checkers while code is in active flux. Side B argues that Side A leads to a "black box" where a single dev dumps massive, messy AI code into a PR at the very end, making it impossible for peers to actually catch deep architectural flaws or design gaps.

My questions for you all:

- How is your team handling the timing of peer reviews for massive, single-developer AI features to avoid drowning in AI Comprehension Debt?

- Does continuous peer-reviewing from Day 1 kill the velocity of AI coding, or does waiting until the final PR gate create a worse bottleneck?

- How has your team adapted Scrum ceremonies, story points, or your Definition of Done (DoD) to handle this shift?

Would love to hear real-world experiences from teams navigating this exact workflow shift today. Thanks!