Issues-First: Slowing Down PRs to Speed Up Shipping

"LGTM."

Merged.

Three weeks later, nobody can find where the auth logic lives.

The spaghetti problem

A PR shows up. It looks good. The tests pass. The description is reasonable. You merge it.

Then another one. Same deal. Looks fine. Merge.

Then a third, a fourth, a fifth. Each one makes sense in isolation. Each one passes review. Each one ships.

Six months later, you're staring at a codebase where the business logic is scattered across fourteen files, the naming conventions conflict, and nobody remembers why half of these changes were made in the first place.

This is the "good-looking PR" trap. The problem is not that the code is bad. The problem is that nobody discussed the approach before the code existed.

The shift: issues before PRs

The Roo Code team made a deliberate change. Issues are now required before PRs get accepted. Every change starts with a written discussion of what the change is, why it matters, and how it fits into the existing architecture.

"In the last week, we have shifted to an issues first approach where issues are required before we make PRs and where we review these issues on a regular basis."

Hannes Rudolph, Office Hours S01E06

The goal is not bureaucracy. The goal is catching misalignment before code exists. A five-minute conversation about approach is cheaper than a two-hour code review that ends with "actually, we should have done this differently."

Why PRs alone fail

Code review is supposed to catch problems. But by the time a PR exists, the author has already invested hours. The sunk cost is real. Reviewers feel pressure to approve work that technically functions, even when the approach creates future problems.

"We're doing this as a team to prevent just simply taking on PRs. Oh, there's a good PR. Let's put it in there. And then we end up with a mountain of technical debt, of really a spaghetti codebase."

Hannes Rudolph, Office Hours S01E06

The pattern is predictable. A contributor submits a PR. It looks reasonable. The team merges it to avoid blocking progress. Repeat until the codebase is a patchwork of isolated decisions that never had a chance to be coordinated.

The tradeoff

This approach is not free. Week one feels slower. PRs that would have been merged immediately now wait for issue discussions. Contributors who want to ship quickly hit friction.

But the friction is the feature. The conversation that happens before code exists is where architectural alignment happens. The review of an issue is a review of intent, not implementation. You can redirect approach in ten minutes instead of discovering problems after the code is merged.

"The technical debt has really gone down. From the days where we were just client work or the code was really messy back in the day, but right now I can say the code is much better organized."

Dan, Office Hours S01E06

Why this matters for your team

For a Series A - C team shipping with five engineers, every architectural misstep compounds. You do not have the headcount to refactor constantly. You cannot afford to have three people debugging a merge conflict that exists because two PRs made conflicting assumptions about how auth should work.

The issues-first approach forces the conversation to happen at the cheapest possible moment: before anyone writes code. A ten-minute issue review can prevent a week of cleanup.

The math is simple. Slower PR acceptance in week one. Faster iteration in month two. The velocity you lose upfront comes back when your codebase stays reviewable.

The rule

If a PR shows up without an issue, ask the question: "What are we trying to solve, and why this approach?"

That question is easier to answer before the code exists. Start there.

How Roo Code enforces issues-first workflows

Roo Code closes the loop between intent and implementation by making the issue discussion part of the agentic workflow. When you use Roo Code with an issues-first approach, the agent can read the issue context, understand the architectural constraints discussed in comments, and generate code that aligns with the agreed-upon approach - not just code that technically works.

An AI coding agent that closes the loop can propose diffs, run tests, and iterate based on results - but it works best when the intent is already documented in an issue. This prevents the agent from making isolated decisions that conflict with your team's architectural direction.

With BYOK (Bring Your Own Key), teams control their AI spend while ensuring the agent operates within the boundaries set by issue discussions. The result: faster implementation of agreed-upon approaches, not faster accumulation of technical debt.

Issues-first vs. PRs-first: a comparison