Same Question, Two Answers
The first tool on your desk that won't repeat itself, and what that should change about how far you trust it.
A while back I was building an iOS app and hit a spot where I needed user data to sync automatically across a person’s devices. In Apple’s world that means wiring your data layer up to CloudKit. I was using SwiftData, the current way to handle persistence, so I asked the model how to connect the two.
The first session, it handed me a solution built on Core Data. Core Data is the older framework, the one SwiftData was designed to succeed. The code was not wrong, exactly. It would have run. It was just the previous decade’s answer to a question I was asking this year, and nothing in the response mentioned that.
I asked the same thing again in a separate session. This time it surfaced Apple’s own documentation and walked me straight to the current SwiftData approach, the one I had been looking for in the first place.
Same question. Two sessions. Two different answers, and the gap between them was not noise. It was years of framework design. If I had only ever run the first session, I would have built on the old way and never known the clean one was sitting right there.
The First Tool That Samples
I have used a lot of tools in twenty-five years. Compilers, debuggers, linters, editors, build systems. Every one of them had a property so basic I never once thought about it: it did the same thing twice. Feed it the same input and it hands you back the same output, today, tomorrow, on the machine in the next room. That sameness is the reason I could trust a tool without watching it. I never had to sort my instruments into ones I could rely on and ones I could not, because none of them had ever surprised me.
The model is the first tool on my desk that samples.
Ask it the same thing on Tuesday and Thursday and you may get two different answers, both fluent, both confident, one of them wrong. It draws from a distribution instead of returning a fact, and the interface is careful not to remind you of that.
A deterministic tool can be wrong. A compiler with a bad flag will be wrong the same way every time, and you can find the pattern and route around it. What the model takes away is reproducibility. The wrongness moves. You cannot build a stable relationship with an instrument that will not hold still, and reproducibility was the quiet thing that let you off-load to every tool you ever trusted. Pull it out and the tool does not get less useful. It gets differently useful, in a way most developers have not accounted for.
Operating Is Not Controlling
The trap is not that the model is unreliable. You can plan around unreliable. The trap is that it does not feel unreliable while you are using it.
You prompt it. You refine the prompt. You do not like the answer, so you re-roll, steer, add a constraint, try again. The whole loop feels like driving. Your hands are on the wheel the entire time, and a thing you are steering feels, in the moment, like a thing you control.
Epictetus opens the Enchiridion by cutting the world in two. Some things are up to us and some are not.
Up to us: our judgments, our choices, what we assent to.
Not up to us: everything else, no matter how close it sits to our hands.
The whole of the philosophy runs on sorting each thing into the right column and then spending your energy only in the first one. Get the sort wrong and you pour yourself into things you were never going to govern, and call the exhaustion that follows bad luck.
Operating a thing is not the same as controlling it. You operate the market when you place a trade. You do not control where it goes. You operate the weather in the sense that you decide when to walk out into it, and you control none of it. And you operate the model when you prompt it, but what comes back is not up to you. It is a sample. You did not produce it. It happened to you, dressed up as something you made.
That is the misclassification, and almost everyone is making it. The output arrives, it is articulate, it appeared in response to your keystrokes, so it files itself under mine, produced, up to me before you have thought about it. Then you stake real weight on it, because that is what you do with things you made yourself.
The Question Changes
Put it back where it belongs. The model’s answer is not up to you. File it under the same heading as the weather and the market and every other external that does not check with you first, and watch what changes.
The question stops being do I trust this. Trust is the wrong frame for an external that samples, the same way trust is the wrong frame for a coin. The question becomes how much am I willing to build on an answer I cannot reproduce. That is a question with a real answer, and the answer moves case by case. A throwaway script, build on it freely, the cost of a bad draw is nothing. A date calculation in a payments path, verify every line yourself before you stake a cent of your judgment on it, because the confident wrong answer costs the same whether a person or a distribution handed it to you.
You start treating the model the way a Stoic treats anything that will not behave. You plan around its behavior instead of trusting its consistency. It is the brilliant contractor who is sharp on Tuesday and wrong on Thursday and never tells you which day it is: you use the work, and you check it, and you do not hand him the keys. You do not fire the weather for raining. You bring a coat.
The Oldest Competence
None of this is a new practice you have to install. This is the oldest competence the philosophy has. Stoicism was never built for a world that behaves. It was built for weather, markets, other people, the body, luck, every force that acts on your life without consulting you. Two thousand years of the discipline is one long training in living well next to things you do not control. The non-deterministic tool is just the newest member of that ancient family.
What is new is only this: it is the first one that lives inside your workflow and wears the costume of something you own. The market is honest about being outside you. The weather never once pretended to be your idea. The model does pretend, every time it answers in your voice to your prompt, and the pretense is the whole of its power to pull you into the wrong column.
So do the thing the philosophy has always asked. Sort it correctly. The output is not yours and never was. Once it sits in the right column, it loses the one thing it had going for it, which was the illusion that you made it and can therefore trust it like you trust your own reasoning. You cannot. You did not do the reasoning. Something drew a sample.
That is the entire move. Not a habit, not a checklist. Just putting a thing back where it belongs, which is the first thing the Enchiridion ever asked anyone to do, applied to the strangest tool a developer has ever been handed.
👉 If you enjoy reading this post, feel free to share it with friends!
Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏
You can find me on X and Instagram.