Your AI Backlog Grows Faster Than You Close It

The night before this week's session, one operator had Claude mass-close more than 500 GitHub issues. Claude created this impressive backlog over a few weeks. The bugs were outdated, irrelevant, and simply too numerous to wade through.

The takeaway: Producing work got cheap; absorbing it — reviewing, deciding, merging — did not. The operators getting value have built ways to say no: batched waves that forbid new spawns, triage that asks whether any of it matters, context files pruned back to an index. Production is cheap now. Your attention is the budget.

What follows are notes from this week's Executive AI Roundtable discussion, shared under the Chatham House Rule.

The Backlog Is the New Bottleneck

One team adopted AI with almost no resistance. What broke was everything downstream of writing the code: "I feel like the old model of feature branches is a little bit broken in this model." Developers spin up a branch, AI writes the code, AI reviews the AI-written code, "and it goes round and round, and it's very noisy." The measurable result: "Now we have 10 times as many feature branches as we used to have."

Another operator described the same dynamic one layer up, in the issue tracker. Claude is "super good at finding lots of insignificant bugs, and spending a shitload of time, and not doing anything useful for me." Worse, the automated reviewer would block a pull request over a pre-existing production error that had nothing to do with the change under review. Every issue spawned more issues. Hence the mass closure of 500-plus tickets in one night, simply to get unstuck.

My own version is less dramatic and just as persistent. I no longer get a stale backlog once a quarter; I get one every week — "this backlog of junk that no longer makes any sense, because that code's long gone."

The pattern underneath all three: production got cheap, and judgment did not. Every process artifact that used to arrive at human pace — plans, branches, tickets, review comments, designs, documentation — now arrives at machine pace.

Batch the Work, and Keep It Serial

One founder runs agents overnight — the graveyard shift pattern — and has since built a governing layer on top.

The run no longer starts from the backlog as found. It starts by ingesting everything outstanding — incoming bugs, epics, the strategy document — and asking a frontier model what these items have in common, then consolidating many issues into fewer. That consolidated set becomes a wave, parallelized against a dependency graph. The waves themselves run one at a time — consolidate, run, reconsolidate, run again. Parallelism lives inside a wave; nothing crosses between them. "It's batch processing. It's defining what the batch is going to be, not based on just taking whatever the backlog was, but analyzing the backlog to create a more intelligent version of the batch."

Then comes the rule that does the actual work: "I don't let them spawn anymore. Whatever they spawn doesn't get done in that wave." Any issues the agents discover mid-wave are deferred to the next consolidation pass. The arithmetic they described: 100 issues consolidate to 50, of which the system judges 25 worth running.

Two results followed. The volume of pull requests dropped — still an order of magnitude above a single human, but no longer unreadable. And a specific failure mode receded: solving one problem in seventeen places across the codebase was an August problem and is not a September one. Consolidating the work intelligently reduces duplication. The instruction that helped it reason like a senior engineer was "to not just be looking at the work that's directly in front of it, but how does it fit together with the rest?" Their framing: the best kind of efficiency is the work you never do at all.

It costs something. You could write more code overnight with parallel agents. They accept the opportunity cost in exchange for a backlog that converges rather than grows.

Ask Whether Any of It Matters

Automatically consolidating a backlog before you run it takes infrastructure. You can also take a more manual approach; when an agent finishes a chunk of work and offers me the next tickets, I ask for a prioritized list, keeping in mind the strategy: "let's go back to the big picture. Do any of these matter?"

Most of the time the answer arrives immediately — roughly nine in ten of the proposed items have nothing to do with the goal. They get backlogged, deleted, or closed.

A similar approach works for bug triage; AI sometimes sees catastrophe in minor issues. "Sometimes if you just say, wait, is that really that horrible of a thing? And it's like, well, oh, actually, on second thought, thank you for pushing back on me. Actually, that's not a big deal at all."

I haven't built any automation around bug prioritization, but I plan to add it to a Claude workflow.

One attendee offered the systematic version. Rather than asking the AI for a verdict on importance, hand it a scoring framework — they named WSJF and prioritization tools like Ducalis — and have it produce the scores. The ranking then comes out as numbers and stated reasons instead of a judgment the model renders differently every time: "this is the next item because of these scores and these reasons."

