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 ar...
For further actions, you may consider blocking this person and/or reporting abuse
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. 😅