PyTorch's playbook for AI coding, as of May 2026 — PyTorch DevLogPyTorch's playbook for AI coding, as of May 2026<br>Edward Yang (@ezyang) ·<br>May 30, 2026<br>· 9 min read<br>ai-agentscode-reviewossllm<br>One of the important topics being discussed among the PyTorch team is how the<br>PyTorch codebase should engage with AI coding agents. Today, many PRs to<br>PyTorch are AI-authored, and there have been obvious growing pains as we&rsquo;ve<br>figured things out. Based on discussions at the most recent PyTorch compiler offsite<br>(May 2026), I&rsquo;ve assembled this playbook for AI coding in PyTorch. It is half<br>descriptive, half prescriptive: it is trying to codify practices that are<br>being used among some members of the team, and bring everyone else along.<br>Hopefully, this post is just the beginning of our ongoing conversation about<br>how to engage with AI coding agents.<br>Norms for AI coding<br>We can think of AI generated code as living in a spectrum, where on one hand<br>we have code that is almost exactly the same as human code, except that it was<br>typed by an AI, and on the other hand completely vibe-coded software which has<br>never been read by a human.<br>PyTorch is production software, used and relied upon by many people. We have<br>a duty to our users to ensure that the code we ship is correct, understandable<br>and maintainable. We think that SOTA coding agents can help us build better<br>software than we could have built purely by hand today, but they present us<br>with novel situations that require adapting our old rules. We think different<br>norms are required depending on where code lives on the spectrum.<br>As a substitution for human written code<br>On the most conservative end, we are adding AI coding but trying to keep as<br>many other aspects of the process fixed. The human should read every line of<br>code. You are responsible for every line of code.<br>Not everything stays the same though. We propose these new norms:<br>In an age of cheap code, we are human review bottlenecked. Authors should<br>work hard to make code review easy. Think about what information your<br>intended reviewer needs and write it down (an AI written commit message is<br>good for completeness, but the LLM is unlikely to know what your reviewer<br>knows and doesn&rsquo;t know). If a PR is big, make sure that there is a coherent<br>order to engage with the change and write down the &ldquo;read order.&rdquo; Don&rsquo;t mix<br>unrelated or cosmetic changes with semantic changes; ask an LLM to separate<br>these out.

It is extremely tempting to ask an AI agent to directly respond to code<br>review comments. Because we believe in human understanding on this end<br>of the spectrum, we think it is important for humans to engage in dialog<br>in review comments. If a human spent time to write a question, they deserve<br>a human response in return.<br>On the flip side, many traditional questions one might ask in code review<br>can be easily answered by an AI agent. Code reviewers should consult AI<br>first, only escalating unresolved questions to humans. You can use<br>@claude on GitHub, or check out a PR locally and use your coding agent<br>locally on it for questions.

It is OK to use a coding agent to autonomously fix code review comments<br>(especially nits), but you are still responsible for reading and owning all<br>the fixes. This especially includes checking that the comment was actually<br>fixed!

Consider asking to directly edit someone else&rsquo;s code. You should ask the<br>author first before, e.g., pushing a commit, but with AI agents this is a very<br>compact way to transmit small nitty feedback that would have been fed<br>straight into an AI agent anyway. It is also a good way to communicate more<br>dramatic changes that would take more time to explain in text–an AI agent<br>can expand text into code and help you verify that the intent of your text<br>is clear. The original author still has to read and take ownership of these<br>changes.

Mass AI PRs<br>Mass AI PRs are when we use agents to generate many PRs in parallel; e.g.,<br>using agents to burn down issues on an issue tracker. Many bugs are not<br>individually important enough for a human to dedicate a few days fixing, but<br>in aggregate, fixing bugs is important, and AI coding agents are a big<br>opportunity to kill low hanging fruit (in the same way AI agents are really<br>good at discovering security vulnerabilities.)<br>The general ask here is that we should have high-level agreement that these<br>fixes, in aggregate have an ROI that justifies the human time spent on it.<br>While the operator of the agent swarm is responsible for doing initial<br>reviews, guiding it and improving it based on feedback, a mass of AI PRs will<br>increase reviewer burden. The point is to have agreed that this review burden<br>is worth it!<br>Well-encapsulated unreviewed code<br>As of today, we do not accept unreviewed AI generated code (aka slop) to the<br>main pytorch/pytorch repo. However, we think the capability of SOTA models<br>today enables the creation of systems that otherwise could not have existed (e.g., via hill climbing.) We have several live...