Some time ago, I asked an AI to write a fairly boring piece of code. It did a pretty good job. I changed a few things, ran the tests, and voila: I was looking at something that probably would have taken me most of the morning to write myself. This is the most exciting part of AI-assisted development for me: from idea to code in less than an hour. I felt great.
Then a user hit a bug.
They came back a second time, and something didn't work. The API needed to return something useful, but there wasn't an obvious answer. The generated code had handled the happy path perfectly well, but it had not really considered what should happen when the happy path wasn't happening. And why would it? I hadn't given it the answer. Someone had to decide what the product should actually do. So I sat there looking at a flow that was technically almost finished, trying to answer questions that weren't coding questions anymore.
Did we mean for it to behave this way?
What should the user see?
What would be least confusing?
And, perhaps most importantly, what are we actually promising this user?
Answering these took some time. And this is exactly the part of AI-assisted development I've been thinking about lately: the leftover hard parts.
There’s a particular kind of work that is difficult to automate because it’s about deciding what the answer should be in the first place.
What happens when the customer does something nobody expected? Is this weird behaviour a bug or a feature? Which of these two perfectly reasonable approaches will make sense six months from now? What are we comfortable promising users? When should we not ship this? And many more.
These questions don't usually come with a neat specification. Sometimes nobody knows the answer yet, or the answer is sitting in a conversation with a customer, or it's buried in a decision the team made two years ago. And sometimes you only discover that you needed to decide after the AI has already produced something that looks finished.
That's what makes this shift uncomfortable: AI can make the output look finished before the thinking is finished. And I think that's easy to miss.
There is a particular feeling I've started noticing more. The code is almost right, which sounds great. Almost right should mean you're nearly done. But sometimes "almost" is where the expensive part starts. If the generated code is completely wrong, that's easy: you throw it away. If it's perfect, even better. But when it's 85 or 90 percent right, you have to understand the remaining 10 percent. And that 10 percent might contain all the interesting stuff. The model has created something plausible, so now you have to inspect it closely enough to notice where plausible isn't good enough.
You have to know what questions to ask and which assumptions it made. You also have to understand the system well enough to recognise the strange case it didn't account for. And you have to care enough to stop and investigate.
That last part truly matters. Because the faster the first draft becomes, the easier it is to feel like you're behind when you are actually doing the harder part.
There's also something satisfying about the old way of working.
You write a little bit of code.
You run it.
It works.
You see the thing on the screen.
You fix something.
You write the next bit.
There's a constant little feedback loop. Do something. Get a result. Move on.
AI breaks that loop.
You can ask for a lot at once and get a lot at once. Sometimes that's fantastic. But sometimes I find myself staring at a large chunk of generated code and thinking: Okay, now I have to understand all of this.
I don't type anymore, but I still need to understand a lot, preferably fast. I need to understand "why", which is already one of the most important things we do in software development. The machine can produce an answer to "how" incredibly quickly. That doesn't mean "why" got easier.
When AI generates code, it's very easy to think of the model as the thing that produced the result. But the model doesn't own the result. We do.
The customer doesn't care that the code was generated. They don't care whether we wrote it by hand, asked an AI to write it, or summoned it through some increasingly elaborate agentic workflow. They care whether the thing works.
And if it doesn't, someone has to explain why, fix it, decide whether it was actually a bug, and whether the behaviour should change.
That's the strange thing about delegation. We can delegate production, but we can't really delegate responsibility. At least not in the same way. We can ask a machine to write the function, but we still have to decide whether that function belongs in the product.
I don't think this means developers become unnecessary. If anything, it makes the distinction between writing code and engineering software more obvious.
Writing code is one part of the job.
Understanding the problem is another.
Making trade-offs is another.
Knowing what not to build is another.
Communicating decisions is another.
Taking responsibility for the result is another.
For a long time, those things were bundled together because the same person had to do all of them. We couldn't separate them very easily. If we wanted software, somebody had to sit down and write it. Now that part is becoming easier to delegate. And that means we're going to see much more clearly which parts of the job were never really about typing in the first place.
I've been trying to get used to that, but I often catch myself wanting the old feeling of productivity. A big diff. Lots of files changed. Something I can point at and say, "Look what I did today."
But maybe the useful part of the day increasingly won't look like that. Maybe it's the hour spent figuring out what should happen when the user comes back for the second time.
Or it's the conversation with a teammate where you realise you've all been assuming something different.
Or it's deciding not to ship something even though the implementation is already sitting there.
That work doesn't look impressive in a Git history. It might not even make a particularly good screenshot. But it is still engineering. Possibly some of the most important engineering.
The easy work is getting cheaper.
The leftover work is still ours.
And I'm starting to think that's where the interesting part of the job is going to be.
A good day used to mean I wrote a lot. Now, sometimes, a good day is one honest decision about an empty response.
It feels like less. It probably isn't.
It just costs more attention.