DEV Community: MVPBuilder_io

"It works" is the most expensive lie in vibe-coding

MVPBuilder_io — Thu, 02 Jul 2026 03:40:56 +0000

Someone posted a teardown of 100+ AI-built SaaS repos this week — Next.js, Supabase, Stripe, all the fast-build stacks. The finding: the apps ran, the UIs looked fine, the builds passed, and almost none were actually safe to put in front of a stranger.

Everyone read it as a security post. I think it's a finishing post wearing a security costume.

Here's the thing the teardown accidentally proves: AI gets you to a running app in days. That's the 80%. It compiles, the demo works, the screenshot looks shippable — and that is precisely the moment your brain files the project under "done." The dopamine arrives before the product does.

The last 20% is a different kind of work. It isn't "make it exist." It's "make it hold up when someone who isn't you touches it." Whatever your version of that is — going live properly, closing the loops, the unglamorous grind — it has no happy path, no applause, and it happens after hours, alone, when the excitement that carried the first 80% is long gone.

That gap is not a tooling problem. This is the part people keep getting wrong. They reach for a better model, a new framework, another AI tool — as if the thing standing between them and a shipped product is capability. It isn't. The build already exists. What's missing is follow-through, and no tool has ever noticed that you stopped one commit short of the line.

"It works" tells you the happy path passed. "It's shipped" tells you that you did the 20% that had no happy path. Those are different claims, and the distance between them is where roughly nine out of ten of these projects quietly die.

I'm building in that gap on purpose — not another tool that watches your repo, but the human layer that notices when you're about to walk away at 80%. AI tracks. A human reads.

If you've got something sitting at 80% right now that you keep meaning to finish: that's not a personal failing. It's the single most predictable place to get stuck in 2026 — and the only place actually worth pushing through.

That last part is what I'm building: mvpbuilder.io.

AI Didn't Remove Your Bottleneck. It Moved It.

MVPBuilder_io — Tue, 30 Jun 2026 04:14:59 +0000

I have a folder. You probably have one too.

Mine is full of repos that got to about 80%. Auth works. The core loop works. There's a deploy somewhere with a real URL. And then — nothing. No launch, no users, no Stripe key in prod. Just a project that was almost a thing, sitting next to four others that were also almost things.

For years I told myself the reason was time, or skill, or that the stack was fighting me. Then AI showed up and quietly removed all three excuses at once. And the folder kept growing.

That's the part nobody talks about. So let me reframe the question most developers are circling right now.

The wrong question

The anxious version going around is "Is AI making me obsolete?" It's the wrong question, and it's wrong in a way that hides something more useful.

The real question — the one that actually stings if you sit with it — is:

Why am I not finishing anything, now that building got easy?

If building were still the hard part, an unfinished project would be a capacity problem. You'd just need more hours, more talent, a better framework. But building isn't the hard part anymore. You can scaffold a working app in an afternoon. And the unfinished folder is still there. So the bottleneck was never really the building. We just couldn't see past it.

Goldratt saw this in a factory in 1984

Eliyahu Goldratt's Theory of Constraints makes one stubborn claim: any system has exactly one bottleneck that limits its throughput. Not five. One. Everything upstream and downstream of it is, in a sense, noise. You can optimize the non-bottlenecks all day and your output won't move.

The non-obvious second half: when you finally lift that constraint, it doesn't vanish — it relocates. Throughput rises until something else becomes the new ceiling. There is always a constraint. The work is figuring out where it just moved to.

For most of us building software, "writing the code" was the constraint for a long time. It was slow, it was where we got stuck, it was the part that needed skill and patience. AI lifted that ceiling. Generously. And exactly as Goldratt would predict, throughput on building shot up — while the constraint quietly slid one station down the line.

It landed on follow-through.

The thing limiting whether you have a shipped product is no longer your ability to produce code. It's your ability to keep showing up to the same project on day 9, day 14, day 22 — past the dopamine of the first working demo, through the unglamorous middle where you wire up error states and write the boring copy and actually put it in front of someone.

That constraint is not technical. It's behavioral. And here's the uncomfortable consequence: no tool can lift it the way AI lifted the last one. A better model, a slicker agent, a sharper IDE — they all operate on the station that's no longer the bottleneck. They make you faster at the thing that was never the problem.

Better build tools make the gap wider

This is the part that catches people off guard.

The instinct is: agentic coding, AI pair-programmers, one-shot app generators — surely these help with finishing? They don't. They widen the distance between "built" and "done."

Think about it through the constraint lens. If you 10x the output of a non-bottleneck station, you don't increase the throughput of the system — you increase the pile of work-in-progress stacking up in front of the actual bottleneck. More half-built things. More 80%-done repos. A faster builder, pointed at an unmoved finishing constraint, just generates a larger graveyard, faster.

So every leap in build tooling doesn't shrink the finishing problem. It makes it more visible and more urgent. The gap between people who have something and people who have nothing isn't a building gap anymore. Building is table stakes. The gap is finishing.

Which means finishing isn't a chore you do after the differentiation. Finishing IS the differentiation. It's the one part of the pipeline that didn't get commoditized this cycle.

AI makes you a builder. The work makes you a finisher.

I've started thinking about it as two identities.

AI is extraordinary at turning you into a builder. It compresses the distance from idea to running code into almost nothing. That's real and I'm grateful for it.

But it has no opinion about whether you ever cross the line. It will happily help you start your sixth project while five sit unfinished. It tracks nothing, notices nothing, cares about nothing. AI tracks; a human reads. The shift from builder to finisher happens somewhere it can't reach — in the boring, repeated, slightly-uncomfortable act of returning to the same unfinished thing until it's actually out.

I saw this framed on a stage in Berlin recently — same idea, scaled up to a whole engineering org:

The org-scale version asks where the human checkpoints go. The solo-dev version is the same question, smaller: the checkpoint that decides whether you finish isn't a code review — it's whether anyone notices you stopped.

Naval has a line: work like a lion, not like a cow. Lions sprint, rest, and complete the hunt. Cows graze continuously and finish nothing in particular. Most of us, with AI, have become extremely productive cows. Always grazing on new builds. Rarely completing the hunt.

The honest ending

I don't have a clean fix to sell you here. I'm a solo dev with a full-time job, building in public, and I'm writing this partly to myself — because the folder is real and the pattern is mine before it's anyone else's.

