AI Opinion & Analysis

• LLMs
• Prompting
• Opinion

Every developer who has been around a while has heard the excuse, usually delivered with a shrug: "works on my machine." The bug is real, the user is not lying, and the developer genuinely cannot reproduce it, because their laptop has a library version, an environment variable, or a cached file that the server does not. The phrase became a joke because it was always technically true and completely useless. We are now watching the exact same failure reappear in a new costume, and it says "it works on my prompt."

You have seen it. Someone demos a prompt that produces a perfect answer. It goes into the product. Within a day the support channel fills with outputs that are wrong, malformed, or unhinged, and the author is baffled, because it worked when they ran it. It did work when they ran it. That is precisely the problem, and it is the same problem we thought we solved twenty years ago.

Same disease, new organ

The old bug came from an environment you did not control and could not see. Your machine had state that the deployment target did not share, so behavior that depended on that hidden state broke the moment it moved.

A prompt has the same hidden state, just in different places. When you tested it, you fed it your clean example, in your phrasing, on the model version you happened to be pointed at that afternoon. Production feeds it a user who writes in fragments, pastes an emoji, switches to Spanish halfway through, or sends the empty string. Same prompt, wildly different input distribution. The prompt did not change. The world around it did, and the prompt had no defenses because you only ever tested it in the world where it worked.

There is a second layer that makes it worse than the original. The old bug was at least deterministic. Given the same machine and the same input, you got the same result every time. A language model is not deterministic by default. The identical prompt with the identical input can return a good answer now and a broken one on the next call. "Works on my prompt" is therefore weaker than "works on my machine," because it does not even reliably work on your prompt. It worked the three times you tried it, and you called that done.

We already know the cure

Here is the part that should be encouraging. The industry did not just complain about "works on my machine" for two decades. We killed it, with a set of practices so ordinary now that juniors assume they always existed: version everything, test against realistic inputs in an environment that mirrors production, put it all in a pipeline that runs before anything ships. The discipline was the answer. The same discipline is the answer here, and prompt engineering is mostly refusing to relearn it the hard way.

What that looks like in practice is not exotic. Pin your model version, because a silent upgrade is a config change that can break every prompt at once. Keep a real test set of messy, adversarial, empty, and multilingual inputs, and run your prompt against all of them, not against the one clean example that made the demo look good. Run each case more than once, because a single pass through a non-deterministic system tells you almost nothing. And gate deployment on those results, so a prompt cannot reach users until it has survived the ugly inputs.

None of this is new thinking. It is testing and version control and continuous integration, pointed at a prompt instead of a binary. The reason teams skip it is that prompts feel like writing, not engineering. You type a sentence in plain English, the model does something clever, and it looks less like code than a note to a coworker. That feeling is the trap. A prompt is a program with an input space larger and stranger than any function you have ever written, and treating it as casual text is how you end up shipping the empty string straight into production.

The teams that will be trusted with AI features are not the ones with the cleverest prompts. They are the ones who looked at "it works on my prompt," recognized an old enemy in a new coat, and reached for the boring tools that beat it the first time. The excuse was funny once. Please do not make us laugh at it twice.

• LLMs
• Opinion

The first time I used an AI assistant to fix a gnarly bug, I felt two things at once: relief that it was solved in four minutes, and a small, nagging sense that I had been robbed. Not by the tool. By myself. Two weeks later the same class of bug showed up in a different file, and I stared at it like a stranger. The AI had solved the problem. I had learned nothing.

This is the part of the AI conversation that gets flattened into slogans. One camp says friction is waste and anything that removes it is pure gain. The other says we are raising a generation that cannot think. Both are too neat. The honest position is that some struggle is where understanding gets built, and some struggle is just pain with no payoff, and the whole skill now is telling them apart.

Not all friction is the same

There is a concept from learning research called desirable difficulty. The idea is that certain kinds of effort, retrieving something from memory instead of rereading it, working a problem before seeing the solution, make the knowledge stick harder precisely because they were hard. The difficulty is not a tax on learning. It is the mechanism of learning. When you struggle to recall how a data structure works and then get it right, you are not being inefficient. You are laying down the thing that lets you recall it next time without help.

