Cheap to build, costly to remember

Lately I've been doing a lot of agentic coding to make digital products and games. I've written about one of my setups before. This post is about what happens afterwards, and along the way. What happens when building is cheap and keeping track of what you've built is expensive.

The new mud

On 2 October, Nielsen Norman Group published an article by Tanner Kohler: The New Big Ball of Mud. The term isn't new. Brian Foote and Joseph Yoder used it in 1997 for software that grows wild, without a plan, until nobody knows how it holds together.

Kohler sees the same thing in people building their own agent systems. A quick test becomes a lasting change. The system grows bit by bit. You patch instead of rebuilding. The mess ends up in a drawer only the AI can find its way around.

He ends with a question I've thought about a lot: would you know what to change here without the AI? If not, you're a bit screwed.

I recognised myself. As a designer I love testing and trying things. I like painstakingly debugging a pile of files a lot less.

Am I in trouble, I wonder?

Cheap to build, costly to remember

My agents remember nothing between sessions. Everything important lives in files. That's the foundation of agentic coding.

It's also where the mess piles up.

Every session leaves a little something behind. A handover note. A new line in the house rules. A line in the decision log. Each one is useful on its own. Together they become a layer of sludge the agents read every single time.

And the agents are good. They follow the rules, even the ones that should have been removed long ago. That's what makes the whole thing quite fragile.

Agents make it cheap to build and expensive to remember what you've built.

BUT, that doesn't mean it always goes wrong. Nick Hodges argues in InfoWorld that agents could become the tool that cleans the mud back up. The reasoning gives me a little hope.

Three kinds of notes

The most useful thing in the NN/g article is a split between three kinds of context.

• Global. What's always true, for the whole project. For me: the "house rules" and the design document.
• Local. What applies to one task. Think specs and handover notes.
• Ambient. A stream of updates that sits there, but nobody maintains. Think the status board, the changelog and the chat history.

The trouble starts when they mix.

A handover note sneaks into the house rules and suddenly it's true for every agent in every task. Nobody notices. It just happens, quietly. Horror!

What I keep and what I ditch

Here's what I'm doing now to make room for context.

Keep

• Our game rules. When something comes in, something else goes out. I read them myself every so often, line by line.
• One place for each kind of context. The global lives in one place. Local notes live next to their task.
• Naming the context when I prompt and give instructions. When I ask for a change, I say whether it applies always or only now.
• The decision log. A log of the choices I've made, so I can remember something in 1 week, and in 6 months.

Ditch

• Handovers that live forever. When the task is done, the note is done. Whatever should live on gets moved to the right place.
• The proverbial "junk drawer". The folder in the repo called "misc" is where the mess hides. Far too tempting to have one.
• Patching forever. Kohler recommends putting off the add-ons for as long as you can. He also says the rebuild comes in the end. Good to be ready to change the structure.

Is it the same in human teams?

Reading about the different levels of context makes me think of all the situations I've been in where everyone on the team has a slightly different context, and a different understanding of the problem.

Some are "down in the weeds" and mostly care about the details, whether that's interactions and validation, WCAG, or load-time optimisation.

Others talk about the floating ambitions for the business and how things "just need to be simplified". Abstract statements that might as well come from another planet.

Some enjoy the middle ground and being all over the place; myself included.

Take a design system nobody owns. It quickly goes the same way. Components get added because they're needed now. Nobody removes them because they were used in that one system that one time. In the end, nobody knows which variant is the right one.

The difference is that people complain. Agents complain a little less.

A person speaks up when the rules get too long. An agent just reads them, every time, burning tokens.

The fix is the same too: someone has to own the context. I have to own the context. You have to own the context.

Agents can suggest changes. We decide.

What I learned

• The cheapest thing you do is build. The most expensive is remembering (read: creating lasting context).
• What always applies should be kept apart from what applies here and now.
• Read the global files yourself. And try to do it more often than you think you need to.
• Ask Kohler's question: would you know what to change without an AI to help you?

If I can say yes, I'm on the right track. If I can't, it's probably time to tidy up the note pile.

It takes steady hands and clever heads to work with AI and agents. Like Prometheus and the flame, it's easy to get burned if you don't do things the right way.

Nobody wants to be left with a ball of mud.

Sources

• Tanner Kohler, Nielsen Norman Group: The New Big Ball of Mud: Why Agentic AI Systems Turn Fragile (2 October 2026)
• Brian Foote and Joseph Yoder: Big Ball of Mud (1997)
• Nick Hodges, InfoWorld: AI coding agents vs. big balls of mud (27 August 2026)