Playbooks
How AI pair programming is changing what code review means
AI-generated code requires 11.8% more rounds of reviewer back-and-forth than human-written code, and when AI review tools do suggest changes, developers adopt those suggestions at less than a third the rate they adopt human reviewer suggestions (16.6% vs. 56.5%) — with over half of unadopted AI suggestions being either incorrect or handled differently by the developer. The traditional review criteria of readability and correctness are proving insufficient because AI-generated code can pass both tests while still following logic no one on the team, including its own "author," actually understands.
Last updated Aug 21 · 19 min read
Why traditional review criteria are breaking down
A widely discussed "Ask HN" thread posed the question directly: how do you review your own code in the age of AI? The consensus that emerged wasn't a new checklist — it was an acknowledgment that traditional review criteria (is it readable, is it maintainable, does it look correct) are proving insufficient on their own, because AI-generated code often "works" while following logic that's unfamiliar or subtly incorrect in ways a surface read doesn't catch (Hacker News).
That's a genuinely different failure mode than reviewing human-written code. A human author, when asked "why did you do it this way," can usually explain their reasoning, even if the reasoning turns out to be flawed. When the "author" is a model and the human submitting the PR didn't necessarily follow every step of its reasoning, that explanatory chain can be missing entirely — which shifts what a reviewer actually needs to verify, from "does this match the author's stated intent" to "can anyone here actually explain why this code does what it does."
What the data actually shows about AI-generated code review
Beyond the qualitative community debate, there's real quantitative research on how AI-generated code changes review dynamics. A comparative study found that human reviewers exchange 11.8% more rounds of back-and-forth when reviewing AI-generated code compared to human-written code — a measurable, not just anecdotal, increase in review friction (arXiv preprint).
The same research examined a specific and revealing metric: how often AI reviewer suggestions actually get adopted into the codebase, compared to human reviewer suggestions. The gap is large — AI agent review suggestions were adopted at just 16.6%, versus 56.5% for human reviewer suggestions. Digging into why, the study found that over half of the unadopted AI suggestions were either outright incorrect or handled differently by the developer than the AI suggested — meaning AI review tools aren't just being ignored out of habit, a meaningful share of their suggestions genuinely don't hold up on inspection.
A separate, arguably more consequential finding comes from an Anthropic randomized controlled trial that recruited 52 (mostly junior) software engineers to learn a new Python library: the AI-assisted group finished about two minutes faster on average — a difference the researchers found was not statistically significant — but scored only 50% on a post-task knowledge quiz about what they'd just built, compared to 67% for the group that coded by hand, "the equivalent of nearly two letter grades" (Anthropic). That's a direct measurement of reduced understanding of your own submitted code — which is precisely the condition that makes traditional review (premised on an author who understands their own work) harder to conduct meaningfully.
The "generate and submit" anti-pattern
A detailed practitioner analysis names a specific, recurring failure pattern directly: "generate and submit," where a developer enables an AI coding tool's agent mode, lets it generate a large diff largely unsupervised, and submits a pull request with a minimal description — effectively turning code review into an audit of AI output rather than a discussion with an author about their design intent (Dev.to).
Reviewers on the receiving end of this pattern report discovering inconsistent patterns across the diff, missing error handling, and security gaps that a more deliberate, human-authored change would have been less likely to introduce in the first place — not because AI-generated code is inherently worse, but because the review the code received before reaching the reviewer (i.e., the author's own understanding of what they were submitting) was thinner than it would have been for hand-written code. The same analysis makes a specific accountability argument worth internalizing directly: submitting a pull request is still, functionally, a claim that "I believe this is production-ready" — that claim doesn't get weaker or transfer to the AI tool just because a model wrote more of the actual code.
A related, unresolved community debate asks the sharper version of this question directly: should the author of AI-generated code also be its reviewer, given that they didn't actually write the logic being reviewed themselves (Hacker News)? There's no settled consensus answer in the discussion — it's presented as a genuinely open structural question about how review responsibility should work once "author" and "the person who wrote the logic" are no longer reliably the same person.
Is AI-generated code eroding what developers actually learn?
A separate, more visible community complaint centers specifically on volume and review fatigue rather than correctness. One consultant reported observing at least eight separate companies embracing AI-generated code across coding, testing, and review itself, without a matching increase in review rigor to compensate — leading to a visible, described decline in overall code quality (Hacker News). A junior/mid-level-engineer-specific version of this concern shows up in the "generate and submit" analysis directly: less experienced engineers are increasingly treating AI output as inherently correct ("the AI is smarter than me"), which shifts more of the verification burden onto senior reviewers and directly increases review fatigue at the senior level.
There's a genuine debate, though, about whether AI code review tooling is itself part of the solution or part of the noise. One perspective argues there's an active "AI code review bubble" of low-value tooling — the argument being that a good reviewer, human or AI, should focus on functional correctness rather than getting lost in minor style or naming nitpicks, which is exactly where a lot of current AI review tools add volume without adding real signal (Hacker News). A separate, more optimistic community evaluation of eight different AI code review tools found real utility in catching bugs and style issues, but also identified a consistent weakness: these tools are comparatively weak at spotting duplicate code, cross-module coupling, and separation-of-concerns problems — architecture-level issues that still require a human's broader view of the codebase to catch reliably (Hacker News; Hacker News).
GitLab's own engineering handbook offers a useful reframe of what's actually at stake here: code review's core purpose has always been knowledge-sharing and team education at least as much as it's been bug-finding, and AI-generated code disrupts that specific function because there's no author on the other end to learn from or ask about intent — the review can catch a bug, but it can't transfer understanding from an "author" who didn't fully form that understanding themselves (GitLab Handbook).
Practical examples
– Real, quantitative finding: the 11.8% increase in review rounds for AI-generated code versus human-written code, measured directly in comparative research rather than reported anecdotally (arXiv preprint).
– Real, quantitative finding: the 16.6% vs. 56.5% adoption gap between AI and human reviewer suggestions, with over half of unadopted AI suggestions found to be incorrect or handled differently (arXiv preprint).
– Real, documented pattern (not one company): the "generate and submit" anti-pattern, where large, minimally-described AI-generated diffs get submitted for review with less upstream understanding behind them than a hand-written change would typically carry.
– Illustrative, not a documented single case: picture a senior engineer reviewing a 400-line AI-generated PR with the description "added user export feature." They ask the submitter why a specific edge case was handled a certain way, and the submitter — who prompted the AI but didn't write the logic — can't answer without going back to ask the AI itself. This is consistent with the documented "generate and submit" pattern above, not a specific verified incident.
Data and evidence
– 11.8% more review rounds for AI-generated code vs. human-written code, per comparative research (arXiv preprint).
– 16.6% adoption rate for AI agent review suggestions vs. 56.5% for human reviewer suggestions — AI suggestions are adopted at less than a third the rate (arXiv preprint).
– Over half of unadopted AI review suggestions were incorrect or handled differently by the developer, per the same study (arXiv preprint).
– Developers using AI coding tools scored 50% on a post-task knowledge assessment, versus 67% for a non-AI control group — finishing about two minutes faster on average, though that speed difference was not statistically significant, per Anthropic's 52-developer randomized controlled trial (a separate study from the arXiv code-review research above).
– At least 8 companies observed by one consultant adopting AI-generated code across coding, testing, and review without a matching increase in review rigor (Hacker News).
– An independent evaluation of 8 AI code review tools found real strength in bug/style detection but a consistent weakness in catching duplicate code, cross-module coupling, and separation-of-concerns issues (Hacker News).
– Evidence not sufficiently verified: there's no single, industry-wide, longitudinal study in the sources reviewed tracking whether overall software defect rates have risen or fallen since AI coding tools became widespread — the evidence here is about review friction, suggestion-adoption, and knowledge-retention specifically, not a settled verdict on end-to-end code quality or defect rates.
Comparisons: AI review tools vs. human reviewers
Dimension: Suggestion adoption rate · AI review tools (e.g., CodeRabbit, Copilot-style reviewers): 16.6% (arXiv preprint) · Human reviewers: 56.5% (arXiv preprint)
Dimension: Strength · AI review tools (e.g., CodeRabbit, Copilot-style reviewers): Bug detection, style/consistency issues (Hacker News community evaluation) · Human reviewers: Architecture-level issues: duplicate code, cross-module coupling, separation of concerns
Dimension: Weakness · AI review tools (e.g., CodeRabbit, Copilot-style reviewers): Comparatively weak at architecture-level, cross-file issues · Human reviewers: Slower, doesn't scale to review volume the same way AI tools do
Dimension: Best current framing · AI review tools (e.g., CodeRabbit, Copilot-style reviewers): A first-pass filter/assistant, not a replacement for human judgment on non-trivial changes · Human reviewers: Still necessary for the knowledge-sharing and architectural-judgment functions AI tools don't reliably cover
The comparison isn't really "AI vs. human review" as competing options — the evidence supports using both, with AI review tools filtering for the issue types they're demonstrably good at (bugs, style), while human review remains the layer that catches what AI tools consistently miss and that preserves code review's knowledge-sharing function.
Real-world use cases
The eight-company observation from the consultant cited above is a genuinely useful real-world signal specifically because it's cross-company: the same underlying pattern (AI-generated code volume increasing without a matching increase in review discipline) showing up independently across multiple, presumably unrelated organizations suggests this is closer to a structural adoption-speed problem than an isolated management failure at any one company.
The independent, hands-on comparison of eight AI code review tools is a second concrete real-world reference point, useful specifically because it's a practitioner's direct evaluation rather than vendor marketing: tools like Kodus, CodeRabbit, and Qodo Merge are specifically noted as more useful when they learn from a team's existing review patterns, rather than applying generic, one-size-fits-all checks that generate noise without matching a team's actual standards (Hacker News).
Common mistakes
– Treating an AI-generated PR's minimal description as sufficient context for review. The "generate and submit" pattern specifically breaks down when the description doesn't capture the reasoning a reviewer needs to evaluate the change meaningfully.
– Assuming AI review tools catch what human reviewers used to catch. The documented weakness in duplicate code, cross-module coupling, and separation-of-concerns detection means architecture-level review still needs a human.
– Letting junior engineers treat AI output as inherently correct without verification, which the "generate and submit" analysis specifically flags as shifting more burden onto senior reviewers and increasing fatigue there.
– Adding AI review tooling to increase volume of feedback without checking whether it's adding signal or just noise. The "AI code review bubble" critique specifically targets tools that generate minor nitpicks rather than functional-correctness findings.
– Assuming the PR author fully understands code an AI generated on their behalf. The measured 50% vs. 67% knowledge-assessment gap suggests this assumption is often wrong, which changes what a reviewer needs to verify in conversation, not just in the diff.
Best practices for reviewing AI-assisted code
1. Require the PR author to explain the reasoning behind non-trivial AI-generated logic in the description or in review, not just describe what the change does — this directly targets the "author doesn't understand their own submission" problem the data shows is real.
2. Use AI review tools as a first-pass filter for bugs and style issues, not a substitute for human review of architecture-level concerns, given the documented gap in what each catches well.
3. Budget for more review rounds on AI-generated code, not fewer, given the measured 11.8% increase in back-and-forth — treating AI-assisted PRs as faster to review across the board isn't supported by the data.
4. Push back on large, minimally-described AI-generated diffs specifically, since this is the exact "generate and submit" pattern documented as degrading review quality and increasing hidden risk (inconsistent patterns, missing error handling, security gaps).
5. Treat AI review tool suggestions with the same scrutiny as any other automated linting output, given the 16.6% adoption rate and the finding that over half of unadopted suggestions are simply wrong — don't assume an AI reviewer's flag is correct by default.
6. Preserve code review's knowledge-sharing function deliberately, per GitLab's framing — ask the "author" direct design-intent questions even when they used an AI tool, since that conversation is how a team keeps shared understanding of its own codebase alive.
Key takeaways
– AI-generated code requires 11.8% more rounds of reviewer back-and-forth than human-written code (arXiv), and a separate Anthropic RCT found developers score notably lower (50% vs. 67%) on post-task knowledge assessments of code they built with AI assistance.
– AI reviewer suggestions are adopted at less than a third the rate of human reviewer suggestions (16.6% vs. 56.5%), with over half of unadopted AI suggestions found to be incorrect — treat AI review tool output as a first-pass filter, not a verdict.
– The "generate and submit" anti-pattern — large, minimally-described AI-generated diffs submitted for review — is a specifically documented, recurring cause of degraded review quality across multiple companies.
– AI review tools show real strength at catching bugs and style issues but a consistent, documented weakness at architecture-level concerns like duplicate code and cross-module coupling — human review remains necessary for that layer.
– Code review's core function has always included knowledge-sharing, and AI-generated code disrupts that specifically because the "author" may not fully understand their own submission — a gap teams need to actively address, not just accept.
Relevant tools.scult.in resources
The Claude Code, Cursor, GitHub Copilot, and DevOps prompt libraries are a practical place to build the kind of design-intent-first prompting habits this article suggests reviewers should be asking for — prompts that force the reasoning to be spelled out upfront tend to produce PRs that are actually easier to review afterward.
If your team is weighing how to structure review process, escalation, and verification checkpoints around growing AI-generated code volume — the exact set of tradeoffs this article covers — that's a scoping conversation worth having with a team that builds AI agents and automation workflows for a living.
Frequently asked questions
How do you review code in the age of AI?
Traditional criteria (readability, correctness) alone are proving insufficient, since AI-generated code can pass both while following logic that's subtly incorrect or unfamiliar to everyone involved — reviewers increasingly need to verify the reasoning behind the code, not just its surface behavior.
Does AI-generated code need more review rounds than human-written code?
Yes — comparative research found 11.8% more rounds of reviewer back-and-forth for AI-generated code versus human-written code.
Who is responsible for bugs in AI-generated code?
Submitting a pull request functions as a claim that the change is production-ready regardless of what tool wrote the code — accountability doesn't transfer to the AI tool.
Is code review still necessary with AI coding tools?
Yes — if anything, the evidence suggests it's needed more, given increased review friction on AI-generated code and AI review tools' documented weaknesses at architecture-level issues.
What tools are people using for human review of AI-assisted code?
Community discussion names CodeRabbit, Copilot's review features, Kodus, and Qodo Merge, with mixed but generally positive assessments of their bug/style detection, and a shared noted weakness on cross-module and architecture-level issues.
Is there an "AI code review bubble" of low-value tooling?
Some practitioners argue yes — that many current AI review tools focus on minor style/naming nitpicks rather than functional correctness, adding volume without adding real signal.
Should the author of AI-generated code also be its reviewer?
This is an actively debated, unresolved question in the developer community — the core tension is that the "author" submitting the PR may not have actually written or fully understood the underlying logic themselves.
What is the "generate and submit" anti-pattern?
A workflow where a developer lets an AI coding tool generate a large diff largely unsupervised and submits it with a minimal description, turning review into an audit of AI output rather than a discussion of the author's design intent.
Does AI-generated code need its own AI reviewer?
Some industry commentary argues yes, framing AI review platforms as an automated "senior engineer" layer for security, race conditions, and performance — shifting the human developer's role toward editor/validator rather than original author.
Do AI reviewer suggestions actually get adopted into codebases?
At a much lower rate than human reviewer suggestions — 16.6% versus 56.5%, with over half of unadopted AI suggestions found to be incorrect or handled differently.
Does relying on AI coding tools reduce what developers actually learn?
An Anthropic randomized controlled trial with 52 developers found the AI-assisted group finished tasks about two minutes faster on average (not a statistically significant difference) but scored only 50% on a post-task knowledge assessment, versus 67% for a control group without AI — a measurable retention/understanding gap.
What's the best AI code review tool right now?
Community evaluation points to tools like Kodus, CodeRabbit, and Qodo Merge as useful specifically when they adapt to a team's existing review patterns rather than applying generic checks.
Is code review's real purpose bug-finding or knowledge-sharing?
Practitioners and GitLab's own engineering handbook frame it as having always been about knowledge-sharing and education at least as much as bug-finding — a purpose that AI-generated code disrupts, since there's no fully-informed human author to learn from.
Are junior developers treating AI coding tools as "magic wands"?
Yes, per practitioner observation — junior/mid-level engineers increasingly treat AI output as inherently correct, which shifts more verification burden onto senior reviewers.
What are AI review tools good at compared to human reviewers?
Bug detection and style/consistency issues, per a hands-on community evaluation of multiple tools.
What are AI review tools weak at compared to human reviewers?
Duplicate code, cross-module coupling, and separation-of-concerns issues — architecture-level problems that require a broader view of the codebase.
Is there quantitative research on how AI changes code review dynamics, or is it all anecdotal?
There is quantitative research — a comparative arXiv study specifically measured review-round increases, suggestion-adoption rates, and knowledge-assessment scores — alongside the extensive anecdotal community discussion.
What does GitLab's engineering handbook say about AI and code review's purpose?
It frames code review's core purpose as knowledge-sharing and education, and notes that AI-generated code disrupts this because there's no author present to learn from or question about intent in the same way.
Why might senior engineers feel more review fatigue since AI coding tools became widespread?
Because junior engineers increasingly submit AI-generated code they haven't fully verified themselves, shifting more of that verification burden onto senior reviewers.
Are there documented real cases of AI-generated code quality declining across companies?
Yes — one consultant reported observing this pattern independently across at least eight separate companies, tied specifically to AI-code adoption outpacing review-rigor adjustments.
How do I review pull requests written by Claude Code or Cursor?
Ask the submitting engineer to explain the reasoning behind non-trivial sections directly, treat AI review tool flags as a first-pass filter rather than a final verdict, and budget for more review rounds than you would for an equivalent human-written change.
How do I set code review standards for an AI-assisted team?
Require PR descriptions that capture design reasoning (not just what changed), explicitly assign architecture-level review to a human rather than relying on AI review tools for it, and track review-round counts to catch review-friction increases early.
How do I avoid the "generate and submit" anti-pattern on my team?
Set an expectation that large AI-generated diffs need a PR description explaining the reasoning, not just the outcome, and push back on submissions where the author can't explain a specific design choice when asked directly.
How do I know if my team's code quality is declining due to AI-generated code specifically?
Track review-round counts, defect rates post-merge, and whether authors can explain their own AI-assisted submissions in review — a rising trend in any of these, correlated with AI tool adoption, is a useful early signal.
How do I use AI code review tools without letting them add noise instead of signal?
Configure them to flag functional-correctness issues and known weak spots (bugs, security, style consistency) rather than treating every minor nitpick suggestion as equally worth a reviewer's attention.
How do I make sure my team still learns from code review despite AI-generated code?
Deliberately ask "why" questions about design decisions in review, regardless of whether AI helped write the code, to preserve the knowledge-transfer function code review has traditionally served.
How do I decide whether to trust an AI reviewer's suggestion?
Treat it with the same scrutiny you'd apply to any other automated linting output — verify it against your actual understanding of the code rather than assuming correctness, given the documented 16.6% adoption rate and high rate of incorrect suggestions.
How do I train junior engineers to review AI-generated code critically instead of trusting it by default?
Explicitly address the "the AI is smarter than me" assumption in onboarding or mentoring, and require junior engineers to explain the reasoning behind AI-suggested code before submitting it, not just confirm it runs.
How do I measure whether my team's code review process is keeping up with increased AI code generation?
Track review-round counts and time-to-merge trends specifically for AI-assisted PRs versus historical human-written baselines, using the documented 11.8% review-round increase as a reference point for what "normal" now looks like.
How do I balance review speed with the added scrutiny AI-generated code appears to need?
Accept that AI-assisted development may not actually speed up the full development cycle once increased review rounds are factored in, and plan review capacity accordingly rather than assuming AI-generated code review takes the same time as reviewing human-written code.
Is there a standard framework yet for how much AI involvement in a PR needs to be disclosed to reviewers?
No industry-standard disclosure framework was found in the sources reviewed; some teams are informally adopting PR description conventions noting AI involvement, but this isn't yet a settled or universal practice.
Does pair programming with an AI tool count as "pair programming" in the traditional sense reviewers should account for?
The comparison is imperfect — traditional pair programming involves two people who both understand the reasoning in real time, while AI pair programming can leave the human partner without that same depth of understanding, which is part of why review needs may differ.
Is there research on whether AI-assisted code has more security vulnerabilities than human-written code specifically?
The "generate and submit" analysis specifically names missing error handling and security gaps as recurring issues reviewers discover in that anti-pattern, but this research didn't find a rigorously quantified vulnerability-rate comparison between AI-generated and human-written code specifically.
Do different AI coding tools (Claude Code, Cursor, GitHub Copilot) produce code that needs different review approaches?
A direct comparison (Builder.io) describes differences in how these tools handle diffs and workflow, but this research didn't find data specifically isolating differential review burden by tool — the general findings in this article (more review rounds, lower AI-suggestion adoption) apply broadly across AI-assisted development rather than to one specific tool.
Is the code review fatigue problem worse at companies moving fastest on AI adoption?
This is a plausible inference from the "at least 8 companies" observation and the general pattern described, but this research didn't find a study directly correlating AI-adoption speed with measured review fatigue across a larger sample.
AI code review vs. human code review — which is more accurate?
Neither is strictly "more accurate" — AI review tools are documented as strong on bugs and style, human reviewers stronger on architecture-level issues (duplicate code, coupling, separation of concerns); the evidence supports using both rather than choosing one.
Claude Code vs. Cursor code review workflow — how do they differ?
A direct comparison describes differences in diff presentation and agent-mode workflow between the two tools, though this research didn't find a quantified difference in resulting review burden specifically attributable to one tool versus the other.
AI reviewer vs. senior engineer review — which catches more real bugs?
Available evidence suggests AI reviewers are genuinely useful for catching certain bug classes and style issues, but senior engineers remain necessary for architecture-level review that AI tools are documented as weaker at.
Is AI-generated code technical debt worse than traditionally-accrued technical debt?
This research didn't find a direct, quantified comparison between "AI-generated technical debt" and traditional technical debt; the "generate and submit" pattern describes a mechanism by which AI-generated debt can accumulate faster if review rigor doesn't keep pace, but a formal severity comparison wasn't found here.
Is "AI slop" pull requests a widely recognized term, or is it niche jargon?
It appears in community discussion (e.g., the "sick of AI splattered code" Hacker News thread) as informal but recognizable shorthand for large volumes of AI-generated code submitted without matching review rigor — not a formal industry term, but a widely understood one in developer circles.
Our team's PR review times have doubled since we started using AI coding tools heavily — is that normal?
It's directionally consistent with the documented 11.8% increase in review rounds for AI-generated code, though a full doubling would be a larger effect than that specific study measured — worth investigating whether PR size or description quality (the "generate and submit" pattern) is compounding the effect further.
Our reviewers keep rejecting suggestions from our AI code review tool — is the tool broken?
Not necessarily — the documented adoption rate for AI reviewer suggestions industry-wide is just 16.6%, with over half of unadopted suggestions found to be genuinely incorrect, so a low acceptance rate is consistent with normal AI reviewer tool behavior rather than a sign of malfunction.
Junior engineers on our team keep submitting AI-generated code they can't explain — how do we fix this?
Set an explicit expectation that PR authors must be able to explain the reasoning behind non-trivial logic in review, regardless of what tool helped write it, and treat an inability to do so as a signal the change needs more upstream understanding before merge.
We're seeing more inconsistent patterns and missing error handling since adopting AI coding tools — is this expected?
Yes — this matches the specific failure signature the "generate and submit" anti-pattern analysis describes, and the fix is typically requiring more upfront design discussion and smaller, better-described diffs rather than abandoning AI tools entirely.
Our senior engineers are burning out from reviewing AI-generated code — what can we do?
Address the volume-vs-rigor mismatch directly: either slow the rate of unreviewed-by-the-author AI code entering the pipeline, or add a documented step (like requiring authors to explain reasoning) that shifts some verification burden back to the PR author before it reaches senior review.
What's the best AI PR reviewer tool for a small team?
Rather than a single universal answer, community evaluation suggests choosing a tool that learns from your team's existing review patterns (named examples include Kodus, CodeRabbit, and Qodo Merge) rather than one applying generic, one-size-fits-all checks.
Is it worth paying for a dedicated AI code review platform, or is built-in tooling (like GitHub Copilot's reviewer) enough?
This depends on your team's specific pain points — if architecture-level issues (duplicate code, coupling) are your main concern, no AI review tool reviewed here fully solves that; if bug/style catch rate is the goal, several dedicated and built-in tools show real utility per community evaluation.
Should we slow down AI coding tool adoption until our review process catches up?
The evidence supports at minimum adjusting review process and capacity expectations in step with AI tool adoption, given the documented increase in review rounds needed — whether that means slowing adoption or scaling review capacity is a team-specific tradeoff.
How do we set realistic expectations with leadership about AI coding tools' actual impact on delivery speed?
Share the review-round data directly — a documented 11.8% increase in review rounds for AI-generated code means the net effect on end-to-end delivery speed may be smaller than raw code-generation speed alone would suggest.
Where can I get help designing a code review process that actually accounts for AI-assisted development?
That's a process and workflow design question worth bringing to a team that builds AI agents and automation systems for a living, since the same core tradeoffs — autonomy, verification burden, and where human judgment stays load-bearing — apply directly to designing a review process around AI-generated code.
Sources
- https://news.ycombinator.com/item?id=44067019
- https://news.ycombinator.com/item?id=49321400
- https://news.ycombinator.com/item?id=45278819
- https://news.ycombinator.com/item?id=43857643
- https://news.ycombinator.com/item?id=46766961
- https://news.ycombinator.com/item?id=43938241
- https://dev.to/sizan_mahmud0_e7c3fd0cb68/the-hidden-cost-of-ai-coding-tools-why-generate-and-submit-is-destroying-code-quality-46o
- https://bdtechtalks.substack.com/p/your-ai-coding-assistant-now-needs
- https://arxiv.org/pdf/2603.15911.pdf
- https://handbook.gitlab.com/handbook/engineering/ai/code-creation
- https://www.builder.io/blog/cursor-vs-claude-code
- https://www.anthropic.com/research/AI-assistance-coding-skills
Need this built into your business?
The free tools and prompts on this site handle the small, solved problems. If what you need is bigger — AI agents & automation, built and maintained for you — that's Scult's day job.
