IKEA Effect: How Vibe Coding Is the becoming the New Excel Hell

Recently I was re-reading a piece on the IKEA effect^[1]. The idea stayed with me, as it tends to, whenever I find myself building something.

The concept is simple, and well-documented in behavioral science. We overvalue what we partially create ourselves. “Labor leads to love.” A bookshelf you assembled with your own hands feels more valuable than an identical one delivered pre-built. You forgive its wobbles. You defend its imperfections. You keep adding to it.

But the same bias that makes us proud of our bookshelves has consequences in organizations. It feeds sunk cost effects: the tendency to keep pouring resources into failing projects because we’ve already invested so much. It drives the “not invented here” syndrome: the reflexive rejection of perfectly good solutions developed elsewhere, in favor of our own^[1]. And it makes delegation harder than it should be, because letting go of something you built feels like admitting it wasn’t that good in the first place.

I think about this every time someone in a boardroom tells me, with genuine pride: “We actually built something ourselves for that.”

We’ve seen this movie before. First, Excel became too important. Then SharePoint became the system of record. Then came low-code. Then no-code. Now: vibe coding. Every wave starts with the same promise: you can build it yourself. And yes, you can. Until the prototype becomes business-critical. Until 20 people depend on it, then 200, then multiple departments, then multiple data sources. Then compliance, security, auditability and uptime suddenly matter. That’s where the IKEA effect kicks in. We value what we build ourselves, so we keep adding to it, keep investing, keep fixing, and sunk costs grow.

The problem is simple: knowing the business problem is not the same as knowing how to engineer software. Risk experts are not automatically software architects. Compliance specialists are not data engineers. Security professionals are not necessarily application developers. Modern enterprise software needs scalable data models, secure integrations, access controls, resilience, traceability and maintainability. And when you add connectors, metadata parsing and automated decision logic, the complexity rises fast. Vibe coding is brilliant for speed. But speed is not architecture.

The question is no longer: can we build it ourselves? The question is: do we really want to maintain what we just built for the next five years?

The Excel Macro Era

Every organization has one. If you’ve spent time in finance, risk, or operations, you know exactly what I’m talking about. It’s a workbook, usually enormous, usually held together by formatting and hope, with macros that someone wrote years ago to automate a reporting cycle that used to take a full day.

That person was usually sharp. Often the cleverest analyst on the team. They saw a problem, opened the VBA editor, and built something that worked. And it did work. It saved real time. It created real value. I’m not dismissing that.

But here’s what happened next.

The macro grew. Someone added a sheet. Someone else changed a column width without knowing the macro read from a fixed range. A pivot table was restructured. Hard-coded references multiplied. Nobody documented anything because nobody expected the workbook to become what it became: a load-bearing wall in the organization’s reporting infrastructure. It exists on no architecture diagram. It passes no code review. It has never been tested, validated, or peer-reviewed. And the person who built it? They left two years ago.

When it breaks, and it will break, the organization goes into crisis mode. Not because the problem is technically complex, but because the logic lives entirely in one person’s head, and that person is no longer there. The cognitive risk was concentrated in a single individual. Risky? Yes. But at least it was bounded. One person built it, one person understood it, and a competent replacement could, with enough time and patience, reverse-engineer it. The system was human-scale.

The SharePoint Era

Then self-service arrived, and the promise was seductive: anyone can build. No IT ticket. No procurement cycle. No developer needed. Business units spun up SharePoint sites the way teams once created shared folders: quickly, abundantly, and without any thought about what would happen six months later.

A compliance team built a controls matrix. HR created an onboarding workflow. A project management office constructed a dependency-tracking system. Each one solved a real problem. Each was built by someone who understood their domain.

But SharePoint sites, like macros, accrete. They grow tentacles. The controls matrix links to a document library in another site. That library was reorganized during a merger, and the links now point nowhere, or worse, to the wrong place. The onboarding workflow triggers email alerts to a distribution list that was disbanded during a reorganization. Permissions have become an archaeological record of every restructuring the company has undergone: layers of access grants that nobody ever revoked because nobody knew what would break if they did.

I’ve walked into organizations where nobody, not IT, not compliance, not the business unit, could tell me how many SharePoint sites they had, who owned them, or what data lived where. The cognitive risk had spread. Instead of one person holding the keys, a small team each understood a fragment of the whole. No single individual could describe the full architecture. But, and this is the important part, the components were still legible. You could open a site, trace its lists, follow its links, audit its permissions. It was tedious. It was expensive. But it was possible. The system was inspectable.

The AI Vibecoding Era

This is where we are now, and the shift is not incremental. It’s categorical.

The barrier to building hasn’t just lowered. It has collapsed. With a natural-language prompt, anyone, and I mean anyone, regardless of technical background, can generate a working application, an AI agent, an integration pipeline, a data-processing workflow. You describe what you want. The AI builds it. It runs. Ship it.