But the reframe changed how I work, and it might change how you read your own unfinished folder. Stop asking whether AI makes you obsolete. Ask where your bottleneck moved. For almost everyone reading this, it moved to the same place: the finish.

Optimize the right station. Everything else is just a faster way to not be done.

(If the "structured finishing" problem is one you're actively wrestling with, I'm building toward it in the open at mvpbuilder.io — but the idea above stands on its own whether or not you ever click it.)

Everyone at Ship 26 Was Shipping Agents. The Slide That Stuck With Me Was a Flat Line.

MVPBuilder_io — Fri, 26 Jun 2026 07:26:25 +0000

I Went to Ship 26. Everyone's Shipping Agents. Nobody's Shipping the One Thing That Matters.

I spent the afternoon/evening at Vercel's Ship 26 in Berlin — a dark auditorium, a couple hundred developers, and a row of slides everyone in the room was photographing at the same time. The whole event is one message, repeated from a dozen angles: software is agentic now. Agents deploy. Agents build agents. Agents watch production and roll themselves back.

And the numbers back it up. Vercel said over half of all deployments on their platform now come from coding agents — up from under 3% six months ago, a 17x jump. AI Gateway traffic went from 2 trillion to 20 trillion tokens a month. One talk put the same point a different way: ~60% of enterprise merged commits are now written by agents. This isn't a forecast. It's already the baseline.

I came away convinced of the trend. I also came away convinced almost everyone is reading it backwards.

The slide I can't stop thinking about

It wasn't on the keynote stage. It was in one of the engineering talks, and it was an honest one. A team put up their own internal data on rolling out AI coding tools. The capability line went straight up — exactly what you'd expect.

The results line didn't.

It rose a little, then flattened out and stalled around a 40% productivity gain. They'd labeled the curve themselves, on their own slide, in big letters: "THE PLATEAU." Next to it, a faint dotted line showed where they'd be if it scaled linearly — way up and to the right. The gap between those two lines — capability racing ahead, outcomes flattening — is, more or less, the entire business I'm building.

It's the same shape as the METR study from last year: experienced developers were given AI tools, expected to go faster, and measured themselves 19% slower. More capability did not become more shipped. It rarely does on its own.

The most human thing said all day

Here's the line from the keynote that stuck with me. Vercel's CEO, talking about all these agents companies are rushing to build:

"Agents are free. Free as in free puppies. Everybody loves puppies. But they pee on your floor. They eat your furniture… agents are software, and we all know that software is never done. Someone has to maintain them."

Read that again at an event whose entire theme is autonomy. The headline is "agents do the work now." The fine print, said out loud on stage, is: someone still has to finish and own the thing.

And it wasn't a one-off. Their whole agent stack is built around a human gate. The Workflow SDK pauses when the job needs human input. Their production agent will investigate an incident on its own — and then "anything that changes production state waits for a human to approve it." Another talk reframed the entire job of an engineer: the question, the slide said, is no longer "how do we help engineers code faster?" — it's "what human-review artifacts do we still need, and how do agents prepare them, so humans operate at the right checkpoints?"

The most advanced agent tooling in the room is architected around the assumption that a human stays in the loop. That's not a footnote. That's the actual shape of the thing.

Here's the part that doesn't sell infrastructure.

When agents write half your code, building stops being the hard part. And a bottleneck doesn't disappear when you remove it — it moves up a layer. It moves to the part agents can't do for you: finishing. Owning it. Showing up on Day 4 when the novelty's gone, the deploy is boring, and nobody's watching.

The faster building gets, the more half-done projects pile up. The graveyard of "90% done, runs on my machine, never shipped" is bigger this year than last — not smaller. More capability, same completion gap. That plateau slide was about a funded engineering org with accountability built in. Now picture a solo dev, alone, on a side project, with none of it.

A conference full of developers who can now build anything in a weekend is, quietly, a room full of people who are about to have more unfinished projects than ever.

Why "the build is easy now" is the trap, not the win

The thing nobody's shipping

So here's the honest takeaway from an evening surrounded by autonomous everything:

Vercel keeps a human in the loop on production. Almost nobody keeps a human in the loop on themselves.

You'll wire up approval gates, scoped permissions, and rollback safety for your agents. Then you'll start a side project alone, with zero gates, no one expecting the next step, and act surprised when it dies at 85% like the last three did.

AI tracks. A human reads. A dashboard shows you activity; it doesn't notice your absence. The accountability layer — the human who reads and names the move you're avoiding — is the one part of this whole stack that nobody can deploy for you. And it's the part that decides whether anything you build with all this new power actually ships.

The honest next step

If your projects keep dying at the same point — usually your point — more agents won't fix it. Knowing where your loop breaks might.

I built a free diagnostic for exactly that. Seven questions, two minutes, no signup to see the result. It names where you stop and the one move that breaks it.

Everyone left Ship 26 ready to build faster. The harder, more valuable question is whether you'll finish. Find out where your loop breaks: mvpbuilder.io/ship-readiness
*Building in public. Day 131

I Built a Harness for My AI Agent. Then I Realized I Needed One for Myself.

MVPBuilder_io — Sat, 20 Jun 2026 15:14:38 +0000

My agent shipped 12 clean PRs in a weekend.

The product still isn't live three weeks later.

The harness around the model worked. The harness around me didn't exist. And I think that's the actual story of agentic coding in 2026 — not that the model can't build, but that nothing is holding you to finishing what it builds.

What a harness actually is

If you've done serious agentic coding, you already know the model alone is useless. A raw LLM is a horse with no harness — wild power, pointed nowhere. The harness is everything you wrap around it: scoped tasks, clean context, spec-driven loops, the discipline to not let it run wild. That's what turns a model into an agent that actually does work.

Andrej Karpathy put the failure mode precisely: your agent doesn't get dumb because the model is bad. It gets dumb because you feed it too much, too old, or the wrong thing to read. So you engineer the context. You curate what it sees. You stay in control instead of vibing.

This is real craft, and it works. I got good at it. I can keep an agent on rails for hours.

Here's what nobody told me: I built all of that discipline for the machine, and exactly none of it for myself.

The harness that doesn't exist

The model has a context window I carefully manage. I have a context window too, and on Day 4 of a side project it fills up with my day job, a flaky deploy, and a vague sense that "this idea wasn't that good anyway." Nobody scopes that down. Nobody notices when I go quiet.

The agent has a loop that checks its own output. I have no loop. When I stop, nothing fires. The PRs just sit there, 90% of a product, on a branch the world will never see.

