Calling an AI model feels like calling a function: you pass in some input, you get output back. But it breaks one rule you’d normally rely on — call it twice with the same input, and you can get two different answers.
Deterministic vs. probabilistic #
A sorting function is deterministic. Feed it [3, 1, 2] a hundred times, get [1, 2, 3] a hundred times. The logic is fixed, written line by line by a person.
A model has no such fixed path. Ask it to sort [3, 1, 2] and it usually gets it right, but ask it something open-ended — “summarize this ticket” or “name this variable” — and the wording can shift every single run, even with nothing else changed.
Build on top of a model expecting function-call reliability, and you will eventually get burned. Plan for variation instead of fighting it.
How a model picks its words #
A model writes one small piece at a time, guessing what should come next based on two things: what it learned during training, and whatever you typed in — the prompt.
Say you ask a model to name a single programming language and nothing else. It looks at your words, guesses the next likely word, then the next, and so on until it stops. Two things fall out of this:
- Ask twice, get two different answers sometimes — “Python” one run, “JavaScript” the next.
- It might ignore your “nothing else” rule and add a sentence explaining its pick anyway. Following instructions exactly isn’t guaranteed.
Picking a model for the job #
Not all models are built the same. Some are cheap and quick but fall apart on anything that takes real reasoning. Others take their time, cost more per call, and hold up much better on hard problems.
There’s no single model that wins on speed, cost, and intelligence all at once — trade-offs come with whatever you pick, and the right choice depends on the task in front of you.
For writing code specifically, today’s models are already solid at most everyday tasks. New releases show up almost monthly, and each round tends to raise the ceiling on what the model can plan, debug, or reason through.
Beyond text #
Text isn’t the only way in or out. A model can take a screenshot and describe what’s wrong with it, listen to spoken audio, or produce a short video clip from a written description. Each of these input/output types is a modality.
These modalities are improving unevenly and fast — video generation in particular has gone from unusable to genuinely convincing in a short stretch of time.
Some ways this shows up while building software:
- Type out what you want and iterate on a plan with the model, back and forth.
- Drop in a screenshot of a broken layout instead of describing the spacing problem in words.
- Talk through a long, messy set of requirements out loud rather than typing all of it.
Knowing how a model works is only half the picture — next, it’s worth looking at where it goes wrong.