The post argues that AI has made code generation cheap, which means software teams need more discipline around specs, tests, design intent, and other engineering artifacts rather than less. The core claim is not that code stops mattering, but that if machines can generate and regenerate code on demand, the durable asset becomes the human intent behind it and the constraints that keep the output safe. The article leans on an analogy to infrastructure as code, where the big win was not faster clicking in dashboards but an auditable record of how systems got into their current state.
Most people reading it accepted the headline and argued over what that actually means in practice. The strongest point was that the immediate bottleneck is not code generation at all. It is evaluation. Teams are already drowning in plausible looking pull requests, design docs, roadmap docs, and auto-generated reviews. The new scarcity is human attention, context, and judgment. Several people said this has broken old heuristics for spotting strong engineers. Volume, polish, and perfect formatting used to signal work. Now they often signal that someone can drive a model. What still stands out is who can reduce moving parts, make better decisions, and produce clearer outcomes.
A second theme was that review itself is getting warped. Large PRs were already hard to review before LLMs. Now they arrive faster, with more files and extra generated explanation layered on top. Many commenters see this pushing teams toward rubber stamping, often with another
LLM in the loop, which misses the real value of review as both quality control and knowledge transfer. Several people argued that if AI is used heavily, the thing worth preserving is the prompt trail, plans, and decision history that led to the code. Shipping only the generated diff and discarding the reasoning is backwards because it throws away the only durable clue about why the implementation exists.
The consensus landing point was blunt. AI can help disciplined teams move faster, especially on explicit, defensive, well-constrained work. It does not rescue weak design, missing context, or unclear requirements. In fact it amplifies them. That leaves companies with a very practical choice. Either raise the bar on specs, tests, invariants, and review structure, or accept a bigger surface area of technical debt, incidents, and shallow understanding masquerading as productivity.