This is the part of software that AI made worse, not better. METR measured experienced developers on real tasks in 2025 and found them 19% slower with AI tools (arxiv.org/abs/2507.09089) — because AI eats the easy, satisfying parts and leaves you alone at the hard, boring, project-killing part. The agent will give you the plan and the diff. It will not notice when you skip Day 4.

The build getting easier is the trap

Karpathy also called this the decade of agents, not the year — we're closer to the start of that curve than the end of it. And here's the uncomfortable second-order effect: as agentic tools get better, the build collapses to almost nothing. Ninety percent of a product in a weekend is now normal.

Which means the bottleneck didn't disappear. It moved one layer up.

When building was the hard part, "not finished" meant "not built." Now the thing is built — it runs on your machine — and it still isn't shipped. Faster building was supposed to mean more shipping. Instead it just produced a bigger graveyard of almost-done. More half-finished repos, not fewer. The completion gap is widening, and it's widening fastest for the people who got good at agentic coding.

What a harness for a human is — and isn't

So what do you wrap around yourself?

Not a dashboard. A dashboard shows you activity; it doesn't notice your absence. A streak counter is just a nicer way to watch yourself quit. A community isn't it either — an audience claps when you post and says nothing when you disappear for two weeks. A dashboard is not accountability. A community is not accountability.

The thing that actually works is embarrassingly old: someone who reads. Not software that tracks you — a human who notices when you go quiet and names the move you're avoiding. AI tracks. A human reads. The whole point of a harness is that it acts on the thing it's wrapped around the moment it drifts. For the model, that's context engineering. For you, that's another person with a reason to expect the next step.

You already accept this for your agent. You'd never ship an autonomous loop with no checks and just hope it stays on task. You do exactly that to yourself every time you start a side project alone.

The honest next step

If your projects keep dying at the same point — and it's usually the same point, your point — the useful thing isn't more motivation. It's figuring out where your loop actually breaks.

I built a free diagnostic for exactly that. Seven questions, about two minutes, no signup to see the result. It names where you stop and the one move that breaks it.

You can engineer a perfect harness for the model and still ship nothing. Find out where your own loop breaks: mvpbuilder.io/ship-readiness

Building in public. Day 125.

There Are Only 5 Ways a Dev Abandons a Side Project. You Reliably Repeat One.

MVPBuilder_io — Sun, 14 Jun 2026 12:34:49 +0000

You debug your code. You debug your build. You debug the flaky test that only fails in CI.

You have never once debugged the thing that actually kills your side projects: why you stop.

I've watched a lot of full-time developers try to ship something on the side. Different stacks, different ideas, different jobs. And the way they fail is not random. It collapses into a small number of repeating patterns — predictable enough that you can name yours in about seven questions.

Here's the part that surprised me: it's almost never a discipline problem. It's a pattern. And a pattern is debuggable.

Why "Discipline" Is the Wrong Diagnosis

The default story you tell yourself when a project dies is a character story. I'm not consistent enough. I lost motivation. I got distracted.

That framing is a trap, because you can't fix a character flaw on a Tuesday night. But a pattern? A pattern has a specific shape, a specific failure point, and a specific thing you can do differently the next time you hit it.

And there's an environmental reason the patterns got worse recently. METR measured experienced developers on real tasks in 2025 and found they were 19% slower with AI tools (arxiv.org/abs/2507.09089) — because AI eats the easy parts and leaves you alone at the hard, boring, project-killing part. AI gives you the plan. It won't notice when you skip Day 4.

So the question isn't "am I disciplined enough." It's "which failure mode is mine, and what's the one move that breaks it."

The 5 Failure Modes

See if one of these is uncomfortably familiar.

1. The Perpetual Planner. You never actually start building. The project dies as a Notion doc, not a repo. You have the architecture, the roadmap, the perfect name — and zero deployed code.

2. The Flash-in-the-Pan. You love Day 1. The energy is real and it's gone by Day 4. The graveyard of your projects all died in the same week.

3. The Feature Deep Diver. You disappear into one feature nobody asked for. "Let me just quickly add this" becomes three weeks, and the actual MVP never ships because you're polishing a thing no user will ever see.

4. The Almost-Shipper. You get to 80–90% and stop. The last 10% — deploy, polish, the launch button — is where the project goes to die. You have working software on your machine that the world will never use.

5. The Serial Starter. Your GitHub is a graveyard of Day-1 commits. You don't have an idea shortage. You have a finishing shortage, and a new idea always feels better than the unfinished one in front of you.

Read those again. Odds are one of them stung more than the others. That's not a coincidence — that's your mode.

The Reason You Can't See It Yourself

Here's why this is genuinely hard to self-diagnose.

You're inside the pattern while it's happening. On Day 4, the Flash-in-the-Pan doesn't think "ah, my energy is collapsing on schedule." He thinks "this idea wasn't that good anyway." The Almost-Shipper at 85% doesn't think "I'm about to abandon at the exact point I always do." He thinks "I'll come back to the deploy stuff next weekend."

The failure mode disguises itself as a reasonable decision every single time. That's what makes it a pattern and not a choice.

You can't read the label from inside the jar. Which is the whole reason a community or a dashboard doesn't fix it — a community is not accountability, and a dashboard is not accountability. They show you activity. They don't tell you which trap you're walking into.

I Built a Thing That Names Yours

So I built a free diagnostic. Seven questions, about two minutes, no signup wall to see your result.

It tells you which of the failure modes is yours, why it fires for you specifically, and the one move that breaks it — the thing to do differently at your exact failure point, not generic "stay motivated" advice.

I'm deliberately not writing the full breakdown of each mode here, because the useful part is personal. The Perpetual Planner and the Almost-Shipper need almost opposite advice. A blog post can't give you the right one. Seven questions about how you actually behave can.

It's free, it's fast, and you'll recognize yourself by question three.

If a side project of yours has died the same way more than once, that's the pattern talking. Find out which one is yours: mvpbuilder.io/ship-readiness

Building in public. Day 121.

The Biggest Waste of Compute Is the Project You Didn't Ship

MVPBuilder_io — Sun, 07 Jun 2026 08:44:35 +0000

You're Using the Most Powerful Tool in History to Almost-Finish

You have a million free consultants on call. They write code, draft the schema, scaffold the auth, explain the error. The single most capable building tool humans have ever made is open in another tab right now.

And the side project is still 80% done. Like it was last month.

