Keep Coding Joy in the AI Era: Write Code Yourself, Let AI Plan & Review

Introduction: The Erosion of Programming Joy

Haskell core developer and Rhine author turion posted on the Haskell Community Discourse forum (https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705, September 2026) asking whether programmers are sliding into "AI burnout" and losing the satisfaction of turning ideas into code by hand. He explicitly states the article is 100% human-written and focuses on a personal, practical question: how to keep the fun of programming while still using AI .

Core Problem: What Happens When You Hand Over All Coding

Turion argues that delegating code writing entirely to LLMs leads to three intertwined risks:

Skill atrophy: After only a few weeks of not writing code yourself, you lose the tactile "hand feel" of programming and struggle to pick it up again.

Codebase degradation: The repository becomes an "LLM wasteland" — code that only the model can maintain, full of logic that is opaque to humans. When bugs appear, you cannot even start debugging because the structure is alien.

Misaligned incentives: LLMs excel at generating "code that runs" but are far worse at producing "code humans can read and maintain." They tend to write code that only they will continue to maintain.

Methodology: Six Concrete Practices

1. Baseline: You Must Write the Code

This is the foundation. Turion insists that core implementation must be typed by a human to retain long-term control over the system and preserve problem-solving intuition.

2. LLM as "Bookkeeper": Planning (Planning)

Treat the LLM as a record-keeping tool — like early computers were for accounting, but with natural language. Feed it discussions, test results, and let it produce an executable todo list persisted as Markdown files with frontmatter (to avoid context-window loss). Critical rule: the LLM asks questions; the human makes every key decision. If you cannot understand the LLM's questions, either it lacks context or you are too tired to continue.

3. Research: Don't Be an Absentee Landlord (Researching)

When an agent researches, do not disengage. Turion says the best of three options — watch the agent think, start another agent, or get coffee — is getting coffee. Instead, run your own searches in parallel so you understand the domain at least as deeply as the agent. Never accept the agent's output as fact; use it to avoid "Let Me Google That For You" drudgery. Practical steps: have the agent write down findings with sources; when it returns a dubious proposal, demand its research basis — about half the time it catches its own error, the other half you can judge yourself.

4. Core Technique: "Plan Together, You Code"

Plan together, but you write the code.

This is turion's self-described "game changer." Mainstream agents push "plan then let agent code." Turion rejects that. Instead:

LLM studies the repo, lists todos, flags pitfalls, summarizes research.

Human writes every line of implementation code.

He describes the resulting workflow as "like agile but without the annoying ceremonies": the task list is always clear, no mental load for high-level planning, deep focus on the current task, fast completion because planning was thorough.

Four benefits:

You keep doing what you love — writing code.

You always know the true state of the codebase — no surprises from "vibe coding" output.

Bad designs are caught early — an autonomous agent may chase a wrong direction; a human spots it instantly.

Your craft stays sharp — you remain a good programmer, even improve.

Appropriate tasks for agent coding: cleanup, small tasks, repetitive work, low-risk refactoring (e.g., filling 7 similar cases after 3 representative ones, benchmarking a module reorganization, replacing an unmaintained library). Not suitable: designing a complex system from scratch.

Two pitfalls turion highlights:

If you write 3 cases and ask the agent to copy-paste the other 7, you should be abstracting instead (e.g., a Traversable instance). LLMs notoriously duplicate rather than abstract; humans must enforce better structure.

If you need the agent to "list all places to change and all pitfalls," your codebase organization is likely poor — you're using the LLM for code archaeology.

5. Give AI a "Reviewer": GAN-Style Review Pipeline

Analogous to Generative Adversarial Networks (generator vs. discriminator), turion builds an automated review pipeline :

Hard rule: No LLM output (code or planning docs) is accepted — or even read — until it passes an automated review agent.

The reviewer checks for logical gaps (e.g., a function refactored in todo 2 but not written until todo 7).

Surprisingly, letting AI review human-written code is highly effective : it catches real bugs and omissions, not just style nits.

6. Reject Frontier-Model Idolatry & Token Anxiety

Turion deliberately avoids cutting-edge commercial models for four reasons:

Environmental cost: Opaque, massive energy consumption.

