TL;DR
Get business pricing on tech for your team
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
A post on the Haskell community forum argues that developers can avoid ‘AI burnout’ by keeping human hands on code while delegating boring, verifiable tasks like planning and research to LLMs. It warns that fully generated codebases become hard for humans to maintain and that coding skills atrophy quickly without practice.
A programmer’s essay on how to keep enjoying programming while large language models reshape software development has circulated widely after being posted on the Haskell community forum, arguing that developers should keep writing their own code and delegate only planning, bookkeeping, and research tasks to LLMs. The author, a Haskell developer, frames the piece as a response to growing ‘AI burnout’ among programmers who feel their craft being reduced to reviewing machine-generated output. The post has struck a nerve in a community known for its enthusiasm for the programming language itself, and its arguments apply to the broader debate over how developers should integrate AI tools.
The author opens by naming the anxieties the essay addresses: fear of losing one’s job to someone with little programming skill but a large Claude account, disappointment with code quality in one’s own projects, and ethical concerns about frontier LLMs run by big tech companies. The author states these ethical concerns are legitimate but outside the post’s scope, and notes the text is written entirely without AI assistance.
The core argument is a division of labor. Programmers should keep writing code themselves, the author writes, for two reasons: to keep ownership of their codebase, and to maintain their skills. ‘If you let it all be generated, it will turn into an LLM wasteland that only your coding agents can thrive on,’ the post warns. The author claims skills degrade quickly, observing that after just a few weeks of handing work to agents, returning to hands-on coding becomes difficult.
The productivity gains, the author argues, should come from having LLMs do ‘nearly everything else’ — especially boring tasks that are ‘not too hard to get right, and easy to check.’ Concretely, the post recommends using LLMs as a natural-language bookkeeping tool: converting long conversations with domain experts into actionable todos, organizing test results into defect-fixing plans, and tracking planning items in markdown files. The author cautions against letting the model make important decisions — it should ask the human instead — and warns that overloaded contexts can silently lose information.
On research, the post advises developers to verify agent findings in parallel using a traditional search engine, and to at least roughly know everything the agent knows. Accepting an agent’s research as fact, the author writes, leads to ’embarrassing technical debt.’
Why Craft Preservation Matters Now
The essay lands amid rapid, often top-down LLM adoption across the software industry, with many teams under pressure to demonstrate productivity gains from AI tooling. The post gives voice to developers who report that reading and debugging generated code is less enjoyable and, in their experience, less reliable than writing code themselves — a claim the author backs only with personal observation, not measurement.
The argument matters because it offers a middle path between two entrenched positions: total AI abstinence and full agent-driven development. The author explicitly acknowledges that some developers cannot abstain because they need to show real productivity gains or fear being left behind as their teams and companies adopt heavy LLM use.
The skill-atrophy warning also has practical weight for hiring and team management: if hands-on coding ability degrades within weeks, as the author claims, organizations relying heavily on agents may find their capacity to verify and repair generated code shrinking at the same time their codebase grows.
Why Haskell Programmers See It Differently
The author draws on the novel ‘Souls in the Great Machine’ by Sean McMullen, which describes a computer built from human components, as a metaphor: the developer’s role is being ‘degraded slowly from being actors to cogs in a machine.’ The worst case the author imagines is a spec-driven workflow where programmers receive specifications, feed them to an LLM, and depend on token allocations from what the author calls a ‘technofeudal lord.’
The post offers a community-specific explanation for why opinions on LLMs differ by language: Haskell programmers, the author says, enjoy ‘the process of expressing thoughts’ in the language itself, which generated code threatens to take away. The author suggests this enjoyment is less common in other languages, which may explain why enthusiasts of different languages disagree about how bright or dark the LLM-assisted future looks.
The essay’s framing of the debate on the Haskell Discourse, a forum historically centered on language design and tooling, reflects how AI adoption has become a live topic even in communities built around programming as a craft.
Claims Resting on Personal Experience
The essay is an opinion piece grounded in one practitioner’s experience, not a study. Several key claims — that coding skills degrade noticeably within weeks of agent reliance, that generated codebases become unmaintainable for humans, and that LLMs are worse at readable code than advertised — are presented without supporting data or benchmarks. Independent research on AI coding assistants shows mixed results on productivity and code quality, and the post does not engage with that literature.
The author also concedes that preferences vary: some developers may find the same delegation satisfying, and the post states outright that LLM abstinence is a valid choice for those who prefer it. Whether the recommended middle path produces the ‘moderate’ productivity gains the author promises — rather than the appearance of gains — is not demonstrated. The full post appears to be cut off mid-sentence on research guidance, so additional recommendations may exist beyond the quoted material.
Where the Debate Goes From Here
The Discourse thread is open for community discussion, where replies are likely to test the essay’s claims against other developers’ experiences with agent-heavy workflows. For readers weighing similar choices, the post suggests a concrete experiment: delegate planning, bookkeeping, and research to LLMs while keeping implementation in human hands, then assess both enjoyment and measurable output over time.
Beyond the forum, the questions the essay raises — how fast coding skills actually atrophy, and whether human-maintained codebases remain viable under industry pressure — will be answered only by longer-term evidence from teams adopting these workflows, and by emerging research on AI-assisted development outcomes.
Key Questions
What is the main recommendation of the essay?
The author recommends continuing to write code yourself while using LLMs for planning, bookkeeping, and research — tasks described as boring but easy to verify — rather than letting agents generate the codebase.
Why does the author say developers should keep writing code?
Two reasons are given: to keep the codebase understandable and maintainable by humans, since fully generated code becomes an ‘LLM wasteland,’ and to preserve programming skills, which the author claims degrade after just a few weeks of relying on agents.
Does the essay argue against using LLMs entirely?
No. The author explicitly says LLM abstinence is fine for those who choose it, but offers a middle path for developers who need productivity gains or work on teams adopting heavy LLM use.
What tasks does the post suggest delegating to LLMs?
Planning and organization tasks: converting expert conversations into todos, organizing test results into fix plans, and tracking items in markdown files — with the caveat that the model should ask the human rather than make key decisions itself.
Are the essay’s claims backed by research?
No. The claims about skill atrophy, code quality, and enjoyment are based on the author’s personal experience as a Haskell developer and are not supported by cited studies or benchmarks.
Source: hn
Fall Picks
fall essentials
As an affiliate, we earn on qualifying purchases.
