CodeRabbit · Indexed content

AI coding tools and agents make it faster to produce code and open pull requests. As those requests accumulate, teams have to decide which changes need attention first. That starts with understanding what each PR needs next and who can move it forward. That is the problem we set out to solve with CodeRabbit Triage. We started by organizing the queue, but quickly realized it was only useful if we could clearly see where each PR stood. What a sorted list can’t tell you An inbox concept is a natural starting point for organizing a PR queue. Some tools group open pull requests into sections, giving reviewers one place to see work that needs their attention. We began with a similar approach, but our filters sometimes labeled PRs as needs review for people who had already approved them. We also surfaced approved PRs with merge conflicts as though they needed another review, even when the next step was for the author to rebase. Those PRs matched the filters we had written. The problem was what the label told the reviewer to do. Someone would open a PR expecting to review it, only to discover that the next action belonged to its author. Repeated mistakes like that give reviewers a reason t…

AI coding tools and agents make it faster to produce code and open pull requests. As those requests accumulate, teams have to decide which changes need attention first. That starts with understanding what each PR needs next and who can move it forward. That is the problem we set out to solve with [CodeRabbit Triage](https://www.coderabbit.ai/triage). We started by organizing the queue, but quickly realized it was only useful if we could clearly see where each PR stood. ## What a sorted list can’t tell you An inbox concept is a natural starting point for organizing a PR queue. Some tools group open pull requests into sections, giving reviewers one place to see work that needs their attention. We began with a similar approach, but our filters sometimes labeled PRs as needs review for people who had already approved them. We also surfaced approved PRs with merge conflicts as though they needed another review, even when the next step was for the author to rebase. Those PRs matched the filters we had written. The problem was what the label told the reviewer to do. Someone would open a PR expecting to review it, only to discover that the next action belonged to its author. Repeated mista…

Before reviewers read a line of code, they have to decide which pull request deserves their attention. That choice gets harder when agents add work faster than teams can assess it and the queue offers little context about urgency, risk, or ownership. We built CodeRabbit Triage to bring that context into the queue, helping each reviewer identify where their attention is needed and what action will move the work forward. Code generation isn’t scarce anymore Agents can open pull requests faster than teams can review them. They also make it easier to try several implementations of an idea. Some engineering leaders are already asking whether creating issues makes sense when an agent can just open a PR. Cheap experimentation is a real gain, but it stops being cheap the moment it becomes a pull request. An unnecessary PR can consume investigation and review time even if it never merges. If it does merge, it carries maintenance obligations, regression risk, and architectural consequences that outlast the minutes it took to generate. Deciding which problems are worth solving remains upstream work, and agents don’t change that. What has changed is the volume and variety of proposed changes a…

Before reviewers read a line of code, they have to decide which pull request deserves their attention. That choice gets harder when agents add work faster than teams can assess it and the queue offers little context about urgency, risk, or ownership. We built [CodeRabbit Triage](https://www.coderabbit.ai/triage) to bring that context into the queue, helping each reviewer identify where their attention is needed and what action will move the work forward. %[https://youtu.be/Q-Rm7d8Rquk] ## Code generation isn’t scarce anymore Agents can open [pull requests](https://www.coderabbit.ai/blog/the-pull-request-lives-on-ai-gave-it-a-bigger-job) faster than teams can review them. They also make it easier to try several implementations of an idea. Some engineering leaders are already asking whether creating issues makes sense when an agent can just open a PR. <div data-tweet-id="2095516796748996843"><a href="https://x.com/taylorotwell/status/2095516796748996843"><img src="/content/assets/triage-pr-queue/taylor-otwell-pr-post.png" alt="Taylor Otwell explains that he disabled GitHub Issues on most Laravel open-source packages and now encourages people to describe bugs to coding agents and open…

Software factories can turn intent into tested code with very little human intervention. Agents pick up queued work, write and test the implementation, respond to findings, and prepare it for release. With enough sandboxes, tools, evaluators, and retries, much of the software production process can run on its own. Passing checks builds confidence in the behavior they cover, but the harder decision comes next. The code may work as specified, yet still introduce a poor boundary, an unexpected dependency, or more risk than the change is worth. The review gate is where teams decide not only if the code works, but also whether it should become part of the system. StrongDM has described a version of the software factory in which people define intent, scenarios, and constraints, then agents generate and validate the implementation without traditional human code review. That approach puts more responsibility on the validation harness. For teams building long-lived systems, a practical design rule applies. Review depth should follow the cost of error. Or, as Vercel’s CEO Guillermo Rauch puts it: Read the full post on X. That is not to say that every change requires a person to read every li…

Software factories can turn intent into tested code with very little human intervention. Agents pick up queued work, write and test the implementation, respond to findings, and prepare it for release. With enough sandboxes, tools, evaluators, and retries, much of the software production process can run on its own. Passing checks builds confidence in the behavior they cover, but the harder decision comes next. The code may work as specified, yet still introduce a poor boundary, an unexpected dependency, or more risk than the change is worth. The review gate is where teams decide not only if the code works, but also whether it should become part of the system. [StrongDM has described a version of the software factory](https://discover.strongdm.com/blog/the-strongdm-software-factory-building-software-with-ai) in which people define intent, scenarios, and constraints, then agents generate and validate the implementation without traditional human code review. That approach puts more responsibility on the validation harness. For teams building long-lived systems, a practical design rule applies. Review depth should follow the cost of error. Or, as Vercel’s CEO Guillermo Rauch puts it: [!…

Engineers develop taste by building software, seeing how people use it, and living with the consequences of technical decisions. That experience shapes what they notice, which approaches they favor, and what they believe deserves to become part of a system. Agentic workflows put pressure on that judgment. A proposed change can arrive with its implementation, tests, and explanation already prepared, while the engineers responsible are still establishing what it does. As the queue grows, they have less time to examine the choices behind each implementation. An accepted approach can also influence subsequent work. Agents draw on patterns already in the repository, so later changes may repeat a design the team gave little thought to when it first appeared. Over time, that choice can become a convention. As more design choices arrive already implemented, engineers can spend more of their time accepting or correcting proposals. They get fewer opportunities to explore alternatives, explain their preferences, and see how their own choices work in practice. Over time, that weakens the habits through which engineering taste develops. Teams can preserve those opportunities by making room to q…

Engineers develop taste by building software, seeing how people use it, and living with the consequences of technical decisions. That experience shapes what they notice, which approaches they favor, and what they believe deserves to become part of a system. Agentic workflows put pressure on that judgment. A proposed change can arrive with its implementation, tests, and explanation already prepared, while the engineers responsible are still establishing what it does. As the queue grows, they have less time to examine the choices behind each implementation. An accepted approach can also influence subsequent work. Agents draw on patterns already in the repository, so later changes may repeat a design the team gave little thought to when it first appeared. Over time, that choice can become a convention. As more design choices arrive already implemented, engineers can spend more of their time accepting or correcting proposals. They get fewer opportunities to explore alternatives, explain their preferences, and see how their own choices work in practice. Over time, that weakens the habits through which engineering taste develops. Teams can preserve those opportunities by making room to q…

Some of the hardest work in code review happens outside the changed lines. A change can look correct in isolation and still break code elsewhere in the system. That is what makes our early results for OpenAI's GPT-6 Astra most interesting. In our evaluation, Astra caught approximately 4% more labeled bugs through actionable findings than GPT-5.6 Sol, and 22% more than Opus 5. The biggest jump comes on harder cross-file reviews, where Astra's gains reach 20% over Sol and 33% over Opus 5. Using that capability at customer scale also means protecting customer data and assessing the model’s public API pricing. What Astra added to code review Our measure here is actionable bug coverage, meaning how many labeled bugs a model catches through findings a developer can act on. Coverage is rounded to one decimal; relative gains use unrounded values. The overall gain over GPT-5.6 Sol appears modest in this first evaluation measure. This evaluation also includes simpler reviews, where there may be less room for a stronger model to differentiate itself; Astra's larger advantage appears in the harder cross-file subset. It is an early, directional result. Coverage is rounded to one decimal; relati…

Some of the hardest work in [code review](https://www.coderabbit.ai/guides/what-is-code-review-and-how-is-it-changing) happens outside the changed lines. A change can look correct in isolation and still break code elsewhere in the system. That is what makes our early results for [OpenAI's GPT-6 Astra](https://openai.com/index/gpt-6-astra/) most interesting. In our evaluation, Astra caught approximately **4% more labeled bugs through actionable findings than [GPT-5.6 Sol](https://www.coderabbit.ai/blog/gpt-5-6-sol-and-terra-benchmark)**, and **22% more than [Opus 5](https://www.coderabbit.ai/blog/opus-5-model-review)**. The biggest jump comes on harder cross-file reviews, where Astra's gains reach **20% over Sol and 33% over Opus 5**. Using that capability at customer scale also means protecting customer data and assessing the model’s public API pricing. ## What Astra added to code review Our measure here is actionable bug coverage, meaning how many labeled bugs a model catches through findings a developer can act on. <figure> <img src="/content/assets/gpt-6-astra/coverage-overall.png" alt="Overall actionable bug coverage on a full 0–100% scale: GPT-6 Astra 61.3%, GPT-5.6 Sol 59.0%,…

In CodeRabbit's latest episode of The Merge, I sat down with software engineer and educator Kent C. Dodds, who has spent much of his career teaching developers how to build better software. He has taught JavaScript testing, React, full-stack web development, and, more recently, how to work with AI tools. We’ve watched AI tools improve quickly, with agents implementing changes, opening pull requests, and iterating on review feedback. That raises a question many developers might be asking, and one Kent asked himself: "What is it that I do here now?" Kent frames the future of software engineering through a thought experiment. As AI takes on more implementation work, he asks what the “last software engineer” would still need to do. His answer is simple: “I think that it’s knowing what to build.” When every arrow hits, choosing the target becomes the skill For decades, a large part of a developer's value came from turning a defined idea into working software. Take the ticket, understand the requirements, write the code, ship the change, and repeat. As agents take on more implementation, the engineer’s role shifts toward deciding what to build, shaping the system, and judging the result.…

In CodeRabbit's latest episode of *The Merge*, I sat down with software engineer and educator Kent C. Dodds, who has spent much of his career teaching developers how to build better software. He has taught JavaScript testing, React, full-stack web development, and, more recently, how to work with AI tools. We’ve watched AI tools improve quickly, with agents implementing changes, opening pull requests, and iterating on review feedback. That raises a question many developers might be asking, and one Kent asked himself: "What is it that I do here now?" Kent frames the future of software engineering through a thought experiment. As AI takes on more implementation work, he asks what the “last software engineer” would still need to do. His answer is simple: “I think that it’s knowing what to build.” %[https://www.youtube.com/watch?v=9hoqdnYBKUQ] ## When every arrow hits, choosing the target becomes the skill For decades, a large part of a developer's value came from turning a defined idea into working software. Take the ticket, understand the requirements, write the code, ship the change, and repeat. As agents take on more implementation, the engineer’s role shifts toward deciding what t…

Coding agents are moving beyond isolated tasks. We now expect them to understand a repository, make decisions across several files, and carry a meaningful part of a project from intent to implementation. That is the standard we used for Fable 5.1. Fable 5 was a thorough model that spent a long time exploring before it acted. That helped on larger coding tasks, but its reviews were slow and produced more comments than we wanted. Fable 5.1 keeps the same habit of checking the environment and planning first, while showing more restraint in what reaches the final review. Our recommendation is to use Fable 5.1 selectively. It is a good fit for high-complexity changes where broader issue coverage matters more than speed. Routine pull requests are better served by a faster, more precise default setup. For coding work, give Fable 5.1 a clear outcome, enough project context, and time to plan. What changed from Fable 5 Fable 5.1 felt faster on small coding tasks and more deliberate on larger ones. In code review, it found almost the same number of known-issue points as Fable 5, but produced 87 fewer final comments and 186 fewer nitpick-style comments. Precision improved by 4.5 percentage poi…

Coding agents are moving beyond isolated tasks. We now expect them to understand a repository, make decisions across several files, and carry a meaningful part of a project from intent to implementation. That is the standard we used for Fable 5.1. Fable 5 was a thorough model that spent a long time exploring before it acted. That helped on larger coding tasks, but its reviews were slow and produced more comments than we wanted. Fable 5.1 keeps the same habit of checking the environment and planning first, while showing more restraint in what reaches the final review. Our recommendation is to use Fable 5.1 selectively. It is a good fit for high-complexity changes where broader issue coverage matters more than speed. Routine pull requests are better served by a faster, more precise default setup. For coding work, give Fable 5.1 a clear outcome, enough project context, and time to plan. ## What changed from Fable 5 Fable 5.1 felt faster on small coding tasks and more deliberate on larger ones. In [code review](https://www.coderabbit.ai/guides/what-is-code-review-and-how-is-it-changing), it found almost the same number of known-issue points as [Fable 5](https://www.coderabbit.ai/blog/f…

In CodeRabbit's latest episode of The Merge, I sat down with Simon Farshid, founder and CTO of Assistant UI, an open-source library for building AI chat and agent interfaces. We talked about the hidden work behind those interfaces, the growing importance of product judgment, and the coding-agent loop Simon runs with CodeRabbit. Assistant UI gives React developers customizable components for AI chat and handles the underlying work, including streaming responses, conversation state, attachments, message editing, voice, and connections to agent backends. The library was born out of Simon's hackathon project. He kept reaching for the same chat interface across his experiments and startup ideas, so he built one. "I didn't plan to make it into a startup," he said. "It was something that I needed myself." Turns out, plenty of other developers had the same problem. Assistant UI now shows up in well over 2,000 open-source GitHub repositories and gets 1.4 million npm downloads a month, including package updates. The hard part is the state “Building chat interfaces seems very easy,” Simon said. “The hard part is state management.” A chat box looks simple until the response starts. Text stream…

In CodeRabbit's latest episode of *The Merge*, I sat down with Simon Farshid, founder and CTO of [Assistant UI](https://www.assistant-ui.com/), an open-source library for building AI chat and agent interfaces. We talked about the hidden work behind those interfaces, the growing importance of product judgment, and the coding-agent loop Simon runs with CodeRabbit. Assistant UI gives React developers customizable components for AI chat and handles the underlying work, including streaming responses, conversation state, attachments, message editing, voice, and connections to agent backends. The library was born out of Simon's hackathon project. He kept reaching for the same chat interface across his experiments and startup ideas, so he built one. "I didn't plan to make it into a startup," he said. "It was something that I needed myself." Turns out, plenty of other developers had the same problem. Assistant UI now shows up in well over 2,000 open-source GitHub repositories and gets 1.4 million npm downloads a month, including package updates. %[https://youtu.be/o41cg-3cM2Q] ## The hard part is the state “Building chat interfaces seems very easy,” Simon said. “The hard part is state manag…

The world runs on open source. From Fortune 100 companies to startups, modern software is built on code that somebody made available for everyone. But the people who keep that code useful, secure, and moving forward are being asked to absorb an onslaught. AI has completely collapsed the cost of producing a contribution, shifting the great bottleneck of software development from generating code, to judging it. No one feels it more than open source maintainers. A maintainer still has to understand the intent, reconstruct the context, test the edge cases, evaluate the security implications, and decide whether a change belongs. Sometimes AI helps a contributor send a great patch. Sometimes it generates a plausible-looking pull request, issue, or security report that creates more work than it saves. And at the worst end, maintainers have faced vitriol and personal attacks for rejecting low-quality AI submissions. GitHub has called the flood open source’s “Eternal September” and now gives maintainers controls to limit incoming pull requests or turn them off. The curl project ended its bug bounty after a wave of low-quality reports. In 2025, its confirmed-vulnerability rate fell below 5 p…