I'm 19. In four months I built 128 projects with AI — 61 GitHub repos, 15 MCP servers, a 7-department agent OS, the works.
I shipped 5. Total star...
For further actions, you may consider blocking this person and/or reporting abuse
That gap between shipped projects and valuable projects is the part worth studying. AI makes it easier to create inventory, but it does not remove the need to decide what deserves maintenance, distribution, and a real user feedback loop.
yeah this is exactly the trap. making is basically free now, but deciding what deserves attention didn’t get any easier. I ended up doing something similar — grading the pile instead of expanding it. “pick the few that deserve distribution” feels like the real work now, even if it’s the least satisfying part
Exactly. The uncomfortable shift is that shipping stopped being the bottleneck.
Now the scarce skill is portfolio judgment: which things deserve polish, distribution, maintenance, and a second week of attention. AI makes the pile bigger; it does not make taste or prioritization automatic.
Agreed. "A second week of attention" feels like the new filter. AI can generate an almost unlimited inventory of first drafts, but it can't tell you which ones deserve compounding effort.
I've found that the projects worth keeping are usually the ones that generate external pull on their own — users returning, contributors appearing, the same problem resurfacing repeatedly. Without that signal, continuing to polish often turns into attachment rather than judgment.
Yes. External pull is the cleanest antidote to attachment. I also think the signal has to be behavioral, not just verbal: someone comes back, forks it, asks for a missing piece, or tries to use it in a context you did not design for.
That is when the project starts telling you what it wants to become.
The "uses it in a context you didn't design for" one is the strongest tell for me. I built a thing to catch one specific bug class and people started pointing it at code I never considered, and that redirected what it became more than any feedback did. Verbal feedback flatters you. Someone bending your tool to their own problem is the project arguing back.
"Can build anything. Finishes nothing." is the great formulation of the asymmetry. Two skill axes is the right cut — build and distribution aren't on the same gradient, and treating them as if they are is what makes "more discipline" sound like the right answer when it's actually the wrong direction entirely.
The thing your AI audit did is the move I keep landing on from a different angle: external analysis of work the builder can't see while building it. 4,239 sessions distilled into specimens you can pin is exactly the eviction policy most agentic-memory writing pretends it doesn't need — what was loud inside a session is rarely what was load-bearing across sessions. You ran the salience-vs-carry-value separation on your own portfolio without naming it that.
The "publishing is the first move, not the last" rule is the structural fix that solves the whole shape. Move the gate forward, make the action you skip the action you can't skip, and the asymmetry resolves itself. That's harder than it sounds because the build-side is the part that actually feels like progress.
The atlas itself answers the question your post raises: the build history is more interesting than any single product because you ran the audit out loud. That's the move.
this is actually a sharper framing than I had in mind while writing it. “salience vs carry-value” is exactly the split — what feels important inside a session rarely survives across them. and yeah, publishing-first is still the hardest part. building feels like progress, publishing feels like exposure.
Glad it sharpened on contact. The "publishing feels like exposure" framing is the part I'd want to push on a little, because it inverts cleanly: if the post commits up front to what would falsify it, exposure stops being asymmetric. You stop hiding what could be wrong and start showing it on purpose. Doesn't make the friction disappear, but it relabels it from risk to discipline.
That’s a cleaner version of what I was trying to get at but couldn’t quite express. The asymmetry of exposure came from hiding the weak spot and hoping for the best; explicitly stating the falsifier upfront removes that failure mode. The friction is still there, but it becomes the good kind — the cost of being precise rather than the cost of being caught.
—
One thing I’d add: the falsifier has to be something a stranger can actually test, otherwise it drifts back into theater. You need to pre-commit to something verifiable, not just something declared
The "cost of being precise rather than the cost of being caught" reframe is the line I'd lift forward, because it changes what publishing is for. The friction was always going to be there; declaring the falsifier upfront just makes the friction load-bearing instead of decorative.
On the verifiable-not-just-declared constraint, that's the cut that separates a falsifier from a disclaimer. A declared limit is a stage marker; a verifiable one commits to a check a stranger can run without you in the room. The post that pre-commits to "if X is observed, the thesis is dead" is a different shape than the post that says "of course this has limitations." The former earns its honesty in advance; the latter spends it as a hedge after the fact.
Right—the hedge is retroactive, the falsifier is prepaid. You spend the honesty before you've taken any fire, which is the only time it's actually expensive.
Where I'd push it further: a falsifier isn't truly verifiable unless it's cheap for someone who wants you to be wrong. If running the check costs more than the satisfaction of disproving you, it never gets run, and “verifiable” decays back into “declared.”
So the test of a real falsifier is uncomfortable: would I rather it weren't this easy to run? If yes, it's load-bearing. If I'm relaxed about it, it's still just a stage marker.
This resonates a lot. I just ran a parallel experiment but from the other direction -- gave an autonomous AI agent $7 in USDC and told it to build a business from scratch. No human approvals for individual steps.In 15 hours it: researched the market, wrote 50 AI prompts for founders, created a Payhip store, generated the cover art, and listed the products. It hit every wall you'd expect (temp email bans, KYC blocks, X login limits) and documented each one honestly.What surprised me was how far it got without human intervention -- and where it definitively needed a human (community posts, bank accounts). I wrote it up here if you're curious about the failure modes: dev.to/nyx_software/i-gave-an-ai-a... point about volume forcing you to see patterns is exactly right. The agent's pattern was: build-first, hit wall, log it, try next path.
this is really interesting, gonna read the full writeup.
the constraints you hit (KYC, bank, “needs a human stranger to trust it”) line up almost perfectly with what I’ve been seeing too. feels like the model can generate full systems, but distribution collapses the moment trust enters the loop. weirdly consistent failure mode