You Shouldn't Trust AI's First Answer [Raw Session]

00:00 — Opening

Hey, welcome back to Slow Builds.

I've been thinking about inconsistency in AI responses, not in a dramatic sense of AI is useless or you can't trust anything it says. More in the practical sense.

If you put the same prompt into a model two times, five times, ten times, you usually don't get the exact same answer back.

Sometimes the meaning is close, sometimes the structure is close, but the wording changes. The examples change, the order changes, and sometimes the emphasis on what it focuses on as the answer changes.

I think that is one of the easiest ways to remember what these systems are actually doing and what they actually are.

They're not pulling one fixed answer from a shelf. They are generating a response based on patterns, weights, probability, context, and whatever instructions are active at that moment.

Even when the prompt is the same, there can be more than one reasonable path for the answer to take.

00:59 — Testing Variation

A simple test would be asking for a random, less common Bible verse, nursery rhyme, slogan, or asking it to generate some other random line or idea, and then running that same prompt several times.

An even better way to do it would be to tell it not to use external sources. Don't go to the web. Don't go out and search websites. Use your own data set.

Because something that's been repeated millions and millions of times, something that's been indexed and is in its thing, it's less likely to make any variation or mistakes on certain common things that are known throughout the entire world.

But some random, and that's why I say the Bible, because there are many verses that are not common. There are some that are extremely common, and then there are others that are very less known or repeated or out there.

So if it has to take its own context and go against its own data set, odds are you're going to get close to what the variation would be, but each time you may get a different variation. You're probably never going to get the exact same wording, just because it's the way that the model works.

So it's not that the problem changed, but the output probably is going to change. And that makes sense, because the model is not choosing from permanent answers. It's moving through possibilities.

02:24 — The Bigger System

But I also think there's another layer to that that people don't always talk about. Maybe they don't even realize it or see it.

The model is part of a bigger system.

There's also routing and hardware and infrastructure. There's load, there's caching. There's all these different aspects that go into a prompt going in and the answer coming back.

There's a big story and adventure that your prompt goes on before it returns something to you.

So the caching and stale data, syncing delays, network issues, any kind of failure along that route could cause the answer to be different.

And when a response feels different, it may not only be because the model generates something. It could also be because the surrounding system is acting differently.

And this is one of the parts I keep thinking about.

What happens when there's a huge amount of load?

Maybe my request goes through exactly the same infrastructure, or maybe it doesn't. Maybe requests get routed to different hardware. Maybe some get queued. Maybe capacity changes. Maybe a provider can route certain requests differently based on location, my token usage, what pay grade I'm on.

Just certain words within my prompt may force it to go in a different direction. Maybe I get put on a lower model. Maybe I'm accessing an old data set.

And I don't actually know what's happening inside every AI provider at every moment. And that is really part of the point here.

Unless I control the infrastructure, I'm trusting the thing behind the name on the screen is behaving the way I think it is.

If I run my own model on my own infrastructure, control my data sets, control where it pulls in data, and control the whole configuration along the pipeline, I can start removing a lot of those variables. I can start making it very consistent.

And I think that's going to be an important role in a lot of very high-level critical systems because it helps consistency, and also lower cost and lower latency.

But that is not how most AI is used.

I open an app, I choose a model name, I type something into a box, and there's an enormous amount between that box and response that I do not control.

I may not control the exact model version. I don't control the servers, the routing. I don't control the data set. I don't control the caching. If tools are involved, I don't control whether every tool returns exactly the same information. And if outside data is involved, that data itself can change.

At some point, I'm trusting the provider and the system around the model.

Maybe the same model was used, but the request was routed differently because the system was busy. Maybe a tool had fresher data one time and older data another time. Maybe some connected system was delayed. Maybe the network was slow. The model had the same name, but some part of that pipeline around it was not exactly the same.

And I'm not saying that that's a conspiracy theory. I'm saying it because AI does not exist as a clean box where a prompt goes in and an answer comes out.

It is a stack system. And once you start seeing it that way, the inconsistency feels less mysterious.

The infrastructure around it is dynamic. The data it touches may be fresh, stale, incomplete, delayed, or cached. The tool it uses may work perfectly one time and fail another time.

But I think they fail them gracefully. I think they do it in a way that we still get a response that could be close. So there are fail-safes. There are backup plans.

06:00 — Code Review Friction

And I run into this a lot with work, with code reviews.

I'll write my code and I'll get our system to run our skill. I'll run it until I think it's passing. I want to run the skill the same way the code reviewer is going to run it.

Its job is to review the code.

And so depending on how that skill and prompt are written, they always seem to find something.

So no matter how many times I run it myself and think I finally got everything, once that gets passed off in a PR and the other code reviewer runs the exact same skill, it notices something. It notices a security thing. It'll focus on security. Maybe it'll focus on the naming. It'll find some weird edge case.

And then, again, I'll try to fix all those.

And some of those findings are legit. And that's what makes this complicated, because as much as I go through it over and over again, it will always find more work.

And it gets frustrating, because you could be changing something small. You could go through that feature yourself and you know you got everything covered, but it will always find more work.

