Most dev tooling was built on assumptions that no longer hold. Humans write code with effort and expertise. Changes are scarce and valuable. Linear workflows—ticket → branch → PR → review → merge—make sense. When agents write most of the code, those assumptions break. The tools we rely on were designed for a different world.

It’s time to re-examine them from first principles.

The PR (Pull Request)

Original assumption: A PR represents non-trivial human effort. It deserves review, discussion, and careful merge. The bottleneck is human capacity to produce PRs.

When agents write the code: PRs can be generated in minutes. Volume explodes. A single developer might produce 10x the PRs. Review capacity doesn’t scale. The PR as “unit of human effort” loses meaning. Maybe we need different units: PRs as “agent output batches” with different review protocols? Or larger units of work with agent-generated sub-PRs that get fast-tracked? The PR workflow needs rethinking.

The Sprint

Original assumption: Sprints bundle work into timeboxes. Velocity (story points, tickets closed) measures team capacity. Planning aligns capacity with demand.

When agents write the code: Capacity is less about headcount and more about prompt design, validation, and integration. “Story points” mapped to human effort no longer make sense. Sprints may still be useful for rhythm and coordination—but the metrics and planning assumptions need to shift. What are we optimizing for? Learning? Shipping? Coherence?

The Branch

Original assumption: Branches isolate work. Merge conflicts are resolved by humans. The main branch is the source of truth.

When agents write the code: Branch proliferation can explode. Every agent run might create a branch. Merge strategies, conflict resolution, and branch hygiene need new norms. Maybe agent-generated branches have shorter lifecycles. Maybe we need different branching models for human vs. agent work. The assumption that “branches are expensive” no longer holds; the assumption that “we can manage unlimited branches” also doesn’t. New tooling and norms are needed.

The Ticket

Original assumption: A ticket represents a discrete unit of work, sized for human implementation. The backlog is a queue of such units.

When agents write the code: Tickets can be implemented in bulk. The backlog might be less “queue” and more “portfolio”—things we might do, with agents doing first-pass implementation and humans doing selection and refinement. Ticket structure, sizing, and workflow may need to evolve.

Where to Start

We’re not saying “throw it all away.” We’re saying: the assumptions behind our tooling have shifted. Re-examine each artifact—PR, sprint, branch, ticket—and ask: what was it optimized for? Does that optimization still hold? What would we build if we started from scratch for an agent-first world?

The teams that ask these questions now will be ahead when the tools catch up.