Coding Isn't Programming

LLM “Vibe Coding” and Productivity

  • Several comments discuss “vibe coding” as using LLM agents to generate almost all code, with humans mainly guiding, configuring, and reviewing PRs.
  • One poster claims they no longer hand‑write frontend code and achieve “team‑level” output via agents.
  • Others report occasional “mind‑blowing” results from LLMs but say this is rare and inconsistent.

Skepticism About LLMs and Complexity

  • Many participants say LLMs work well for boilerplate, common stacks (especially React/frontend), and small scripts, but break down around 100–300 LOC or when full‑codebase context is needed.
  • Observed problems: looping between a few wrong templates, non‑compiling code, forgetting prior edits, deleting needed code, poor performance on niche tools/languages, and inability to handle real business‑scale complexity without strong human guidance.
  • Predictions that “everything will change next year” are compared to repeated self‑driving car timelines; several expect disappointment and note lack of a clear “Moore’s law for LLMs.”

Lamport’s Thesis: What vs How, Algorithms vs Programs

  • Multiple summaries of the talk:
    • Programming should be “thinking and abstraction first, then coding.”
    • Algorithms are abstract; programs are concrete implementations.
    • Executions should be modeled as sequences of states; invariants (properties true in all states) are central to correctness, especially in concurrency.
    • Good specs separate what a system should do from how it does it; without specs, behavior can’t meaningfully be called “correct” or “buggy.”
  • Commenters generally agree abstraction and explicit behavior design improve correctness, but some argue “what” vs “how” is purely relative abstraction, not a hard boundary.

Max-Function / Negative-Infinity Example

  • The talk’s “find max in an array” example and use of “−∞” to handle empty arrays spark debate.
  • Critics note ambiguity between an empty array and one containing only −∞, and argue for explicit error flags or non‑empty types instead.
  • Others say the −∞ trick is acceptable at the abstract/spec level, with mapping to error handling done at implementation time; some point out the spec is closer to a supremum than a maximum.

Terminology: Coding, Programming, Software Engineering

  • One camp says “coding/programming/software engineering/hacking” are effectively interchangeable in practice; arguing fine distinctions is unhelpful pedantry.
  • Another camp insists the distinctions matter:
    • Coding = producing code;
    • Programming/engineering = designing systems over time, handling correctness, maintainability, concurrency, safety, etc.
  • Some see the “coding isn’t programming” line as a post‑LLM move to define human value as design/abstraction rather than typing code; others note this debate long predates LLMs and echoes older “bricklayer vs architect” tensions.

Professionalization and Title Gatekeeping

  • Discussion of “software engineer” as a protected title in some jurisdictions (e.g., parts of Germany) leads to broader debate:
    • Pro‑gatekeeping: society needs licensed professionals (like civil engineers, doctors) when failure has serious public consequences.
    • Anti‑gatekeeping: paper credentials often block capable practitioners, with historical examples where great contributors lacked formal recognition.
  • Some argue that for most software (non–safety critical), strong licensing is unnecessary; for safety‑critical domains, responsibility should rest on domain‑specific regulations and audited tooling.

Pedantry, Formalism, and Accessibility

  • Some find the talk and thread “insanely pedantic,” others say the industry’s low rigor justifies more pedantry.
  • The shift from plain language to mathematical logic in the talk is criticized as alienating to most practitioners and reminiscent of waterfall/UML‑style processes; defenders say more formal math/logic training for programmers would be beneficial.
  • There is acknowledgment that abstraction and specs are powerful, but also concern that highly formal methods are usable only by a small subset of mathematically trained developers.