Another attendee suggested "You need blinders" — scope discipline, so the agent stays on the change in front of it instead of being pulled off by a problem it noticed somewhere else.

A Release Pipeline Powered By Silence

One operator running eight concurrent Claude sessions, each in its own git worktree, has replaced release planning with a timer.

Development work pushes straight to master. Master deploys continuously to a canary environment that, by design, blends whatever every Claude session is doing. Each push resets a twelve-hour clock. When master goes untouched for twelve hours, that build promotes to beta, which automatically deploys to that environment. Three days later, it promotes to early access, which reaches friends, family, and early-adopter customers. Five days after that, those changes promote to a stable release, which reaches everyone. Each stage is an isolated tenant running the full stack, and they can force a promotion when the code is at a good resting point.

Their verdict on it: "It's kind of beautiful. It's kind of working for me really well."

Then the limit, stated by the person who built it: "I feel like it's really not going to work if I just turn that loose to nine developers on our team." Nine developers across time zones never produce a twelve-hour silence, and one ready feature can't ship without shipping everything else in the blend. Another attendee suggested a different approach — a release train, with fixed departure times rather than a silence detector.

A practice that works beautifully for one person can be structurally impossible for nine, and AI widens that gap rather than closing it. More on why the tools assume a team you don't have in AI Coding Tools Assume a Team You Don't Have.

Documentation Debt Is a Real Line Item Now

One team gave their developers an instruction that worked for twenty years: keep the documentation and architecture notes current. Under AI, that instruction produced a CLAUDE.md of 1.5 megabytes that "made every session just complete trash."

The cleanup required sharding the monolith into individual files and replacing the instruction entirely. The new one asks a question before anything gets written down: is this super valuable? The premise behind it: "every additional line has, like, an exponential cost." The founder who described it called the category documentation debt, and noted the strangeness of the work it now creates: budgeting real hours to make documentation smaller, which is "kind of a bizarre thing to be spending time on compared to anything you would have thought 5 or 10 years ago."

A founder elsewhere in the call arrived at the same destination from the opposite direction. Their root context file holds no content at all now: "I think of that file as like the back of the Argos catalogue now." The back pages of a mail-order catalog, all index — "it's just an index now for everything else, and then that index points to all your other documentation."

An attendee who reviews a lot of these files stated the governing rule plainly: keeping every file the model reads "as tight as possible is, like, the number one" priority. They have seen context files that consume the session allowance on their own, before any work begins.

Nobody Has Written the Manual for Directing AI

Every operator in the room is improvising, and one founder explained why. Documentation, skills, and agent instruction files are a new category — "So I call it cognitive code, the documentation, because it's what we're telling the AI directly to use." Unlike ordinary code, there is no corpus of it to have learned from. "There's no training on the best practices. It's utterly new stuff."

Which produces the situation they described with some amusement: "The irony is we're like, but you should know how you work. But of course it knows how it works as well as we know how our own brains work." The opportunity in that: "if you're able to figure out stuff that works well, then that's new insight in the market."

I hit the same wall from the practical side, directing AI to build AI systems: "the prompts that it generates are terrible prompts." The workaround is embarrassingly literal — I tell Claude to go read Anthropic's own documentation on writing better prompts, and then it comes back with something much better. "AI doesn't know how to do AI. It's hilarious."

For instance, Claude had constructed a prompt itemizing forbidden activities instead of following the current advice to state instructions positively. Models and people alike misread negations.

The same absence shows up in how the output reads. My global prompt — not a per-project file, the global one — carries an instruction against mannered prose, which is the padding of foreshadowing and self-congratulation: "there's expository, like, there's foreshadowing, like, 'oh, and now for the really important bit.'" The tell that started it: "'And then we stuck the landing!' ... Just tell me what you did."

For plans and technical documentation, I go further and ask for sixth-grade English, which buys unambiguity more than simplicity — "it just prevents a lot of metaphor and compound sentences that are difficult to decipher and easy to misinterpret." A plan I can scan and approve is worth more than a plan that reads well. One attendee keeps a skill for the same purpose, pointed at output rather than input, invoked whenever a wall of text arrives: "I have a skill that's called Wait What?" — and "it just concisely simplifies everything, almost like it's explaining it to a fourth grader." Another suggested borrowing the aerospace industry's controlled language, ASD-STE100 Simplified Technical English, as the target register outright.

