BrusselsRequirements, not coding speed, are software’s real bottleneck.
Queueing theory shows speeding a non-bottleneck leaves cycle time unchanged; in software, the constraint is requirements and review, not code.
Most enterprise AI deployments target code generation, leaving requirements-cycle time unmeasured.
Sources: Hacker News
THE CORE LAW
Eliyahu Goldratt's Theory of Constraints (1984) states that any system's throughput is determined by a single bottleneck. Improvements anywhere else are illusions — the queue just shifts upstream or downstream of the real constraint.
LITTLE'S LAW
In any stable queue, average cycle time equals work-in-progress divided by throughput. Doubling coding speed without reducing the requirements backlog just grows the WIP pile — features sit longer waiting for clarification, review, or deployment.
WHERE SOFTWARE TIME ACTUALLY GOES
Multiple industry studies (Forrester, McKinsey, DORA) consistently find developers spend 20-30% of time writing new code. The rest is meetings, requirements clarification, code review, testing, debugging, and deployment coordination.
THE BROOKS PRECEDENT
Fred Brooks made the same argument in 1975's The Mythical Man-Month: the hard part of software is not writing code but deciding precisely what to build. He called requirements specification the task where conceptual errors are most expensive and most common.
THE MEASUREMENT GAP
Enterprises track lines-of-code, PR velocity, and commit frequency because those metrics are easy to instrument. Requirements-cycle time — from idea raised to specification frozen — is rarely measured at all, so AI's effect on the actual bottleneck remains invisible.
WHY AI TARGETS CODE ANYWAY
Code is text with a formal grammar, abundant training data, and verifiable outputs — ideal for LLMs. Requirements elicitation is tacit, political, and cross-functional, which is exactly why it remains the constraint and why no tool has automated it in fifty years.