What is the 70% wall?

For the first stretch, you are asking for things that have been built ten thousand times before. A signup form. A dashboard. A list with a filter on it. There is a well-worn answer for each one, and the AI has seen all of them. This is genuinely the fastest way to get a working idea in front of a human being, and it is worth doing.

Then the requests change shape. Instead of add a page, it becomes make sure this customer cannot see that customer’s data. Instead of add a button, it becomes handle the case where the payment goes through but the confirmation never arrives. These are not harder to type. They are harder because the right answer depends on how the whole app fits together, and the AI is only looking at one piece of it.

So it gives you something that looks sensible on its own and is wrong in the bigger picture. The code runs. The screen looks right. The problem shows up three features away, a week later, and now you are holding a bug you cannot describe in code you did not write.

The instinct when things break is to ask the AI to fix it, then ask again, then again. That instinct is the trap. Researchers ran a controlled experiment on exactly this: 400 code samples put through 40 rounds of improvement, using four different ways of asking. They found a 37.6% increase in serious security holes after just five rounds. Asking harder made the code less safe, not more. That study has not been through peer review yet, so treat it as one strong result rather than a closed case, but it matches what every founder in this position reports.

There is a second signal in the shape of the code AI writes. GitClear analyzed 623 million code changes and found copy-pasted code up 81%, while tidying up and simplifying dropped 70% against 2022 levels. In plain terms, the same instruction gets written out again in nine places instead of once. Nothing is shared, so nothing can be fixed in one go. That is the mechanical reason a small change keeps having large consequences. GitClear sells code-quality software and works from its own customers, so the link to AI is a reasonable guess from the timing rather than something they proved, but the direction is hard to argue with.

Google’s 2025 DORA research gives the fairest summary available: AI makes teams faster at shipping and worse at keeping things working. It magnifies whatever good habits were already there. If those habits were never there, because you are a founder and not an engineering department, it magnifies that too.

Almost none of it is more code. The wall is a decision problem wearing a technical costume. What is missing is someone who has shipped this before deciding which of the remaining features actually matter, which can wait until there are customers to complain about them, and which were never worth building.

The work itself divides into three honest piles. There is what you keep, which is usually more than founders expect: the idea, the steps people go through, the design decisions, and everything you learned by putting it in front of people. There is what gets rebuilt, which is usually the foundation, because the rules about who can see which data have to be right underneath rather than patched on top. And there is what gets cut, which is the pile nobody wants and everybody needs.

That last pile is the one an AI assistant will never give you, because it will build whatever you ask for. It is also, uncomfortably, the one most agencies will not give you either, since they are paid to build what you ask for rather than to talk you out of it.

This is the part worth insisting on with whoever you work with next. Having a copy of the code is the easy half of ownership. The half that matters is being handed a plain-English map of where your logins live, where the rules about who sees what are enforced, and what happens between someone tapping a button and the data changing. If you cannot get that in a sentence, you do not yet own it in any way that helps you.