The Last 30%: Why AI App Builders Stall, and How a Software Factory Finishes the Job

A friend messaged me recently with a question I hear almost every week now. He is not a developer. He wants to build a real app, and he asked which tool to use. One of the app builders everyone talks about, or an AI coding tool like Claude Code.

He had already tried an app builder. His description of the result stayed with me: it looked done. The screens were there. The buttons worked. Then he used the app for real and found what was missing. Behavior that should have worked didn't. The tool told him the app was finished, and the app disagreed.

That gap is the whole story. A first version is cheap now. The last part is still the job.

I told him what I tell everyone: any of these tools can get you most of the way. The tool is not the differentiator. What happens after the first generation is: writing down what you actually want, breaking it into small pieces, checking each piece, and refusing to call anything done until the checks pass.

There is a name for that loop. People call it a software factory.

Most of the way is a demo. The finish is the product.

App builders like Lovable, Replit, and Bolt are good now. Describe an app and you get screens, forms, a login page, and a deploy button in minutes. That is enough for plenty of ideas.

But a demo and a product are different things. The first part is visible. The last part is not: what happens when someone enters the wrong data, who is allowed to look at what, what the app does when the network drops, and what happens when two people change the same thing at once. None of it shows up in a screenshot.

Addy Osmani named this the 70% problem. His essay is field experience, not research. The tool gets you to something impressive quickly. The rest is where experience, review, and real testing decide what lasts.

Even Lovable's own docs say it: "Something breaking is a normal part of building" (Lovable docs). That is not a knock. It is a description of the work.

What a coding harness actually is

A coding harness is a program that puts an AI model inside your project.

That sounds simple because it is. You open a terminal (the text window where you type commands), point it at your project folder, start the harness, and give it a task. Unlike a chat window, it can open the files in the project, change them, run commands, and run the project's tests. When it finishes, the change is sitting in your project, ready for you to inspect.

Three worth knowing:

• Claude Code is Anthropic's terminal harness. It has a plan mode where the model proposes an approach before touching anything, plus helpers like subagents and skills.
• pi is a small, open terminal harness from Mario Zechner, built to be extended.
• omp, or oh-my-pi, is a separately maintained fork of pi with more built in, including plan mode and reviewer subagents.

Do not get attached to the names. A harness without a process is just faster typing. The process is the factory.

What a software factory is

A software factory is a repeatable way to move an idea to working software with AI agents, with checkpoints a human controls.

The phrase is decades older than this wave of AI. Hitachi adopted it for its software works in 1969, and Microsoft's architects tried in 2004 to assemble apps from reusable parts. Both bet that standardizing the process would make software predictable. The assembly line did not stick. Software is not a line of identical bolts.

The new version keeps the useful part. The agents are flexible workers. The fixed part is the process: what to build, how to split it up, and how you know a piece is finished.

Five things: a project, a rulebook, a spec, a plan and tickets, and gates. Gates are the checks that decide when a piece is done. They are what people skip.

The temptation is to treat the agent as the factory. It is not. The agent is the line worker. You are the plant manager. Your job is not to type. Your job is to define "done," then check it.

Cortex, a company that builds developer tooling, put it this way: "the factory is the loop, not any single coding agent inside it."

The loop, step by step

1. Turn the idea into a spec. One page. Who is it for? What are the three things it must do? What is it explicitly not going to do? What does success look like? Most of the failures I see start here, with requirements that never leave someone's head. GitHub's Spec Kit is one reference. A document you can read out loud to a friend is enough.

2. Make the agent plan before it builds. Claude Code and omp both ship a plan mode, and you can always ask for a plan in a file. Read it. It should say what it will change, in what order, and what could break. A bad plan caught in thirty seconds is cheaper than a bad build caught in three hours.

3. Break the plan into small tickets. One ticket should mean one change, one check, one review. Each ticket says what to build and how you will know it is done. My rule: if a ticket cannot be finished and verified in one sitting, it is still too big. You can keep tickets in a numbered list in a text file. When the project grows, GitHub tracks them as issues, with one branch per ticket.

4. Let the agent implement one ticket at a time. The agent reads the rulebook, the spec, the plan, and the ticket. It changes the code, writes a test for the change, runs the tests, and shows you the result. One ticket gets one branch: a parallel version of the project that holds just this change until you approve it. Approving and folding it back into the main project is called merging. If tickets do not overlap, a harness can run several at once; Claude Code calls that agent teams.

