The art of programming and why I won't use LLM

Programming as art vs. programming as work

• Many agree with the “programming as art / self‑expression” framing, especially for side projects and hobbies. They enjoy crafting solutions end‑to‑end and feel LLMs would remove the fun part.
• Others see professional programming primarily as delivering business value or problem‑solving; code is a means, not art. For them, who wrote the code doesn’t matter as long as it works, is secure, and maintainable.
• Several separate “career vs. job”: enjoying code craftsmanship in personal time while using any productivity tool, including LLMs, at work.

LLMs as tools, abstractions, and black boxes

• One camp views LLMs as just another abstraction layer, akin to compilers, high‑level languages, or libraries: offloading repetitive work is part of programming’s history.
• The opposing camp stresses qualitative differences: compilers and CPUs are (largely) deterministic, spec‑driven, inspectable, and semantics‑preserving; LLMs are probabilistic, opaque, and lack guarantees, so calling them “automation” is misleading.
• Some argue LLMs shift the activity from programming to “management” or “prompting,” which they don’t want; others say that’s exactly the direction many abstractions were always pushing toward.

Productivity, correctness, and trust

• Enthusiasts: LLMs are “power tools” or “aggressive autocomplete.” They speed up boilerplate, glue code, data‑munging scripts, unfamiliar APIs, and tedious refactors. Used with tests, type systems, and review, they feel like fast junior devs.
• Skeptics: reviewing unpredictable LLM output is slower than writing correct code directly in a familiar language. Errors are non‑obvious and “weird,” making proofreading harder. Many only trust LLMs for ideas, search, explanations, and trivial code.
• Several worry about overreliance degrading skills, code quality, and maintainability—especially if large systems are largely LLM‑generated.

Cultural, career, and industry implications

• Some see anti‑LLM stances as a kind of “luddism” or romanticism that will not age well; they expect market pressure to favor those who embrace the tools.
• Others fear wage pressure, commoditization of “monkey coding,” and a future dominated by generic, hard‑to‑maintain, AI‑written code, with a small minority of high‑skill “codecrafters.”
• There are concerns about using SaaS LLMs that train on proprietary code, as well as speculation that LLMs will bias ecosystems toward mainstream stacks they’re good at.

Reactions to the original essay

• Some find the piece honest but inherently judgmental toward LLM users.
• Others criticize its prose (non‑capitalization, grammar) and note the irony that an LLM could easily “fix” it—demonstrating one mundane but real use case.