How GitHub merge queues prevent AI velocity sickness

Velocity sickness is the stress and operational drag that appear when AI makes individual engineers produce code faster than their team can prioritize, review, understand, and safely ship it. It shows up as overflowing pull requests, conflicting work, abandoned agent sessions, and important architectural choices hidden inside temporary chats. The problem is not that coding agents create too much code. It is that implementation accelerates while team decision-making does not. A shared agent-first control plane can help teams keep plans, acceptance criteria, verification, and accountability connected as agents work. The goal is impact, not merely output.

At a Glance

AI-assisted implementation moves faster than traditional team coordination.

• Core problem: More code does not automatically create more customer or business impact.
• Early symptoms: Pull request backlogs, merge conflicts, duplicated agent work, and scattered priorities.
• Key shift: Treat planning and implementation as distinct engineering modes with different tools and review points.
• Durable context: Keep decisions in shared, long-lived plans rather than isolated agent chats.
• Human ownership: Engineers must retain control of consequential technical and product decisions.
  

What is velocity sickness in software engineering?

Velocity sickness occurs when AI increases code output faster than a team can make decisions, coordinate work, review changes, and validate outcomes. The result is a misleading sense of progress: activity rises sharply, but product direction, code ownership, and customer impact may not improve at the same rate.

For an individual developer, the first sign may be a stack of agent-generated branches that all need review. For an engineering organization, the same pattern becomes systemic. Multiple people pursue adjacent ideas, merge queues become congested, and critical context disappears between sessions.

This is not an argument for slowing down or avoiding coding agents. It is a warning that implementation speed exposes constraints elsewhere in the delivery system. Once code is cheap to generate, attention, decisions, review capacity, and verification become the scarce resources.

A useful distinction is between output and impact. Output is commits, pull requests, prototypes, and completed tasks. Impact is a useful product change that fits the system, solves the intended problem, and works reliably for the people who use it. A team can have plenty of the first while failing to create enough of the second.

Why does AI create pull request overload and merge friction?

AI creates pull request overload because implementation can now outpace the team’s ability to inspect changes, resolve overlapping edits, and decide what should ship. More branches do not create more review capacity, so queues, conflicts, and low-signal reviews quickly become delivery bottlenecks.

Traditional engineering workflows assumed that writing code was usually the slowest step. That assumption shaped the tools and habits around code review. When agents can generate multiple implementations in parallel, a team can reach review saturation before it reaches implementation saturation.

The practical consequences include:

• More merge conflicts: Several agents or developers edit the same files, interfaces, or assumptions.
• Weaker reviews: Reviewers skim large changes because the volume is unmanageable.
• Unclear priority: A technically complete change may not be the most valuable change to merge.
• Fragile merge queues: A backlog of interdependent changes makes ordering and integration harder.
• Higher rework: Work built on an unreviewed decision may need to be discarded later.

GitHub’s documentation on merge queues describes how queued pull requests are validated against the latest target branch before merging. That mechanism helps protect branch integrity, but it cannot solve an earlier problem: whether the underlying change is aligned with the team’s intended direction.

The best response is to move the most important review earlier. Before generating substantial code, align on the intended behavior, boundaries, tradeoffs, and acceptance criteria. Code review then becomes a check that the implementation matches an already understood decision, rather than a late-stage debate about what should have been built.

How do stacked pull requests change merge coordination for AI teams?

Stacked pull requests, a chain of small, dependent branches that each build on the one before it, become far more common once coding agents are involved. An agent working through a multi-step task naturally produces this shape: one bounded change that unlocks the next, rather than one large diff. Done well, this keeps individual reviews small and focused. Done poorly, it creates a fragile chain where updating an early PR forces every dependent branch to rebase, and a stalled review at the bottom of the stack blocks everything above it.

The coordination problem is visibility: a reviewer looking at PR #3 in a stack needs to know it depends on PR #2 still being open, and that a change to #1 will ripple forward. Without that context surfaced automatically, teams either avoid stacking (and go back to unreviewable mega-PRs) or manage the dependency chain manually, which breaks down as agent-generated stacks grow longer and more frequent.

Levr's PR and CI integration treats pull requests as first-class objects auto-linked from branches and commits, with CI results streaming in bound to commit, branch, and PR. That link makes a stack's dependency chain visible in the same place as the rest of the project, instead of something a reviewer has to reconstruct from GitHub's branch list.

Merge coordination is one piece of a larger shift — see how multiplayer agentic engineering brings support, product, and engineering into the same shared task context

Why do AI teams start moving in too many directions?