5. Review, then merge. The agent will tell you it is done. Treat that as a claim, not a fact. Two questions decide the merge: does it do what the ticket asked, and do the checks pass? Read the changes yourself. Passing tests are necessary. They are not enough.

6. Close the loop. After a ticket merges, update the plan and write down anything the agent got wrong. That note becomes a new line in the rulebook. This is how the loop gets better instead of just getting faster.

Match the amount of process to the risk. A typo fix is one ticket and no plan. A new app needs the full loop.

A real example: adding tags to a small blog

The Flaskr tutorial app is the official Flask tutorial: a tiny blog where you sign in, write posts, and edit your own. It ships with tests, and the whole suite finishes in well under a second. That matters. A loop with a slow signal is a loop you will stop running.

The feature: optional tags on posts. A post can have zero to five tags. They show under the post, and clicking one lists every post with that tag. The scope is small on purpose, and still big enough to touch the real parts of an app: data, forms, pages, permissions, and tests.

The spec fits in five lines:

• Posts can have zero to five tags, typed as a comma-separated list.
• Tags are trimmed, lowercased, and duplicates are merged.
• A bad tag shows a message, not a crash.
• Tag pills link to a page that lists matching posts.
• Guests can read and filter, but cannot create or edit.

The tickets:

1. Add the two small tables that store tags and link them to posts.
2. Write the tag rules and test them without touching a page.
3. Add the optional tag field to the create form.
4. Load and update tags on the edit form.
5. Show tag pills on the post list and add the filter page.
6. Add permission and safety tests, then update the setup notes.

Ticket 2 is the one to study. The agent writes a small piece of logic and a few tests. The tests must fail before the change and pass after. That is the difference between "looks done" and "is done." Any agent can say done. A failing test that starts passing is evidence.

Before you merge, you check the boring things. Did the change touch only the files the plan named? Do the original 24 tests still pass? Can a guest still be blocked from editing someone else's post? Are the tags still there after a reload? None of this needs a computer science degree. It needs you to look.

It is a tutorial app inside the Flask project itself, so you clone Flask and step into the example folder. It also has no way to upgrade the database in place, so a change to the data layout means resetting the tutorial database, which wipes it. A good plan surfaces details like that first; a bad one finds them in the first test run.

I did not run this loop on Flaskr to make this point. The files and the test count are real; the agent run is the part I am describing, not reporting. This is the same loop I use on work I care about.

Running your own factory

You do not need a platform, just a harness, a project folder, and a few habits.

Start in the harness, not the app builder. Before you ask for code, make four things: a rulebook, a spec, a plan, and a list of small tickets. Run one ticket at a time.

The rulebook is the most important file you will write. It tells the agent how to run the app, how to run the tests, and what not to touch. In Claude Code it is called CLAUDE.md (how that works); many other harnesses use AGENTS.md. Add a line every time the agent gets something wrong.

Then make the checks automatic. You want tests, a well-formed-code check, and your own read of the change. Claude Code splits instructions the agent follows from checks the tooling enforces (best practices), and hooks wire in the second kind.

Save repeated instructions as skills. If you work alone, this is your operations manual.

Harness choice matters less than you think. The differences are how they feel, what they cost, and how much comes built in. Pick one and stop shopping.

What still goes wrong

The loop does not remove failure. It moves failure to places where you can see it.

Review becomes the bottleneck. The agent can produce more code than you can read. If you cannot review a change, do not merge it.

Plans drift. Re-plan at each milestone, or the plan becomes fiction.

In one 2025 study of 16 experienced developers working in codebases they knew well, the group was 19% slower with AI tools while believing it was faster. DORA found AI raises throughput but can hurt delivery stability without strong testing. The tool amplifies whatever process surrounds it: good gates get more output, bad gates get more mess.

A harness runs commands on your machine. It can read files and use credentials it should not. Give it the least access it needs, keep your live app out of reach, and review what it can touch.

Some work should stay with an app builder. A weekend mockup is the right call. For anything you plan to maintain, the last 30% is the whole thing, and the loop gets you through it.

The tool is not the answer

My friend asked which tool. The better question is which process.

The last 30% will still be there.

A software factory is not a product you buy or a model you switch to. It is a spec you can read, a plan you can review, a list of small tickets, and gates that decide when work is done. The agents do the typing. You own the definition of done.

If you are building something and you are stuck in the last 30%, start a conversation. That is usually the interesting part.

If you run a services firm and want to turn repeatable work into a product, that is the problem I work on at HARBOR. The HARBOR framework is the version of this loop for a business.