What is the 70% wall? (why the last 30% of your app is the hard part)

What it actually is

The 70% wall is the point in building an app where prompting stops closing the gap between “looks done” and “actually done.” It shows up almost exactly where the name suggests: the screens exist, the happy path runs, the demo looks great, your app is roughly seventy percent there. Then the remaining thirty percent, the edge case that only shows up on the third click, the thing that breaks when two people use it at once, the bug that comes back after you thought you fixed it, turns out to take as long as everything before it did.

It’s the software version of renovating a house. Framing and drywall go up fast, and the place suddenly looks finished in photos. Then comes the wiring behind the walls, the plumbing that has to actually hold pressure, the inspection that fails twice before it passes. None of that shows up in a photo, and none of it moves faster just because the framing did.

Why your AI just did this

By the time you hit this wall, the codebase has usually built up the small debt of every quick “just make it work” prompt from the first few hours: logic copied instead of reused, a data shape that changed once without updating every place that reads it, error handling nobody asked for and nobody got. Early on, prompting felt like it worked because the project was small enough that a targeted fix landed on the actual problem. Past a certain size, a fix in one spot surfaces a break somewhere else the agent isn’t holding in view in that one exchange, especially across a fresh session that doesn’t remember yesterday’s reasoning, only the code it left behind. The model’s coding ability hasn’t changed. What’s grown is the number of places a single change can ripple to, faster than one instruction can account for.

When you’ll run into it

• “Fix the login bug” fixes login, and profile settings quietly breaks somewhere unrelated.
• The agent says some version of “that should do it” two or three times for the same bug, and it keeps coming back reshaped.
• You’re roughly four to eight hours into your first real project, past the point where every prompt added a visible new screen or feature.
• Adding one more feature means touching three files that already exist for other features, and nobody, including you, remembers why they’re wired the way they are.
• The app works perfectly in the exact sequence you demoed, and falls over the moment someone clicks in a different order.

What to check

• Whether your last several prompts were all fixes rather than new features. Several fixes in a row with no forward motion is the signal, not a reason to send one more
• Whether you can describe, in one or two plain sentences, what’s actually broken and why. If you can’t, that’s the scope to narrow before touching more code
• Whether the last fix touched the real function causing the problem, or just quieted the symptom (a try/catch, a stray null check, a workaround bolted on top)
• Whether you’re asking for “fix the whole feature” instead of one function or one file. Smaller scope gives the agent less room to fix one thing by breaking another
• Whether it’s worth asking the agent to explain the current structure back to you before writing any new code, so you’re both looking at the same picture

Say it like a dev

Instead of: “just make it work, add whatever you need” Say: “before touching code, explain what’s actually broken and why, then we’ll fix it”

Instead of: “it’s basically done, just needs some polish” Say: “we’re past the easy seventy percent, let’s slow down and scope this one bug at a time”

Instead of: “keep trying things until it works” Say: “scope this to just the checkout function, don’t touch anything else until this is understood”