Spaghettification

This one follows on from Fight the Framework, where I talked about how full-stack frameworks become a black hole for AI because the execution path vanishes into the framework internals. That was one black hole. I want to take the idea further, because black holes are not just a framework problem. They are everywhere in how we work with agents.

A black hole is any point where the agent loses visibility. A gap in what it can see, read, or verify. The dangerous part is what happens at the edge of one. An agent does not stop and say "I cannot see in there, please help." It improvises. It hallucinates, or finds a hacky workaround, or makes an assumption that sounds right and barrels on. That improvisation is the whole problem, and it is where trust quietly falls apart.

Newer models are better at not falling in. Something like Opus 4.8 will often pause at the edge where an older model would have charged straight through. But better is not solved. The real move is to design the black holes out of your workflow rather than hope the model survives them.

A dependency is a black hole you invite in. The agent cannot see inside it without going and reading the source, so every package you pull in is another region of your code it has to take on faith.

That used to be a good trade. It is worth reconsidering now. As agents get faster and better at coding, the maths quietly flips. The thing a small library saved you, the agent can often just produce itself, in your own codebase, where every line is visible. Large libraries still earn their place. But a dependency you only half-use is increasingly a gap you did not need to open.

This is the counterintuitive one. Agent memory, shared skills, team-wide workflows, the things we add to make agents more helpful, often create more confusion than they help.

The problem is contradiction. The moment your standing context says one thing and your prompt says another, the agent has to stop and reconcile the two before it can do anything. Why is this mentioned when I was asked about that? Should I reconcile them? Pick one? All of that is attention spent away from the task you actually set. It costs real time, and I think it produces a worse outcome, because the energy went into resolving a conflict instead of doing the work.

Again, newer models handle this better. They can hold the contradiction, work out that you clearly meant the thing you just asked for, and carry on. But surviving a conflict is not the same as not having one. Just because the model can cope does not mean you should be feeding it the gap in the first place.

The same thing happens around data. If you frame a task as though the agent understands the data, but it has no actual access to that data, it will literally just make shit up.

And it does that because you made it sound like it should already know. You wrote the task as if the understanding was in the room, so the agent fills the gap rather than admitting the gap exists. Newer models are better at catching themselves here, at saying "hang on, I cannot actually see this." But it is still a risk, and an easy one to remove. If the agent needs the data to do the job, give it the data. Do not describe data as if it is already there.

I have not worked out how to avoid this one yet.

When a result is not what the agent expected, it tends to blame the part it cannot fully see. The classic is "hot module reloading must be broken." It almost never is. The reload is fine; the expectation was off. Same shape as "the failing tests must be unrelated to my work." The dev stack becomes a false horizon: it looks like the edge of the problem, but the real problem is somewhere else.

So where does all this land. The more you can avoid black holes, and make sure your agent has full visibility of everything that happens, the better everything gets. The right context. The data. The decisions. The entire journey of the code, start to finish.

Do that, and it completely changes your development workflow, and the level of trust you can put into agents. Not because the model got smarter, but because you stopped asking it to reason across gaps it could never see across in the first place.

The False Horizon is still out there, unsolved, and I am fine admitting that. But the rest of them, the dependency you half-use, the conflicting guidelines, the data you only described, those you can design out today. Every one you close is light that gets back out.