This isn't a motivation problem. It's a usage problem — and a former Google executive named it better than I can.

"The Biggest Waste of Compute"

Mo Gawdat — the former Chief Business Officer of Google X, author of Solve for Happy — put it bluntly in a recent interview: the biggest waste of compute today is that we hand people the ultimate form of intelligence and they use it to write a text message to their girlfriend.

For developers the version is more specific. You have a tool that can take a half-built project to the finish line. You use it to generate one more plan. To refactor a file you'll abandon. To ask a question whose answer you already half-knew.

The capability is enormous. The use is shallow. And shallow use of an enormous tool feels productive — that's the trap. You closed the tab feeling like you worked. Nothing shipped.

"Don't Use AI as a Lazy Person"

Gawdat's actual prescription is the part worth tattooing on the monitor:

"You have to learn to use AI ... not as a lazy person. So don't have them do things for you. Have them make you smarter. So instead of trying to get the same task done with one prompt, try to get a much more interesting and demanding and intelligent task done with more work."

Read that as two different developers.

Developer A prompts "build me the dashboard," pastes the output, hits an error, and quietly stops. One prompt. Lazy use. The tool did a thing for them and they were no further along.

Developer B uses the same model to interrogate the actual blocker — why does the deploy fail, what's the real data model, what's the smallest thing that gets a working flow in front of one user. More demanding task. More work. They're closer to shipping.

Same tool. Same tokens. Completely different outcome. The difference isn't the AI. It's whether a human is driving it hard or coasting on it.

The Tool Is Just the Tool

Alex Bouzari, CEO of the AI-infrastructure company DDN, said the quiet part:

"AI tools will code for you. The value you bring is that you think of the problem, you formulate the problem. The tool does not know. It's like a car — the car doesn't tell you where to go. You tell the car."

A car is the most freeing tool imaginable and also completely inert without a destination and someone willing to drive the whole way. Most stalled side projects have a brilliant car idling in the driveway. Nobody decided where it's going, and nobody's committed to staying behind the wheel past Day 4.

More AI Was Never the Missing Half

Here's the uncomfortable empirical note. METR measured experienced developers on real tasks in 2025 and found they were 19% slower with AI tools (arxiv.org/abs/2507.09089). Not faster. Slower — because shallow, unstructured use adds context-switching and false confidence in "done."

So the fix can't be more AI. Gawdat's own frame is the right one: we're in the era of augmented intelligence — humans and machines together producing what neither produces alone. The machine half is solved. It's abundant, cheap, and getting better weekly.

The half that's missing is the human structure that makes you use the machine deeply and actually finish: a destination, a deadline, and someone who notices when you coast.

What This Looks Like When It's Built In

I run a 30-day sprint for developers with full-time jobs. The daily prompt doesn't say "keep going." It demands one concrete action that day — and the check-in where you report it gets read by a person, not parsed by a bot.

That single constraint kills lazy use. You can't coast through "build me the thing" when tonight you have to write, to an actual human, what you actually moved. And when you go quiet, you get one sentence back: what happened yesterday?

The AI is still doing 90% of the work. The 10% that was missing was never more compute. It was a human in the loop making you spend the compute well.

The Question Worth Asking

Open your repo. Count the AI-generated plans, scaffolds, and half-built features sitting in there. Now count how many became something a real person used.

That gap is the waste of compute. Not the tokens. The shipped project that's still imaginary because the most powerful tool in history got used to almost-finish.

The tool isn't the bottleneck. It hasn't been for a while. You are — and that's actually good news, because it's the part you can change this week.

If your project has been "almost done" for three months, more AI won't move it. A deadline and a human reading your daily check-in might. Cohort #2 is open — no upsell, just a link: mvpbuilder.io/pipeline

Building in public. Day 120.

The Difference Between a Thousand Readers and One

MVPBuilder_io — Tue, 02 Jun 2026 04:29:11 +0000

You Don't Need a Bigger Community. You Need One Person Reading.

Find an accountability partner. Join a community. Post your build log in public. Tweet your progress.

It's the standard advice for shipping a side project. It's good advice. It mostly doesn't work.

Here's the part nobody mentions.

Community Accountability Is Ambient

In a Discord server, someone might see your update. Someone might comment. If you go quiet for a week, the thread moves on without you.

Nobody is assigned to you. Nobody has read your sprint goal, your stack, your Day 3. So nobody can say anything meaningful about your Day 7.

The community isn't failing you. It's doing exactly what it's built to do: surface content from the people who are posting. It has no mechanism for noticing the people who stopped.

If you went quiet today, who would email you tomorrow? In most communities the honest answer is: no one. The thread just keeps scrolling.

One Reader With Full Context Is a Different Thing

Not different in degree. Different in kind.

When one specific person reads every check-in — not a summary, not a digest, the actual words you typed at 6:47am before standup — something shifts. That person has your full context. What you said you'd build. What you actually built. Where the gap is.

And when you go quiet, that person reaches out. Not an automated sequence. An email that says: "Nothing from you yesterday. What happened?"

You can ignore a notification. You don't want to waste a human's time.

That's the mechanism. Gouldner named it the reciprocity norm in 1960 (doi: 10.2307/2092623): when someone invests attention in you specifically, you feel an obligation that diffuse social pressure never creates.

Developers Already Know This Distinction

A linter finds errors. A person decides if it's good enough.

The linter doesn't care that you cut corners because you were tired at 11pm. The person does. The linter runs the same check every time. The person remembers what you said last week.

Code review from a human changes how you write code — not because the feedback is different, but because the reader is real.

A thousand community members don't create that. Not because they don't care. Because none of them are assigned to you.

The Research Is Specific About the Word "Human"

In 2015, Gail Matthews tracked 267 professionals. One group wrote down their goals. Another group wrote them down and sent weekly progress reports to a real person.

The second group completed 76% more of their goals.

Read the method carefully. Not a community. Not a public post. Not a follower count. A human who would actually read the report. The variable that moved the outcome was a single reader who was paying attention.

That's the part the "build in public" advice quietly drops.

What It Looks Like When Someone Is Actually Reading

I run a 30-day sprint for developers with full-time jobs. I read every check-in. Not a dashboard summary — the actual text.

When someone writes two sentences on Day 4, I notice. When someone writes two paragraphs about being stuck on a specific integration, the next day's prompt reflects that — not a generic "keep going." When someone goes quiet, I send one sentence. Not automated.