Turn Adversarial Review Off at the Edges

Cross-provider review has become standard practice in this group. One operator's rule is to always send work to a different vendor than the one that produced it: "I use adversarial review, and I always cross the street for it." Which side authors and which side edits is a per-project decision, not a fixed hierarchy — "The question is, who's the author and who's the editor? And I start from both sides." I use my open-source impasse skill for this. More on the method in AI Code Review by a Rival Model.

An attendee added a variant that costs one sentence and no setup: "send this to a blind reviewer." Claude spawns a sub-agent without the working context, so the reviewer doesn't inherit the conversation's accumulated assumptions. "I think that adversarial reviews are probably underrated, and then I also think that blind reviews are underrated, too."

The new finding was about when to switch it off. "There was big profit in turning off adversarial review when I'm in the earlier discovery or prototyping phase." Nothing depends on the code yet, and the round trip dominates the loop. The second exception is sharper: during a deep refactor, "80-90% of the time was being spent in AR" — adversarial review. The reviewer treats every incremental change as a threat to the rest of the codebase and defends against it — precisely wrong when the job calls for "some really big cuts."

Adversarial review is a tool for changing code that already works. At both extremes — a blank page, or a rewrite that intends to break things — the reviewer's instinct to protect what exists works against you.

Give the System Authority to Interrupt You

One operator has built both a business operating system and a personal one, and gave the personal one a power most people would not hand over: "I've given it the authority to tell me, you spend too much time on certain things, like, that's not moving the needle."

That verdict needs data, and commercial time trackers weren't accurate enough. So they had Claude build a replacement: a tool that "every 15 seconds just can check and see what I'm working on." Each evening, it tallies time by category and asks whether it got the categories right, so corrections train it. A weekly review compares intended allocation against actual — the kind of report that surfaces a sentence like you spent zero time on marketing.

An operator building a business OS described a related feature in their own system: it issues prevarication alerts when you are visibly working on one thing while claiming another is the priority, and it carries a standing question baked in as a design principle — what is the number one thing? It is the most disciplined set of Claude skills I have seen.

The counterweight arrived as an analogy about a very light racing bike making "the square root of f*** all difference to how fast I go uphill, because the limiting factor is the" rider. My version: being 10% better at your tooling probably matters far less than focusing on the number one thing in your business. Customers don't care which model, if any, builds your product.

The Bug Count Nobody in the Room Believed

Asked when they last saw a bug, one founder couldn't produce a recent one: "the only time we're seeing bugs, really, is when we've got something wrong in the plan at the start." They floated the logical conclusion — "Can we just do away with testing, and can we just skip that part, just spend all our time on planning?"

The pushback was immediate and came from three directions. One technical founder: "I don't think I've experienced that, so maybe you have the magical prompts." A line from the chat, which I read out: "If you don't test, you won't see bugs." And the line that closed it, an hour later when the claim resurfaced: "Be afraid of the questions that you ask if you think you have no bugs."

To be fair to the claim, the mechanism behind it is real and worth copying even if the bug count isn't. Plan review is where their quality gate actually sits — "it's really forcing yourself to do a good plan at the start. It's too easy to skip it and just accept it" — to the point of considering printing plans out to read them properly. Their commits show the discipline structurally: roughly a third of a typical diff is skills and documentation, a third is unit tests, and a third is the code that does the thing. Documentation and agent skills live in the same repository as the code, so the workflow keeps all three in sync on every commit.

They also supplied their own doubt: "It sounds a bit suspect, though. I don't think I would be that person."

Find the Constraint That Isn't Code

One founder's growth limit is onboarding: 40 to 100 hours of human work per customer, spread across roughly three months, with 40 to 50 hours spent on account setup alone. They rebuild each client's entire existing workflow inside the product. Their own assessment of the economics: "We need to drive them up, because the hourly behind it is rubbish."

The advice from the room was pricing, not automation. The counterintuitive part was the history — charging nothing for onboarding wasn't winning them customers, and charging for it seemed to help, alongside other changes they made at the same time. "We'd get taken seriously then." Another founder pushed it further: an expensive setup signals a white-glove product, which can win sales rather than deter them. I suggested sizing the fee so it funds the growth of the delivery team, which turns onboarding from the ceiling on growth into the thing that raises it.

