The problem is especially familiar in solo projects: I may guide an implementation and then be the person responsible for reviewing it. Knowing what I intended to build is useful context, but it can also make me less likely to question my assumptions. After a long implementation session, I still need to inspect the result with enough attention to catch security issues, broken business rules, and unexpected changes.

That concern is part of a broader engineering conversation. Martin Fowler distinguishes agentic programming, where a developer reviews the agent’s work, from “vibe coding,” where the code may not be inspected. In either case, someone remains accountable for how the software behaves. Fowler, “Agentic Programming”

The review burden is becoming more visible

In Sonar’s 2026 State of Code survey, 38% of 1,149 respondents said reviewing AI-generated code took more effort than reviewing code written by colleagues; 48% said they always checked AI-assisted code before committing. These are self-reported survey results from a code-quality vendor, not an independent measurement of review time, but they suggest the verification burden is a practical concern beyond my own workflow. Sonar, State of Code Developer Survey 2026

Practitioners have described the same tension. Thoughtworks’ Birgitta Böckeler recommends carefully reviewing generated code and pausing when an agentic coding session becomes overwhelming. Her examples include misunderstood requirements, unnecessary complexity, and changes that could create maintenance costs later. Böckeler, “The role of developer skills in agentic coding”

In a separate migration case, Thoughtworks’ Rahul Ramesh describes code review as a significant part of the work, even when generation itself was fast. He notes that an AI reviewer may identify syntax or common practices, while intent and business rules still need human confirmation. That distinction matters: code can be locally plausible and still violate what the system is supposed to do. Ramesh, “Research, Review, Rebuild”

There is also research on cognitive bias and decision fatigue in code review. Jetzen and co-authors designed prototypes to address these concerns, but describe their work as an early step, not proof that a particular tool eliminates bias or fatigue. The specific case of a developer reviewing their own AI-assisted change deserves careful framing: it is a real concern in my experience, not a universal result established by that paper. Jetzen et al., “Towards debiasing code review support”

The goal is to direct human attention

A review skill should help answer a narrower question than “Is this code good?” It should help the reviewer see which parts of a change deserve closer inspection, why they matter, and what context is still missing.

The AI Code Review Triage skill follows that approach. It starts by establishing the intended behavior and review scope, then traces consequential changes through relevant code paths. It prioritizes risks such as authorization boundaries, core business rules, data integrity, failure handling, and concurrency when those categories apply.

For a candidate finding, the skill asks for evidence, a trigger, a concrete consequence, and a focused way to verify it. If a claim depends on a business rule that is not in the available context, it should be presented as a question for the domain owner rather than as a confirmed defect.

Google’s AutoCommenter research offers a useful precedent for scoped AI assistance in code review: the system focuses on programming-language practices and was evaluated at industrial scale. That is different from claiming that a model can infer a system’s business intent or approve a change. Google Research, “AI-assisted Assessment of Coding Practices in Industrial Code Review”

A second reader, not an approval bot

When I review my own change, I already know the story I meant to implement. I want the skill to push me back toward the evidence in the code: what changed, which paths it affects, what assumptions it relies on, and what still requires domain judgment.

That can help organize the review, but it cannot guarantee that every issue will be found. A narrow, evidence-based report can still miss a risk when the relevant context is absent. A long list of generic warnings can also consume attention instead of focusing it. The skill therefore avoids treating “no actionable findings” as approval and calls out validation gaps separately.

A useful triage step should complement tests, static analysis, security scanning, and human review. It is most valuable when it helps a reviewer spend limited time on consequential behavior rather than repeating generic style advice.

Keeping review practice sharp

Reviewing real changes is where triage matters. But staying sharp also means practicing on code that is unfamiliar and low stakes. I built One Diff a Day for that: a daily review game with a quick diff for low-energy days and a deeper challenge when I have more time.

That deliberate exposure is a complement to review triage, the skill focuses attention on a real change, while the game keeps the habit of reading unfamiliar code active.

--

The broader trade-off is straightforward. Faster code generation can increase the amount of code that needs to be understood. Triage may make the review more focused, but the reviewer remains responsible for security boundaries, domain rules, and whether the change is fit to merge. The skill’s job is to make those questions harder to overlook.