I’ve seen it happen. A six-person firm recently used a lightweight, model-native framework to generate a testing solution in about two weeks with two people. Comparable work used to take two years. That’s extraordinary. I’m not pretending it isn’t.

But I’ve also been in rooms where I asked the person who built the solution a simple question: “Can you walk me through the architecture?” And they couldn’t. Not because they’re not smart. They are. But because they didn’t design the architecture. The AI did. It made thousands of micro-decisions during generation: how to structure functions, what dependencies to introduce, how to handle edge cases the prompt never mentioned, where data flows terminate. Those decisions are now embedded in a system the organization will rely on. And nobody, not the builder, not their manager, not the IT department, reviewed, questioned, or even saw them.

This is the fundamental shift, and I want to be precise about it.

In the Excel macro era, the builder understood the logic because they wrote every line. The cognitive risk was concentrated, but it existed in a human mind that could be consulted.

In the SharePoint era, the builder understood the structure because they configured every component. The cognitive risk was distributed, but the system was inspectable. You could trace it.

In the vibecoding era, the builder does not understand the architecture, and neither does anyone else. The generated code may be clean. It may follow best practices. It may even include comments. But the person who prompted it into existence cannot explain why a particular function was structured the way it was, what dependencies it silently introduced, or how it handles data in ways the prompt never specified. The system is a black box that someone in your organization built and deployed into a production environment.

I’ve started calling this cognitive debt. Not technical debt, which implies you know what you owe. Cognitive debt means you’ve deployed something you cannot mentally model, cannot fully inspect, and cannot reliably debug. The debt isn’t in the code. It’s in the gap between what exists and what anyone understands about what exists.

The Constant

Strip away the technology and the dilemma is the same every time:

Maintenance. In the macro era, it was manual, undocumented, and dependent on one person. In the SharePoint era, it was configuration drift, permission rot, and link decay. In the vibecoding era, it’s debugging generated code with no design intent, investigating behaviors that no human designed, approved, or anticipated.

Time. Each era saved time on the front end and lost it on the back end. The macro saved hours per cycle and cost days of reverse-engineering when the builder left. The SharePoint site saved weeks of IT procurement and cost weeks of navigation and troubleshooting. The vibecoded application saves months of development and will cost an amount we don’t yet know. That’s part of the problem.

Value. The IKEA effect intensifies with each era because the effort-to-build ratio drops while the sense of ownership rises. A macro took hours; the builder was attached but also aware of its limits. A SharePoint site took an afternoon; the team was invested but recognized it was rough. A vibecoded application takes minutes; the builder feels they’ve created something remarkable with almost no effort, which makes them more likely to deploy it, more likely to rely on it, and less likely to question what’s actually inside.

And the risk? The risk escalates with every era while the awareness of it diminishes.

In the macro era, risk was concentrated in one person. Bounded. Human-scale.

In the SharePoint era, risk was distributed but legible. Messy, but inspectable.

In the vibecoding era, risk is diffuse and opaque. Not even the builder knows the architecture. Not even the builder knows what’s behind it. The system operates correctly until it doesn’t, and when it doesn’t, there is no design document, no domain expert, no mental model to consult. There is only generated code executing decisions that no human made.

Do We Really Need to Address This?

I get asked this. The argument goes: people have always built their own tools. Excel macros never killed anyone. SharePoint sites are ugly but functional. AI-generated code is just the next step. Why overthink it?

Yes. We do need to address this. And the reason is one word: accountability.

Not the abstract, board-level kind. The regulatory, enforceable, fined-if-you-get-it-wrong kind. Three frameworks in particular make this concrete, and none of them accept “the AI built it” as an answer.

GDPR: The Accountability Principle

The GDPR isn’t just about getting consent and adding a cookie banner. Its core is Article 5(2), the accountability principle: data controllers must not only comply with the regulation’s principles but be able to demonstrate compliance. That means maintaining records of processing activities under Article 30, conducting data protection impact assessments where risks are high under Article 35, and being able to show, on demand, that personal data is processed lawfully, fairly, and transparently.

Now apply that to a vibecoded workflow. Someone in your marketing team prompts an AI into building a customer segmentation tool. It works. It processes personal data. It was never documented. The person who built it can’t tell you what data fields it accesses, what third-party API it quietly called during generation, or where the output is stored. A data subject exercises their right to know how their data is being processed. A supervisory authority asks you to demonstrate compliance.

You can’t. Not because you’re unwilling, but because you genuinely don’t know. The system exists, it processes personal data, and no one in your organization can explain how. Under the GDPR, that’s not a technical problem. It’s a compliance failure. And the fines reflect that: up to €20 million or 4% of global annual turnover, whichever is higher.

The EU AI Act: Deployer Obligations

The EU AI Act doesn’t just regulate the companies that build AI systems. It regulates the organizations that deploy them. Under Article 26, deployers of high-risk AI systems must use the system according to the provider’s instructions, assign human oversight to people with the necessary competence and authority, monitor the system’s operation, ensure input data is relevant and representative, keep automatically generated logs for at least six months, and inform providers and relevant authorities of any serious incidents without undue delay^[2].

