--dangerously-skip-reading-code
AI-generated code is renewing old dreams of specifying software in prose or Markdown while machines handle the implementation, raising the prospect that engineers might one day stop reading code altogether. Commenters argue that shifting rigor to specifications, tests, and formal verification runs into both theoretical limits (like the halting problem) and long‑standing practical issues seen in UML, CASE tools, and requirements management systems. Many see current large language models as powerful accelerators for routine coding but emphasize that human understanding, responsibility, and careful design remain the real bottlenecks—and that overly spec-driven, agentic workflows risk producing unmaintainable “slop” rather than reliable systems.
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.