Vibe coding and agentic engineering are getting closer than I'd like

Original Article ↗ Hacker News Discussion ↗

Large language models are rapidly shifting software development from hand-crafted code toward “vibe coding” and agent-driven workflows, where AI generates and even refactors substantial parts of a codebase. Commenters argue over whether this leads to unmaintainable “slop” or simply exposes and accelerates existing good and bad engineering practices, emphasizing that responsibility, review, and testing still rest with humans. Many see real productivity gains, especially for boilerplate and greenfield work, but worry about subtle bugs, loss of deep understanding, long‑term maintainability, and what widespread AI adoption means for careers and incentives in the industry.

Vibe coding vs. “agentic engineering”

  • Many see “vibe coding” (one‑shot prompts, minimal review) and “agentic engineering” (multi‑step, tool‑using agents) as points on a spectrum, not a clear divide.
  • Several argue the real difference is whether humans still care about architecture, tests, and reviews, not how many agents are in the loop.
  • Others think the distinction is mostly branding: both rely on the same LLMs and can devolve into unchecked code generation.

Code quality, slop, and maintainability

  • Strong fear that LLM‑generated code will massively increase code volume, complexity, and tech debt, eventually exceeding both human and LLM ability to reason about it.
  • Others counter that most existing human code is already a mess; LLMs can be at least as good, and sometimes better, when guided by good engineers and guardrails.
  • Rewrites “from scratch” (by AI or humans) are widely seen as risky; incremental refactoring plus strong tests is preferred.
  • People describe real projects where LLM‑assisted code was later cut down 3–10× and simplified, revealing bugs and over‑engineering.

Productivity, LOC, and review bottlenecks

  • Many report large personal productivity gains, especially for boilerplate, refactors, tests, and unfamiliar stacks.
  • Others say the last 5–10% of work (edge cases, design, debugging) still dominates effort, so headline speedups are overstated.
  • LOC is criticized as a bad metric, but used as a proxy for review burden: going from ~200 to ~2,000+ LOC/day breaks traditional review and process assumptions.

Responsibility, risk, and trust

  • Strong consensus that legal and moral responsibility stays with the human or organization, not the LLM vendor.
  • Some only skip line‑by‑line review for low‑risk, local tasks; for security‑sensitive or core systems they still inspect everything and add heavy testing, fuzzing, or property‑based tests.
  • Relying on LLM‑generated tests to validate LLM‑generated code is viewed by some as a dangerous self‑referential loop.

Organizational incentives and market forces

  • Multiple commenters note management pressure and FOMO: “AI must work” because so much capital and career risk now depend on it.
  • Market forces are seen as optimizing for cost and speed, not code quality; some predict widespread adoption of “good enough” AI slop if it’s cheaper.
  • Others argue careful teams will use LLMs to improve design and tackle long‑ignored tech debt, differentiating on reliability.

Impact on engineers and learning

  • Some see LLMs as amplifiers: great engineers get much better; bad engineers just make more mess, faster.
  • There’s concern that constantly delegating thinking and implementation will erode skills, architectural “proprioception,” and the ability to maintain legacy systems.
  • Existential anxiety is common: fear of being reduced to agent babysitters, or of future juniors never learning fundamentals.

Reported effective workflows

  • Common “responsible” patterns:
    • Use agents heavily for boilerplate, migrations, simple endpoints, and test scaffolding.
    • Invest early in linters, CI, strong test suites, and explicit “skills”/constraints for agents.
    • Treat agents like powerful but alien junior devs: specify clearly, iterate, and review diffs, especially architecture‑shaping changes.
  • “Vibe coding only” is generally tolerated for prototypes, personal projects, or throwaway experiments, not for long‑lived, critical systems.