I'm dialing back my LLM usage

Original Article ↗ Hacker News Discussion ↗

Overall sentiment

  • Many experienced developers report initial enthusiasm followed by dialing back usage, especially for large, integrated features.
  • Consensus: LLMs are powerful assistants but poor autonomous programmers; value depends heavily on scope, context size, and user discipline.
  • Thread repeatedly contrasts “AI as tool” vs “AI as replacement,” with most arguing strongly for the former.

Where LLMs work well

  • Small, localized tasks: single functions, tests, log statements, small refactors, simple scripts, boilerplate/scaffolding, CRUD wiring.
  • “Super-StackOverflow”: quick conceptual explanations, surfacing APIs, brainstorming designs, pointing to docs or man pages.
  • Frontend/UI glue (HTML/CSS/JS/Tailwind) and repetitive patterns (e.g., model wiring, controllers, tests).
  • Code review and lint/static-analysis help: often catching real issues, though mixed with noise.
  • Architecture comprehension: summarizing large code areas, generating diagrams and docs, helping navigate under-documented systems.

Where LLMs fail or backfire

  • Large, tangled or legacy codebases; background “agents” often get lost, loop, or create messy diffs.
  • “Vibe coding” entire features/apps: leads to balls of mud, loss of mental model, and feeling like “the new guy on your own project.”
  • Subtle bugs and hallucinated APIs; plausible-but-wrong answers can waste more time than obviously wrong ones.
  • Poor at obscure or niche solutions (e.g., specific DNS records, shader code, SIMD) unless heavily guided.
  • As autonomous agents across a repo: many report loops and breakage within minutes, not the promised fully-automated workflows.

Mental models, ownership, and code quality

  • Strong emphasis on programming as “theory building”: if you don’t build the theory, you can’t truly maintain or debug.
  • Reviewing LLM code is likened to endlessly supervising a zero-trust junior; reading bad code is slower than writing good code.
  • Several insist: if you commit it, you own it—“but AI wrote it” is not a valid excuse.

Effective usage patterns

  • Treat LLM as a junior pair-programmer: you decide architecture, write design docs, keep high-level control, review every change.
  • Keep tasks small, write tests first, use modes that separate “ask/inspect” from “edit,” and stop using the model after 1–2 bad iterations.
  • Some adopt rules like “I type every character myself; AI only suggests” to retain understanding and skill.

Skills, cognition, and long‑term concerns

  • Fear of “steroid” effects: short-term productivity boosts, long-term erosion of problem-solving and coding skill.
  • Worries about choosing easy AI-amenable work (more code) over hard engineering work (thinking, design, coordination).
  • Debate over whether next-token predictors can ever handle true program “theory”; some see hard limits, others expect continued incremental gains.

Hype, economics, and skepticism

  • Many note a repetitive HN pattern: “LLMs are great but messy” vs “I’ve 2–10×’d output with agents,” often without code shown.
  • Some attribute aggressive pro-agent narratives to VC incentives, influencer culture, and native advertising.
  • Broad agreement: LLMs are already very useful tools; using them as autonomous coders for complex, long-lived systems remains risky and immature.