The Backlog Is Dead. Now What?

A pattern is emerging among the best engineering teams I talk to: no Linear, no Jira, no backlog at all. When I ask where they track issues, the answer is usually some version of "we don't." A two-page Google Doc, a Slack channel, maybe nothing. They just fix things.

This isn't new—forward-thinking teams have been drifting this way for years. But it's accelerating fast enough to have a name now. People are calling it post-backlog engineering, and it's worth paying attention to because the teams doing it are winning.

The argument is straightforward: AI collapsed the cost of fixing a bug to roughly the cost of understanding it. If it takes the same effort to type "@codex please fix this" as it does to file a ticket, why file the ticket? And if the issue matters, it'll come up again. If it doesn't, you just saved yourself the maintenance cost of a stale backlog entry that nobody will ever read.

This is right. And it's incomplete.

Bugs Aren't Decisions

The post-backlog argument is strongest when applied to defects. A broken checkout flow, a misaligned button, a race condition in the API—these are known problems with known solutions. The only question is whether they're worth fixing now or later. AI makes "now" cheap enough that "later" stops making sense.

But most of what fills a backlog isn't bugs. It's decisions disguised as tasks. "Add SSO support." "Redesign the onboarding flow." "Build a dashboard for enterprise customers." These aren't defects with known solutions. They're bets about what matters, and they require thinking that no agent can collapse.

When you kill the backlog, you kill the tracking of both bugs and decisions. The first is fine—fix bugs on sight, no ceremony needed. The second creates a vacuum. Without a backlog, there's no default next thing to do. The post-backlog crowd celebrates this: a blank page forces a real OODA loop, forces you to step back and think about what you should be doing next.

They're right. But they underestimate what the blank page demands.

The Google Doc Is Doing More Than You Think

The teams that operate without backlogs aren't actually operating without artifacts. They always have something: a living document, a shared note, a two-page brief that describes the current project. When they talk about "no issue tracking," what they mean is no persistent queue of work items. The thinking artifact still exists. It's just informal.

This is the tell. The task list dies, but the thinking doesn't. Someone still has to decide what to build. Someone still has to hold the context of why this project matters, what the constraints are, what success looks like, which edge cases were considered and which were punted. In a seven-person team, that context might live in one person's head. It works because everyone is one Slack ping from the answer.

But context that lives in one person's head has a half-life. We've seen this pattern before: a small team ships fast because they hold all the context. Then someone leaves, or a new person joins, or an agent picks up the task at 2am—and the context evaporates. The Google Doc that held the project brief gets archived. The Slack thread scrolls into oblivion. The code ships, but the reasoning behind it is gone.

Post-backlog engineering solves the bureaucracy problem. It doesn't solve the knowledge problem.

The Cost Curve Shifted, Not Disappeared

The core insight of post-backlog thinking is about a cost curve: when the cost of fixing converges with the cost of understanding, you should fix more and track less. This is true, and it's the right framing. But it only applies to one side of the equation.

There are two costs in building software:

1. The cost of fixing a known problem. What code to change, which file to edit, how to structure the component. AI is collapsing this toward zero.
2. The cost of deciding what's worth building. What problem matters, what constraints exist, what success looks like. This is going up.

Why is the second cost increasing? Because the solution space exploded. When building was slow, prioritization was naturally constrained—you could only ship a few things per quarter, so you picked carefully. When agents can ship features in hours, you can build anything. The constraint shifts from execution bandwidth to decision quality.

A seven-person team running agent swarms can deliver what used to take fifty engineers. Which means they're making fifty engineers' worth of product decisions, compressed into seven people's judgment. The leverage is extraordinary. So is the blast radius of a bad decision.

The backlog was never great at making those decisions—it was mostly a queue, not a thinking tool. But at least it created a moment of explicit choice: this ticket is P1, that one is P2, this one we're not doing. Post-backlog engineering removes the queue but doesn't replace the decision framework. It trusts that small, high-context teams will make good calls intuitively.

That's mostly true. Until it isn't.

What "Think More" Actually Requires

