How to Keep Enjoying Programming When LLMs Take Over
AI burnout is real. The fear of being replaced by someone with a big Claude subscription and zero respect for code quality is creeping through every team. The codebases suffering from "vibe coding" sessions are hard to ignore. This guide is for developers who want to stay in control of their craft while still squeezing some real productivity out of large language models.
The author, a Haskell programmer, makes one thing clear: this is not a pro-LLM manifesto. The ethical concerns around frontier models are legitimate, and they are not being dismissed here. But the question on the table is narrower and more practical. How do you keep the joy of programming alive when LLMs promise to do it all faster?
Why You Must Keep Writing Code Yourself
If you let an LLM generate everything, your codebase becomes an alien landscape that only coding agents can navigate. That is a fast track to losing ownership of your own software. The more immediate danger is skill erosion. Hand off your coding work to an agent for a few weeks and you will struggle to come back. The threshold to surrender your keyboard is dangerously low.
LLMs are not nearly as good at producing readable, maintainable code as the marketing suggests. They are adequate when they are editing their own output exclusively. But a fully generated file that hides a bug somewhere is a familiar nightmare. The code looks plausible, but the reasoning behind it is opaque to a human eye.
Let LLMs Handle the Boring Work
The productivity gains do not come from letting agents write code. They come from offloading everything else. Think of LLMs as bookkeeping tools that you can speak to in natural language. Turn a long conversation with domain experts into a list of action items. Run a test, record the results, let the LLM organize a plan to fix what broke.
Markdown files with frontmatter work well for tracking these planning items. LLMs have large context windows, but they can still silently lose information when the context gets too full. Never let an LLM make a crucial decision on its own. Make it ask you questions. If you do not understand what it is asking, that is a signal that either the context is missing or you need a break.
Research Without Handing Over Your Brain
When you hand a research task to an agent, the temptation is to watch it query away while you make coffee or start another project. Do not fall for it. Research yourself in parallel using a standard search engine. You should roughly know what the agent finds before it presents its results.
Accepting agent research as fact leads to embarrassing technical debt. The goal is not for the agent to outsmart you. The goal is that you do not have to Google what it already found. You should understand the domain you are modelling at least as well as the agent does. Make agents write down their findings with links to sources. When they come back with a strange proposal, ask them which source supports it. Half the time they will catch their own error. The other half, you will be in a position to make a sound judgment yourself.
You Are the Coder
This is the core idea. Most coding harnesses push you toward a "plan first, then let the agent code" workflow. Reject that. Plan together, but you do the coding. Tell the LLM to research your codebase, surface the current todos, highlight the files you need to touch, flag potential pitfalls, and remind you of relevant background research. Then write the code yourself.
This approach works because you stay in control. You always know the state of your codebase. You discover bad plans early instead of watching an agent grind through a flawed approach for hours. And you keep sharpening your skills. The agents handle the incidental work around you. You handle what you enjoy.
The advantages are concrete. You never lose track of where you are in a session. You never have to rewrite LLM slop. You never get surprised by weird generated code sneaking into your project. It works like agile without the ceremonies.
When Coding Agents Actually Help
There are narrow cases where a coding agent is genuinely useful. Cleanup tasks, routine work, low-risk refactorings. You left a handful of FIXMEs in your code on purpose to save time. You wrote the three interesting cases and the remaining seven are obvious adaptations. You want a module reorganization benchmarked before committing. These are valid use cases.
Designing something complex from scratch is not one of them. Be careful of the trap where you write three interesting cases and tell the agent to handle the rest. What looks like a simple adaptation might be an opportunity to abstract, to apply a lens or recognize a type class instance. LLMs are notorious for copying large swathes of code instead of seeing the pattern. You, as a human, can do better.
Build an Automated Review Cycle
The concept is borrowed from generative adversarial networks, where a generator and a discriminator work together to produce better results than either alone. In LLM-assisted coding, that means no artefact gets accepted without being reviewed by a separate agent.
This applies to both code and plans. When an agent finishes coding, the job is not done until a reviewer agent finds nothing worth fixing. Plans get the same treatment. It is exhausting to spot logical holes in a plan manually, especially when a refactoring step in one todo depends on code written in a later todo. A review agent catches those.
Even your own code benefits from this cycle. A review agent will catch genuine bugs, point out omissions, or just nag about documentation. It keeps you focused on the actual task. If you do not want to read an LLM review yourself, instruct it to fix minor findings automatically.
Frontier Models Are Not Worth the Risk
The biggest models are not your friends here. They consume enormous amounts of energy, though LLM companies are not transparent about exactly how much. They make it hard to build trust because they pretend to be far cleverer than you, and ultimately you are responsible for every line of code that ships. Blaming a machine for bad code is something bad managers do to their employees, and it is ridiculous to do to a service.
Frontier models also burn through tokens faster, making it impossible to predict whether you will finish a task in a given session. If your workflow does not require a frontier model, stick with a smaller one. You save tokens, you reduce dependency on big tech, and you give yourself a path toward eventually switching to open-weight alternatives.
Token Anxiety Is a Service Outage
Running out of tokens mid-task is not a personal failure. It is a service outage. The number of tokens available in a session is determined by a company that can change it without warning. Treat it the way you would treat a train losing internet connection. Cache big assets beforehand. Always have offline work ready to go.
Keep a planned list of todos that you can work through independently. When your agent comes back online, hand it the cleanup tasks. Do not let your entire workflow grind to a halt because a vendor decided to throttle your access.
LLMs will never replace human developers at their core activity. They would need to be far more reliable, far more resource-efficient, and genuinely accountable for their output. Until then, the best strategy is simple: stay in the driver's seat, let the machine do the tedious work, and keep writing code that you are proud to own.