AI can build anything. Except a plan.
Last updated 2026-08-11
My app was 70% done for two months. I know the number because I said it out loud every week, to anyone who asked, with total sincerity: almost there. The first weekend had been intoxicating — a working sign-up flow, a real dashboard, an AI chat window turning my sentences into software. By week nine I was staring at a session literally named "continue." Not "fix the payment redirect." Not "onboarding polish." Just continue — because the work no longer had names, only momentum debt. Somewhere back in sessions four through six lived the reasons for decisions my code now depended on, and I couldn't find them, because a chat thread is where reasons go to die. The demo I recorded in week one was the high point. Everything after it was archaeology.
If you've got your own session named "continue," this essay is for you. We're the same person.
What is the 70% problem?
It has a name because a serious engineer gave it one. Addy Osmani — who leads developer experience work on Chrome — called it the 70% problem: AI tools take you from zero to 70% of a working application astonishingly fast, and then progress doesn't slow — it inverts. The last 30% is edge cases, integration, the seams between features. It's the part that has always required engineering judgment, and it's precisely the part the magic weekend never shows you.
Osmani's sharpest observation is who gets hit hardest: not developers, who recognize the wall and climb it, but non-engineers, who "find themselves stuck in a frustrating loop" — each fix breaking something else, because they can't see the structure underneath.
The market data agrees with the anecdotes. Lovable — the flagship of vibe coding, with every incentive to say otherwise — published its own Build Economy report in June 2026. Eight in ten of its users say they intend to monetise what they've built; 60.5% aren't making money yet. Intent clearly isn't the bottleneck. Something between built and earning is — and it lives in the 30%.
Sit with what that means: the pain isn't in generation. Generation is solved — spectacularly. The pain is after generation, in everything the generation didn't leave behind: the decisions, the dependencies, the shape. The missing artifact isn't code. It's structure.
Why haven't the obvious fixes worked?
Everyone who hits the wall tries the same three fixes, in the same order.
Fix one: keep everything in the chat. It's already there, right? But chat scrolls away. The decision that constrains today's feature is forty screens up in a thread you'll never reread, or worse, in a different thread. Context windows are working memory, not memory. Nothing persists on purpose.
Fix two: write it all down. A requirements doc, a Notion page, a README. It's accurate for exactly one day. Documents don't know when the code changes; they have no life of their own, and a stale plan is more dangerous than no plan, because you trust it.
Fix three: get a faster builder. A newer model, a stronger agent. But speed was never the bottleneck — the first 70% was already fast. A faster builder just delivers you to the same wall earlier, with more unstructured code piled behind you.
Persistence, life, and the right bottleneck. Hold onto those three — they're the spec for the actual fix.
What are professional developers doing about it?
Here's the part that should make you feel less alone: the experts hit the same wall, and 2025 was the year they moved — en masse — to the same answer. Plan first, generate second.
They call it spec-driven development, and it went mainstream fast. Amazon built Kiro, an IDE whose entire premise is that you write a spec before the AI writes code — and demand was so heavy that AWS had to cap sign-ups behind a waitlist. GitHub open-sourced Spec Kit, a toolkit for exactly this workflow, and the stars piled up in weeks. Martin Fowler's site — roughly the closest thing software architecture has to a court of record — has been running a whole series treating spec-driven development as a discipline. And Andrej Karpathy, who coined "vibe coding" in the first place, spent mid-2025 arguing the real skill is context engineering: the delicate art of filling the model's window with exactly the right information.
When the people who can code start insisting on plans before generation, that tells you something about what the rest of us are missing.
But look at the shape of every one of those tools: an IDE, a command-line kit, markdown specs in a git repository. All of it developer-facing. The professionals built the planning layer — for themselves. The people the 70% problem hits hardest are exactly the people these tools weren't built for.
What would a real fix look like — for the rest of us?
Run the three failures backwards and you get the requirements.
Chat scrolls away, so the plan needs persistence — a place decisions live that isn't a transcript. Documents go stale, so the plan needs life — it has to be tended, updated as work happens, by the same AI doing the work. And since the bottleneck is structure, not speed, the plan needs shape you can see: phases, dependencies, done-ness, visible at a glance to someone who will never open the repository. Finally, it has to hand off cleanly — package everything an AI builder needs into its context, which is context engineering done for you rather than by you.
Leefy is my attempt at that shape, and I'll describe it plainly. Your project is a living tree on a canvas — the hero image above is a real plan, not a mockup. Branches are the work; the trunk is what everything depends on; seasons phase the work so you're never doing everything at once. The AI tends the plan — grows branches, prunes dead ends, flags the collision between two features before you build the second one — and when it's time to build, it hands a clean, structured brief to the builder.
I won't tell you it makes software easy. Nothing makes software easy. It makes the invisible 30% visible — which is the difference between being stuck and knowing what's next.
Where do I start?
You've already done the hard part — you recognized the wall, which most people mistake for their own inadequacy. The next step is deliberately small: scroll back up to the plan at the top of this page and imagine it's your stuck project, laid out where you can finally see it. Then start one of your own. It's free, and there's no card — the only gate is the beta waitlist, which we open in waves.
And if you read all this and think I've got it wrong — that the missing layer is something else entirely — I genuinely want that email. Being corrected is cheaper than being stuck.