How to Enjoy Programming With AI (Without Losing the Craft)

To enjoy programming with AI, stop using it to write code you have to review line by line. Use it instead to eliminate the boilerplate that never brought you joy in the first place, and spend the reclaimed hours on architecture and tools you actually own.

That sounds simple. Most developers are doing the opposite.

Why is there a backlash against AI coding tools?

In September 2026, a software engineer published a post called "One Month Without AI" that went viral in developer circles. His complaint wasn't that AI wrote bad code. It was that months of agent-delegated coding had left him without a real grip on his own codebase.¹ He estimated he understood less than 20% of what his AI-generated code actually did, and said the experience left him "dumber, lazy, and a worse developer."¹ Stepping away for a month, back to manual coding, gave him relief.

He's not alone. Adoption of AI coding tools keeps climbing: 84% of developers now use or plan to use them, up from 76% in 2024, according to Stack Overflow's 2025 Developer Survey.² But trust is collapsing at the same time. Nearly half of developers, 46%, say they don't trust AI output, up sharply from 31% a year earlier, and overall positive sentiment toward AI tools has dropped from over 70% to roughly 60%.²

More use, less trust, less joy. That's the paradox behind the question of how to enjoy this work again. The answer isn't to opt out. It's to be deliberate about where AI gets pointed.

Why does AI-assisted coding feel hollow?

There's real research behind the burnout, not just vibes. A randomized controlled trial from METR had experienced open-source developers complete tasks with and without AI tools. The developers using AI took 19% longer than the developers who didn't, even though they believed AI had made them roughly 20% faster.³ The gap between how fast AI feels and how fast it actually is turns out to be enormous, and closing that gap without noticing is exhausting on its own.

An eight-month embedded study of about 200 employees at a US tech company, run by UC Berkeley Haas researchers and published in Harvard Business Review, found something similar at the organizational level. AI didn't reduce anyone's workload.⁴⁵ It intensified it, through task expansion, blurred boundaries between work and non-work, and more multitasking. People took on more, worked more hours, and did it without being asked to.⁴ The researchers warned that the early productivity surge gives way to burnout if companies don't set clear norms.⁵

Evil Martians has framed the mechanism cleanly: writing code is a meditative, satisfying process, and reviewing AI-generated code is a cognitively taxing one. When AI writes and you review, you've swapped the enjoyable part of the job for the draining part. And because tasks now feel easy, there are no natural stopping points left. You just keep going.

Is all AI coding work equally draining?

No. The research above is almost entirely about judgment-heavy, review-intensive work. It looks very different when AI is pointed at boilerplate.

GitHub's own research, surveying more than 2,000 developers and running controlled experiments with Copilot, found that when AI handles repetitive, low-judgment work specifically, 60% to 75% of developers report increased job fulfillment and less frustration.⁶ 73% said Copilot helps them stay in flow, and 87% said it helps preserve mental effort during repetitive tasks.⁶

That's the split. AI erodes joy when it's substituting for craft decisions you'd rather make yourself. It restores joy when it's substituting for glue code, CRUD scaffolding, and config files you never wanted to write anyway. Same tool, opposite outcome, depending entirely on what you hand it.

Engineer Kyle Redelinghuys draws a useful line here: craft-focused developers enjoy the process of writing code, while delivery-focused developers care about shipping.⁷ Neither is wrong. But if you're craft-focused and you've been letting AI write the parts you'd normally enjoy while you review the output, you've built a job that satisfies neither instinct.

Why building internal tools with AI feels different

There's a category of AI-assisted work that sidesteps this whole problem: building software you own instead of stitching together rented APIs. When you're gluing together a third-party SaaS's endpoints, you're bound by someone else's data model, someone else's rate limits, someone else's roadmap. The AI is doing integration labor, and integration labor against a foreign system rarely feels like craft.

