Treating Code as Machine Code: The Shift to Spec-Driven Engineering

As LLMs make manual code review impossible due to the sheer volume of output, software engineering must treat code as a disposable implementation detail. Organizations must restructure to remove human bottlenecks and allow engineers to operate with greater autonomy. Consequently, the focus of engineering rigor must shift from writing and reading code to defining precise specifications and automated tests.

Key Points

• LLM-generated code should be viewed as a form of machine code or bytecode that humans no longer need to read or maintain directly.
• Organizational structures must change to accommodate AI speed, as traditional processes like manual code reviews and rigid coordination become productivity bottlenecks.
• Rigor must shift from the implementation level to the specification and testing levels to ensure software quality without manual intervention.
• Engineers should act as pseudo-product designers, owning entire streams of work and focusing on business logic rather than syntax.
• The new unit of knowledge for software projects should be standardized specifications that are automatically verified against AI-generated code.

Sentiment

The community is predominantly skeptical. While some commenters share practical spec-driven workflows they find effective, the majority view the article's premise as reinventing failed historical approaches. The strongest pushback argues that sufficiently precise specs are just programming by another name, and that AI has not solved the fundamental information-theoretic challenges of software specification. There is broad agreement that AI accelerates code production but deep disagreement that this means code can be treated as disposable machine output.

In Agreement

• Plan/spec files should be the unit of review rather than code — several commenters describe workflows where specs are checked in alongside implementation and the code becomes a disposable build artifact
• RFC keywords (MUST, SHOULD, MAY) in specifications improve LLM compliance and could formalize the spec-driven approach
• The shift is already happening in practice — some teams treat code as generated output from specs and harness configurations, with one commenter calling it 'clean room code generation'
• AI is changing the economics of human thought, and building more prototypes and one-off tools is a great use case even if core architecture changes are not
• Languages like Dafny with pre/post-conditions could enable LLMs to iterate on implementations until provably correct

Opposed

• A spec detailed enough to be unambiguous is essentially code itself — this fundamental problem predates LLMs and has never been solved
• Historical precedents (UML, CASE tools, BPML, PRIDE, no-code tools) all failed because they could not escape the inherent complexity of specifying software behavior precisely
• Verifying that code conforms to a natural language spec involves unsolved problems related to the halting problem and Rice's theorem
• The spec-driven pitch mirrors past outsourcing arguments: give better specs, accept bad code, rewrite later — but the orchestration effort exceeds just writing the code yourself
• Removing humans from the loop is nonsense — AI magnifies judgment of skilled individuals but cannot replace the need for understanding system behavior, dependencies, and real-world constraints
• LLMs make exactly the kinds of mistakes humans struggle to catch and have been optimized for persuasiveness, making review of their output fundamentally unreliable
• Rework is not free — the electricity, hardware, and coordination costs are real, and venture capital may be masking the true economics