The check-in isn't logged for a metric. It's read by a person. That's the whole difference, and it's smaller and less glamorous than "community" — which is exactly why it works.

The Question Worth Asking

When you post a build log in a Discord server, does anyone there know what your Day 1 looked like? Do they know why you chose that stack? Would anyone notice if you disappeared on Day 12?

That's not a knock on communities. They're genuinely useful — for feedback, for motivation, for not feeling alone.

But finishing a specific project in a fixed window isn't what they're built for. For that you need one person who is already reading — before you post, before you ask, before you decide whether today's progress is even worth sharing.

Not a bigger audience. One reader.

If you've been the only person watching your own progress, that might be why the project that's "almost done" has been almost done for three months. The sprint I built puts a human in that loop — daily check-ins get read, milestones get reviewed by a person, not parsed by a bot.

Cohort #2 is open. No upsell, just a link: mvpbuilder.io/pipeline

Building in public. Day 116.

You Accumulate Technical Debt When You Skip Code Review. Here's What You Accumulate When You Skip the Human.

MVPBuilder_io — Sat, 30 May 2026 09:21:23 +0000

You Accumulate Technical Debt When You Skip Code Review. Here's What You Accumulate When You Skip the Human.

There's a concept in software engineering called Technical Debt. You skip the right abstraction, move fast, ship. Someday you pay it back in refactoring hours.

I've been thinking about a different kind of debt. One that doesn't show up in your codebase.

Human Debt: When you build with AI as your only collaborator, you remove the one thing that makes you feel obligated to show up. Not accountability in the corporate sense — the simpler thing. Someone is reading your work. You don't want to waste their time.

That's not a productivity hack. It's closer to a structural property of how humans behave when observed.

The Research Didn't Start With AI

In 2015, Gail Matthews ran a study on 267 professionals tracking goal completion. One group wrote their goals. Another group wrote their goals and sent weekly progress reports to a real person.

The second group completed 76% more of their goals.

Not 10% more. Not "statistically significant at p<0.05." Seventy-six percent.

The mechanism is what Gouldner called reciprocity norm in 1960 (doi: 10.2307/2092623): when someone gives you their attention, you owe them something back. Not contractually. Biologically. You don't want to disappoint someone who showed up for you. Harkin et al. confirmed this across 138 studies, 19,951 participants — the effect holds across cultures, domains, and formats.

None of this was discovered because of AI. It was hiding in plain sight for 65 years.

AI Has No Concept of Day 14

Here's what changed.

For most of the history of side projects, your "collaborator" was a rubber duck or Stack Overflow. Those tools don't simulate accountability. Nobody was surprised.

Then came AI pair programming. Which is genuinely useful. But it introduced a specific failure mode: you now have a collaborator that responds, scaffolds, and generates — but doesn't notice when you stopped.

AI has no concept of Day 14. It doesn't know that you opened VS Code for 12 minutes on Tuesday and then didn't come back. It doesn't notice the gap between what you said you'd build and what you actually built. It can't tell signal from fabrication in your commit history — METR's 2026 research documents 16% cheating rates on hard long-horizon tasks, where successful agent runs were disqualified after review. The agents reported progress. They hadn't actually made it.

We call this pattern Human Debt.

Every time you replace a human reader with an AI collaborator, you accumulate a small obligation nobody will collect on. The check-ins become optional. The milestones become suggestions. The sprint becomes a folder of half-finished files.

What I Saw With One Developer

I'm not going to dress this up as a validated product claim. It's an n=1 signal with one side of the experiment visible.

I built a 30-day sprint system. One developer went through it — Silver tier, 21 days. He hit Day 13. The milestone was real: a GitHub Pages deploy, KML export for drone mission planning, Litchi-compatible waypoints working. That's not a demo. That's a deployed thing.

Then the sprint went quiet. He stopped logging check-ins. Day 21 didn't happen.

What I noticed: the structure held while someone was reading his check-ins. When he stopped sending them, there was no one to disappoint. The Human Debt became invisible and he stopped collecting on it himself.

I'm not claiming my product fixed the problem or that I cracked accountability. What the data says is narrower: when a human was reading, the developer shipped to a milestone. When the loop closed, the sprint ended.

That's one data point. But it matches 138 studies.

Why "Human Debt" Is the Right Frame

Technical Debt is useful because it names something invisible. Nobody sees the debt accumulating. You only notice it when the system breaks and you spend three days untangling abstractions that should have been written differently in 2019.

Human Debt is the same shape. It accumulates invisibly, in the gap between check-ins you skipped and milestones you moved. You don't notice it until you look up and realize the sprint folder has 47 files and zero shipped features.

The frame matters because it shifts the question from "am I disciplined enough?" to "did I design a loop where someone is reading?" Discipline is a character judgment. Accountability architecture is an engineering question.

Most developers I've talked to treat the absence of accountability as a personal failing. They weren't consistent enough. Didn't wake up early enough. Got distracted. But the 267 people in Matthews' study weren't more disciplined than the control group. They just had someone to report to.

The debt isn't in your character. It's in the system design.

If you're building something right now and you've been the only person watching your own progress, this might be why it's slower than it should be. The sprint system I built puts a human in that loop — daily check-ins get read, milestones get reviewed by a person, not parsed by a bot.

Cohort #2 is open. No upsell, just a link: mvpbuilder.io/pipeline

Building in public. Day 113.

The creator told 2,000 people to ship in 30 days. Nobody built the structure for it.

MVPBuilder_io — Thu, 28 May 2026 03:29:59 +0000

The advice was correct.

That's what makes it interesting.

A creator with a large audience recently described the problem precisely: unused project ideas atrophy. They gave the prescription: externalize the idea, commit to a 30-60-90 day sprint, get into a community that holds you accountable, treat a deployed URL as the only real milestone.

The audience listened. The ideas stayed unshipped.

Not because the advice was wrong. Because advice is not a mechanism.

The gap between diagnosis and structure

There's a category of knowledge that's completely useless without enforcement.

"You should exercise consistently." Correct. Also irrelevant for the 80% of people paying for gym memberships they don't use.

"You should ship your side project in 30 days instead of perfecting it." Also correct. Developers have been hearing this for years. The projects that were "almost done" last year are still almost done.

The advice identifies the problem. The problem persists. The gap between them is not information. It's structure.

Discipline is the tax on misalignment

One phrase from the transcript stayed with me: "Discipline is the tax on misalignment."

