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

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.