Trust: Hard to trust a "pretends to be smarter than you" black box; ultimate responsibility is yours — outsourcing accountability to a machine is absurd.

Uncertainty: Fancier models burn more tokens; you cannot guarantee a session finishes. Smaller models that suffice are more reliable.

Replaceability: If your workflow doesn't depend on a frontier model, you can swap to open-weight/self-hosted models later, avoiding lock-in to a "technofeudal lord."

On token limits: treat exhaustion as a service interruption , not a planning failure. The vendor promised "LLM access"; if they don't deliver, they breached. Token quotas are opaque and adjustable. Mitigation: always keep an offline-ready task list (like working on a plane without Wi-Fi). When tokens run out, switch to offline tasks; when service returns, let the agent clean up.

Side-Effect Warning: AI Boilerplate as "Mental Asbestos"

Long exposure to LLM-generated text — especially when the model doesn't truly understand — harms mental well-being. Turion advises: treat LLM verbiage as potentially hazardous , limit intake. Prefer discussing code with real humans (vision, interesting details). Only read AI output after the automated reviewer has "sanded the edges."

Programming is fundamentally social: PRs, issues, commit messages are communication — even with your future self. Never submit a fully AI-generated PR as-is. Turion admits doing this once; the reviewer's annoyance was justified. Agent-written descriptions are tool output, not communication. Attach them folded in <details> tags as debug logs; most people won't open them.

Author's "Health Check": Organic Gardener vs. Chemical Farmer

After adopting this workflow, turion estimates ~2× productivity vs. pre-LLM — far less than "full vibe coding" claims, but sustainable. He compares himself to an organic gardener using gentle fertilizer , while vibe coders flood fields with industrial chemicals. Short-term yield may favor the latter, but the organic approach lasts.

Commentary: Two Dissenting Voices

A Core Library Maintainer's Perspective

A Haskell core library maintainer started from the opposite angle: "If I lose LLMs, can I still enjoy programming?" because AI let him realize previously impossible ideas by offloading drudgery. He found he already unconsciously followed many of turion's practices. On token anxiety, he uses OpenAI's transparent monthly plan with /status command, questioning the "betrayal" framing as contradictory — worrying about AI overload while complaining about insufficient quota.

Turion clarified: his concern is workflow fragility when a vendor changes quotas unpredictably. He proposes a "fair market" standard: independent token-metering tools, fixed quotas guaranteed for months, reliable uptime SLAs — no vendor currently meets all three.

Core Library Maintenance: Where AI Falls Short

Turion's collaborator hasufell gave a reserved assessment for tasks like Haskell Core Libraries Committee issue #411 (low-level primitives, weird APIs such as Windows/PowerShell): "below expectations." He uses LLMs only as search tools because they don't truly understand PowerShell; correct process handling requires human trial-and-error. LLMs converge to "common workarounds" rather than optimal solutions — dangerous for core libraries. Additionally, LLMs quietly erode your confidence in your own judgment : when you sense you haven't fully thought through a decision, the model's surface confidence can mislead.

Team Policy: Accommodating Different AI Habits

Hasufell hopes the industry reaches a state where teams hire engineers with varying AI usage styles and design policies to let them collaborate. Example: prefer non-AI users for code review, but need policies like banning auto-generated commit messages to avoid burning them out. In open source, communities are already splitting over LLM scraping rights (e.g., Sourcehut, Codeberg restricting access) — hasufell sees this divergence as healthy.

Three Takeaways for Developers and Teams

"Hands-off" AI use carries hidden costs. Short-term speed gains may erode maintainability, personal craft, and team trust — costs that surface only when things break.

AI fits best as bookkeeper, research assistant, and reviewer — not lead author. Keep decision authority and tactile coding with humans; delegate repetitive, transactional work. The boundary in ultra-low-tolerance domains (core libraries, complex systems) remains for each team to explore.

Token anxiety reflects a structural dependency. How much are our workflows held hostage by platform pricing and quota policies? This is not just turion's problem; it's an industry-wide issue as we rush to adopt AI coding tools.

The Haskell forum discussion offers no universal answer, but it frames a question every programmer should answer personally:

When AI can write code for you, do you still want to write it yourself?