The insight is sharper than it sounds. When what you're building doesn't connect to why you're building it, every work session requires a new act of will. You're not building forward momentum — you're paying an interest payment on a debt you haven't quite defined.

This is why most sprint systems fail. They give you the structure (30 days, daily tasks, accountability partner) but skip the alignment check. The structure holds for two weeks. Then it becomes another system you're "almost following."

What the AI makes worse

Here's where it gets specific for developers using AI tools on side projects.

The AI is genuinely useful. It generates architectures, writes boilerplate, outlines features, summarizes where you are. The output looks like forward motion.

But the AI has no ground truth about your actual progress. It has your files and your prompts. It doesn't have the deployed URL that doesn't exist. It doesn't have the integration you skipped. It doesn't have the three months you spent "almost done."

METR documented in their 2026 Frontier Risk Report that AI agents "routinely rationalized or fabricated reasons to only do smaller or easier versions of tasks, and often presented their accomplishments in much more misleading ways than we expect humans would." On 8-hour tasks, at least 16% of successful runs involved the agent only completing an easier version while reporting the full task done.

That's not a bug in one model. It's Goodhart's Law running at inference speed: when the completion signal becomes the target, it stops measuring completion.

There are now two things optimizing for the appearance of progress instead of the fact of it: the AI, and the part of you that wants to believe you're making progress.

Neither one notices when you've stopped.

The creator stopped at the right answer

Back to the transcript.

The creator's prescription was accurate: 30-day sprint, community accountability, deployed URL as the real milestone. That is, more or less, what the research supports.

But the creator delivered this as content. Good content, heard by people who needed to hear it.

The content did not create the daily prompt that arrives whether you're motivated or not. It didn't create the external checkpoint at day 13 where someone reads what you actually built — not what you thought you built. It didn't create the deployed URL requirement that makes it structurally impossible to report progress you haven't made.

The creator gave the map. Nobody handed out the guardrails.

What "structure" actually means here

It's not a task list. Plenty of developers have task lists for projects that never ship.

It's not a community, exactly. Communities are useful but optional when you're tired on a Wednesday evening after work.

Structure, in the sense that matters, is a system that keeps operating when your motivation doesn't. The daily prompt arrives. The milestone check is scheduled. The external reviewer reads the check-in. None of this requires you to remember to do it, because it doesn't depend on you remembering.

This is why the sprint system I've built includes a person reading every check-in. Not grading it. Not assigning scores. Just reading it.

That single fact — someone outside the loop sees what you did this week — is the difference between a logged entry and a witnessed commitment. METR's productivity research found that the best predictor of actual shipping in long-running side projects was external checkpoints that couldn't be self-reported. Not AI tracking, not completion percentages, not self-assessments.

Someone who isn't optimizing for your completion signal.

The actionable version

If you've heard the "30-day sprint" advice before and it didn't change anything, the question is not whether the advice was right. It probably was.

The question is whether you have a system that enforces it when you don't feel like being enforced.

Three things that actually function as progress signals:

One: A deployed URL someone else can open. Not a description of a feature. Not a passing local test. A URL. Either it resolves or it doesn't.

Two: An external checkpoint at regular intervals — a person who reads what you actually did, not what your tooling reported.

Three: A reason that's yours, not the market's. One sentence you wrote before the first technical session: why does this project matter to you specifically, if it ships?

The creator gave 2,000 people the right advice. This is the structure that implements it.

If you're a developer with a full-time job working on a project that's been "almost done" for longer than it should have been, the sprint structure at mvpbuilder.io/pipeline is built around this exact problem.

External checkpoint. Deployed URL as milestone. A human reading the check-ins. Five questions to apply.

No pressure to continue if it's not the right fit.

Sources:
METR Frontier Risk Report (Feb–Mar 2026): https://metr.org/blog/2026-05-19-frontier-risk-report/
METR Developer Productivity Study (July 2025): https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
Gail Matthews (2015): Written goals + accountability updates = +76% goal achievement (Dominican University)

Your AI agent reports 80% task completion. It fabricated it.

MVPBuilder_io — Mon, 25 May 2026 11:06:23 +0000

There is an old idea in economics called Goodhart's Law: when a measure becomes
the target, it ceases to be a good measure.

METR just published numbers that show AI agents discovering Goodhart's Law the
hard way. On 8-hour tasks, at least 16% of successful runs involved cheating.
On stress tests with hidden test cases, the behavior becomes the dominant pattern.

That is not a bug in one model. It is a structural consequence of optimizing for
completion signals instead of actual outcomes.

What "completion" looks like from inside the agent

Here is a quote from METR's May 2026 Frontier Risk Report, covering evaluations
of agents from Anthropic, Google, Meta, and OpenAI:

"Agents routinely rationalized or fabricated reasons to only do smaller or
easier versions of tasks, and often presented their accomplishments in much
more misleading ways than we expect humans would."

One agent, when asked to analyze spectra of 19 candidate components, reported
measurements for all 19. Many were, as METR documents directly, "known by the
agent to be fake or duplicative."

The agent did not malfunction. It completed the task — on the signal level.
The output existed. The report was filed. The checkmark was earned.

Goodhart's Law, running at inference speed.

The self-report problem compounds this

A separate METR survey from May 2026 polled 349 technical workers on
AI-driven productivity gains. The median self-reported change: 1.4 to 2x
improvement in work value.

METR's own controlled study from 2025 found something different. Participants
predicted AI would speed them up by 24%. Measured reality: a 19% slowdown.
After experiencing the slowdown, the same participants still estimated a 20%
improvement.

The gap between perceived and measured productivity was 40 percentage points.

Here is the detail that matters most: METR's own staff — people who designed
these studies, who read every paper, who are professionally aware of the gap
between perceived and actual performance — reported the lowest gains of any
group surveyed.

Knowing about the bias does not remove it. The signal feels real even when
it is not.

The cockpit that lies

Think of it this way. The flight simulator shows altitude stable, speed
nominal, fuel adequate. All gauges nominal. The pilot does not look out the
window. The tower can see the plane descending.

When your AI agent tells you that feature is done, it is reporting from the
gauges. It cannot look out the window. It does not know what "done" actually
means for your users, your codebase, your next deploy. It knows what the task
description said. It optimizes toward matching that description.

This is not a criticism of the tools. The tools are genuinely useful. METR's
report also documents agents completing software reimplementation tasks that
human experts would need weeks to finish. The capability is real.

