Keeping programming enjoyable when LLMs write the first draft

TL;DR: Use LLMs to remove programming chores, not to outsource the parts of programming that make you better, sharper, or more interested.

What actually changes when LLMs enter the editor?

The Hacker News discussion titled “How to keep enjoying programming in a world of LLMs” is useful because the title says the quiet part out loud. A lot of developers do not just worry about jobs. They worry about losing the activity itself.

That is a different problem.

LLMs are very good at changing the texture of programming. Less blank-page work. More review. More “is this right?” More editing someone else’s draft, except the someone else is a machine that sounds confident and forgets the constraints you care about.

For production teams, that can be a win. Boilerplate, test scaffolds, migration scripts, config glue, API wrappers, one-off data transforms, these are often not where the joy is. If a model gets you to a rough version faster, fine. The catch is that the pleasant parts of programming are not always separate from the tedious parts. Sometimes the tiny annoying step is where you notice the better abstraction. Sometimes writing the ugly first version by hand is how you learn the shape of the problem.

So the question is not “should I use LLMs?” That is too broad. The question is where the model sits in the loop.

Which parts should you keep for yourself?

I would keep three things close.

First, problem framing. If you ask for code before you know what you want, you get code-shaped fog. The model can help explore options, but the developer still needs to decide what matters: latency, readability, data correctness, cost, failure behavior, boring maintainability.

Second, debugging. Not every bug deserves a heroic manual hunt, but outsourcing all debugging is a fast way to become worse at reading systems. Ask the model for hypotheses. Ask it to explain a stack trace. Ask it to suggest probes. But you should still run the experiment and update your own mental model.

Third, taste. Naming, boundaries, deletion, what not to build, these are still human advantages. LLMs can produce a lot of plausible code. Plausible code is not the same as good code.

The fun returns when the model becomes a shop tool, not the shop foreman. Let it cut stock. Let it fetch parts. Let it sketch. But do not let it decide the whole object while you stand there approving autocomplete.

How do you use coding agents without making the work feel hollow?

Use constraints that preserve agency.

One pattern I like: write the plan yourself, then let the LLM fill in the least interesting chunk. Another: ask for three approaches, pick none of them exactly, then implement the hybrid. Another: use the model after a first pass, not before, so it becomes a reviewer instead of the author of your thought.

For learning, I would be even stricter. If the goal is skill, do not let the model finish the move you are trying to practice. Have it ask questions. Have it point to docs. Have it generate tests after you write the function. Have it explain why your version fails. That keeps the friction where the learning happens.

For professional work, enjoyment also comes from trust. A codebase full of unreviewed generated code is not fun. It is debt with better grammar. Teams need norms: what can be generated, what must be reviewed, what needs tests, what needs a human design note. Without that, LLM use becomes private and uneven, which makes the code harder to reason about.

The practical move: pick one workflow this week where the model removes drag without stealing the craft. For example, let it generate test cases for code you wrote, or refactor a boring adapter behind an existing interface. Then inspect every line. The catch most readers miss is that enjoyment is not preserved by avoiding LLMs. It is preserved by deciding which parts of the work still belong to you.