The best engineering teams Dan Robinson talks to have something in common: no Linear, no Jira, no backlog of any kind. Not because they're disorganized — because they've decided issue trackers get in the way.
Robinson builds Detail, an AI bug finder, so he has a front-row seat to how high-performing teams actually work. When he asks where they route bug reports, the answer is sometimes "Slack" — but the real answer is closer to "nowhere." One team runs all of engineering, product, and design on a two-page Google Doc. There's no backlog because they don't believe in one.
"I noticed a pattern among engineering teams building products I love. It seemed a little wacky, but I kept noticing it: no Linear, no backlog, no issue tracking at all... I think it's actually a disciplined mode of operating that just doesn't have the right tooling or terminology yet. I'm seeing teams scale this to 30+ engineers, and their products are winning in competitive markets, so it's important to ask why."
Robinson calls this Post-Backlog Engineering. It's not rebellion for its own sake — it's a coherent operating model with a real theoretical basis. And it's worth understanding before dismissing it.
The case for ditching the backlog
The first argument is about signal. If a bug matters, it'll come up again. Users will report it. Engineers will encounter it. The product will behave badly in a way that's hard to ignore. You don't need to file a ticket to preserve the memory — the problem will remind you of its existence. Tickets that sit untouched for six weeks were probably never that important.
The second argument is economic, and it's the one AI has fundamentally changed. Filing a ticket made sense when fixing an issue cost ten times as much as writing it down. You wanted to preserve your understanding before losing the context. But when an AI agent can understand and fix most bugs in roughly the same time it takes to write a ticket, the math inverts. Robinson puts it precisely: typing "@Linear create a ticket, P2, assign to me" in Slack takes the same effort as typing "@codex please fix this, assign the PR to me." At that ratio, the ticket is pure overhead.
The third argument is about inertia. A backlog is a list of answers generated in the past. Consulting it each morning means acting on stale information instead of asking the harder question: given everything that happened this week, what actually matters most right now? A blank page forces a real OODA loop. The backlog gives you something to do without requiring you to think.
The vacuum no one talks about
The arguments for post-backlog engineering are sound. But Robinson's thread is prescriptive about what to stop doing and nearly silent on what fills the void. Tickets were annoying — but they served more functions than anyone appreciated while they were still being filed.
The most obvious loss is the audit trail. When a client asks "what did your team actually do last month," the answer used to live in Jira or Linear — a timestamped record of tickets created, assigned, and closed. Post-backlog teams have no equivalent. The work happened, but the record is scattered across git commits, Slack threads, and the memories of whoever did it. None of that is retrievable in any useful form.
Billing evidence disappears along with the audit trail. Agencies and consultants who bill by the hour have historically relied on some combination of timesheets and ticket history. Post-backlog teams generate neither. The work is real and the hours were spent — but proving it becomes a manual reconstruction exercise every invoice cycle.
Team visibility erodes as you grow. With seven engineers, you roughly know what everyone's working on — you share physical space or a small enough Slack that context diffuses naturally. At fifteen or twenty, that ambient awareness starts to break down. Tickets were a forcing function that surfaced what people were working on, even if nobody read them carefully. Without them, the only alternative is constant verbal sync, which doesn't scale either.
Past decisions become invisible. When a new engineer asks "why was the auth code written this way," the traditional answer was a Jira ticket with comments, a linked PR, and a thread of context. The post-backlog answer is often "go ask someone who was there" — which works fine until it doesn't, and until the people who were there have left.
AI chats are the new issue tracker
Here's the part Robinson's thread gestures toward but doesn't fully articulate: when an engineer routes a bug to "@AI in Slack" instead of filing a ticket, the AI conversation that follows IS the record. Not a diminished record. A richer one.
A ticket captured a title, a description, and some comments. An AI coding conversation captures the diagnosis — the engineer stepping through the stack trace with Claude, the three hypotheses that were wrong, the fourth one that was right, the edge cases surfaced along the way, the final fix with its rationale. The ticket was a placeholder. The conversation is the actual work.
The problem is that AI conversations are invisible and ephemeral. They live in individual engineers' sessions, gone when the window closes, inaccessible to the rest of the team. The most valuable intellectual work in a post-backlog org happens in AI sessions — and none of it is searchable, shareable, or persistent beyond the moment it was generated.
Scribe captures all of it. Claude, Cursor, Gemini, Codex, OpenCode — every AI coding session across every provider, automatically parsed from local session logs, timestamped and connected to the projects they belong to. The chat that replaced the ticket is now part of a searchable, team-visible record of what actually happened.
What your team's AI history unlocks
Making AI sessions searchable at the team level creates capabilities that didn't exist in the ticket era — not just replacements for what tickets did, but genuinely new ones.
The most immediate is deduplication. Before opening a new AI session to investigate a bug, search what your team has already explored: was this already looked into? Resolved? Partially explored and abandoned? Without this, three engineers have the same conversation independently. With it, the third engineer starts from where the second one stopped.
Expertise routing becomes possible without an org chart. Post-backlog teams have no "assigned to" field, no component ownership table, no formal record of who knows what. But Scribe can answer from first principles: who's been spending time in AI sessions touching the payment module? Whose conversations involve the database migration code? Expertise emerges from the record of actual work, not a manually maintained doc.
Billing becomes provable again. Every AI session is timestamped. Every git commit is timestamped. Scribe aggregates both into invoice-ready evidence without anyone tracking time manually. "We spent approximately 23 hours on AI-assisted work related to your infrastructure migration" is a claim backed by session logs and commit history — not an estimate reconstructed from memory two weeks later.
And as agent-driven development matures, there's a fourth unlock: context injection. Agents operating without prior context drift — they make locally reasonable decisions that conflict with choices the team already worked through. Feeding an agent your team's prior AI conversations about a codebase area, before it touches that area, closes that loop. The team's accumulated knowledge becomes the agent's starting context instead of starting from zero.
Post-backlog works for 7. Scribe makes it work for 30.
Robinson is explicit about the constraints. Post-backlog engineering requires small, flat teams with "high ambient context." You need every issue to be one Slack ping from the right person. You need a stable enough team that people remember when something came up before.
That's an accurate description of the requirement. It's also a description of something that degrades with team size. Ambient context isn't an engineering choice — it's a function of headcount and physical proximity and shared history. The reason post-backlog requires small teams is that small teams are the only ones with enough shared context to operate without a written record.
Scribe manufactures that ambient context artificially. When every engineer's AI sessions are team-visible and searchable, you don't need to sit near someone to know what they've been working on. You don't need a stable team to know an issue was already investigated. You don't need to ping someone to find out who understands a codebase area. The record exists — and it was written for free as a byproduct of the actual work.
The ceiling on post-backlog engineering isn't philosophical. It's informational. Teams hit it because shared context can't be maintained past a certain headcount. Solve the information problem and the ceiling moves. That's what Scribe does.
The memory layer, not another tracker
Scribe isn't a ticket tracker. It doesn't ask engineers to update anything, file anything, or maintain any artifact for the benefit of the org. That's the premise of the old model — and it's exactly what post-backlog teams correctly rejected.
Scribe is the memory layer for teams that already decided tickets are wrong for them. It captures what those teams actually produce — AI conversations, git commits, file changes — and makes that record searchable, team-visible, and billable. The work is already happening. Scribe just makes sure it doesn't disappear.