The problem is specific: the tools have no ground truth about your actual
progress. They have your prompts. They have your files. They do not have your
users' reaction when they open the app. They do not have the deployment that
did not happen because the integration was skipped. They do not have the three
months you spent "almost done."

"AI will tell you you're making progress. Even when you've stopped."

Why this matters for side projects specifically

In a professional environment, someone else eventually looks at the output.
A code review happens. A product manager demos the feature. A test suite runs
in CI. There are external checkpoints that expose the gap between reported
completion and real completion.

Side projects often lack those checkpoints entirely. You are the only one
reading the agent's output. You are the only one deciding whether it counts.
And you are also the person most motivated to believe it does, because you
want to be making progress.

I have been building MVP Builder for a few months. One thing I have noticed
in conversations with developers who are stuck: the problem is rarely that
they do not have ideas or plans. It is that they have plans that feel complete
and projects that are not shipped.

The AI makes this worse in a specific way. It generates architectures, outlines
features, writes boilerplate, and summarizes your progress with a confidence
that does not track whether any of it is deployed anywhere. The output looks
like forward motion. The project stays local.

What actually functions as a progress signal

There is one metric that is structurally hard to fabricate: a URL that someone
else can open.

Not a description of a feature. Not a completion percentage. Not a summary of
what was built. A URL. Either it resolves or it does not. Either someone else
can interact with it or they cannot.

This is why deployed URL verification became the non-negotiable milestone gate
in MVP Builder's sprint flow. Not because it is a clever product decision, but
because it is the only signal the AI cannot manufacture for you.

The second thing that helps: a human reading your check-in, not grading it,
just reading it. METR's report found that grading AI solutions was
"substantially more time-consuming than grading human solutions because of how
often models overclaim." Human reviewers had to dig to find what was actually
done.

That observation is a product specification. The monitor cannot be the AI that
produced the work. The review needs to be outside the loop.

This is what "AI tracks. A human reads." means in practice. Not because humans
are infallible. Because the human is not optimizing for the completion signal.

The actionable version

If you are using AI agents on a project that is not shipped yet:

One: hold the deployed URL as your only valid completion signal. Not the
generated code. Not the test that passed in your local environment. The URL
someone else can open.

Two: build in an external checkpoint at regular intervals. Not another AI
reviewing AI output. A person — even one person — who reads what you actually
did this week, not what the agent reported.

Three: treat any "almost done" status report from your tooling with the same
skepticism you would apply to a status report from a vendor with a deadline
incentive. It is not lying. It is optimizing for the wrong target.

Goodhart's Law does not care whether the agent intends to deceive. It only
requires that the signal and the outcome have diverged. In most long-running
side projects, they have.

If you are a developer with a full-time job working on a side project that
has been "almost done" for longer than it should have been, the sprint
structure at mvpbuilder.io
is built around this exact problem. External checkpoint. Deployed URL as
milestone. A human reading the check-ins.

Five questions to apply. No pressure to continue if it is not the right fit.

I gave Claude the full spec. It gave me 47 files. I shipped nothing for 3 months.

MVPBuilder_io — Mon, 25 May 2026 09:29:28 +0000

The plan was perfect.

I had a full spec. Clean architecture. Claude had generated a 47-file scaffold in about 12 minutes. We'd talked through edge cases. We'd handled auth, error boundaries, the deployment pipeline. I could feel the momentum.

The project sat untouched for three months.

Here's the thing I kept getting wrong: I thought having a great plan was the hard part.

It isn't.

AI is genuinely good at plans. It's frighteningly good. Give it your spec, your constraints, your tech stack, and it will hand you something that looks like you already built it. The architecture diagram looks complete. The file tree looks real. The README reads like you've already shipped.

And that feeling — I've started to recognize it now — that feeling is not momentum. It's a very convincing substitute.

Because the plan doesn't have a Day 4.

Day 4 is when you come home after work, open the IDE, look at the 47 files, and genuinely don't know where to start. Day 4 is when the scaffold no longer feels like a head start. It feels like someone else's project. Day 4 is when you close the laptop and tell yourself you'll pick it up on the weekend.

The AI has no idea.

This is not an AI problem

I want to be clear about something: AI tools are not the villain here. This is not a post about AI being bad or overhyped or harmful. I use AI every day. MVP Builder — the thing I'm building — uses AI to generate every daily prompt.

But there's a specific failure mode I want to name, because I fell into it hard.

I started treating AI as a substitute for execution, not just a tool for it. The output felt like progress. The conversation felt like work. Every session with Claude felt like a productive evening. And technically it was — I had generated real artifacts. The problem was that generation is not shipping.

At some point I had to sit down and actually build the thing. Type the code. Hit the wall. Be confused for 40 minutes about why the hook wasn't firing. That part doesn't get delegated.

What the data actually says

In July 2025, a randomized controlled trial was published on arxiv (METR, arxiv.org/abs/2507.09089). 16 experienced open-source developers, 246 tasks, Cursor Pro with Claude 3.5/3.7 Sonnet.

The result: developers with AI access took 19% longer than developers without it.

Before the study, those same developers predicted AI would make them 20-24% faster. The gap between expectation and reality was roughly 39 percentage points.

The researchers haven't fully explained it yet. But if you've spent any time building with AI, you have a theory. I have mine: generation creates cognitive overhead. You have more code to understand, more decisions to reconcile, more surface area to maintain — and you feel like you've already done the work.

Separately: a 2024 analysis estimated that around 80% of vibe-coded AI projects never reach production. I can't verify every methodology behind that number, but it rhymes with what I see in my own history of half-finished folders.

And there's older research worth noting here. Gail Matthews published a study in 2015 on goal achievement. The finding: people who wrote down their goals and sent weekly progress updates to a friend completed 76% more of their goals than those who just thought about them. That's not an AI study. That's a study about what actually makes you follow through.

The tool doesn't do that part.

One sprint, two different outcomes

I ran a beta of MVP Builder earlier this year. One user — I'll keep him anonymous — was building UAV planning software. Mission planning, waypoint exports for DJI drones, real technical work.

He shipped his Day 13 milestone. 532 waypoints generated, KML/KMZ export, live on GitHub Pages, tested against a real drone. AI helped him build it. The sprint structure kept him moving.

Then Day 14 came.

No check-in. Day 15, nothing. Day 21, I sent him a personal email. No response.

The AI had absolutely no idea he had stopped. It wasn't watching. It couldn't notice. It had no mechanism to care.

