How to keep enjoying programming in a world of LLMs

An unnamed Haskell programmer published a long personal essay on discourse.haskell.org about staying productive with LLMs without letting the enjoyment of programming disappear. The author frames the risk as a slow shift from being an active coder to being a cog that just hands specs to an agent and waits for tokens to run out. Their proposed fix is a specific division of labor: the human keeps writing the actual code, while LLM agents take on everything else the human finds tedious.

For planning, the author treats an LLM as a natural-language bookkeeping tool: feeding it a messy conversation between domain experts or a set of test results and having it organize the material into tracked todos, using markdown files with frontmatter rather than trusting a model's context to hold everything reliably. Crucially, the author says the agent should never make the crucial decisions itself; it should ask questions instead, and if those questions are unclear the human should step back and think rather than push through.

For research, the author argues you should investigate a topic yourself in parallel with the agent rather than simply accepting the agent's findings as fact, warning that blind trust here breeds "embarrassing technical debt." As a check, the author has agents write down their research with links to the resources used, then interrogates the agent about a suspicious proposal later: in the author's estimate, there is a 50% chance the agent will catch its own mistake when questioned about its sources, and in the other 50% the human has to read the cited resource and judge for themselves.

Coding agents are described as genuinely useful only for a narrow set of tasks: cleanup, small routine work, low-risk refactors, swapping out an unmaintained library, or finishing a batch of already-planned low-risk todos overnight while the human is away, with a "supervisor agent" left to work unattended. Even then, the author insists it is important to do most of the coding work personally, since heavy reliance leads to code only the agents themselves can understand, and because skills erode quickly once a programmer stops writing code regularly. The essay also states plainly that LLMs are "way worse" at producing good, human-readable code than commonly advertised, generally coping better with code they will keep editing themselves than with code meant for a human to read.

Before accepting or even reading anything an LLM produces, whether a finished piece of code or a plan, the author argues for an automated review cycle, comparing it to the generator/discriminator setup behind generative adversarial networks: a second agent should review the first agent's output until it has no more findings, and the author says applying this to their own writing has caught genuine bugs and omissions, not just style nits.

The piece closes by pushing back on a comment from what the author calls "some vibe coder on the internet," who told the author they were completely underutilizing what frontier models can do. The author agrees this is a fair description of their approach but defends it: frontier models use a large amount of energy, by the author's account, and relying on them blurs responsibility. The author's position is that a programmer is responsible for the code they produce, not the machine that helped write it, so using an LLM only makes sense if the human stays enough of an active participant to take that responsibility. The retrieved copy of the post cuts off before the author's concluding remarks.

Key facts

An unnamed Haskell programmer argues the human should keep writing the actual code, delegating only planning, research, cleanup and automated review to LLM agents.
The author estimates a 50% chance that a coding agent will catch its own research mistake when questioned about its sources, meaning the human must independently check the cited resource the other half of the time.
The essay calls for an automated review cycle, likened to the generator/discriminator setup in generative adversarial networks, before accepting or even reading any code or plan an LLM produces.
Coding agents are described as suited mainly to cleanup, small routine tasks, low-risk refactors, or finishing already-planned low-risk todos overnight while the programmer is away.
The author states LLMs are "way worse" at producing human-readable code than advertised and argues frontier models use a large amount of energy, framing responsibility for the code as resting with the human, not the machine.

Why it matters

The post speaks to a live anxiety in programming communities: burnout, fear of being replaced by less skilled colleagues armed with AI tools, and the sense that codebases are quietly degrading as more of them get generated rather than written. Rather than arguing for full LLM abstinence or full automation, the author sets out a specific middle path meant to preserve both productivity gains and the personal enjoyment of coding.

Who it affects

The essay is aimed at programmers, particularly those working in expressive or niche languages like Haskell who describe getting real enjoyment from writing code, and who feel pressure to adopt heavy LLM usage because their team, company or industry is moving that way. It also speaks to anyone worried about losing programming skills or ownership of their codebase to agents.

How to use it

The author's concrete workflow: keep doing the actual coding yourself; use an LLM as a natural-language planning and bookkeeping tool, tracked in markdown files with frontmatter, without letting it make key decisions; do your own research in parallel with an agent's research and verify suspicious findings by asking the agent to cite and justify its sources; reserve coding agents for cleanup, small routine work, low-risk refactors, or an unattended overnight run through a batch of already-planned low-risk todos; and require an automated review cycle, a second reviewer agent checking the first agent's code or plan, before accepting or reading any of its output.

How solid is it

This is a first-person opinion and how-to essay posted to the Haskell community's discourse forum, not a study or benchmark. Its claims, including the 50% figure on agents catching their own research mistakes, reflect the author's own estimate and personal workflow experience rather than measured data. The copy of the post available here is cut off before the author's final section.

Risks and caveats

The recommendations are drawn from one programmer's practice with Haskell and may not generalize to other languages, teams or codebases. The author explicitly sets aside broader ethical concerns about frontier LLMs run by large tech companies, saying those have already been "discussed at length" elsewhere and are not the subject of this post.

“You're completely underutilising what frontier models are capable of.”

— quoted in the post as "some vibe coder on the internet"