As large language models become more prevalent in software development, many programmers worry about losing their craft—both the practical skills and the enjoyment of writing code. According to a post on the Haskell discourse forum, there’s a middle path between wholesale AI adoption and complete abstinence.
The core concern is what the author calls a “spec-driven dystopia”: simply handing specifications to an LLM, generating code, and watching token supplies dwindle under corporate control. This approach risks degrading programmers from decision-makers to “cogs in a machine,” particularly if generated code becomes unreadable and unmaintainable.
The author argues that LLMs excel at tasks other than code generation itself. They work best as planning and research tools—what the post frames as “bookkeeping machines” that operate in natural language. For instance, an LLM can convert technical conversations between domain experts into actionable to-do lists, organize test results into debugging plans, or research unfamiliar codebases and highlight areas needing changes. The key is that humans remain the decision-makers: the LLM should ask questions, not make crucial choices unilaterally.
When researching is delegated to an LLM, the author recommends parallel human research using traditional search engines. This prevents “embarrassing technical debt” and ensures programmers genuinely understand the domain, not just accept the agent’s output as fact. Similarly, research results should be documented with links so claims can be verified later.
The pivotal recommendation is to keep programming yourself. Rather than planning first and then having an agent code, the author suggests planning together while preserving human authorship of the actual code. The LLM can be asked to research the codebase, identify changes needed, flag pitfalls, and provide context—but the programmer writes the code.
This workflow reportedly increases enjoyment because programmers focus on what they find engaging, always understand their codebase’s state, catch bad plans early, and continue honing their skills. LLM agents should be used only for cleanup, small routine tasks, and low-risk refactorings—the tedious work that doesn’t involve core creative decisions.
The author emphasizes that this approach yields moderate productivity gains without the burnout or code-quality degradation associated with full code generation pipelines. Skills atrophy is a real risk: programmers who stop coding for even a few weeks can struggle to return to manual authorship.
Key facts
- The author recommends using LLMs for planning, research, and identifying codebase changes rather than code generation
- Programmers should maintain code authorship to preserve skills, code quality, and job satisfaction
- Delegated research should include parallel human verification and documented sources to prevent technical debt
- LLM agents should assist around the programmer’s workflow, not replace their role as primary coder
- The post emphasizes that programmer enjoyment depends partly on the programming language used and individuals’ relationship to coding itself