Moyai - Monitor you agents for failures
Stop guessing if your agents are failing and start monitoring them for failures. We surface agent failures by looking for behavioural anomalies your your agent traces and classify failures with RCA and remediation steps.
Works on your existing observability stack, no new SDK required.
Or book a call with the founder
✍️ From the editor’s desk
Welcome to the 61st issue of Deep Engineering!
On 21 August, Niruthiha Selvanayagam and Taher A. Ghaleb posted a study of 248,641 AI-attributed pull requests that received at least one AI-attributed review. Among pairs with complete, nonnegative timestamps, the observed median first-review latency was 1.2 minutes across products and 4.7 minutes within the same product. The authors caution that timestamp availability and reviewer composition limit the comparison, but both figures show how quickly automated feedback can enter the workflow.
That speed solves only the waiting problem, because an agent can inspect a change and propose a fix without owning the decision to merge. When an engineer accepts code they did not write line by line, the human reviewer has a different job. They still need to verify the intent, weigh the architecture against the team’s history, and decide whether the change belongs in the codebase at all.
Sándor Dargó has been working inside that shift rather than observing it from a distance. He is a Senior Engineer at Spotify who works primarily in C++, writes at sandordargo.com about software design and code review, and now writes very little code by hand himself. His practical deep dive explains why a bad pattern becomes a future instruction for an agent, why review comments still need context, and how his AIR formula turns a vague objection into something another engineer can act on and learn from.
Let’s get started.
Thor.ai — Context for Coding Agents
Thor keeps one current, sourced record of what is true across your tools, so your coding agents are never working from a stale spec.
🧠 Practical Deep Dive
Fix This Is Not Enough, Even When an Agent Wrote the Code
by Sándor Dargó, Edited by Saqib Jan
Two words that make your brain do three jobs
Fix this.
Have you ever received a code review comment that said only that? I have, probably more times than I would like to admit. The thing about a comment like fix this is that it is not really about the code. By the time you have finished reading those two words, your brain has already done at least three different things.
You try to figure out what is wrong. You try to figure out why they did not tell you what is wrong. And if we are honest, there is a third one, because you have probably already started wondering whether you are an idiot, since someone had to leave a comment like that in the first place. That is a lot of work for two words.
So this is the subject I care about. Not formatting, tooling, or the technical mechanics of pull requests. The conversation between people. Even with AI writing more of our code and reviewing more of our pull requests, those conversations still matter. I think they matter more than ever, not less.
Code reviews are about people, and I say that as someone who barely writes code by hand
I have to admit something. I do not think I have written a single line of code by hand since November last year. I might be exaggerating a little, because sometimes the AI really does not get it right and you go in and change it yourself. But even then, you are more likely to say, this is what I actually meant, use this. It is rare that I start writing code manually now, unless I am doing it for my own enjoyment.
Even in this environment, or maybe especially in this environment, code reviews are often a cause of stress and conflict between people. Done well, they do the opposite. They amplify learning, build trust, and improve the quality of what you ship.
A bad pattern that gets merged will be copied by your agents
Code reviews are three things at once. Quality assurance, knowledge sharing, and collaboration.
As quality assurance, a review is a safety net. Not the ultimate safety net, just one of them. It catches inconsistencies, maintains standards, and helps enforce architectural patterns. I said I would not talk about style, and I do not mean formatting here. I mean architectural style, which AI agents still find difficult to get right and difficult to review. They are getting better. They are not there yet.
The part I want to emphasize is catching issues before they get merged and spread through the code. If you accept something that goes against your architectural patterns, the next time an agent may do the same thing because it has already found an occurrence in the codebase. It sees a pattern, so it follows it.
That is why reviewing code manually matters now, probably more than ever. If anything bad goes in, it spreads. Even when you have to accept some technical debt, it is worth paying it off quickly.
AI has already changed how we review
A review is the last line of defense. It is essential for the long-term health of your codebase, and after the automation and a long CI pipeline, it is often the final human check before code gets merged, assuming your organization still has one.
AI helps, and I think it will help more. It is not enough yet. Human insight still catches what machines cannot, especially the context of a large project, architectural constraints, and historical knowledge that is not documented anywhere in the codebase.
AI has already changed how we review. As pull request volume grows, you cannot keep pace by reviewing every change manually, and that itself becomes a source of stress. A growing share of those pull requests are partly or fully AI-generated, and you can only hope that the author reviewed what was generated and understands what the code does.
Many teams, perhaps most, now have an AI reviewer involved in pull requests. It is not a replacement yet. The question is not whether AI changes code reviews. It already has.
Reviews also give you a fresh perspective, which matters even more once agents write the first draft. Author bias is real. When you write code, you miss your own mistakes, just as you can miss errors in a letter you wrote and then read back. Hand it to someone else and they may spot the mistake faster.
What is obvious to you, already inside the context of the change, may not be obvious to anyone else. Reviewers have to build their own mental model, and they may reach a different conclusion from that model. That difference is exactly the thing worth sharing in a review. They can question assumptions and point out edge cases you forgot.
Reviewing AI-authored code is a different job
The author probably did not write every line. They accepted every line, hopefully after a thorough review of their own. Confident-looking code can hide a shallow understanding of what it does.
So why did you do it this way? is now a first-class review question rather than a nitpick. It can lead to an important discussion, and it can reveal that not much was considered because the code was generated quickly and the person wanted to move fast, often for perfectly valid reasons. As a reviewer, you increasingly verify intent, not just implementation.
That is also the answer to what we are actually reviewing. Syntax validity is mostly the compiler’s job. As a reviewer, you make sure the change matches the intention of the team and should be shipped at all, because every piece of code is a liability that someone has to maintain. Even when that someone is an agent, the agent has costs.
Then you make sure the architecture is right. Once something is in your codebase, an agent will recognize it as a pattern to follow, so you want as few bad examples there as possible. If you use bots, you can give them different tasks. Verify the syntax, verify that the code is modern, verify that edge cases are covered, and verify the architecture as long as your architecture is documented. The actual intent stays completely human.
Fix This Is Not Enough, Even When an Agent Wrote the Code
The full deep dive continues with the forms of review, the arguments against dedicated reviews, Sándor’s multi-agent experiment, the failure modes that slow teams down, and the AIR formula with three worked examples.
Featured Newsletter - C++ Doctor
Weekly C++ insights, practical examples, code challenges, and curated resources for more than 1,600 developers.
🛠️ Tool of the Week
PR-Agent is a community-maintained open-source reviewer that deploys through GitHub Actions, webhooks, Docker, or a local CLI.
Run
/review,/improve,/describe, and/askseparately, so automation follows the team’s review policy.Feed
AGENTS.mdand repository settings into reviews, keeping feedback closer to local conventions and architecture.Deploy across GitHub, GitLab, Bitbucket, Azure DevOps, or Gitea through Actions, webhooks, Docker, or CLI.
Choose hosted or local models through LiteLLM while keeping prompts and orchestration under the team’s control.
📎 Tech Briefs
GitLab 19.3 lets Duo resolve review discussions - Duo now edits the source branch, summarizes the change, and closes the review thread automatically.
GitHub makes the rule insights dashboard generally available - Owners can inspect rule evaluations and bypasses across repositories and organizations, making automated merge gates auditable.
Codex 0.150.0 blocks project instructions from untrusted projects - Untrusted projects no longer supply project-level
AGENTS.mdinstructions, reducing repository instruction injection risks during agent-assisted development.Azure Pipelines adds aggregated code coverage views - Teams can inspect aggregated coverage by folder, file, module, and build configuration before approving complex changes.
JetBrains measures how much code developers hand to agents - Survey results separate agent-generated, AI-assisted, and manual code, giving reviewers a clearer basis for ownership policies.
That’s all for today.
If this issue was useful, forward it to an engineer who reviews more pull requests than they write.
Keep building,
Saqib Jan - Editor-in-Chief, Deep Engineering
Partner with Deep Engineering
If your company wants to reach senior developers, software engineers, and technical decision-makers, speak to us about partnering with Deep Engineering.