Almost finished, already abandoned
A personal reflection on AI coding, the attachment earned through building, and finding the motivation to finish.
I was talking to a friend the other day about the projects you can now build with AI. You have an idea, spend a few hours working with a coding tool, and suddenly there’s something on screen that looks remarkably close to what you imagined.
Then you spend the next week trying to finish it.
That jump to “80 or 90 per cent done” is exciting, even if the percentage turns out to be wildly optimistic. The remaining work is less satisfying. Something breaks under slightly different conditions. A fix creates another problem. The product looks ready until you actually try to use it properly.
I’ve found myself losing interest at that point. Another almost-finished project gets put aside, with every intention of coming back to it.
What interests me is how little attachment I sometimes feel to something I was so excited about a few days earlier.
When building software was more hands-on, there was a history behind whatever ended up on screen. You had planned parts of it, made mistakes, worked out why something wouldn’t behave, and eventually got it working. There was that small, disproportionate hit of satisfaction when a problem you’d been stuck on finally gave way.
Over time, those experiences gave you reasons to care about the thing you were making. You remembered what had gone into it.
With AI doing much of the coding, I can arrive at a similar-looking result without having accumulated much of that history. I’m pleased it exists. I might be impressed by how quickly it appeared. But I haven’t necessarily developed the same attachment to it.
There’s an awkward sunk-cost element to this. Having spent weeks on something can make you reluctant to abandon it, even when abandoning it would be sensible. I wouldn’t argue that we should make development harder just to manufacture commitment.
Still, I wonder whether some of the effort we’ve removed was doing useful work on us as well as on the software. Solving those problems helped turn an interesting idea into a project I felt invested in finishing.
There’s a practical side to that history, too. You become familiar with the code.
You remember the part you rushed, the workaround you weren’t entirely happy with, or the decision that seemed sensible at the time. When something breaks, you have a rough idea of where to look. You know where the bodies are buried because, occasionally, you buried them.
When a tool has written large portions of the project, that familiarity can be missing. I can recognise that something is wrong without understanding enough of what’s underneath to investigate it myself.
So I go back to the tool.
Describe the issue, accept a fix, try again. Sometimes that works beautifully. Other times, I end up circling the same problem, explaining it slightly differently and hoping the next attempt will stick. A fix appears to work, then the issue returns somewhere else.
That’s a particularly frustrating place to be: close enough to see what the finished product should look like, but unable to make it behave quite as intended.
And by then, the novelty has worn off. The next idea offers another few hours of rapid, visible progress. The current one offers an evening trying to understand why a button still does the wrong thing.
I don’t think every abandoned experiment is a loss. Being able to try an idea cheaply and discover it isn’t worth pursuing is useful. But I’m less comfortable when I leave behind something I still believe in, simply because I’ve run out of patience with finishing it.
I still get enormous enjoyment from creating with these tools. What I’m beginning to question is whether excitement about how quickly I can build something tells me very much about how much I want it to exist.
Before starting the next project, I’d like to have a better answer to that.