"Think more, obey less" is the best line in the post-backlog playbook. A blank page instead of a pre-filled queue forces genuine prioritization instead of mechanical ticket-churning. This is the right instinct—and it's exactly what intent engineering is designed to support.

But "think more" is easy to say and hard to operationalize. What does thinking more actually look like?

It looks like asking: Which user problem are we solving? Not which feature are we building—which friction are we reducing? And how do we know that friction exists? Is there evidence, or just an intuition?

It looks like specifying: What does success look like? Not a vague sense that the product got better, but observable, testable outcomes that close the loop between what you intended and what you shipped.

It looks like considering: What are the constraints and edge cases? Not after the agent hallucinates a solution, but before—so the solution is right the first time.

It looks like answering: What must not degrade? Defining clear health metrics so AI coding tools have hard bounds for refactoring safely.

It looks like persisting: Why did we make this decision? Not for bureaucratic accountability, but so the next person (or agent) who touches this code starts from context, not from zero.

None of this requires a backlog. But it does require structure. The Google Doc is doing this job today—badly. It's unstructured, unsearchable, ephemeral, and it doesn't push back on you. It doesn't ask "is this testable?" or "what evidence supports this priority?"

The successor to the backlog isn't nothing. It's a better thinking artifact.

The Intent Spec Is Not a Ticket

It's worth being precise about what replaces the backlog, because the worst possible outcome is building a slightly different backlog and calling it innovation.

A ticket says: here's a task, do it. It's a unit of work in a queue. It assumes someone upstream already decided what to build and why. The ticket's job is to describe the what and coordinate the who.

An intent spec says: here's a problem, here's why it matters, here's what success looks like, here's what constrains the solution. It's not a unit of work—it's a unit of thinking. It doesn't sit in a queue waiting to be pulled. It's the artifact that makes the thinking explicit and persistent—something a human can review and an agent can execute against.

# A unit of Product Intent
objective: "Users can export data directly to their AI coding agent to avoid manual copy-pasting."
outcomes:
  - "Export modal displays within 200ms"
  - "Data formats correctly as markdown"
  - "User receives confirmation callback on success"
constraints:
  - "No data leaves the browser without explicit consent"
  - "Must use existing primary button styles"

The post-backlog teams are right that the ticket is dead. What they're using instead—the two-page living document, the shared brief, the project note—is a proto-intent-spec. It's the right instinct without the right infrastructure.

Who This Is Really For

The teams operating post-backlog today have specific traits: small, flat, high-trust, high-context. They don't need backlogs because every engineer makes good independent judgment calls, and the whole team fits in one room.

But here's what's interesting: those same traits make them ideal candidates for intent specs. They're already doing the hard part—thinking carefully about what to build. They just don't have a persistent artifact that captures that thinking.

The value isn't coordination (they don't need it) or process (they'd reject it). The value is:

Amplified decision quality. When your intent is structured—objective, evidence, constraints, success criteria—you catch bad assumptions before the agent burns an afternoon on the wrong approach. The spec pushes back on vagueness the way a good co-founder pushes back on hand-waving.

Agent-ready context. A Google Doc describes a project for humans. An intent spec describes it precisely enough for an agent to execute without guessing. When your team runs agent swarms at scale, the quality of the spec is the quality of the output.

Persistent reasoning. Six months from now, when someone asks "why did we build it this way?", the answer is in the spec—not in a deleted Slack thread or an archived Google Doc. The spec is the product, more durable than the code it generated.

The Real Frontier

The death of issue tracking isn't really about tracking. It's about a deeper shift: the execution layer of software engineering is being commoditized. Building the thing is fast and getting faster. Understanding what to build—and making that understanding persistent, structured, and precise enough for agents to act on—is the new bottleneck.

The backlog was a coordination tool for the old bottleneck: too many tasks, too few hands. It made sense when the hard part was building. Post-backlog engineering correctly diagnoses that the old bottleneck is gone.

But the blank page where the backlog used to be isn't the endgame. It's the starting point. The teams that win from here will be the ones who build the best thinking infrastructure—not the most tickets, not the fanciest kanban board, but the clearest, most persistent articulation of what they're building and why.

The backlog is dead. Long live the intent.