I am happier writing code by hand

Emotional experience and “vibe coding”

• Several commenters resonate with the addictive, gambling-like reward loop of “vibe coding”: type a prompt, get plausible code, chase the next “almost works” result.
• Others say it feels bad: long waits, “almost there but not quite” outputs, and a sense of not really having done the work or learned anything.
• Many explicitly value the joy of crafting code, entering flow, and understanding systems; delegating to AI feels like losing the fun part and becoming a babysitter or manager.

Productivity vs code quality

• Some report dramatic speedups (2–6x, even shipping full products rapidly), especially for boring CRUD, UI boilerplate, refactors, tests, and config.
• Others find no net gain: reviewing and debugging AI output takes as long as writing it, especially when models hallucinate APIs or subtle bugs.
• There’s concern that management will prefer “10–50x more low-quality code that mostly works” over smaller amounts of high-quality code, leading to long‑term maintenance nightmares.
• Non-determinism is seen as a key difference from past “power tools”: you can’t rely on consistent behavior for the same prompt, which complicates trust and process.

Human expertise, understanding, and responsibility

• Strong theme: if you can’t “code by hand,” you can’t safely use AI. You won’t catch logic, performance, concurrency, or architecture pitfalls, nor fix failures when AI gets stuck.
• Many argue real productivity comes from deep understanding of the codebase and domain; writing code yourself is how you build that mental model.
• Others counter that you can still internalize context via design, review, and careful prompting; coding is just one way to think, not the only one.

Careers, roles, and labor dynamics

• Widespread anxiety that juniors and “10-lines-of-code obsessives” will be squeezed out; remaining roles become higher‑level orchestrators of agents and architecture.
• Some foresee salaries holding while expectations rise; others expect commoditization and lower pay as “anyone can prompt.”
• Debate over whether PMs, architects, or devs are more at risk; consensus that simply becoming a “glorified PM” won’t preserve SWE compensation.
• Historical analogies (Luddites, looms, tractors, carpentry) are used both to argue inevitability of displacement and to highlight that outcomes depend on labor power and institutions, not technology alone.

Appropriate uses and limits of AI tools

• Common “pragmatic” pattern: use AI for dull, repetitive, or syntactic tasks (schema → struct, test scaffolding, CI/YAML, simple translations, doc queries), but hand-write core logic and designs.
• Several describe mixed workflows: design and key pieces by hand, keep agents busy on side tasks, repeatedly refactor/verify with tests and human review.
• Others report using AI to successfully tackle messy real-world tasks (e.g., poor third-party APIs) but stress that domain experience and intuition about where LLMs fail remain essential.

Analogies and what counts as a “tool”

• Carpentry and power‑tool analogies are heavily debated:
  • Pro‑AI side: like power tools/CNCs or cars vs horses; handcraft remains as a niche hobby, not industry standard.
  • Skeptical side: LLMs are more like slot machines or contractors than saws—stochastic, opaque, and capable of quiet, catastrophic errors.
• “Centaur” vs “reverse‑centaur” framing: compilers and bandsaws amplify human intent; LLM code risks putting the human in a subordinate supervisory role.

Hiring, skills, and the future of the craft

• Some report little change in interviews (LeetCode and system design still dominant); others note harder problems and quiet but widespread AI cheating.
• There’s concern that if AI coding is required, manual-craft skills will atrophy, leaving no one able to debug failures when AI can’t help.
• Many expect a long transition: demand for strong seniors/architects may rise even if the total number of SWE jobs (especially junior roles) shrinks.