Nobody in the room claimed AI had solved any of this. The constraint on that business is human hours and pricing courage, and no amount of agent throughput touches either one.

Everyone Is a Pre-AI Engineer

Asked at a party what they do for work, one attendee has started answering: "I'm a pre-AI engineer." My response: everybody is. Nobody has figured this stuff out yet. For every article announcing that product managers are now engineers, my read is — maybe you're better off if your engineer knows something about product management than if your product manager is using AI. But I don't know. We'll see.

That admission is scarce, and the gap it names is wide. One attendee, who has these conversations with a lot of CEOs, described the pattern: "there's lots of CEOs, you know, we've had these conversations for, oh, you know, 'I'm AI native,' and it turns out they've used ChatGPT." In one case, a CEO had told their CTO the company must be AI-native, while that same CTO refused to allow Claude on the CEO's machine as a security risk. Meanwhile, "there's an extraordinary amount of people who are sort of using it in a very, very casual way" with no practice to lean on.

The failure mode waiting at the other end — among the operators running the most machinery — was named by someone else in the room: fake work. It was the answer to a description of the pull of an accelerating tool: "The more you have it, the faster you go, the more brilliant you are, and then you wake up the next morning, and you're like..." The antidote offered was deliberately low-tech: "I think there's something about pen and paper and humans." The attendee who runs adoption programs refuses to let participants automate anything at first — "I'm generally trying to get people not to do anything in an automated way. Because I think you learn so much by setting the systems up."

Both halves are true at once. These tools are the most useful thing to happen to a small company's leverage in a generation, and the speed they create is exactly what makes fake work feel like progress. The operators doing best in this room have built something that says no.

Where to Start

• Cap what your AI creates at what you can close. Pull the last month of issues, branches, and pull requests; if created outpaces resolved, that's a process failure, not a productivity win.
• Forbid mid-run spawning. Whatever your agents discover during a batch goes to the next batch, not this one. Consolidate before you execute.
• Add the big-picture question to your review loop. Before accepting a proposed list of next steps, ask whether any of them serve the goal. Delete the ones that don't.
• Match your release process to your headcount. Promotion-on-silence works for one person and breaks at nine; a team needs fixed departure times instead.
• Shrink your context file. Shard it, make the root file an index, and price every added line as a permanent tax on every future session.
• Turn adversarial review off for prototypes and deep refactors. Keep it for work on an existing codebase, and send the review to a rival vendor.
• State instructions positively, and demand plain language. Tell the model what to do rather than what to avoid, and specify a reading level for plans and documentation.
• Review the plan, not just the diff. The operators seeing the fewest bugs moved their quality gate to plan review — print it out if that is what it takes to read it properly. Keep testing anyway.
• Measure where your time actually goes before you optimize it. Give one system the data and the standing permission to tell you the answer you won't like.
• Find your real constraint before you automate anything. If it's human hours in onboarding or delivery, reconsider your pricing first — agent throughput won't touch it.

Resources From the Roundtable

• Claude Code — the default harness for nearly everyone in the room; sessions, sub-agents, skills, and the CLAUDE.md context file under discussion all live here.
• OpenAI Codex — the other half of the cross-vendor review pattern, and where one operator's overnight waves are launched.
• impasse — my open-source skill for cross-provider adversarial review; installs into Claude Code, Codex, or Cursor and finds the rival models you already have.
• git worktree — the mechanism behind running eight concurrent AI sessions on one repository without them colliding.
• WSJF — Weighted Shortest Job First, the scoring formula suggested for making AI prioritization deterministic rather than vibes.
• Ducalis — prioritization software raised as the off-the-shelf version of the same idea.
• ASD-STE100 Simplified Technical English — the aerospace controlled-language standard, proposed as a target register for AI-written documentation.
• Obsidian — the local markdown vault one operator uses for AI-facing notes, after Claude Projects failed to find files stored on a cloud drive.
• Notion — where one operator reads the briefs their overnight agents produce, deliberately outside the chat.
• Rize — the commercial time tracker that wasn't accurate enough, and got replaced by a purpose-built Claude tool.