How to Keep Enjoying Programming in the Age of LLMs: Coding by Hand, Delegating the Rest

A discussion thread on Haskell's community forum is making the rounds among developers with a simple but pointed argument: let LLMs handle planning, research, and review, but keep writing the actual code yourself. It's a direct response to the rise of fully autonomous coding agents, and it reframes AI adoption as a question of role division rather than all-or-nothing delegation.

What the Discussion Is Really About

A post titled "How to Keep Enjoying Programming in a World of LLMs" appeared on Haskell's Discourse forum and has been circulating among developers well beyond the Haskell ecosystem. The core proposal is straightforward: use LLMs for the peripheral work of software development — organizing requirements, researching libraries and APIs, reviewing finished code — while leaving the actual writing of implementation code to a human. The stated goal is to preserve a moderate productivity gain without sacrificing the satisfaction of programming itself.

From Vibe Coding to Deliberate Delegation

This argument doesn't exist in a vacuum. Over the past year or two, agentic coding tools like Cursor, Claude Code, and Devin have pushed adoption toward what's been nicknamed "vibe coding" — a workflow where a developer describes intent and lets an AI agent generate and even commit entire implementations with minimal manual review. That shift boosted output speed for many teams, but it also produced a recurring complaint: developers increasingly can't explain the logic in their own codebase because they never actually wrote it. The Discourse thread reads as a direct counterpoint to that trend, proposing a middle path instead of an all-in or all-out stance on AI tools.

Why Keeping Your Hands on the Code Still Matters

The reasoning behind the proposed division of labor centers on ownership and comprehension. Planning, searching documentation, and reviewing code are tasks where an LLM's speed genuinely helps without touching the core logic. Writing the implementation, by contrast, is where a developer builds and retains a working mental model of the system — the kind of understanding needed to debug an issue at 2 a.m. without asking an AI to re-explain code it originally wrote. Handing every line of implementation to an agent may look efficient in a sprint retro, but the thread argues it quietly erodes a developer's ability to reason about their own system over time.

What This Means for Teams and Individual Developers

For individual developers, the practical takeaway is less about rejecting AI tools and more about drawing a line: use them as a research assistant and a second pair of eyes, not as the primary author of your codebase's logic. For engineering teams and hiring managers, this framing raises a subtler question that's likely to show up more in code reviews and interviews going forward — not just whether code works, but whether the person who submitted it can explain why it works. As AI-assisted development becomes standard rather than novel, that distinction may become a more meaningful signal of engineering skill than raw output speed.

Takeaway

The debate isn't really about whether to use LLMs in software development — that ship has sailed. It's about which parts of the job should stay human, and this thread offers one clear, testable answer: delegate the surrounding work, keep the core craft.

Reference: https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705