Shipping is cheap now. Deciding what to ship is the bottleneck
For most of software history, the expensive step was building. Deciding what to build was cheap by comparison — a founder's conviction, a customer call, a planning meeting — because whatever you decided, engineering would take weeks to deliver it, and the queue in front of engineering hid every other problem.
Coding agents broke that arrangement. When a well-specified issue can become a reviewed pull request in hours, the queue in front of engineering drains, and whatever was hiding behind it becomes the new constraint. What was hiding is the decision: knowing which issue is worth writing well enough to hand to an agent in the first place.
“export fails on big workspaces”
“CSV export times out for us”
“exports broken since Tuesday”
a coding agent
PR openedreviewed by a humanThe bottleneck didn't disappear, it moved
The engineering-side version of this story is now well documented. Teams adopt AI coding tools, code output jumps, and delivery barely moves, because review, QA, and deployment weren't accelerated with it — GitLab calls it the AI paradox, and Built In has covered the same productivity puzzle. Teams that do clear their backlogs then hit the wall behind it: cross-team dependencies and human-speed decision-making.
But review and QA are being tooled up too, and they are downstream problems — they slow down code that already exists. The upstream problem is stranger: code increasingly exists before anyone has decided the work is valuable. CodeRabbit's framing is the cleanest we've seen — better models don't solve a judgment bottleneck — a prompt or a support ticket can become a proposed change before the organization has established its priority. When building is nearly free, the cost of building the wrong thing doesn't fall. It just gets paid faster, in review time, maintenance surface, and product sprawl.
Why "just decide faster" doesn't work
The tempting response is to treat deciding as a throughput problem: more planning meetings, faster grooming. But decision speed was never the constraint — decision quality under thin evidence was. Most teams decide from a backlog that is a poor proxy for reality: duplicated requests filed under different names, bugs with no sense of how many customers hit them, feature ideas with no revenue attached, and the loudest recent conversation over-weighted because it's the one people remember.
That backlog was tolerable when engineering capacity forced you to pick three things a quarter; errors got absorbed by the queue. When agents let you act on twelve things, a mis-ranked backlog turns capacity directly into waste. The evidence pipeline — capture, dedupe, quantify — was always sloppy. It just never had to be the load-bearing part before.
The decision layer is an evidence problem
The fix is not a smarter prioritization framework. RICE scores computed on bad inputs are bad scores with decimals. The fix is making the inputs true:
- Every request captured where it lands — Slack, support, sales calls, GitHub — not just the ones someone remembered to file.
- Duplicates merged by meaning, so demand concentrates into countable themes instead of scattering across forty phrasings. This is what feedback aggregation means in practice.
- Each theme carrying its requesters, accounts, and revenue, so "how many people want this and who are they" is a lookup, not an archaeology project.
This intake work is high-volume and low-judgment, which makes it the part AI does reliably today — the same models that made shipping cheap make triage cheap. Disclosure: this is the layer we build. Modem does the capture, dedupe, and quantification automatically and files the results as tracked issues, on the theory that humans should spend their scarce attention on the ranking, not the bookkeeping. The dedupe holds across channels because the same issue and the same person link into one context graph, which is what makes a theme's count something you can rank on. Our approach is at AI feedback triage. Whatever tool you use, the point stands: the decision layer is only as good as the evidence under it.
What stays human is the actual call. Evidence can tell you twelve enterprise accounts want SSO; it cannot tell you whether serving them beats the self-serve motion you'd rather run. That judgment — strategy against evidence — is the job that's left, and it's a better job than triage was.
What this looks like on a team
The teams adapting fastest have quietly inverted their process. Instead of quarterly planning producing a list that engineering slowly executes, a continuously-triaged backlog produces ranked, evidence-backed candidates, humans make fast calls on what clears the bar, and well-specified issues flow to engineers and agents as capacity frees up. The planning meeting shrinks into a standing review of what the evidence says has changed.
The prerequisite is that issues are written well enough to execute without a clarifying meeting — agents are unforgiving about this in a way junior engineers weren't, which is its own topic: how to give coding agents a backlog they can execute.
The uncomfortable version of the conclusion
"Deciding is the bottleneck" flatters product people, so treat it with suspicion: it can be read as "my meetings matter more than ever." The operational version is less flattering. Deciding is the bottleneck, and most of what makes deciding slow and wrong is clerical — unread feedback, uncounted demand, duplicated tickets — and the clerical part is now automatable. Teams that automate it get a real advantage: their judgment runs on true inputs at the speed their agents can build. Teams that don't will keep shipping the wrong things, faster than ever.
