-​-dangerously-skip-reading-code

Original Article ↗ Hacker News Discussion ↗

Scope and limits of “code conforms to spec” automation

  • Several comments argue full automation is impossible in general (halting problem, Rice’s theorem), but others note practical subsets can be checked, especially for “human-comprehensible” programs.
  • Formal verification exists (PSL, Lean, total functional programming, theorem provers), but writing precise specs/proofs is harder than writing code and rarely scales to whole systems.
  • Natural-language specs are seen as too ambiguous; any spec precise enough for formal checking effectively becomes a programming language.

Specs, markdown, and “code as artifact”

  • Many discuss shifting rigor from code to specs/tests: markdown/RFC-style specs as primary artifacts; code and tests generated from them.
  • Some propose plans/specs as the PR unit; implementation is “just” an artifact that could even be regenerated from scratch.
  • Skeptics point out this resembles long-standing requirements-management tools and methodologies (UML, BPML, DOORS, CASE, PRIDE) that never eliminated programmers.
  • Several note that highly detailed specs “are the code”; if the problem were just missing rigor in specs, it would have been solved before LLMs.

AI-generated code, review, and reliability

  • Strong concern that LLMs make human-style mistakes but faster, and humans are poor at spotting subtle misalignments in unfamiliar code.
  • Some envision near-future “infallible” agents; others counter that current systems still make the same structural errors, with no clear path to infallibility.
  • Treating LLM output like bytecode and not reading it is criticized: bugs (especially security/privacy issues) require responsibility and human understanding.
  • Proponents argue heavier automated testing and spec-driven harnesses can provide sufficient confidence, but critics doubt tests alone can cover all critical behaviors.

Process, economics, and organizational effects

  • Many push back on “rework is almost free”: real systems have customers, data migrations, UX expectations, and public APIs that make change expensive.
  • Commenters see AI as drastically reducing coding time, but not the need for product understanding, coordination, design, and quality assurance.
  • Some compare AI enthusiasm to outsourcing hype: better specs, more tests, and tolerance for mediocre code often end up more work than doing it well directly.
  • There’s concern about “slop coding”: maximizing LOC and agent activity over maintainability, and about leadership mandates for spec-driven/agentic processes that engineers find low value.

Tools, languages, and spec styles

  • Suggestions include RFC 2119 keywords, XML/OpenSpec formats, contract-based languages, and theorem-prover-backed languages.
  • Experience is mixed: such approaches can steer models well when specs are complete, but specs often become verbose, granular, and harder to read than code.