Building your own internal tool with AI is different. You control the schema, the workflow, the UI. There's real architecture to decide, and AI clearing away the boilerplate around that decision, the routing, the forms, the auth scaffolding, actually frees up the bandwidth to make those decisions well. That's the version of AI-assisted coding GitHub's satisfaction numbers were measuring.⁶

Retool's 2026 Build vs. Buy survey of 817 enterprise builders backs this up at scale. 35% of teams have already replaced at least one SaaS tool with something they built themselves, and 78% expect to build more custom internal tools in 2026.⁸ 51% have already shipped AI-built production software their team actively uses, and about half of those report saving six or more hours a week.⁹ That's not a hobby trend. That's teams finding the version of AI-assisted development that pays off in both hours and satisfaction.

It's the same shift covered in how AI frontend generation is killing niche SaaS: the boilerplate that used to justify a $200-a-month subscription now takes minutes to generate, and the judgment work of deciding what the tool should actually do stays yours. Platforms built for exactly this job, like Remy, exist because the gap between "AI can write this" and "someone still has to own it" is where the real work, and the real satisfaction, now lives.

Why is building your own tools the rational default now?

Joy aside, the financial case for redirecting effort toward owned tools isn't subtle. The average company now spends $4,830 per employee per year on SaaS, up 21.9% year over year, while holding roughly 275 SaaS applications in its portfolio.¹⁰ 53% of all SaaS licenses go unused within a 30-day period.¹⁰ Some estimates put enterprise waste from unused licenses as high as $18 million a year, with Gartner estimating organizations lose about a quarter of their SaaS budget to unused entitlements.¹¹

That's the backdrop against which spinning up another subscription stopped being the obviously cheap option. If AI can absorb the boilerplate of building the internal equivalent, the build vs. buy math tilts toward building, and building is also the version of the work developers report enjoying more.

The governance catch nobody wants to hear

The same ease that lets a developer build something satisfying on a Tuesday afternoon also lets that tool proliferate outside any oversight. Retool's report found many builders are shipping internal software outside traditional IT governance, because development is outpacing procurement.⁸ UpGuard's State of Shadow AI research found 81% of employees and 88% of security leaders report unapproved AI tool use at work, and 45% of workers find workarounds when tools are blocked.¹²

The fix isn't to lock everything down. It's that the tools people build for joy still need an owner, a place to live, and someone checking what data they touch. Ungoverned joy is still a liability. Lightweight guardrails, not prohibition, keep the fun sustainable.

How do you actually enjoy programming with AI?

If the goal is genuine satisfaction rather than just throughput, a few concrete habits make the difference:

1. Delegate boilerplate, not architecture. Let AI write the CRUD scaffolding, the config, the test fixtures. Make the structural decisions yourself.
2. Decompose before you prompt. Break a task into pieces small enough that you can actually verify the output, instead of reviewing a wall of generated code you can't hold in your head.
3. Review deliberately, on a schedule. Set a fixed time to read and understand AI output rather than skimming it between other tasks. That's where the METR gap between felt speed and real speed closes.³
4. Protect craft hours. Block time each week to write something by hand, on purpose, the way the "Month Without AI" post rediscovered by stepping away entirely.¹
5. Build owned tools instead of gluing rented ones. Redirect AI-freed hours toward internal software you control, not another integration against someone else's SaaS API.
6. Set your own stopping points. Because AI-assisted tasks rarely feel hard enough to naturally end, decide in advance when a task is done, rather than letting "it's easy, keep going" expand your day.⁴

Joy is a build decision, not a tooling decision

The developers burning out aren't burning out because AI writes code. They're burning out because they're spending their AI-freed hours reviewing more of someone else's system, integrating against more rented APIs, and absorbing more tasks into the same workday.⁴³

The fix isn't a month without AI, though that experiment clearly taught its author something real.¹ The fix is pointing AI at the boilerplate you never liked writing anyway, and spending what's left of your attention on architecture you actually own. That's the version of this job that was fun to begin with.