The graveyard got bigger
Before AI, my side project graveyard was already respectable. Half-built APIs. A mobile app that made it to boilerplate before I came to my senses. A couple of tools that seemed like brilliant ideas at 10pm on a Wednesday and looked embarrassing by Saturday. I'd start things, lose momentum, and move on. Classic. Nothing to be proud of, but nothing to be alarmed by either.
Since I started leaning into AI tools, that graveyard has roughly tripled. Maybe more. I'm not sure whether to be amused or concerned, so for now I'm going with both.
This isn't a complaint. It's an observation that I think a lot of engineers are quietly having and not saying out loud: AI has dramatically lowered the cost of starting something, but it hasn't touched the cost of finishing it. And that gap is getting a lot of people into situations they didn't fully anticipate.
The activation energy problem
Starting a side project used to be a tax. You'd have the idea, feel genuinely excited about it for about 20 minutes, and then the reality would set in. You'd need to set up the project structure, configure the tooling, scaffold the basic architecture, write the boilerplate, and figure out whatever you didn't already know before you could even get to the part you actually wanted to build. For someone with a family, kids, and a finite number of hours in a week, that tax was often enough to kill the idea before it started.
AI changed that calculus completely. Tools exist now where you answer a few prompts and you have a working base project. What used to take an evening now takes 20 minutes. The friction that acted as a natural filter on which ideas were worth pursuing is mostly gone.
That sounds like a good thing. More ideas get a shot. More experiments happen. More learning occurs. And honestly, it is a good thing, in a lot of ways. But it also means a different kind of filter has to do the work that friction used to do, and I'm not sure most of us have figured out what that filter is yet.
What the dopamine is actually doing
Here's what I've noticed in myself: the early stages of a project with AI feel really good. Suspiciously good. You describe what you want, it builds something, you can see it taking shape, and you get this hit of momentum that used to take days to arrive. That momentum was hard-won before. You'd earned it by the time it showed up. Now it shows up almost immediately, and it doesn't necessarily reflect the actual state of the project.
The dopamine hit is real and it's a little addicting. I tell it to do something and it does it pretty well. If only my kids listend that well. I can modify the code directly if I want, or I can just prompt my way through the change. Either way, I'm moving fast, I'm building, and it feels like being an IC again in the best possible way. For someone who's been in engineering management for a few years, getting back into builder mode has genuine appeal. It scratches an itch.
But that feeling can deceive you about where you actually are. You can feel 70% done when you're 20% done. The scaffolding is up, the core interaction works, and then you hit the part of the project that requires something AI can't just generate for you. Getting real users. Solving the data problem. Building the social layer that would actually make the thing useful. Dealing with hosting and maintenance and the ongoing cost of keeping something alive.
That's where my projects go to die. Not at the start, and not because I lost interest in the idea. At the point where the problem stops being a technical one.
The finite time problem hasn't moved
I have a family. I have kids. I like going outside and touching grass occasionally. Those things have not changed because AI got faster. The number of hours available to me for side projects is roughly what it was two years ago. What's changed is how many projects I can spin up within those hours, not how many I can sustain.
This is the part that I don't think gets enough attention in the conversation about AI productivity. We talk a lot about how much faster you can move in the early stages of building something. We talk less about the fact that the costs that actually kill most side projects aren't the early stages. They're the middle and the end. The integration work. The "this would be great but I need to figure out X first" stretches. The slow realization that the thing you've built needs ten more things before it's useful to anyone else.
One project I started recently was something my wife wanted: an app for a specific need she had. With AI I got further faster than I expected. And then it stalled, not because the code got hard, but because the idea ran into a real-world constraint that no amount of prompting was going to solve. The business logic behind it, the data sourcing, the bits that required coordination outside of a code editor. Those parts are still what they always were.
Another is my own personal site, migrating away from a third-party tool and hosting it myself. I've learned a lot. I've also had the "is this actually worth the operational overhead" conversation with myself several times. That project might make it. It might not. But either way, it's a good example of how AI gets you into a place where you're dealing with the real tradeoffs faster, not a place where the tradeoffs disappear.
The "one more prompt" problem
There's a version of the "one more ticket" trap that I'm starting to recognize in myself. You know the one: you're wrapping up for the night, you tell yourself one more line, one more fix, one more push. Hours pass.
AI has a version of this. One more prompt. Let me just try this quickly. That's interesting, let me push it a bit further. Next thing you know it's well past when you meant to stop, and you're deep in a project that may or may not exist in three weeks.
I have to be more deliberate about stopping now than I used to. Not because the work is exhausting, but because it doesn't feel like work in the way it used to. The friction that used to signal "you're working hard, you should probably rest" has been smoothed away, and without it, it's easy to drift well past what's reasonable.
Is this actually a problem?
Here's where I land, provisionally: the explosion in unfinished projects isn't necessarily bad. It depends on what you're getting out of it.
If you're exploring, experimenting, learning tools by building with them rather than reading about them, there's real value in having ten unfinished projects. You're not maintaining a graveyard of failures. You're running a series of experiments at a cost that used to be excessive.
Where it becomes a problem is if the unfinished projects represent wasted commitments to people you made promises to, or if the dopamine of starting is genuinely replacing the satisfaction of finishing. Starting is easy now. It always felt good, but it was hard enough that it filtered out the weak ideas. Now the filter is gone and you have to supply it yourself. That requires a kind of intentionality about which projects deserve your sustained attention that I don't think comes naturally, and I don't think the tools help you develop it.
The exploration is great. Being able to try something new without investing a weekend in scaffolding is genuinely valuable. But time is still the constraint it always was, and the projects that matter, the ones that are actually for something, still need you to show up past the dopamine phase.
I don't have a clean answer for how to balance this. I'm not sure one exists yet. What I do know is that "I can build more" and "I should start more" are different statements, and AI has made it very easy to confuse them.