AI is forcing us to write good code

Original Article ↗ Hacker News Discussion ↗

Perception of the article and AI marketing

  • Many see the post as thinly veiled marketing for an AI startup (product link high on page, “minutes to production” slogan).
  • Some dismiss it outright due to polished branding and startup tone; others say the content matches their own experience and is genuinely useful.
  • Concern that non-experts (especially managers) will treat it as authoritative guidance and turn it into rigid policy.

AI adoption: solo vs teams

  • Commenters argue agents are far easier for solo devs than teams due to:
    • Diverse working styles and differing trust/enjoyment of agents.
    • Risk of a single “AI power user” overwhelming team capacity with sweeping changes.
  • Fast, ephemeral, per-branch dev environments are widely praised, both for agents and humans.

Testing, 100% coverage, and Goodhart’s Law

  • Strong disagreement over 100% coverage:
    • Critics call it bad advice for most projects; point to unreachable code, edge conditions, and industries (e.g. brakes) that do fine below 100%.
    • Supporters say line/branch coverage is a minimum bar for agents; tests are cheap when AI writes them.
  • Multiple people warn about Goodhart’s Law: if AI is judged on “lines covered,” it will generate meaningless tests (“1 == 1”) to satisfy metrics.
  • Some recommend focusing on branch or MC/DC-style coverage, property-based testing, and testing error paths rather than raw percentage.

Guardrails vs “good code”

  • Many note the article describes guardrails (types, tests, linting, environments), not inherently “good” design or architecture.
  • Risk: 100% syntactically clean, well-tested code that is still structurally bad or unmaintainable.
  • Several say humans should define type signatures, specs, and invariants; AI should fill in implementations and tests.

Capabilities and limits of LLMs

  • Positive experiences: AI accelerates boring code, test writing, refactors; pushes teams to improve DX, documentation, and naming so agents work better.
  • Negative experiences: agents generate slop, junior-level abstractions, and “tautological” tests; require heavy review that many devs won’t actually do.
  • Debate over LLMs as teaching tools: some use them for self-learning; others warn about confidently wrong explanations and shallow understanding.

Formal methods and spec-first workflows

  • A few describe promising workflows: write high-level specs (e.g. TLA+/PlusCal) or PRDs, then have AI implement code strictly to the spec.
  • Formal verification and property-based testing with AI assistance are seen as emerging but still immature.