Read that list again and ask yourself: how do you assign competent human oversight to a system that no one, including the builder, understands? How do you monitor an operation whose decision logic you cannot trace? How do you ensure input data is appropriate when you don’t fully know what the system does with it? The regulation assumes a chain of accountability that runs from provider to deployer to affected individual. A vibecoded system breaks that chain, because the deployer is also the builder, and they cannot fulfill any of these obligations for a system whose architecture they cannot describe.

The penalties are significant: up to €35 million or 7% of global annual turnover for the most serious violations. But the real risk isn’t the fine. It’s the moment a regulator asks you to show your human oversight measures for a system you can’t explain, and you have nothing to show.

DORA: The Register of Information

For financial institutions, the Digital Operational Resilience Act adds another layer. Financial entities must maintain a comprehensive register of information documenting their ICT third-party arrangements, including the services provided, the dependencies, and the risk associated with each. That register must be available to regulators and kept current.

A vibecoded integration pipeline is a textbook example of how this breaks. Someone builds a tool that connects to external APIs, processes data from third-party services, and introduces dependencies that were never explicitly requested or documented. Those dependencies exist in the generated code. They connect your systems to external services. And if they’re not in your register of information, you have a compliance gap you don’t even know about. Not because someone hid it. Because no one ever saw it. The AI introduced it during generation, and the builder couldn’t tell you what it did.

The Common Thread

Three frameworks. Different domains, different regulators, different penalties. But the same expectation: if you deploy a system, you are accountable for what it does. You must be able to explain it, monitor it, document it, and demonstrate oversight. That expectation does not bend because the system was built by an AI rather than a person. If anything, it tightens, because regulators are already aware that AI-deployed systems introduce risks that traditional governance was not designed for.

When an Excel macro produces an incorrect financial figure, someone is accountable. The person who built it. The person who reviewed it. The person who relied on it. We can trace the chain.

When a SharePoint workflow exposes sensitive documents to the wrong audience, someone is accountable. The site administrator. The compliance officer. The person who configured the permissions. The system is messy, but the accountability chain exists and can be reconstructed.

When a vibecoded AI agent processes personal data in a way that violates GDPR, or makes a decision that falls foul of the EU AI Act’s deployer obligations, or introduces an undocumented third-party dependency that creates a DORA compliance gap: who is accountable?

Not the AI. Not the model. Not the prompt. The organization that deployed it. The individual who built it. The manager who allowed it into production without review. The compliance function that didn’t know it existed. The board that didn’t ask whether anyone in their organization was deploying systems they couldn’t explain.

Accountability does not transfer to a system you cannot understand. You cannot delegate responsibility to a tool you cannot inspect. And you cannot demonstrate compliance to a regulator for a system whose behavior you cannot describe.

What Changes

I’m not arguing that we stop building. That would be absurd. The tools are powerful, the speed is real, and the organizations that refuse to adopt them will be left behind by the ones that do. I’ve seen what’s possible when people move fast: real solutions to real problems, built in days instead of months.

But building fast without governance is how you get the IKEA effect at organizational scale: a collection of wobbly bookshelves that everyone is proud of and no one can maintain, sitting in a building that an inspector is about to visit.

The response is not to stop building. The response is to build with governance: to ensure that what gets built is documented, reviewed, understood well enough to be accountable for, and connected to a framework of oversight that doesn’t depend on the builder’s continued presence or comprehension. That means challenging the “not invented here” syndrome: the reflex to build when a tested, maintained solution already exists. And it means running a pre-mortem before you ship: imagine the system has failed, then ask why. That exercise surfaces the questions no one asked during generation: what data it touches, what dependencies it introduced, what breaks when it breaks^[1].

That means knowing what exists in your environment, who built it, what data it touches, what decisions it makes, and who is responsible for it. Not because building is wrong. Because deploying something you can’t explain is.

The technology has changed three times. The dilemma hasn’t changed once: maintenance, time, and value. What has changed is the distance between the builder and the architecture, and with that distance, the ability to be accountable for what’s been built.

In the macro era, one person could hold the whole picture. In the SharePoint era, a team could collectively reconstruct it. In the vibecoding era, no one holds the picture at all. That’s not a technology problem. That’s an accountability problem. And accountability problems don’t solve themselves.

We don’t need to wait for the first major failure to start taking this seriously. We have enough failures already. The question is whether we learn from them, or whether we keep building bookshelves we can’t straighten, in rooms we can’t inspect, for inspectors who are already on their way.

October 2026

Sources:
^[1] “The IKEA effect on Cybersecurity investment decisions.” Digital Security Leadership, 12ways.net, October 2022. https://12ways.net/blogs/the-ikea-effect-on-cybersecurity-investment-decisions/
^[2] EU AI Act, Article 26: Obligations of deployers of high-risk AI systems. European Commission, AI Act Service Desk. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26