The Developer's View of Everything
When everyone tells the same story, the danger is not that the story is wrong. It is that once it becomes the only story, the places it does not fit stop being examined.
The story we hear nowadays is a software developer’s view of how things get built and then treated as the way all work should be done. I want to look at that more closely, because generalizing the developer’s view onto every workflow and every problem is sometimes an improvement and sometimes an imposition.
Most (If Not All) Work Is Deterministic
What took me a year of working intensively with AI to see clearly is this. Most work, in the end, is deterministic. A credit officer approves or declines. An editor runs the piece or holds it. A doctor treats or waits. Whatever messy thinking happened before, the work resolves into a decision that has to be consistent. The same evidence should produce the same call, today and next week, from this person and the one beside them. That consistency is not optional. It is what makes a decision trustworthy, defensible, and accountable.
At work, our minds wander, associate, and guess, but the decision we deliver does not wander. We sit on top of the evidence and reason our way to a call that holds. The determinism is not in the brain. It is in the discipline of grounding a decision in evidence until it becomes consistent. We have a non-deterministic mind, but held to evidence, it produces a deterministic decision. That is what professional judgment is.
The Machine Is a Different Shape
AI does not work this way. An AI model is probabilistic at its core. It matches patterns and draws an answer from a spread of likely possibilities. Ask an LLM the same thing more than once and the answers can differ, both of them plausible. Even when you pin it to one, that one is the most likely continuation of your words, not a decision reasoned from your evidence. It is not sitting on top of the facts and choosing. It is sampling what usually comes next.
Our workplace is built on a non-deterministic process that produces a deterministic decision, anchored in evidence. An AI model, by contrast, is a probabilistic process that produces a probabilistic output, anchored in patterns. The machine and the human are opposite shapes.
If you are working with AI, it takes effort to do evidence grounding and quality gates to make a probabilistic output more pseudo-deterministic. Most of the time, you are narrowing the chance of errors, not eliminating them.
Deterministic Is a Developer’s Word
Let’s step back and look at what we are actually discussing. Deterministic is not even a word most people use for their work. It is a developer’s word. Outside software, nobody calls a decision deterministic. They call a leader decisive and an employee precise. Same idea, different language. A decisive leader makes the same call from the same facts. A precise employee delivers the same output to the same standard. That is determinism, named in human terms, and it was the quiet expectation of professional work long before software borrowed the word.
This matters because the frame arrived before the technology did. Now we start describing our own work in the developer’s vocabulary, and once the words are theirs, their way of producing the work starts to feel like the natural next step.
A borrowed vocabulary carries a ranking with it. In the developer’s world, the word for good is frontier: the newest model, the latest method, the edge of what is possible. Borrow the language and you inherit the ranking, and by that ranking your own work is never frontier. The steady, consistent work a profession is built on starts to feel dated, not because it stopped working, but because it is now being judged against someone else’s idea of what counts. This is how a borrowed word does its real damage. It does not just rename the work. It quietly persuades you the work was never good enough, and that the cure is to do it their way.
The Harness Does Not Travel
The developer’s way of producing the work has a name too. The harness. You describe what you want, and you set AI agents loose to build it, check it, and build again, running without stopping and without waiting for you. The people building the frontier models are right that this is powerful. In software it is genuinely transformative. I have watched it turn a day of work into an hour. On the right task the gain is real, the kind of 10x to 20x that sounds like marketing until you have seen it.
But look at what the number measures. Speed. From the start, this technology has been about speed. Faster code, faster drafts, faster answers. We treat hitting the multiple as success. But speed is a means, not an end. A boost is only worth something if the time it frees becomes something new. What you do with that time is where the real gain would be.
That is the step the conversation skips. Everyone shares how they hit the multiple, a day of work folded into an hour. Almost no one shares what the freed day was spent on, or what new value came from it. The story stops at the boost. The boost gets reported as the result.
Someone Builds the Rules
The speed is not as clean as it looks. A fast probabilistic model produces hasty, half-finished output. This is common, and it is not only hallucination. The model can retrieve too little, anchor on the wrong thing, or lose the focus of the task, and still hand you something that reads fine. So engineers build grounding and quality gates around it. They pin it to sources. They check its output against fixed rules before it passes. Every one of these is a deterministic move.
In my experience, the 10x to 20x only holds when a lot of that deterministic design sits underneath it, governing what the agents may do and how their work is checked. The speed is real, but it runs on a frame of deterministic rules. And who builds that frame? A human, easily. Deciding what counts as grounded, what a gate should catch, where the model may range and where it may not, that is judgment about the work, written down as rules. It is the most human part of the system, and the part the harness cannot build for itself.
Whose Call It Is
None of this makes the model less remarkable, and none of it is a reason to keep it out of the work. There are large parts of every job where a probabilistic output is exactly what you want, and the model produces it faster and often better than I can. The skill, the thing a year of this has taught me, is telling those parts from the parts that need a decision instead of a sample. And that is not a developer’s call to make on behalf of every other field. It belongs to the people who know what their own work actually has to produce.
Replace or Improve
AI replaces human work. We say it like a fact about the technology. It is not. AI did not decide to replace anyone. People built it to do that, and people chose to tell it that way. It describes a choice we made, not something the machine did. And the choice could go the other way. Replace is one intention. Improve is another. The tool is the same. We picked replace.
The better version is possible. AI can raise the quality of human work, not just the speed of it. That is the one worth building. It is also the one nobody is selling.
The media still describes the human economy in the developer’s language, and still prefers the doom ending, because doom reads better than nuance. What I have not seen, not once, is a headline showing AI making a human economy more prosperous, backed by a real case. Until that case exists, and until the story is told in our own words, the headline will keep selling the end of work.
The prosperous version is available. We have just not written it yet. The story is ours to choose, and so far we have chosen the one that frightens.