AI teams lose focus when agents make it cheap to pursue many ideas at once without a shared view of priorities, dependencies, and system boundaries. Parallel execution is valuable only when work starts from aligned decisions and does not create competing technical paths.

Agentic development encourages exploration. That is useful, especially when a problem has several plausible solutions. The failure mode appears when exploration turns directly into implementation without a visible decision point.

Imagine three engineers addressing a slow checkout flow. One agent rewrites caching behavior, another redesigns an API contract, and a third replaces a client-side state pattern. Each change may be reasonable in isolation. Together, they can create overlapping changes, incompatible assumptions, and a larger review surface than the original problem required.

A shared plan should establish enough structure for parallel work:

• The user or system problem being addressed.
• The decision that needs to be made before implementation starts.
• The relevant services, modules, interfaces, and constraints.
• Explicit non-goals that prevent scope expansion.
• Dependencies and owners for parallel tasks.
• Acceptance criteria and verification expectations.

This is not heavyweight documentation for its own sake. It is coordination infrastructure. When implementation is inexpensive, a short period of explicit alignment can save a large amount of generated code, review effort, and token spend.

What does “agent bankruptcy” mean, and why does it waste work?

Agent bankruptcy is the practice of abandoning active agent sessions because their context, progress, and purpose are too difficult to reconstruct. It wastes work because the next session often repeats exploration, consumes more tokens, and risks making inconsistent decisions from incomplete context.

The pattern is familiar: several terminals, branches, or chats are active at once. By the next day, no one can quickly answer what each agent was trying to accomplish, what it learned, or which changes are still relevant. Starting fresh feels easier than recovering the work.

The issue is not that agents have limited session context. The issue is that the meaningful state of a project lives only inside the session. If the chat holds the architecture rationale, explored alternatives, open questions, and intended next steps, the team has made the agent session the system of record.

Instead, separate state from action:

• State: The shared plan, decisions, constraints, progress notes, and unresolved questions.
• Action: The temporary coding agent that investigates, modifies code, runs tests, or reports findings.

With this separation, agents can be replaceable. A new agent starts from the durable project context, not from a vague prompt or a lost conversation. Humans can also reorient quickly by reading the same source of truth.

Give coding agents shared project context, not isolated prompts.

Levr connects issues, acceptance criteria, test evidence, workflow gates, and agent activity so work stays understandable even when implementation happens across several agents.

Explore agent-first project workflows

Why must humans retain ownership of critical decisions?

Humans must retain ownership of critical decisions because coding agents can propose and implement options, but they do not carry the team’s accountability for product intent, system evolution, customer consequences, or long-term maintenance. Delegating execution is different from delegating judgment.

Not every choice needs a meeting. Formatting, routine refactors, narrowly defined test updates, and mechanically verifiable changes can often be delegated safely. The decisions that need deliberate human ownership are those that reshape constraints or make future work harder to reverse.

Examples include:

• Changing a public API or data contract.
• Selecting an architectural boundary between services or modules.
• Altering authorization, privacy, or security behavior.
• Choosing behavior that affects customers or pricing.
• Accepting technical debt in exchange for speed.
• Replacing a foundational dependency or workflow.

AI can still make these decisions easier. It can surface relevant code, map dependencies, identify alternatives, and summarize tradeoffs. But the final choice should be explicit, reviewable, and connected to the people responsible for maintaining the system.

That is why chat alone is a poor home for consequential decisions. A chat is optimized for rapid interaction. Decision records need to remain visible after the implementation is merged, the agent session ends, and the original participants have moved to other work.

How does a shared planning document improve agentic development?

A shared planning document improves agentic development by making important context durable, visible, and reusable across people and agents. It turns a plan from a disposable prompt into a decision record that guides parallel implementation, simplifies review, and preserves the rationale behind system changes.

The plan should act as a portal into the software system. Rather than asking an agent for a generic implementation, use the plan to pull forward the parts of the system relevant to the change: related components, existing conventions, dependencies, risks, unknowns, and decisions that require agreement.

A useful technical plan does not need to be long. It needs to make the following questions easy to answer:

• What problem is being solved, and for whom?
• What existing behavior or system area is relevant?
• Which decisions are already made, and which remain open?
• What alternatives were considered, and why was one chosen?
• What work can run in parallel without conflict?
• How will the team verify that the change is correct?

Anthropic’s Claude Code memory documentation explains how persistent project instructions can provide context across sessions. Durable shared plans serve a broader team purpose: they preserve the project-specific decisions that agents and humans need, rather than relying on any one person’s local session history.

