Understanding-Capacity Gap

Problem

When the team treats raw generation throughput as the measure of progress, it commits to more output than anyone on the team can specify in enough detail to be unambiguous, verify against intent, or hold in their head as a coherent system. Each unverified change looks done because it compiles, reads fluently, and was merged, so the perceived productivity curve climbs. Underneath, the fraction of output that nobody has actually understood grows, and reliability holds only on the cases that happen to fall inside the team's shrinking verifiable frontier. Outside that frontier — the inputs, interactions, and assumptions nobody had the capacity to check — correctness silently degrades, and the gap surfaces later as defects, rework, and a system the team can no longer reason about or safely change.

Solution

The remedy is to treat the capacity to specify, verify, and understand as the binding constraint and to refuse to scale generation past it. Measure delivered, verified, understood output rather than raw generation volume, and make the unverified fraction a tracked, visible number that gates further generation. Cap work in progress to what the team can actually review and reason about, so each generated change is specified precisely enough to be checkable and is verified against intent before more is produced on top of it. Invest the freed-up production time into the labour that did not get cheaper — sharper specifications, stronger checks, and deliberate effort to keep a working mental model of the system — and define the team's verifiable frontier explicitly so work outside it is flagged as unvalidated rather than silently assumed correct. Where verification cannot keep pace, throttle generation rather than letting the gap grow.

When to use

• A team uses agents to generate code, documents, or analysis at a volume well above what it could produce by hand.
• Progress is measured mainly by generation throughput — changes shipped, tickets closed, output produced — rather than by verified, understood delivery.
• Output is merged or shipped on light review because it reads fluently and the build is green, so the unverified fraction is neither measured nor capped.