And even when you pass it all yourself and submit it, the code reviewer will run that same skill and it will find more work. It will find more problems or more suggestions.

And it's frustrating to a point because the thing will never be green. It will give me green test results, but it'll never give me a full green code pass.

So there comes a point where you just have to trust that you covered all those cases. You have good code that can go out.

But there are times it does find stuff that you missed, and it can make good suggestions. But it can also disagree with itself.

And that's a big thing.

I find that a lot where depending on how many times you run it, and what prompt you give it, or what you tell it to look at or don't tell it to look at, it will contradict itself from time to time.

And that's where I get it to start to feel this fuzziness about, am I running through the same model? Am I running through the same infrastructure? Did this skill look at the same code? Did it use the same memory context and instructions?

And that's where this all kind of comes, because you need a piece of personality behind it. And there needs to be a real person still checking stuff and running the checks and balances, basically.

08:37 — Using Variation on Purpose

And outside of code at work and our system, I don't mind these inconsistencies that much.

I actually use it on purpose.

So for the book that I'm working on, for the thumbnails for these videos, the scripts, personal code projects, I will pass it around. I will ask the same model multiple times to get different responses and check.

I will take one response, I'll ask multiple models, I'll ask multiple systems. I will give the answer from one to another to see what it says about it.

I want to get those things. And sometimes I'll take the answer, and I actually like that they don't give me the exact same thing because I don't necessarily want AI to give me the answer and then I just accept that answer.

I want to see the different directions it goes.

It lets me be the one who makes a choice.

One model might catch something another one missed. One might give me an idea I hadn't even thought about or considered before. And another might push it in a direction I don't like.

So I can move back, or I can go into an uncomfortable stage and figure out how to work that in. But I'm the one who makes the decision. I'm the one who decides where I want this to go.

And with the book especially, this matters.

It is supposed to be my thoughts, my experiences. I don't want the model deciding what I meant just because it produced this clean, beautiful paragraph.

I need to review it. I need to push it into other things. I need to get my thoughts in there and make my decisions.

I can get three different approaches to solving something, look at the trade-offs, test them, decide what actually fits what I'm building or writing.

So the inconsistency isn't always a weakness. Sometimes I intentionally create more of it.

I just don't want to confuse the AI giving me an answer with me making the decision.

10:38 — When AI Sounds Certain

And that matters because people often treat AI output like it is the truth.

They ask once and assume the answer is the answer.

But sometimes you need to ask again. Sometimes you need to compare responses. Sometimes you need to check the source, test the code. You need to slow down and remember that confidence in the wording does not always mean confidence in the process.

That is part of what I keep coming back to when I look at this.

The answers may sound clean. They may sound complete. They may sound certain. But behind that answer is a system that can vary from moment to moment.

If we're using AI for brainstorming, it can actually be useful. The variation gives you different angles.

But if you're using it for facts, code, money, health, legal questions, things that matter and need precision, timeliness, and consistency, that variation is something that has to be managed. It has to be considered.

And in certain situations, you can't just put it into OpenAI or ChatGPT and accept what it says.

It has to be built properly, and it has to be the right kind of system. It can't just be me chatting and getting random answers about what the chemicals in my pool should be, or what's the weather tomorrow?

Because the goal is not to pretend AI is perfectly consistent, and it's not to reject it because it's imperfect.

The goal is to understand what kind of tool it is.

It's powerful. It's useful. But it's not static.

The same prompt can lead to different answers because the model is working through probability. And the same system can behave differently because the infrastructure around it is always moving.

12:24 — Repeatability and Judgment

That is why I think repeatability matters. Verification matters. Running the same prompt more than once matters.

And sometimes intentionally asking another model the same question matters.

Not because I'm trying to find the model that tells me what I want to hear. You can't do that.

It's actually the opposite. It always tells you what you want to hear. It always tells you you're the best, you're the greatest. And you have to step back from that and see what it's doing and why it's doing it.

So you have to take that with a grain of salt.

I try to force the models to tell me I'm wrong. I want it to tell me a different answer, how to look at something different, so I can't just trust what I'm getting.

So I'm not trying to find the one that tells me what I want to hear. I want the disagreement. I want to see where they differ.

Then I can look at those answers, use my perspective, use my likes and dislikes, test what I can test, and decide what I actually think.

Because AI is not just a brain in a box. It is a process. It's a system. It's infrastructure, hardware, and it's just code in the end.

And sometimes the process changes the answer. Sometimes the data set changes the answer.

So you have to be careful. You can't accept it blindly.

You have to use your human intuition and review what you're getting.

But at the end of that process, I want to be the one who makes a decision, and I want to make it mine.

I don't want to just blindly assume that I'm getting the right answer. I want to use it to help me make faster decisions.

I want to use it to help me speed up the process of finding the answers, getting through the code, writing the book, doing a YouTube script, like this one here.

I've read this, redid this one a few times. I've added my own stuff on top of it. And I've gone off script more than once, and I do that all the time.

But that's okay.

It's there as a guideline. I didn't use this as a replacement and just robot it through. I use this as a guide to get me to where I want to go.

Alright, thanks for watching. Bye.