Cheap Code or Cheat Code?

I recently built another side project. An idea grabbed me, AI got me to a working version within hours, and then the features started piling up. Oh, and it could do this too. That would be neat as well. After each one, the agent cheerfully reported back: “All tests are green, every feature works perfectly. What's next?”

A week later I had moved on to a new toy.

This keeps happening. The gap between an idea and a working result keeps shrinking, but so, sometimes, does my interest in that result.

It's an odd position to be in. I can build things I never used to have the time or energy for. An idea that would have sat on a shelf for months can be tested in a single evening.

So why do the things I make sometimes matter so little to me?

A Cheat Code for My Favorite Game

Before AI, a project like this would probably have taken me months, and might well have joined my other abandoned side projects.

But those months would have been full. I'd have wrestled with unfamiliar tools, gotten stuck, gotten angry, and worked my way out. I'd have felt that small rush when something finally ran after the fourth failed attempt.

Today I can skip most of that road and go straight to the result. It turns out I wanted the road as well.

It reminds me of cheating in The Sims. As long as money is short, you have plans: earn some, fix up the house, upgrade a little at a time. Then you type motherlode, buy everything on your list, and the game somehow stops being fun.

Not because the house turned out badly. Building it just wasn't the only point of playing.

Programming sometimes works the same way for me. I think I want the finished thing, when I also want to be the one making it: to figure it out, make the decisions, and learn something along the way.

That doesn't make “harder” better by default. I don't miss a single hour I ever spent debugging stupid errors. For a business, a quick prototype is often exactly right: test the assumption, don't overspend, move on.

When I'm building for myself, though, the result isn't the only thing that counts. Handing over the work can mean handing over the very reason I started.

Limits Helped Me Choose

Features used to carry a price I could feel: an evening, a weekend, a few weeks. I had to decide whether each one was worth it.

Limited time and energy forced me to focus. I didn't always choose well, but the question “do I actually need this?” asked itself.

With AI, it's easy to never ask it.

When adding a feature takes one short message to an agent, almost any idea feels like reason enough to try. And while the agent is busy, I can dream up the next one.

That's how a small personal experiment grows settings, modes, and integrations. Adding them is fun. Using most of them turns out to be optional.

I catch myself checking that a new feature works, collecting my little “wow,” and moving straight on to the next. But confirming that a feature works is not the same as finding a place for it in my life.

And it's mainly generating code that got cheaper. I still have to understand it, review it, and, if the project stays with me, maintain it.

The cost of building used to stop me and make me think. Now I have to build that filter deliberately.

I Wanted a Helper but Became a Reader

There were times I had no idea how to implement something and felt like I'd walked into a wall. Estimates had been given, people were waiting. That brought anxiety, and occasionally outright panic.

At one point I left myself a written note: “You've been here plenty of times. You got through every one of them. You'll figure this one out too.”

Reading it calmed me down. Often the panic itself was the biggest obstacle. Once I was calm, it was easier to break the problem into pieces, try another angle, and eventually find a way through.

So I don't want to romanticize everything about working before AI. That anxiety I don't miss at all. Being able to ask for an explanation or talk through options on the spot means a lot to me. But getting support so I can keep moving on my own isn't the same as handing the entire journey to someone else.

I remember my first days with ChatGPT clearly. I felt like I'd started loving my work even more.

It was as if getting permanently stuck was no longer possible. Unfamiliar API? Ask. Confusing parameters? Have them explained. Need a small function? Grab an example and keep going.

The answers weren't always right, but they were usually enough to get me unstuck. I was still writing the code myself. I just had a helper beside me who would take any question.

Things began to change when the model started writing large chunks of the project for me.

Now I describe a task, wait, and review what comes back. And here's a quirk of mine: I've always enjoyed writing my own code far more than reading someone else's.

Good code by someone else can be a pleasure too. Everything is laid out cleanly, the names guide you, and the decisions add up to a picture that makes sense. It's a little like listening to music: you can feel the next step coming.

Agent-written code rarely gives me that. It may run and solve the problem, but I don't like reading it. I have to reconstruct the reasoning behind decisions I barely took part in.

That changes the nature of the work. Less of my time goes to what I enjoy and more to what I used to tolerate as a necessity.

Skip the reading, though, and a different problem shows up. The project fills with parts I know nothing about except that they seem to work. When one breaks, asking the agent again is easier than digging in myself.

On paper it's still my project. The sense that I actually know it fades a little at a time.

Getting an Answer Doesn't Mean Learning

I also worry about what this does to the learning process.

Picking up an unfamiliar technology used to mean starting a course, finding a video series, or reading a few articles. Now asking a model is usually enough. It explains, shows an example, and, if you like, just does the task for you.

Getting an answer in seconds is a genuine gift, and I'm not sure we've fully taken that in yet.

I remember hunting for answers on forums. If nothing turned up, you started a thread and waited for someone with the right experience to notice it and feel like helping. Or you hoped someone had already written up the same problem and its solution.

Let's be honest, too: most of us just read existing answers rather than starting threads and sharing what we knew. I leaned on knowledge other people had left behind just like everyone else. Getting help is incomparably easier now.

But has learning gotten easier along with it?

Years ago, a book on learning foreign languages gave me an explanation that stuck. New words and structures are easier to absorb when they're tied to something beyond their translation: a sound, an image, a smell, a taste, a particular situation. We don't memorize a word in isolation; we attach it to experience we already have, and later those associations help us recall it mid-conversation.

