Keep the Plumbing, Reject the Doctrine

Your AI build didn't fail. One belief inside it did.

When an AI project stumbles, the reflex is to judge the whole thing. Scrap it or defend it. Both moves skip the useful question: which part was actually wrong?

Here's a clean example from an AI coding workflow working on a WordPress codebase. Before changing anything, the model had to pick which files to read. The rule was simple: follow the model's own list of related files.

It missed. In the log's words: "Those three suggestions were sibling surfaces, not the missing caller chain." The model pointed at neighbouring code that looked relevant, not at the chain of code that actually calls into the thing being changed. Without that chain, it was reasoning from the wrong evidence.

The tempting response is to tear it up. But the schema, the persistence, the hash checks, the budgets, the prompt isolation, the exact resolver all held. The plumbing was right.

What was wrong was a doctrine: the assumption that the model's suggestions were enough to find the context. So that's the only thing that gets rejected. The fix is to stop relying on the model to guess where to look. Always load the plugin's entry point. Give it a small, versioned pack of how WordPress itself works.

That split matters more than the fix. Throw out the infrastructure and you destroy the part that worked. Keep the assumption and you guarantee the same miss next time.

Most post-mortems record what changed. Few record what you stopped believing. Only the second tells you whether your next decision is a kill, a fix, or a double-down.

When your last AI pilot disappointed you, did you reject the system, or the belief it was built on?

Originally posted on LinkedIn