Now compare that to the friction of fighting a badly documented API for an afternoon, or hand-formatting a table, or writing the same boilerplate for the tenth time. That friction teaches you nothing you did not already know. It is the pain of a task, not the effort of learning. Handing it to a machine is an unambiguous win, and anyone romanticizing it has confused suffering with growth.

The trouble is that these two kinds of friction feel identical in the moment. Both are annoying. Both make you want the answer now. And the AI is equally happy to dissolve either one. So the tool that saves you from pointless boilerplate is the same tool, with the same one-keystroke ease, that saves you from the productive struggle that would have made you better. It does not know the difference, and if you are not paying attention, neither will you.

The muscle you do not know you are losing

Here is what worries me, and I say this as someone who loves these tools and uses them all day. The loss is invisible while it happens. You do not get a warning that says your debugging intuition is atrophying. You just notice, months later, that you reach for the assistant a beat earlier each time, that the threshold of difficulty at which you give up and ask has quietly dropped. The struggle you skip does not announce itself. It shows up as an absence, later, when the tool is not there or is confidently wrong and you have lost the ability to check it.

There is a real professional risk in this. The senior engineer who is valuable is valuable because of ten thousand small struggles that built judgment. If the next cohort skips those struggles, they arrive at senior titles with junior instincts, and they will not know it, because the code shipped and the tests passed the whole way up.

A rule I actually use

I have started asking one question before I hand something off: will I need to understand this again? If the answer is yes, if this is a domain I work in, a system I own, a skill I want, I do the struggle first and let the AI check my work or fill the gaps. If the answer is no, if this is a one-time chore in a corner of the world I will never revisit, I hand it over without a shred of guilt and move on with my afternoon.

This is not a call to suffer for its own sake. Suffering for its own sake is a religion, not an engineering practice. It is a call to be deliberate about which difficulties you outsource, because the machine will take all of them if you let it, and a few of them were the point.

I still fixed that bug in four minutes. I would do it again. But now, on the problems I actually care about getting good at, I make myself sit in the not-knowing a little longer before I ask. It is slower. It is also the only part of the work that is still making me better, and I am not ready to give that up for a faster Tuesday.

• LLMs
• RAG
• Opinion

Every few months a bigger model lands and the timeline decides intelligence just went up a notch. Meanwhile the people actually shipping features are not sitting around waiting for more parameters. They are fighting a different battle entirely, one that no benchmark score fixes: getting the right information in front of the model at the right moment. That, not size, is where most AI features live or die now.

The model is smart. It just does not know your stuff.

A frontier model has read a staggering slice of the public internet. What it has not read is your customer's last three support tickets, your internal pricing rules, the state of the order the user is asking about, or the document sitting in the tab next to your app. On everything that matters to your actual product, the smartest model on earth starts out ignorant, and no amount of extra parameters changes that. The knowledge it needs lives in your systems, and the job is delivery.

Watch where real failures come from. When an assistant confidently invents a policy, it is usually not because the model was too dumb to reason. It is because nobody put the real policy in front of it, so it filled the gap with something plausible. Swap in a bigger model and you get a more articulate wrong answer. Give a smaller model the right paragraph and it answers correctly. The bottleneck was never the brain. It was the briefing.

More context is not the same as better context

The obvious counter is that context windows are exploding, some models now take a million tokens or more, so just throw everything in and let the model sort it out. This does not work, and it is worth understanding why, because it kills the laziest version of the idea.

Long-context models do not attend evenly across everything you give them. The well-documented "lost in the middle" effect shows models reliably use what sits at the start and end of a long input while quietly glossing over the stuff buried in the middle. Stuff a huge context full and you can watch quality sag, not climb, as the signal gets diluted by noise the model has to wade through. There is a reason people now talk about "context rot," the way a model's grip loosens as the window fills with marginally relevant material. Dumping is not the answer. Curation is.

So the skill is not fetching more. It is fetching less, better. Retrieval that surfaces the three passages that matter instead of the thirty that might. A memory layer that remembers the two facts about this user that change the answer, and forgets the noise. Tool calls that pull a live value at the moment it is needed instead of a stale snapshot baked into a prompt an hour ago. Every one of those is a context problem wearing a different hat.

Why this is where the frontier actually is

Look at where serious effort is going and the shift is obvious. RAG, agents, tool use, memory systems, the whole apparatus is engineering to assemble the right context on the fly. None of it makes the base model smarter. All of it makes the model better-informed at the instant it answers, and that turns out to matter far more for whether your feature works.

