The 70% problem

Anyone who has built something with a coding agent knows the first afternoon. A screen appears, then a second one, data flows, and the demo works. It feels like most of the job is done.

Then comes the rest. The empty state, the slow network, the migration from the previous version, the warnings from Swift concurrency. Each fix takes longer than the feature did, and some fixes break something that worked.

This course starts there, because the harness is the answer to that second phase.

A name for the pattern

Addy Osmani described it in December 2024 and called it the 70% problem. With AI tools, people reach about 70 percent of a product surprisingly fast. The final 30 percent then turns into diminishing returns.

He also describes what the stall looks like from the inside. You ask for a small fix. The change seems reasonable and breaks something else. You ask for that to be fixed, and two new problems appear. The code looks complete and gives way under real use.

One more observation from the same article matters for this course. These tools help experienced developers more than beginners. The agent writes quickly, and it takes someone who knows the craft to see what is missing and to steer.

Why the wall is there

The first 70 percent is the part that shows. Screens, navigation, the happy path. An agent is good at it, since each piece has thousands of public examples.

The last 30 percent is what makes software hold. On an iOS project it has familiar names.

• Edge cases. No network, an empty list, a user who taps twice, a very long name.
• Architecture. Where state lives, which module may depend on which, how the app migrates its data.
• Verification. Tests that describe behavior, a build with no warnings, a release that passes review.

None of this appears by accident. Fast code that nobody verified does not bring you closer to it. It moves you away, since every later change lands on code nobody fully understands.

The wall marks the point where unverified work stops being cheap. A stronger model pushes it back a little and does not remove it.

Three ways of working

How you work with the agent decides when you hit the wall, and whether you get past it. The table simplifies, and real work mixes the three.

	Vibe coding	Approving every step	An engineered harness
Who checks the work	Nobody	You, action by action	Checks set up in advance, then you at the end
Speed at the start	Very high	Low	Moderate
Speed after a few weeks	Collapses	Stays low	Holds
Control	None	Total, as long as you keep up	On what you chose to control
Fits	A throwaway prototype	A risky or unfamiliar operation	Software that has to last

Vibe coding

Andrej Karpathy coined the term in February 2025. He described accepting every suggestion, not reading the diffs, and letting the code grow beyond his own understanding. He also said what it was for, calling it “not too bad for throwaway weekend projects”.

That last part got lost along the way. Vibe coding is a fine way to find out whether an idea deserves a real project. It becomes a problem when the prototype quietly turns into the product. Everything that builds the wall is present. No tests, no stated architecture, and nobody who knows why the code is the way it is.

Approving every step

The opposite reflex is to keep the agent on a short leash. It proposes an edit, you read it and accept. It wants to run a command, you approve. Nothing happens without you.

This is safe, and you stay in control. It is the right mode for an operation that cannot be undone, or for a codebase you are still discovering.

As a daily way of working it has a cost. You become the slowest part of the loop, and the agent spends most of its time waiting for you. There is a quieter risk too. After the fiftieth approval of the day, people stop reading. The control is still there on paper.

An engineered harness

The third way moves your decisions earlier. You decide once what the agent may do without asking, what it must never do, and which commands say that a piece of work is done. Then you let it run inside those limits.

The compiler and the tests answer the agent directly, at every step. You come in at the points you chose, usually to review a result that has already passed its checks.

You give up watching every action. You keep control over what matters, and you can keep it when the volume of work grows.

Agentic does not mean unsupervised

“Agentic” is often used as if it meant vibe coding with more steps. The two differ on one point, which is whether anything checks the work.

In vibe coding nothing does. In agentic engineering the agent has autonomy and the work is verified, by checks that were designed for that purpose. Simon Willison drew the same line a few weeks after the term appeared, when he wrote that not all programming with AI assistance is vibe coding.

Seen this way, the harness is how the last 30 percent gets done. Edge cases come from specifications and tests. Architecture comes from instructions and boundaries the agent can read. Verification comes from feedback it cannot skip.

From owning code to owning decisions

There is a larger shift behind all of this, and I want to name it before going further.

Writing code is no longer the bottleneck of software engineering. Syntax, the standard library, the subtle corners of a language, all of that is available to anyone with an agent, instantly, in any quantity. For years we judged engineers on exactly that knowledge. A senior was someone who knew the language deeply, knew the frameworks, and knew the details that trip up everyone else.

I would not say that knowledge stopped mattering. You cannot review what you do not understand, and the rest of this lesson shows how much reviewing there is. What changed is that this knowledge no longer tells a senior apart. A model has it too.

What a model does not have is judgment. Which of three working implementations fits this codebase. Whether a test proves anything. When a shortcut is fine and when it will cost a release. Whether the agent’s confident summary matches what the diff actually does. That is where experience shows now, and it is what the last 30 percent is made of.

So I think we are entering an era of judgment engineering. Senior developers are still needed, and not to type the code. They direct an agency of agents, decide what those agents may do, and answer for the result. We are moving from being owners of code to being owners of decisions. A harness is the set of decisions you make once so that you do not have to make them again at every turn of the loop.

The rest of this module describes that harness, starting with what an agent really is.

Sources

• The 70% problem, hard truths about AI-assisted coding, Addy Osmani, December 2024.
• Not all AI-assisted programming is vibe coding, Simon Willison, March 2025. It quotes Andrej Karpathy’s original definition in full.