I see the same thing in programming. When I write code myself, get it wrong, hunt down the cause, and fix it, the solution comes wrapped in context. I remember not just the right answer but the path to it. A ready-made solution from AI doesn't produce that experience on its own. Did I actually learn something, or will I ask the exact same question next time?

Earlier this year my frontend team and I started writing Python and talked about the best way to learn it. One view was that courses had become unnecessary: the model would explain everything as we went.

That may be enough for some people. In my experience, access to explanations doesn't make anything stick.

I'm learning Rust. Reading the book, I kept thinking, “this all makes sense.” Then I'd sit down to build something and find myself looking up how to declare a variable, again. Recognizing a construct on the page is very different from producing it when I need it.

JavaScript is a different story. I've been writing it for more than ten years. Even when I take no pleasure in reading generated code, the syntax never gets in my way. I spent years typing those constructs by hand, getting them wrong, and fixing them, and they've worn deep grooves in my memory.

A Rust book or a Python explanation can give me a basic understanding. Without practice, though, it never turns into that kind of confidence.

In that sense, I think we developers have been lucky. Our daily work doubled as practice. We solved problems for a company, got paid for it, and learned along the way. Not every task taught us something, but many did.

Years on the job guarantee nothing by themselves, of course. You can have ten years of experience or one year repeated ten times. So the question isn't only whether I write the code or hand it to AI. What matters is whether I meet something new, understand the solution, and come away seeing things differently. AI can help with that, or it can let me walk past yet another chance to learn.

The link between working and learning no longer feels automatic to me. A company cares about time and results. If an agent is faster, the task goes to the agent. But if I keep delegating exactly the steps I could have learned from, where is that experience supposed to come from?

I don't think a company job alone will be enough to build experience anymore, especially in a field where the goal is to ship as much as possible, as fast as possible. Learning will likely need its own time, maybe even outside work. What used to happen on its own now takes a deliberate decision.

I don't believe learning with AI is impossible. Quite the opposite: being able to ask follow-up questions, request a different example, or pick apart my own mistake can help enormously. But only if I stay a participant in solving the problem, not just the recipient of an answer.

So next to “what do I want to keep for myself?” sits a second question: what do I need to do myself in order to actually learn this?

Other People's Speed

Against that backdrop, I hear it from every direction: I have ten agents running in parallel. I have a hundred. Everything gets generated while I sleep.

And I feel like I'm missing out.

Have I not automated enough? Is my approach already obsolete? While I'm reading one diff, someone else is kicking off ten more tasks.

Strangely, my first reaction is to tune my automation even further. As though the enjoyment is bound to come back once I learn to generate more, faster.

But what exactly am I trying to improve?

If my problem is that I'm losing my grip on the project and don't want to read generated code, more of that code won't fix it.

I see posts from other developers describing the same loss of joy in the work. Some are considering a different career. Others want to go back to writing code by hand, however much slower that turns out to be. I don't know how far our reasons overlap, but I recognize some of what they describe.

Someone else's way of working may suit someone else's goals perfectly well. I don't need to prove that a hundred agents is a bad idea. I need to understand why I'm using other people's agent counts as the yardstick for my own progress.

Producing more code isn't the goal. I want to make useful things and enjoy how I make them.

Just Because I Can Doesn't Mean I Have To

Agents can take on more and more work, but that doesn't mean they should get all of it, whatever the endless feed of posts about new capabilities suggests.

It reminds me of living in a consumer society. Everywhere something is tugging at my attention: buy me, try me, eat this, drink that. But an offer being available and attractive doesn't mean I need it. Respond to every pitch and you soon end up with a heap of things you don't use, expenses you didn't need, and habits you never actually wanted.

Agents set a similar trap. I can always launch one more task, add one more feature, try one more tool. The ability to keep going says nothing about when enough is enough. That line I have to draw myself.

A comment under a video about getting too deep into agents made me laugh out loud. A man described how, at four in the morning, his wife asked if he was texting another woman, because she'd never seen him so active at night. He was just sending another prompt to an agent that had stalled partway through a job.

It's a funny story, but the feeling in it is familiar: one more message and then I'll sleep. One more result. One more small tweak.

So a tool meant to free up my time can swallow every hour I'm willing to give it. So I need to learn not just how to use these tools, but where to stop.

Taking Back the Choice

I like the idea of generative art. You don't craft every detail by hand. You set up an environment, define rules and constraints, look at what comes out, and adjust.

Working with AI has something of that. There's room for creativity here too: how you frame the task, what context you supply, how you structure the process.

But it's a different activity. It can be interesting and still not give me what writing code gives me. I don't have to pretend the two are interchangeable.

I also don't think today's tools are the final form. The model's commands, reasoning, tool calls, reports, and questions, all poured into one endless wall of text, are unlikely to be the best way to interact with any of this. Some of the discomfort may come less from delegating than from how delegating is organized right now.

Still, I don't want to wait for the perfect tool.

Every so often I set aside time to change something about how I work. A different app, a new approach, a small tool of my own. Throw things at the wall and see what sticks.

Practice quickly reveals what theory hides. An approach can sound wonderful and I'll still find myself avoiding it. A simple change I expected nothing from can stay with me for years.

These days I want to start those experiments not with “how do I automate even more?” but with different questions:

Sometimes the answer will be more automation. Sometimes it will be writing a part that matters to me by hand. And sometimes it will be not adding the next feature at all.

I don't know how we'll be writing code a year from now. But I can already be more deliberate about which parts of the work I keep for myself.

Maybe I don't need another side project with twenty features. Maybe I need one small change that brings the joy back.