The New Big Ball of Mud: Why Agentic AI Systems Turn Fragile

Source: Tanner Kohler; Nielsen Norman Group article · 2026-10-02

Building systems for working with AI agents is software engineering, whether or not the builder knows it. And increasingly the builders aren’t engineers: a growing crowd of vibe architects with little technical background are crafting complex systems that rely on large context libraries to help them in their daily work. In a recent study of these users, we recognized a familiar pattern that has plagued software architects for decades.

Software engineers learned long ago that systems patched together to meet today’s needs turn fragile and unmaintainable. They learned to plan their architecture so that changing a system later wouldn’t cost more time, money, and expertise than they had. AI makes all these resources feel unlimited, and we saw the result: with nothing forcing them to prioritize, these vibe architects were building big balls of mud. In the AI era, a big ball of mud works surprisingly well — until accumulated complexity makes the system difficult to direct, diagnose, or reconstruct.

A big ball of mud is a system scraped together for short-term functionality, not architected for long-term durability.

The term comes from Brian Foote and Joseph Yoder’s 1997 paper, which observed that most real software at the time looked this way. Such a ball-of-mud system may be useful, but its fragility makes it costly to maintain. Like a shantytown built hastily out of necessity, it needs constant patching and jury-rigging to keep running, rather than holding up like the infrastructure of a master-planned city.

Big balls of mud typically emerge when scarcity meets reality. There’s not enough time, money, or expertise, yet something must be created. Early software teams worked in a “code-and-fix” mode, which sufficed until problems got harder and their big balls of mud became unsustainable. The industry responded with the heavily planned “waterfall” era, modeled on mature engineering disciplines. But when it proved impossible to foresee every need up front, it moved toward an Agile framework.

Our participants were retreading this history. They coded and fixed, with little forethought about architecture or durability, planning to keep molding the clay to fit whatever problems arose.

The difference today is that AI has turned that scarcity into abundance. Building is cheap, so nothing forces a builder to prioritize, and people overbuild. One advanced participant said:

“When I talk to people who say they are advanced in AI, what I often see is what I consider overengineered. It has a lot of fancy words, a lot of flashy tools, but it doesn't get you that much more value for the time you spend in it ... Because AI makes it so easy for you to build something, people actually start overbuilding because it feels productive."

It starts when a user has the AI build a proof of concept for something that seems useful. For example, they create a rules.md file to restrain their agents from annoying or problematic behaviors. The file isn’t planned or thoroughly tested; it is a first draft. But the user quickly moves on to other things while the AI diligently continues referencing the context that was created, as instructed. And before long, the user’s workflows have adapted to rely on it.

“I didn't write the structure myself... I worked with Claude [...] to just build the structure for itself [...] now I'm kind of [...] stuck in the way that it works. And I've never really taken the time to greenfield improve what I did."

As new needs arise, users bolt new functionality onto the original version of their system that they’re hanging on to. One participant’s tool went through three stages:

Stage 1: The participant noticed that her team had limited visibility into work tracked in Asana, so she used AI to build an Asana widget that surfaced each project’s status without requiring stakeholders to sift through more than 50 tasks.

This participant could not write code. Yet, with AI removing the brakes, a small throwaway widget grew into a crossfunctional dashboard. This is piecemeal growth.

“[Claude is] always hammering me that I'm stuck in this prerevenue infrastructure loop.

Other participants could not locate, in front of us, important files their systems relied on; they had to ask the AI to find them and explain what they contained. The system had slowly grown to the point where they no longer understood exactly where everything lived, how the AI was using it, or what it contained. If they had to recreate the system, they probably couldn’t.

“I might even be dependent on it [...] If I experience even a slight amount of challenge [...] I ask it to help me instead of actively thinking about it myself [...] I think I would definitely feel frustrated if the tool was taken away.”

When users can’t or won’t clean up a mess, they contain it: everything goes into one place so the rest of the system stays tidy. In agentic systems, the rug is really a junk drawer — the user keeps needing what’s in it, but only the AI can find anything. One participant emailed himself articles and links throughout the day for the AI to collect. There were too many to process, so they went into a folder called to be synthesized, with no naming scheme. When he later asked the AI to pull relevant material from that folder for a project, it retrieved the wrong articles, and he spent 45 minutes fixing the instructions instead of doing real work.

This pattern resembles Harry Potter visiting the Gringotts bank. Harry knows he has a vault, and he vaguely knows what’s in it, but he can’t find it or access it without a goblin guide. Our participants relied on the AI to navigate their mess, and it did so surprisingly well, which makes it tempting to keep sweeping more and more under the rug. Whether the AI can keep compensating as the pile grows is an open question; the 45 minutes lost to the wrong files suggest it has limits.

Eventually, many systems, AI-centric or not, are rebuilt or abandoned.