How can teams shift from code velocity to idea velocity?

Teams shift from code velocity to idea velocity by exploring and evaluating more possible solutions before committing agents to implementation. Success means identifying better problems and decisions sooner, not converting every early concept into a branch, prototype, or pull request.

With traditional development costs, building often served as the primary way to learn. When agents lower the cost of implementation, teams can test the quality of an idea earlier. A plan that is explored and then rejected is not failed work. It is prioritization performed before unnecessary code exists.

This avoids prototype gravity, where an early implementation gains momentum simply because it already exists. Generated code can create a false sense of commitment. Once a prototype is visible, teams may feel pressure to refine and ship it even if it is not the strongest route to the intended outcome.

Use a lightweight decision process instead:

1. State the intended outcome: Describe the customer, operational, or technical result that matters.
2. Explore the system: Identify the code, constraints, dependencies, and risks that shape the choice.
3. List viable options: Include the option to do nothing or defer the change.
4. Make the decision explicit: Record the chosen approach and its rationale.
5. Delegate bounded work: Give agents tasks with clear acceptance criteria and ownership boundaries.
6. Verify and review: Check tests, runtime evidence, code quality, and whether the outcome still matches the original intent.
   

How can Levr keep agent work aligned with engineering decisions?

Levr can keep agent work aligned by giving humans and coding agents shared issues, structured acceptance criteria, workflow states, tests, and audit history. The same project context guides planning, execution, verification, and review, reducing the gap between intended work and completed work.

One way to structure this workflow in Levr’s agentic workflow is to define intent in natural language, connect it to an issue with acceptance criteria, allow an agent to pick up bounded work, and require automated verification plus human approval before completion.

This is especially useful when several coding agents operate in the same project. Levr supports shared context and attributed activity across Claude Code, Cursor, Codex, Copilot, and other Model Context Protocol, or MCP, clients. Instead of relying on separate chat histories, the team can keep the project state tied to work items and verification gates.

For an engineering manager, the value is operational visibility. You can inspect blocked work, throughput, test health, and whether tasks are being completed by people or agents. For developers, the value is faster recovery and clearer handoffs: the relevant context remains attached to the work rather than trapped in a single agent session.

The Whole Stack, Visible: The Levr Dashboard

Velocity sickness thrives on invisible work — PRs nobody's tracking, agents nobody remembers starting. The Levr Dashboard aggregates open issues, active runs, and blocked work into a single pane of glass, so a growing PR queue or a stalled dependency chain shows up before it becomes a bottleneck.

The Levr Dashboard surfaces blocked work and PR backlogs in real time, before they become a coordination crisis.

What should a team do this week to prevent velocity sickness?

To prevent velocity sickness this week, separate planning from implementation, make plans durable and shareable, and review critical decisions before agents generate substantial changes. These habits reduce duplicate work, improve collaboration, and preserve human ownership without giving up AI-assisted speed.

Start with three changes that require little process overhead.

1. Name the gear you are in

Before opening an agent session, ask whether the task is planning or polish. Planning means understanding the system, exploring alternatives, and choosing a direction. Polish means inspecting implementation, tightening behavior, testing, and preparing a change to ship. A tool that is useful in one mode may be poor for the other.

2. Turn each meaningful plan into shared state

When a task involves a consequential decision, create a short plan outside the agent chat. Include the problem, relevant system context, chosen direction, open questions, and acceptance criteria. Update it as the team learns. The plan should be readable by a teammate or a new agent without an oral handoff.

3. Share the plan before assigning implementation

Ask a teammate to review the plan before assigning a major task to an agent. This is an inexpensive way to surface missing context, competing work, and assumptions that may be obvious to someone else. The earlier the feedback arrives, the less generated code must be reviewed or discarded.

Technical Deep Dive FAQ

What is an AI coding agent?

An AI coding agent is a software tool that can use a language model to inspect a codebase, reason about tasks, modify files, run commands, and report results. Unlike autocomplete, an agent can operate across multiple steps. It may search for relevant code, generate an implementation, execute tests, and revise its work. Its usefulness depends heavily on the context, permissions, task boundaries, and verification process provided by the engineering team.

What is agentic development?

Agentic development is a software delivery approach in which coding agents participate in planning, implementation, testing, and maintenance tasks alongside human engineers. It does not require full autonomy. Teams can use agents for narrow, supervised tasks or for longer workflows with checkpoints. The central challenge is coordination: agents need accurate project context, clear acceptance criteria, controlled access, and a way to record their work in the same operational system used by people.

How do you prevent AI-generated pull requests from overwhelming reviewers?

