The Eighty Percent Wall
When I started this series the argument felt like it needed defending. Two months later it is close to consensus, and the industry has named the failure that comes next.
When I started writing this series in August, the argument I was making felt like it needed defending. Two months later it is close to consensus, and the conversation has moved somewhere more interesting.
In July, Built In ran a piece arguing that the biggest winners of the AI shift are not engineers. Engineers gain efficiency, which was the expected story. The larger change is happening among non-technical domain experts who can now describe a tool in plain language and get one, without a technical bottleneck standing in between.
The participation numbers say the same thing. By one measure, roughly 63 percent of active users of AI-assisted coding are not developers, and they are product managers, founders, designers, and people who know a specific business well. Major League Hacking reported that in April 2026, 10 percent of its community members were founders, double the year prior and the highest rate in seven years, with project completion rates at events roughly doubling. Y Combinator has reported startups running codebases that are up to 90 percent AI-generated.
Something real is happening, and it is not confined to people like me.
But the more useful development is that the industry has started naming the failure, and the name is very good.
They call it the eighty percent wall.
You build with AI assistance, it goes quickly, and within weeks you have something that looks complete. Screens work. Flows connect. You can demonstrate it to somebody and they will nod. Then real work arrives and it does not hold, because underneath the finished-looking surface is a data model that was never designed for the thing you are now asking it to do. One analysis described it exactly: applications that appear complete while resting on fragile, unstructured data that fails under real-world logic.
I read that phrase and recognized the entire series I had just written.
Everything I have described over these last two months is about the last twenty percent. Not the part that makes a demo work. The part that makes a system survive.
Whether a vendor has a stable identity, decided at the moment the catalog was created rather than a year later when the same company exists three times under slightly different names. Whether facts are recorded as history rather than overwritten, because you cannot go back and record something you did not record. Whether permissions hold across a buyer, their team, a consultant acting on their behalf, and a vendor seeing a scoped slice. Whether the audit exists before anybody asks for it. Whether you can change the shape of live data without breaking somebody's account.
None of that shows up in a demonstration. All of it shows up on the day the first serious buyer runs their operation through your product, and by then it is not adjustable.
That is the difference between building something and building something that holds.
That is the difference between building something and building something that holds, and I now think it is the only distinction that will matter over the next few years.
Because the first one is about to be everywhere.
If the barrier to producing working software has genuinely collapsed, and the evidence says it has, then a great many tools are about to exist that did not before. Most will be built by people who understand a problem well, which is a real advantage and the argument I have been making all along. And most will hit that wall, because the things in the last twenty percent are invisible until they are urgent, and nothing about the tooling forces you to confront them early.
The advantage does not go to whoever builds fastest. It goes to whoever built the unglamorous parts before anything forced them to.
Before I turn any of that into advice, some accuracy about where this actually stands.
Multiple categories are live and more are being added. Vendor agreements are signed and vendors are onboarding. Buyers are running assessments and receiving results. Design partners and beta partners have found things I had wrong and I have fixed them.
There was a point where I believed I was close to complete and I was closer to halfway. That was not a planning failure so much as not yet understanding the shape of the curve, and once I had seen it once I never misread it the same way again. There is more to build inside what already exists, more categories to add, and almost certainly categories I have not thought of yet.
I also did not build this in a vacuum, and I would not recommend that anybody does. Before a line of code existed I spent months interviewing TMS vendors, describing what I intended to build and asking whether it was something they would participate in. I built it because the answer was yes. Validating demand before building is not a step you get to skip because the building got cheap.
What real operations taught me afterward was different in kind. A beta partner ran three reasonable requirements through the matching engine and it returned nothing at all, which no amount of careful design would have caught and which took about ten minutes of contact with a real operation to expose. That is what users are for, and it is a separate question from whether they want the thing at all.
What I would defend is narrower. The things that can be learned from users should be learned from users as early as possible. The things that cannot be added later should be built before you need them. Confusing those two categories is what the eighty percent wall actually is.
If you have read all of these, here is what I would want you to take.
The scarce thing is still knowing what the tool has to do. That has not changed and I do not think it will. Every piece of this was possible because I had spent thirty years accumulating opinions about how buyers choose and where implementations fail. The technology did not supply any of that, and for somebody without it the same tools will produce confident, well-structured work that solves nothing.
Sort your decisions by what they cost to reverse. Most are cheap, so make them fast and be wrong quickly. A small number are permanent because their consequences accumulate in your data, and those are worth an extra week each. Identity, history, boundaries, and who can see what. That is nearly the whole list.
Expect to be uncomfortable for a while. The vocabulary is dense before it is difficult, the plumbing takes far longer than the domain, and you will have the week where three things break because you fixed one. None of that is a verdict on whether you belong.
And decide what you will not compromise on before you are under pressure, because the version of you with a deadline is not the one who should be making that call.
I started this to document how one operator built something without being able to write a line of code. What I found along the way is that the code was never the interesting part. The interesting part is judgment about what to build, discipline about what gets accepted, and honesty about what you do not know.
Those are not technical qualities. They are the ones you already brought.
Go build the thing you have been sitting on.
Selecting supply chain technology?
PreShiftIQ matches buyers to vendors on measured fit across TMS, dock scheduling, ELD, carrier vetting, and fleet management. Vendors pay for outcomes, never for influence, and the buyer match is free.
See how matching works at preshiftiq.com/how-it-works.
Sources
- Built In, on domain experts rather than engineers as the largest beneficiaries of AI-assisted building, July 2026.
- Major League Hacking community and event data, reported April 2026, on founder participation and project completion rates.
- Industry analysis of the eighty percent wall in AI-assisted development, June 2026.
- Boston Consulting Group with Alpega, AI Is Already Moving the Logistics Industry Forward, March 2026.