This is also why two teams using the identical model ship wildly different products. The model is a commodity they both rent from the same API. The difference is entirely in what each team feeds it: how they chunk and rank their documents, when they call which tool, what they choose to remember and what they let go. That plumbing is the actual product. The model is the easy part, because you can buy it off a menu.

I am not claiming bigger models are pointless. A stronger model does more with a messy briefing and is more forgiving of a sloppy retrieval step, and that is real. But the returns from a better model are shrinking while the returns from better context are wide open, because most teams have barely started on the context side. If your AI feature is underperforming, the honest first question is almost never "do I need a bigger model." It is "did I actually give it what it needed to answer." Nine times out of ten, you did not, and that is a problem you can fix this week without waiting for anyone's next release.

• LLMs
• Prompting
• Opinion

You run a prompt, get a good answer, run the exact same prompt again, and get something different. Sometimes it is a rephrasing. Sometimes it is a different conclusion. If you come from normal software, where the same input gives the same output forever, this feels like the thing is broken. It is not broken. It is doing exactly what it was built to do, and understanding why will change how you use these tools.

The model does not pick a word, it picks from a distribution

At every step, a language model does not decide on the next word. It produces a probability for every possible next token. The word "blue" might get 60 percent, "green" 20 percent, "warm" 5 percent, and a long tail of everything else splitting the rest. Then a sampler reaches into that distribution and draws one.

Temperature is the knob that reshapes those odds before the draw. Turn it up and the flat, unlikely options get more weight, so the output wanders and surprises you. Turn it down and probability piles onto the front-runners, so the model plays it safe. This is a feature. You want a brainstorming assistant to roam and a data-extraction call to stay boring. The variation you are seeing at normal temperature is the model exploring, on purpose.

So the obvious move is to set temperature to 0. Now it always takes the single most likely token, greedy decoding, no dice roll. Same prompt, same answer, forever. Right?

Temperature 0 is not the guarantee you think it is

In practice, temperature 0 gets you close but not all the way. People assumed for years that the leftover wobble was just floating-point noise, some vague hand-wave about GPUs being messy. That answer was never satisfying, and in 2025 researchers at Thinking Machines laid out the actual culprit, and it is more interesting than randomness.

The real cause is batch invariance, or rather the lack of it. When you send a request to a hosted model, you are not alone. The serving system bundles your request together with whatever other requests arrived at the same moment and runs them through the GPU as one batch. That batch is different every time, because it depends on who else is calling the API at that instant, something you have zero control over.

Here is why that matters. Floating-point addition is not associative. Adding a set of numbers in one order can give a very slightly different result than adding them in another order, down in the last bits. When the batch size changes, the GPU kernels split and sum their work in a different order, so the model's internal numbers drift by a hair. Almost always that hair is invisible. But every so often two candidate tokens are nearly tied, the drift nudges one above the other, and the model picks a different word. From there the two answers diverge, because each new token conditions on the last one.

Sit with that for a second. The nondeterminism you see is not the model being random. It is your request sharing a GPU with strangers. The cause is numerical, not magical, and it is fixable. Batch-invariant kernels that pin the reduction order now ship in serving engines like vLLM and SGLang, and with them you can get genuinely reproducible output. Most hosted APIs do not turn that on by default, because it costs a bit of throughput, so the wobble stays.

How to actually think about it

Stop treating a single model output as a fact and start treating it as a sample. One run tells you what the model tends to say. It does not tell you what it always says. That reframe fixes a lot of bad habits.

If you need the same answer every time, do not lean on the model's internals to give it to you. Cache the result keyed on the input, and serve the cached copy. That is deterministic by construction and it is cheaper. If you are extracting structured data, run the call, but validate the shape and constrain the output with a schema so a reworded answer cannot break your parser. If you are evaluating a prompt, never judge it on one run. Sample it ten times and look at the spread, because the spread is the real behavior and a single lucky run is a trap that will embarrass you in production.

And when a demo shows you one perfect output, remember what you are looking at. You are seeing one draw from a distribution, chosen and probably cherry-picked. The honest question is not whether it can produce that answer. It is how often, and what the other draws look like. Ask for a few more and you will learn more in thirty seconds than the polished screenshot will ever tell you.