LLM-powered tools amplify developer capabilities rather than replacing them

How much of dev work is “just typing code”?

• Many argue the article overstates time spent on “how” (coding). They report most effort goes into understanding the domain, existing systems, and designing data structures and interfaces.
• Others counter that in some roles (frontend, consultancy, embedded) coding really is 80–90% of their day, especially when requirements and designs are handed down.
• Several stress that in real work the three “buckets” (why / what / how) form a tight feedback loop, not a waterfall; writing code reveals missing requirements and bad assumptions.

Planning, TDD, specs, and correctness

• Debate over how far you can/should design before coding: some advocate clear specs, tests, and even formal proofs; others say you only truly understand problems by “tinkering in code.”
• Skepticism toward strict TDD-as-dogma: unit tests often get thrown away as requirements change; many see more value in types, integration tests, and regression tests.
• Strong agreement that correctness lives in the real world and requirements, not in the code itself.

Where LLMs help – and where they don’t

• Broad consensus: LLMs are accelerators, not replacements. They’re strong at:
  • Boilerplate, glue code, unfamiliar APIs/frameworks, translations (e.g., Java→TypeScript, pandas→polars).
  • Explaining legacy/framework “inside baseball” and suggesting refactors or implementation plans.
• Weak spots repeatedly cited:
  • Non-trivial architecture, data modeling, and trade-offs.
  • Consistency across large codebases and long-lived refactors (context limits, drift).
  • Subtle bugs, security issues, and maintaining quality tests.

Effective workflows vs “vibe coding”

• Many successful users keep LLMs in chat or “super autocomplete” mode, with human-in-the-loop copy/paste and code review, likening them to a fast junior dev.
• Letting an agent freely modify a codebase is widely described as producing messy, opaque, bug-prone systems.
• Some report 10–20–30% speedups and big reductions in procrastination; others find LLMs can be slower than just coding, especially in unfamiliar stacks or when you must read every line anyway.

Careers, juniors, and broader impact

• Experience is seen as more important, not less: only seasoned devs reliably spot LLM mistakes and design flaws.
• Concern that juniors relying on LLMs learn poorly and ship “vibe-coded” spaghetti.
• Disagreement on macro impact: some see AI as an excuse for layoffs; others see it mostly raising expectations and enabling more ambitious projects rather than reducing developer need.