The AI feature that guessed where your data goes

I lost an afternoon once convinced a model had gotten dumber overnight. A feature inside an app I was building took a handful of inputs from the user, worked out what each one meant, and ran the right operation on each. It sailed through the demo. Then real inputs started coming in and the answers were wrong. Not crashing wrong. Confidently, specifically wrong, the kind that looks like a real answer right up until you hold it next to what the user actually typed.

If you are asking why your vibe coded AI feature gives confidently wrong answers, the honest answer is that it is almost never the model and almost never the prompt. It is the architecture underneath. You asked one prompt to look at a blob of inputs and infer which value belongs to which operation, and inference is a guess. The fix is not a smarter prompt, it is to stop making the code guess. But you do not get to that fix until you name the real cause, and the reflex buries it.

why does my AI app give confidently wrong answers?

Because the model is good at plausible, and plausible is not the same as correct. When a single prompt receives everything at once and is told to sort out what goes where, it reads the blob and infers the routing. Nothing forces that inference to be right. In the demo the inputs are tidy and it guesses correctly, which is the worst possible outcome, because it teaches you the thing works. The first time real inputs arrive shaped a little differently, the guess drifts, one value lands in the wrong slot three steps back, and everything downstream is built on it. No error fires, because nothing broke. The code did exactly what you asked. You just asked it to guess.

This is the wall almost every vibe coder hits once a feature does more than one thing. Vibe coding is very good at generating each piece. Getting the pieces to route data correctly between them is a different skill, and it is the one that decides whether the output is trustworthy.

why won't a better prompt fix it?

Because the prompt is not where the bug lives, and a bigger prompt is a hotfix aimed at the symptom. I know this because I did the reflex first. I blamed the prompt, rewrote it, added examples, told it to be careful, made it longer. Each version fixed the one case I was staring at and quietly broke a different one. That pattern is the tell. When a fix moves the bug instead of removing it, you have not found the cause yet, you have just relocated it, and you can burn a whole day feeling productive while shipping the same class of error in a new spot.

The discipline that saves the day is boring and it is the same one that matters everywhere else in this work: name the cause before you reach for the fix. Here the cheapest way to name it is a two-architecture test. Hold the inputs constant, change only the routing mechanism, and watch which variable actually moves the result.

So that is what I did. I took the same five inputs and ran them through two builds on the same job. The first was the prompt I had been polishing: one call, all five inputs pasted in, told to figure out what goes where. It mis-slotted them again, silently. The second was dispatch: each input moved to its operation through an explicit contract, this named field in, this named field out, nothing inferred. Same five inputs, two builds, one confidently wrong and one correct. That was the moment the cause stopped being "the model is off today" and became "the model is guessing because nothing in the code made it certain." Prompt tuning had never touched the real problem, which is why it never held.

what does routing by contract actually look like?

Once the diagnosis is right, the fix is small and structural. Each operation declares exactly what it takes and what it returns. An orchestration layer moves named fields between operations, so no step ever receives a blob and guesses, each one gets precisely the fields it needs. The model is asked to do the single thing it is genuinely good at, the actual operation, and it is never asked to infer the plumbing. This is what AI orchestration is underneath the buzzword. It is dispatch, not one clever prompt holding all the state in its head. The routing becomes a structure instead of a hope, and a structure returns the same answer on real inputs that it did in the demo.

The cost is real and worth naming, because pretending it is free would be its own dishonesty. Dispatch is more scaffolding up front than one big prompt. You have to decide the contracts, name the fields, and wire the moves, and that is slower on day one than pasting everything into a single call and hoping. What you buy for that hour is an AI feature whose correctness does not depend on the inputs staying as tidy as they were the day you demoed it. On anything a real user touches, that trade pays for itself the first week.

If you are building an AI feature into your app and it keeps returning answers that look right and are not, and you want a second set of eyes on whether the fix is a prompt or the architecture underneath it, that is the kind of custom-app build work I take on. If it would help to have it diagnosed and routed properly the first time, /work-with-us.

questions that keep coming up

The output is right most of the time. Isn't that good enough? For an internal script, maybe. For anything a user relies on, a feature that is confidently wrong some of the time is worse than one that errors, because nobody knows to check it. Right most of the time on inputs you controlled in testing tells you almost nothing about inputs you did not.

How do I know it's the architecture and not the model? Run the two-architecture test. Hold the inputs fixed and change only how the data is routed. If explicit dispatch returns correct answers where prompt tuning could not, the model was never the problem, the guessing was.

Do I have to rebuild the whole feature to fix this? Usually not. The change is at the routing seam: stop handing one call a blob to infer from, and move named fields between operations instead. The operations themselves rarely change. What changes is that they stop receiving a guess.

I still use a single prompt for plenty of things, the ones where there is genuinely one input and one job. The shift is that I no longer ask a prompt to be the router, because a router that guesses is not a router. It is a very confident coin flip, and it will land wrong on the first input you did not think to test.