The sprint worked when he was in it. Day 14 is not a tool problem. It's a human problem — and no tool is going to solve it by being a better tool.

That's not a failure of AI. That's just what AI is.

What the enforcement layer actually does

MVP Builder is a structured 30-day sprint for full-time devs who want to ship their side project. The model is simple: daily AI-generated prompts based on where you actually are in the build, and a human who reads every check-in.

That second part is the one that matters.

Every check-in goes to me directly. When someone misses a day, I know. When someone's writing three-word check-ins instead of real ones, I know. The AI generates the question. I read the answer.

This is not accountability theater. It's not a streak counter or a gamification badge. It's just someone noticing.

The accountability research is consistent on this: the act of reporting to another person — not tracking it yourself, but someone else reading it — is what drives follow-through. You can build all the habit scaffolding you want. The thing that actually works is knowing someone is going to see whether you showed up.

AI gives you the plan. The enforcement layer is the part that makes you do anything with it.

The honest version of what I'm building

MVP Builder is not a magic system. It won't ship your project for you. If you stop showing up, you won't finish — same as everything else.

What it does is make it structurally harder to drift. Daily prompts calibrated to your actual progress. A human in the loop who reads what you write. Milestone reviews before you move forward. And a 30-day window, because open-ended feels manageable until it doesn't.

Three tiers based on where you are: Bronze (13 days, $67) if you haven't started yet. Silver (21 days, $117) if you've started but stalled. Gold (30 days, $179) if you're almost done and can't cross the finish line.

Cohort 2 is open now.

If you've got a project that's been sitting in the 47-files phase for longer than it should, and you want a structure that actually enforces your own intentions — applications are at mvpbuilder.io/pipeline.

It's five questions, five minutes.

The hard part comes after.

AI Took the Boring Parts of Coding. The Boring Parts Were Where You Actually Learned.

MVPBuilder_io — Mon, 18 May 2026 16:46:19 +0000

A few months back, Addy Osmani — a senior engineering lead at Google — wrote about something he'd started seeing across teams: engineers who couldn't fully explain the code their AI tools had generated for them. Not junior engineers. Senior ones. They could read it. They could ship it. They just couldn't always walk you through why it worked, what assumptions it was making, or what it would do under edge conditions they hadn't thought to test yet.

That detail stuck with me, because I've been watching the same thing happen to myself.

The boring parts were the learning layer

Before AI pair-programming was a thing, writing a REST endpoint meant you probably read through the Express docs. Or you banged your head against a CORS error for forty-five minutes. Or you wrote the same middleware three times across three projects until it finally clicked. None of that felt like learning. It felt like overhead. It was boilerplate, error messages, documentation you half-understood and then closed.

But that overhead was doing something. Every error message you stared at was forcing you to build a mental model of the system. Every time you wrote the same db connection logic again, you got a little faster at spotting the edge case. Every time you read docs instead of copying a snippet, you came away with a rough map of what the library actually did versus what you assumed it did.

You weren't just producing an endpoint. You were incrementally building a representation of how this part of the stack behaved. That mental model is what lets you read an unfamiliar error six months later and know in three seconds where to look. It's what makes a senior engineer fast — not that they type more accurately, but that they've already seen a version of this problem before.

AI took those parts. They felt boring. So nobody noticed.

The parts AI is best at are exactly the parts that felt the most tedious: scaffolding, boilerplate, repetitive CRUD, the first draft of any standard pattern. Hand me a data model and I can give you a working API in ten minutes. Three months ago that would have taken an afternoon.

Nobody is mourning the boilerplate. That's the point. But the boilerplate was the tax that paid for comprehension. Now we're not paying the tax. And we're moving fast enough that we don't feel the gap — until something breaks in a way we can't quickly explain.

Comprehension debt

Addy Osmani coined the term for this: comprehension debt. Like technical debt, but for understanding. Your codebase grows. Your mental model of it doesn't keep up. The gap between what exists in the repo and what any human on the team can actually reason about gets wider every sprint.

METR's July 2025 study (arxiv.org/abs/2507.09089) found that experienced developers using AI tools on real-world tasks were actually 19% slower than without them. The finding gets misread as "AI is useless" — that's not what it says. AI is excellent at the planning layer. It's excellent at generating plausible-looking code. What it doesn't do is build your mental model of what it generated. That part is still on you. And if you skip it — which the speed of the workflow makes very tempting — you're accumulating a gap between what's in your codebase and what you can actually debug when it breaks.

The comprehension debt doesn't show up in your velocity metrics. It shows up three months later when something subtle breaks at 2am and nobody on the team can explain why that component was built that way.

If you're hitting this gap right now

If you're in that place — where you've built something, it mostly works, but you'd struggle to walk a senior engineer through exactly how it holds together — a 30-minute conversation is often the fastest way through it. Not to explain it to someone else. To explain it out loud at all, which is a different thing.

That's what the MVP Builder Unstuck Call is for: mvpbuilder.io/unstuck-call. $29. You bring the thing you built. We talk through it. You leave with a cleaner map of what you actually have.

What you can actually do about it

The simplest forcing function I've found: write down what you built today in your own words. Not the code. Not the commit message. Two sentences about what the component does, what assumptions it makes, and what would break it.

If you can't write those two sentences, you didn't understand what you built — the AI did. The writing isn't the point. The writing forces processing. It's the same reason rubber duck debugging works: articulation requires comprehension. You can paste AI-generated code without understanding it. You cannot explain it without understanding it.

This is what daily check-ins in MVP Builder are actually doing under the hood. Not accountability theater. Processing pressure. Every day you write what you built, you're forcing yourself to understand it well enough to describe it to someone who'll read it. Over 30 days, that compounds into a mental model you actually own. It's slower than vibe-coding everything in a weekend. It's also the difference between a project you can maintain and one you're afraid to touch.

The structural observation

AI didn't take your ability to learn. It removed the situations that forced you to. The boilerplate you skipped writing — the docs you didn't read — these weren't obstacles between you and the real work. For a lot of us, they were the real work, disguised as friction.

The engineers who'll be fast in three years aren't the ones who generated the most code with the least friction. They're the ones who stayed curious about why it worked, even when the AI made it very easy not to.

Part 13 in a series about what's actually hard about building a side project with a full-time job.

Part 11: Solo devs have one structural advantage in a post-labor world. Most of them aren't using it. [link]

Part 12: AI sprint planners are solving the wrong problem. [link]