Prevent review overload by limiting agent tasks to well-defined changes, agreeing on key decisions before code generation, and requiring test evidence with each pull request. Break broad initiatives into independently reviewable slices with clear ownership boundaries. Reviewers should not need to rediscover the product goal or architecture rationale from a large diff. A linked plan and acceptance criteria let review focus on implementation quality, correctness, and any deviation from the agreed approach.

Should coding agents make architecture decisions?

Coding agents can help investigate architecture decisions, but humans should make and record the final choice when the decision has lasting technical, product, security, or operational consequences. An agent can map dependencies, compare approaches, identify risks, and draft an implementation plan. Those are valuable inputs. However, engineers and technical leaders remain accountable for future maintenance, reversibility, and alignment with broader product constraints that may not be present in the agent’s prompt or local repository context.

What should be included in an AI implementation plan?

An AI implementation plan should include the problem to solve, relevant system context, intended behavior, constraints, non-goals, decisions already made, unresolved questions, acceptance criteria, and a verification approach. It should also identify files, services, APIs, or ownership boundaries that matter to the task. The purpose is not to prescribe every line of code. It is to provide enough shared state that different agents or teammates can make consistent progress without reconstructing the project from scratch.

How do shared plans reduce duplicated agent work?

Shared plans reduce duplication by recording what has been investigated, what decisions have been made, what remains unknown, and what work is already in progress. Without that context, separate agents may independently search the same code, propose incompatible approaches, or repeat abandoned experiments. A durable plan gives each new agent a common starting point and lets humans see whether parallel work is complementary or overlapping. It also makes it easier to stop low-value work before it reaches implementation.

What is the difference between planning mode and a durable decision record?

Planning mode usually helps an individual agent develop a proposal during an active session. A durable decision record captures the resulting context and remains available beyond that session. The difference matters because a plan inside a temporary conversation can disappear from team awareness after code is generated. A shared decision record is visible to reviewers, future maintainers, and other agents. It explains why the team chose a direction, not merely how one agent attempted to implement it.

How can engineering managers measure whether AI is creating real impact?

Engineering managers should look beyond raw output such as commits, generated code, or pull request counts. Useful signals include cycle time, blocked work, rework, pull request review time, test health, defect trends, delivery predictability, and whether completed work maps to planned priorities. Attribution also matters. Teams need to know what actions were taken by people and by agents, plus what verification occurred. These measures reveal whether AI-assisted speed improves delivery or simply creates more coordination work.

When should an agent task require human approval?

An agent task should require human approval when it changes public behavior, security controls, access permissions, data handling, architecture, core dependencies, or other decisions that are costly to reverse. Approval is also appropriate when tests cannot fully validate correctness, such as user experience changes or ambiguous business rules. Narrow, well-tested maintenance tasks may use lighter review. The level of oversight should match the potential blast radius, uncertainty, and reversibility of the change.

Can multiple coding agents work on the same project safely?

Multiple coding agents can work safely on the same project when the team establishes shared context, explicit task boundaries, dependency awareness, and verification gates. Parallelism works best when agents own separate modules, tests, research tasks, or clearly defined slices of a plan. It becomes risky when agents independently modify shared interfaces or pursue competing architectural directions. A shared control plane helps expose task relationships, preserve decisions, attribute changes, and make conflicts visible before they become difficult merge problems.

Key Takeaways

AI increases implementation capacity, but teams only benefit when decisions, context, and verification keep pace.

Use AI speed to improve choices, not merely to multiply code.

• Recognize the signal: Pull request overload and abandoned sessions often indicate a coordination problem, not an implementation problem.
• Separate roles: Agents can perform actions, while shared plans preserve project state and human decisions.
• Review earlier: Align on consequential choices before generated code creates review debt.
• Prioritize ideas: A plan that is never implemented can still be valuable if it prevents low-impact work.
• Keep proof connected: Tie acceptance criteria, tests, results, and approvals to the same work item.

The best agentic engineering workflow preserves human judgment while making execution faster and easier to verify.

Further reading

• GitHub documentation: Managing a merge queue
• Anthropic documentation: Claude Code memory
• Levr agent-first project management platform
• Levr features for agents, issues, tests, and workflow gates
• How Levr’s agentic workflow operates
• AI security and the agent-ready web
  
  

Ship at agent speed

Give your coding agents a control plane, not just a prompt.

Levr connects Claude Code, Cursor, Codex, and Copilot to shared project context with issues, gates, test suites, and attributed workflow history. Free access is available during beta.

Get early access, it’s free

No credit card required during beta.