I have a problem.
Actually, I have 84 public GitHub repositories.
I checked.
Eighty-four.
And that's just the public ones.
To be fair, they aren't all active projects. Some are old. Some are experiments. Some are tiny tools. Some have been abandoned, resurrected, renamed, rebuilt, or replaced by another project that I apparently decided absolutely needed to exist.
But still.
84.
I have always been the kind of person who gets excited about a new idea before I've finished the last one. AI coding tools did not create that problem.
They did, however, remove basically every obstacle that used to keep it under control.
It used to be harder to start something
Not necessarily hard, but there was friction.
You'd have an idea.
Maybe you'd think about it for a while. Research a library. Read some documentation. Figure out how you wanted to structure it. Decide whether learning an unfamiliar framework was worth the trouble.
Sometimes somewhere in that process you'd realize:
You know what? I don't actually care enough about this.
And that was probably healthy.
Now I can have a thought like:
It would be cool if there were a terminal MIDI player.
And ten minutes later I have a Rust project, a Ratatui interface, MIDI playback partially working, a name, a logo idea, and opinions about the layout.
The responsible part of my brain never even got a meeting invite.
AI destroyed the activation energy
This might be one of the biggest ways AI coding tools have changed how I build software.
They didn't just make programming faster.
They made starting dramatically easier.
A new language isn't as intimidating because I can ask questions while I work.
An unfamiliar library isn't a weekend of documentation before I can touch anything.
Boilerplate barely matters.
I don't have to remember the exact configuration for every framework I've ever used.
If I want to know whether some weird idea is technically possible, I don't necessarily have to spend three hours researching it first.
I can just try it.
And honestly, that's pretty incredible.
I've built things with Rust that I probably wouldn't have touched yet otherwise. I've experimented with terminal UIs, local AI models, MCP servers, desktop apps, browser APIs, image tools, audio tools, little utilities, developer tools, and an unreasonable assortment of other things.
Some became real projects.
Some taught me something useful.
Some lasted approximately one evening.
I don't think any of that time was wasted.
But there is definitely a side effect.
Every idea can become a project now
This is where things get dangerous for people like me.
Previously, there was a natural filter between:
"That would be neat."
and
"I'm building that."
AI has made that filter extremely thin.
Sometimes nonexistent.
I'll be working on one project and run into a tiny annoyance.
That annoyance gives me an idea for a tool.
I ask an AI coding agent whether the idea would work.
It says yes.
Obviously this is unacceptable.
Now I need to build it.
Two hours later the original project is sitting abandoned in another terminal tab wondering where I went.
It's not even always a big idea.
Sometimes it's:
- I wish this command did one extra thing.
- It would be nice if I had a little UI for this.
- Why doesn't this tool show this information?
- I bet I could make this work in the terminal.
- What if this accepted pasted images directly?
- Could I make this local instead?
- I wonder if this model would run in the browser.
- This existing tool is almost what I want, except...
That last one is particularly dangerous.
Except.
Nothing has generated more repositories on my GitHub account than "this is almost what I want, except..."
Prototyping has become ridiculously cheap
And I mean cheap in more than just money.
The cost in time, effort, and mental energy has dropped.
I can test an idea before I've fully committed to it.
That's a huge advantage.
There are projects I've started where I realized pretty quickly that the idea wasn't as interesting as I thought. In the past, I might have spent days figuring that out.
Now I can sometimes figure it out in an hour.
Delete it. Archive it. Move on.
That's not failure.
That's a prototype doing its job.
The problem is that the exact same thing also makes it very easy to chase the next shiny idea.
And the next one.
And the one after that.
AI makes getting from 0% to 30% incredibly fast.
Unfortunately, 30% is also right around where another idea starts looking very exciting.
Starting and finishing are completely different skills
This is the part AI hasn't magically solved.
Starting a project is exciting.
You're creating everything from scratch. Every hour produces something visible. The architecture is clean because you haven't had enough time to ruin it yet. There are no users. There are no weird edge cases. Nobody has opened an issue explaining that your perfectly reasonable code breaks when their username contains an emoji and they're running Linux on a refrigerator.
Everything is possibility.
Finishing is different.
Finishing means:
- fixing boring bugs
- handling edge cases
- writing documentation
- testing things you already thought worked
- cleaning up shortcuts you took during the prototype
- packaging
- deployment
- accessibility
- updating dependencies
- realizing the feature you added three weeks ago broke something completely unrelated
AI can help with all of that.
But it doesn't make that stage feel like a shiny new project.
And that's the actual trap.
When starting becomes nearly frictionless, finishing has more competition than it ever did before.
But I don't actually want the friction back
This is the weird part.
I don't think the solution is to force myself to stop starting things.
I like experimenting.
A lot.
Some of the most useful things I've learned came from projects I had absolutely no business starting.
Sometimes I'll build something mostly because I want to learn a library.
Sometimes I want to see whether an idea works.
Sometimes existing software annoys me.
Sometimes I just think something would be fun.
Not every repository needs to become a product.
Not every side project needs users.
Not everything needs a roadmap, monetization strategy, launch plan, or compelling answer to "What problem does this solve?"
Sometimes the answer is:
I wanted to see if I could make it.
That's still one of my favorite reasons to program.
AI has made that kind of experimentation ridiculously accessible.
I don't want to lose that.
I just need to occasionally remember that GitHub also allows you to work on repositories that already exist.
Apparently.
I'm trying to separate experiments from commitments
The distinction I've started thinking about more is whether I'm exploring an idea or starting a project.
Those don't have to mean the same thing.
I can spend an evening testing some strange concept without mentally adding it to my collection of Things I Must Finish Someday.
That's harder than it sounds.
Especially when you've already named it.
Naming it is usually where I'm screwed.
Once it has a cute name and an icon, we're in dangerous territory.
But I think there's something useful about allowing yourself to prototype freely while being more selective about what gets promoted into an actual ongoing project.
Maybe the experiment taught me what I wanted to know.
Maybe the idea isn't strong enough.
Maybe another project already solves it.
Maybe it's fun enough to continue.
Maybe I open the repo three days later and immediately think:
Oh hell yes. I still want this.
That's probably a better signal than the initial burst of excitement.
This might be one of AI coding's strangest effects
We talk constantly about whether AI makes developers more productive.
How much faster can it write code?
How many tasks can an agent complete?
Which model gets the highest score?
Those things matter.
But I think there's another effect that's harder to measure.
AI changes what we're willing to try.
Ideas that previously weren't worth the setup cost suddenly are.
Technologies that felt too unfamiliar become approachable.
Tiny personal tools become worth building.
Ridiculous experiments become a Tuesday night.
The distance between curiosity and working code has gotten incredibly short.
For developers who already suffer from chronic "I could build that" syndrome, this is both wonderful and absolutely terrible.
I have learned more because of it.
I've tried things I wouldn't have tried before.
I've built tools I genuinely use.
I've also accumulated enough repositories that GitHub probably thinks I'm several people.
So no, I don't think AI made me a chronic project starter.
I was perfectly capable of doing that myself.
It just gave me a much faster shovel.
And apparently I have been digging.
Top comments (14)
One thing I’d add to the experiment-versus-commitment distinction is a promotion contract.
Before a prototype becomes a project, write down the evidence it earned, the next irreversible cost, and its stop or revisit date. Otherwise “I learned enough” and “I lost interest” look identical in the repository archive, while every named prototype keeps a claim on attention.
Cheap starts are valuable. The missing mechanism is making continuation compete for a finite portfolio budget.
I like the “promotion contract” idea a lot. That feels like a really useful way to separate “I learned what I needed from this” from “I just wandered off and forgot about it.”
The part about named prototypes keeping a claim on your attention is painfully accurate too. Once something has a name, a repo, and probably an icon, my brain immediately starts treating it like a real project whether it deserves that status or not.
Making continuation actually compete for a limited amount of attention is probably the part I need to get better at.
That is exactly the trap: a name, repo, and icon are cheap, but they make the prototype feel socially and emotionally “real”.
A compact promotion contract can stay small: what uncertainty the prototype was meant to reduce, what evidence it produced, the next decision that evidence supports, and which existing project must lose attention if this one continues.
That last field is the useful one for me. Continuation should consume a scarce portfolio slot, not happen because the artifact is charming or unfinished.
Yes, exactly. “A name, repo, and icon are cheap, but they make the prototype feel real” is such a good way to put it. I think that’s a huge part of why it gets harder to stay honest about what’s actually an experiment versus what’s become a real commitment.
I also really like the idea that continuation should cost an actual portfolio slot. That feels like the part most of us skip. We let things continue because they’re interesting or charming, not because they’ve earned enough to displace something else.
That framing is genuinely useful though. Asking what uncertainty the prototype was meant to reduce, what it actually proved, and what loses attention if it continues is a much better checkpoint than just “do I still like this idea?”
The activation-energy framing is right, and I'd push it one step further: starting got ten times cheaper and finishing didn't change at all. That ratio is the actual problem. Eighty-four repos isn't weak discipline, it's the rational output of a cost curve that moved on one side only.
Which means the fix isn't restoring the old friction, because you can't and mostly shouldn't. Some of those 84 taught you Rust, terminal UIs and MCP servers, and the old filter would have blocked that too. It was never smart about what it rejected.
The friction worth reintroducing is the deliberate kind. A paragraph written before any code exists, saying what done looks like. Not a spec , just enough that abandoning it later is a decision rather than a drift.
The metric I'd actually track isn't repo count. It's how many you'd start today knowing in advance what finishing costs. That number is usually much smaller than 84, and it's the one worth designing around.
I really like that distinction. Starting got dramatically cheaper, but finishing didn’t, and that probably is the part that creates the imbalance.
I also agree about not wanting the old friction back. A lot of the stuff I’ve learned came from projects that probably never would have survived that older filter in the first place.
The deliberate-friction idea is interesting though. Even just defining what “done” means before I get too attached to the shiny part of a project would probably help a lot. I especially like the idea of treating abandoning something as an actual decision instead of just letting it slowly drift into the repo graveyard.
I think the interesting part isn't really that AI makes us start more projects. It's that it changes the cost of exploration. Before AI, the friction of learning a stack, setting things up, reading docs, etc. naturally filtered a lot of ideas. Now we can test an idea in a couple of hours and get enough evidence to decide whether it's actually worth pursuing.
For example, I might have an idea for a dashboard and build a working version with Next.js, an API, and a database just to test the concept. If the interaction model doesn't feel right after that experiment, I can drop it without spending weeks building the rest of the system. The problem starts when we confuse a successful prototype with a commitment.
For me, the useful distinction is: explore freely, commit selectively.
A prototype reaching 30% isn't necessarily an unfinished project. Sometimes 30% is exactly enough to prove that the idea isn't worth the next 70%.
AI makes that loop much faster. The real skill becomes knowing which experiments deserve to become systems, and which ones should simply be archived.
I really like this way of framing it. “Cost of exploration” feels exactly right. AI makes it so much easier to find out if an idea is actually interesting before sinking a ton of time into it.
Also yes, the prototype vs commitment thing is huge. I think that’s where a lot of us get tripped up. Not every 30% project is an unfinished failure. Sometimes it did exactly what it needed to do and proved whether the idea was worth continuing or not.
“Explore freely, commit selectively” is a really good line.
The "this is almost what I want, except..." one got me 😅
I'm literally doing this right now. I'm a week away from launching a proxy service and somehow shipped two side tools on the way, an MCP server and a bandwidth meter, because each one was "just a quick thing." They actually turned out useful, but the main product is still the part that isn't finished lol.
With 84 repos, how do you decide which ones get to the finish line?
Honestly, I don’t have a very scientific system for that lol. Usually a project makes it to the finish line if I find it useful enough that I keep using and maintaining it myself, or if other people start using it and that gives me a reason to keep improving it.
A lot of the others are basically experiments. If I learned what I wanted to learn or proved the idea worked, I’m okay with letting them sit there. I think the harder part is recognizing when something is actually worth committing to versus when it was just a fun detour.
Also, your “just a quick thing” turning into two shipped side tools while the main product waits is painfully relatable 😂
Lowering activation energy shifts the option value of starting versus finishing. When scaffolding an unfamiliar stack requires effort, that initial friction acts as a hurdle rate, filtering out marginal curiosities before they demand sustained focus.
When an agent handles the initial boilerplate, spinning up an 85th repo becomes an essentially free call option with immediate novelty and zero entry fee. Yet maintenance and finishing costs remain strictly convex. Every abandoned prototype adds ambient cognitive drag, and the frictionless thrill of early-stage generation continually outbids the unglamorous grind needed to close out a release.
This is a really good way to frame it. Starting really does feel almost too cheap now, while finishing still costs the same amount of focus and follow-through it always did. And yeah, the cognitive drag of abandoned prototypes is very real. They may be small, but they still hang around in the back of your brain. Really appreciate this, you explained the tension better than I did in some parts honestly.
The cost I'd watch isn't starting, it's coming back. With code you typed yourself, the reasons behind it are still in your head when you return; with something an agent scaffolded in ten minutes there's very little memory of why anything is the way it is, so resuming project #37 means re-reading it like someone else's code. That might be why the original project sits in the other tab: switching away got free, switching back quietly got more expensive. A two-line note at the moment you leave, where you stopped and the very next step, is the cheapest fix for that I know of. Out of the 84, how many could you pick up today without reading the code first?
This is a really good point. I focused so much on how cheap it is to start now that I didn’t really think about the cost of coming back.
And yeah, with something I built slowly myself, I usually remember why things are structured the way they are. With a project that came together really fast with an agent, sometimes I come back a week later and have to reconstruct my own reasoning from the code.
I’ve gotten better about leaving notes and keeping docs around for that exact reason, but the two-line “where I stopped + what’s next” idea is probably the highest-value version of it.
Out of the 84, I could definitely pick up some immediately, but there are absolutely others where I’d need to read through things first and remind myself what I was doing. 😅