AI Didn’t Turn Everyone Into a Developer. It Turned Software Into IKEA Furniture.
The furniture is fine. The problem is what you're asking it to hold.
My first New York apartment looked like an IKEA showroom. That was the right call: cheap, light enough to get up three flights of stairs, and I could assemble it myself. Then I stood on one of the KALLAX shelves to change a lightbulb.
That shelf broke, but the rest of the shelves were fine. So I ended up looking at it for years. That wasn’t IKEA’s fault. I asked flat-pack furniture to do load-bearing work.
For a startup, a guest room, a prototype: IKEA-rated is the right call. Low load, forgiving tolerances, and replacing the whole thing in a couple of years isn’t a failure. That’s the plan. You’re not supposed to live there forever. Custom built-ins cost more and take longer. You commission them when you know what the room is for and how long you’ll be there.
IKEA is not intrinsically good or bad. But misplaced IKEA carries risk.
A disruptive industry outsider from advertising and media founded an HR SaaS platform. He and his team assumed employment was simpler than it is: one start date, one end date, one tenure. The data model was built to match.
It wasn’t an enterprise problem. Rehires, interns, seasonal workers: these aren’t edge cases. They’re just employment. There were enough early customers without them that the model held up long enough to become structural. Over time, it grew from a hangnail to something undeniable.
I joined the product team seven years in. We had over a thousand customers: the tool still demoed great, but our churn rate was high.
The consequences of living with this IKEA-rated data model were real. Benefit eligibility calculations broke. Tenure data became unreliable. HR teams had to verify years of service by hand in severance cases. I was on an escalation call when a customer said: “Have any of you actually worked in HR?”
The friction had gotten so acute that we assembled a SWAT team to scope a fix. They came back with an eye-popping estimate: a full year of work, plus migrating every existing client.
Nobody was willing to write that check. Customer success kept their workarounds. Sales continued to dodge the question. The whole company knew it was a flaw.
IKEA became load-bearing by accident. Not because nobody noticed. Because fixing it kept losing to building on top of it.
This didn’t require AI. What AI changed is what happens next.
Before AI, fast-built software had a natural ceiling. The builder hit the edge of what they could execute, and the output showed it. Rough spacing. Wireframes that weren’t polished. A clickable prototype that only worked on the happy path and failed on the edge cases.
That roughness wasn’t just aesthetic. It was a stopping point. Not because it always prompted the right conversation, but because the build slowed before it went too far. Some version of “this isn’t ready yet” made the scope legible. The roughness was a de facto prevent control. It didn’t always work. But it created a moment.
That ceiling is gone.
A non-engineer with access to AI agents doesn’t hit a wall at the edge of their skill. The scaffolding goes up. The function runs. The interface is polished. Engineering may not be in the room at all.
There’s no moment where the build visibly exceeds the builder’s reach, and so there’s no natural stop before the prototype has taken on load it was never rated for. The build doesn’t slow down. The accumulation that used to stall at a scrappy prototype stage has no natural interrupt now. Instead of one IKEA-rated data model making its way to a thousand customers, you might be building one of them a week.
It’s not that the conversation used to happen and now doesn’t. It’s that there’s nothing left to force a pause. The ceiling wasn’t a process or a review. It was the roughness. Remove the roughness, and you remove the only thing that made the scope visible before it was too late.
The accumulation doesn’t stop when the build looks good. It stops when the load exceeds what the build was rated for.
Ultimately, IKEA will fall down under load. The consequences are undeniable, even if the root cause is invisible.
The prototype and the production build are visually indistinguishable. That’s a direct consequence of the ceiling being gone. No roughness means no surface signal. Now, the output that started as a three-day experiment and the output built to last look the same. The spacing is right. The function runs. The interface is polished.
If you’re trying to decide whether a piece of software is load-bearing by looking at it, you can’t. The surface no longer tells you. What used to be legible: the seams, the rough edges, the places where the build was clearly still in progress. None of that is there anymore. You have to look somewhere else.
Prevention is the obvious answer. Make the classification call before the build starts. Does the furniture match what it’s holding?
The problem is you don’t always know which prototype is going to take off. The prevent control is increasingly unreliable.
The harder question: does the furniture *still* match what it’s holding? Detection is the realistic lever.
The tell is the unofficial workaround. Not a crisis. A quiet absorption. Someone in customer success cross-checks the system output manually before calls. Finance reconciles a field by hand each quarter because the calculation has been unreliable since the migration. IT keeps a shared doc explaining what to do when the automated report fails. None of it is on a roadmap. It’s just how it’s done now.
Those people aren’t the failure. They’re the signal. They’re absorbing load for months or years. The actual failure was earlier. But the workaround is still running, which means there’s still time.
You can’t always prevent IKEA from becoming structural. But you can learn to read the signs before the quiet failure becomes the loud one.
I’m Clare Hawthorne. I fix friction at the seam between technology, finance and go-to-market.