Garbage in, garbage out — why AI can't fix your broken process

Every team I talk to this year is trying to bolt an AI onto its worst process. The support queue nobody wants to read. The PRDs nobody wants to write. The design reviews nobody wants to prepare for. The pitch is always the same — the model will do the annoying part, and the humans will do the interesting part. What actually happens is that the model does the annoying part badly, and the interesting part turns out to have been depending on the annoying part all along.

What a broken process looks like

• 01Nobody can name the input. "We just kind of… collect feedback."
• 02Nobody can name the output. "It's supposed to inform the roadmap."
• 03Nobody can name the decision. "We talk about it in leadership."

A process like that cannot be automated. It can only be accelerated — which is the last thing you want, because you will now generate the same undefined output faster, in more places, with more confident language, and with a paper trail that reads like it was written by someone who understood the problem.

"The model is a mirror with a good vocabulary. It will show you your process exactly as it is, and then dress up what it sees."

The order of operations

Before any team gets to add AI to a workflow, they should be able to answer three questions in one sentence each: what goes in, what comes out, and what decision the output changes. If they can't, no model will save them. If they can, they may not even need one — often the exercise of writing the sentences fixes the workflow, and the AI turns out to be a rounding error on the actual improvement.

Where it actually works

AI works, reliably and beautifully, in the places where humans had already written the process down and were bored of executing it. Well-labeled data. Well-defined transformations. Well-known evaluation. It fails, reliably and expensively, in the places where nobody was willing to write the process down in the first place — because the model cannot infer a stance the team never took.

The point

The good news is that this is not a technology problem. It is a design problem. It is the same design problem senior teams have always had — write the thing down, take the stance, name the input and the output and the decision — and then decide, calmly, whether a model belongs anywhere near it. Usually the answer is smaller and more embarrassing than the deck suggested. That is fine. That is the answer that actually ships.