A LinkedIn post circulating this week made an observation worth sitting with. AI write-throughput in a serious engineering team can hit fifty pull requests a day. The team's merge-throughput is two. The author's own bug-finder product had hit the same wall on the customer side — initial deliveries of twenty findings per session, sometimes fifty, came back as a request for two a day. The findings were fine. The cost was elsewhere. Review, validate, merge, and regression-watch costs hours per item, multiplied by every engineer on the team, makes the math fall apart fast. The bottleneck moved. The new ceiling is what the team can absorb.
The diagnosis is right. The prescription the bug-finder category will produce — "rank better, surface fewer, prioritize harder" — repeats the mistake the cloud-runtime layer made before it. The right answer to "which two findings today" is not a smarter ranker. It is a different category of product entirely, and the path to getting there is the same one yesterday's piece on enterprise distribution walked at the policy layer.
"Which Two" Is a Values Question
The reason a ranking algorithm cannot answer "which two findings should this team look at today" is that the answer depends on information the ranker cannot see. The team had a customer-facing incident last Thursday that traced to a specific subsystem; findings in that subsystem are worth more this week than they will be in three weeks. There is a marquee launch on Wednesday; findings touching the deploy path or the feature flag system are urgent in a way no static rule will capture. The payments code is in calibration mode; the team treats finding-class A as cosmetic in payments and catastrophic in identity. The new hire is reviewing in their first week and the standards have been deliberately relaxed for their first three PRs so the team can see how they reason about ambiguity.
None of that is in the codebase. It lives in the team's lived context — incident logs, deal calendars, code-area maturity assessments, hiring decisions, the conversation in last Friday's retro. A ranker that looks at the AST and the static analysis output and the commit history is solving the prior problem, which was "find more bugs." The product problem now is "let the team encode its own values in a way the finder can rank against." That is an authoring problem. Calling it a ranking problem will produce a generation of finders that compete on signal-to-noise and lose every renewal at the eighteen-month mark when the customer realizes the signal-to-noise was never the bottleneck.
What Absorb Rate Actually Depends On
A team that absorbs ten changes a day without a regression has done specific things to make that possible. The CODEOWNERS file is calibrated so the right person sees the right change without a thread of "who should review this?" The review template asks the questions that surface blast radius before line-level critique — what does this touch, what could fail under load, what is the rollback path. The merge gate is configured to catch the failure modes the team has actually hit in the last six months, not the ones some other team hit in a different stack. The on-call rotation is staffed at a level where the engineer who merges at four pm is not the engineer who pages at midnight, so the merger has slack to think.
All of those are practice artifacts. None of them are product features. A team that has done this work absorbs more change with less risk than a team that has not. The output of the work is review craft, codeowner judgment, lint config that matches the team's specific failure history, and a culture in which the question "what could break this?" gets asked before "is this style-correct?" The ceiling moves. The work to move it is craft work, and the category-level honesty about it is what bug-finder vendors will eventually be forced into when their growth model bumps the absorb-rate cap on every account.
Where the Customer Feedback Was Pointing
The post's most useful detail is the customer telemetry. Twenty findings per session, sometimes fifty, came back as a request for two a day. Read that as a UX complaint and the answer is a ranking algorithm. Read it as a domain truth and the answer is different. Customers are saying that the unit of useful work in their environment is "two items per day that fit the team's actual attentional budget after the rest of the day's responsibilities," and that the input format of "fifty findings ranked by static severity" is the wrong shape for that unit. The product question is not "how do we surface the right two." The product question is "how do we let the team author the filter that determines what the right two means for them this week."
That is the wrapper-pattern argument at the bug-finder layer. The vendor provides the surface; the operator authors the standard that runs against the surface. The vendor that ships a configurable filter — backed by the team's own incident log, codeowner-weighted blast-radius scores, deploy-calendar awareness, individualized risk profiles per code area — is shipping for the actual market. The vendor that ships a "smarter default ranker" is shipping for a market that exists only in the spec doc.
The Generation-Absorption Gap Is the Signal
The gap between "AI ships 50, your team merges 2" is being read in the category press as a problem to close. The category press has it backward. The gap is the signal of where the high-yield work now lives. The work has moved from writing code to judging code — to deciding which changes are worth the absorb cost given everything the team is doing this week. Judgment is not a product feature. Judgment is a praxis output, accumulated from sustained time in the actual work, encoded in the artifacts the team produces and the conversations they have at standup.
The bug-finder category will split over the next eighteen months. The vendors that recognize they are selling into a judgment surface will build the authoring layer the operators need. The vendors that keep selling "more findings, better ranked" will hit the absorb-rate ceiling on every account and the renewal conversations will turn into pricing pressure. The cloud-runtime layer already played this out at a different layer of the stack. The pattern repeats.
The next layer at this scale is the same as the next layer at the enterprise scale. Authorship. Which operator, with what depth of context, encodes the rules that decide what gets attention today. The vendors did their part. The hard part is whether the team's judgment gets a place to live inside the product.
Top comments (0)