Maintaining Programming Joy in the Era of LLMs

The rise of Large Language Models (LLMs) has created a paradox for developers: while productivity can increase, the intrinsic joy of programming—the act of expressing thoughts through code—is often replaced by the tedious task of reviewing AI-generated "slop." To avoid AI burnout and the atrophy of technical skills, developers must transition from being "meat proxies" for AI agents to using LLMs as high-leverage support tools for planning and research.

The Risk of "Vibe Coding" and Skill Atrophy

Over-reliance on LLM-generated code leads to a degradation of both the codebase and the programmer's cognitive abilities. When developers stop writing code and instead rely on agents to generate entire files, they risk creating an "LLM wasteland"—codebases that are alien to human readability and maintainable only by other agents.

Beyond the codebase, the human cost is skill atrophy. As noted by community members, the ability to architect small projects or think deeply in a programming language can vanish quickly when outsourced to an LLM.

"I've seen this happen to myself where suddenly I had trouble planning out the architecture for a very small project... I realized that when I asked Claude for a bunch of ideas and then I selected the best one based on my experience, I was exercising that exact skill. I wasn't exercising the skill of coming up with the solution from scratch."

A Sustainable Workflow: Human-Centric AI Assistance

To maintain professional growth and personal enjoyment, the most effective workflow is to plan together, but code alone. In this model, the LLM handles the incidental, boring, and high-volume work, while the human retains ownership of the implementation.

1. LLMs for Planning and Bookkeeping

Instead of asking an LLM to "build this feature," use it as a natural-language bookkeeping tool. Use it to:

Convert domain expert conversations into actionable todo lists.
Organize test results into a structured plan for fixing defects.
Track planning items in Markdown files to avoid context window loss.

Crucial Rule: Never let the LLM make crucial architectural decisions. Force it to ask you for direction when it reaches a decision point.

2. LLMs for Research and Discovery

Use agents to gather information, but do not accept their results as absolute facts. The goal of AI research is to eliminate the "Let Me Google That For You" friction, not to replace the developer's understanding of the domain.

Require agents to provide links to resources.
Verify weird proposals by asking the agent which specific resource supports the claim; this often triggers the model to discover its own hallucinations.
Research in parallel with a search engine to ensure you understand the domain as well as or better than the agent.

3. The Human as the Primary Coder

Refuse the "plan first, then let the agent code" lure. Instead, let the LLM research the codebase, identify the necessary edit points, and warn you of potential pitfalls, but you write the actual code. This approach offers several advantages:

Ownership: You always know the exact state of the codebase.
Early Detection: You recognize a bad plan during the implementation phase rather than after an agent has spent an hour generating a flawed solution.
Skill Maintenance: You continue to hone your coding abilities.

Implementing an Automated Review Cycle

To ensure quality, no LLM-produced artifact—including plans—should be accepted without an automated review cycle. This mimics Generative Adversarial Networks (GANs), where a "generator" agent produces the work and a "discriminator" agent reviews it.

This cycle is particularly useful for:

Code Review: Using a separate agent to find bugs or omissions in your own hand-written code.
Plan Validation: Using a review agent to spot logical holes (e.g., a plan that requires a function in step 2 that isn't written until step 7).

Managing Technical and Mental Constraints

Handling Token Depletion

Token limits should be treated as service outages rather than a lack of purchase. To prevent work from grinding to a halt, maintain a tangible list of planned todos that can be worked on offline. This ensures that when the "technofeudal lords" limit your access, you can continue producing value independently.

Avoiding "LLM Gibberish"

Excessive consumption of LLM-generated text can be mentally draining. To protect psychic health, limit the consumption of raw LLM output and prioritize human-to-human communication for high-level visions and architectural discussions. Avoid sending completely generated PR bodies to colleagues, as this is a tool output, not genuine communication.

Perspectives on the Future of the Profession

Community discussion reveals a deep divide in how developers view the automation of coding:

The Hobbyist View: Some argue that programming is transitioning from a profession to a hobby, similar to blacksmithing or luthiery—economically impractical but personally fulfilling.
The Efficiency View: Others contend that the primary goal is solving business problems, and if LLMs speed up that process, the "craft" of typing code is an unnecessary sentimental attachment.
The Hybrid View: Many find success by using small, fast models for routine tasks (like creating domain classes with specific invariants) while maintaining a tight grip on the architectural reins to avoid the "agent swarm" overhead.