Deterministic, Immutable and Other Words I’ve Picked Up From AI
I do a lot of vibe coding these days. We hear plenty about the importance of keeping a qualified human in the loop when working with AI. In my case, I am that human. I make sure the AI and I agree on the requirements, approach and solution before we start building, and I stay involved as we progressively design, build and test the result.
During those conversations, and throughout the build process, I’ve noticed something interesting. There are certain words and actions that AI comes back to again and again.
They’re not AI words. AI didn’t invent them. In many cases they’ve been part of software engineering for decades. Some I’ve known and used for years, some I’ve rarely had reason to use, and others describe familiar concepts with a level of precision that makes them particularly useful when a human and an AI are trying to agree on exactly how something should behave.
What interests me is how naturally they’re becoming part of the language of AI-assisted development. I suspect the next generation of designers, developers and solution people are going to hear them a lot more often too.
The danger is that we start repeating the language without really understanding what we’re saying. So I’ve started compiling a list of the words I keep encountering, what they actually mean and, perhaps more importantly, why they’re useful ideas in the first place.
Here are a few that keep coming up.
Deterministic
Something is deterministic when the same input, under the same conditions, produces the same result.
If I give a system A, B and C today and get X, I want A, B and C tomorrow to produce X again. That’s particularly interesting when we’re building with AI because AI itself can be probabilistic. Ask essentially the same question twice and you may get slightly different answers.
So when someone asks whether part of a solution is deterministic, they’re really asking a simple question: can we rely on this behaving the same way next time?
That’s often exactly what we want from software, even when we’re using a less predictable tool to help us build it.
Heuristic
A heuristic is essentially a practical rule of thumb. It won’t guarantee the right answer every time, but it gives us a useful way to make a decision when an exact answer would be difficult, expensive or unnecessary.
We use heuristics all the time without necessarily calling them that. If we decide that a piece of content over a certain length probably needs a summary, or that three failed attempts should trigger a different process, we’re using a simple rule to make a reasonable decision.
This makes heuristic a useful companion to deterministic. Sometimes we’re saying, “If A happens, B must always happen.” Other times we’re saying, “When we see A, B is usually a sensible thing to try.”
A heuristic isn’t a fact or a guarantee. It’s an informed shortcut that’s useful often enough to help us make a decision.
Immutable
Immutable means something can’t be changed after it has been created.
That doesn’t necessarily mean nothing can ever change. It means we don’t rewrite the original. If something changes, we create a new value, version or record while preserving what existed before.
Think of a historical transaction. If we change yesterday’s transaction every time our understanding changes, eventually we no longer have a reliable record of what actually happened yesterday.
Calling something immutable is therefore more than saying, “Please don’t edit this.” We’re saying that preserving its original state is part of the design.
Idempotent
Idempotent is probably one of the less familiar words on this list, but it describes a very useful idea.
Something is idempotent when you can do the same thing more than once without each repetition creating an additional unintended result.
Imagine we send a request to create a payment but don’t receive a response. Did the payment fail, or did it succeed and we simply didn’t hear back? We need to try again, but we certainly don’t want to charge the person twice.
If that operation is idempotent, we can safely repeat the request. The system recognises that we’ve already asked it to perform that particular action and doesn’t blindly do it again.
This comes up constantly in integrations, APIs and automation because retries are a normal part of building reliable systems. Networks fail, responses time out and processes get interrupted.
The useful question behind the word is wonderfully simple: what happens if we do this twice?
If the answer is “we accidentally create two of them”, idempotency might be something worth thinking about.
Scalar
A scalar is simply a single value.
That value might be a number, a piece of text, a true/false value or another simple value depending on the context. The important distinction is that we’re talking about one value rather than a collection, structure or more complex object.
If someone’s age is 51, that’s a scalar. If we have a list containing the ages of 100 people, we’re no longer dealing with a single scalar value. Likewise, "Sydney" can be a scalar value, while a customer record containing a name, address, phone number and email is a more complex structure made up of multiple values.
You’ll hear the term used in slightly different ways across programming, databases, mathematics and data systems, but the underlying idea is similar.
When AI says it “expects a scalar”, the useful translation is usually: give me one value, not a collection of things.
Smoke Test
A smoke test is a quick test to establish whether the important parts of something basically work before we spend time testing it more deeply.
We deploy a change. Does the application load? Can we perform the core action? Are the important components responding? Has anything obviously caught fire?
If the smoke test fails, there isn’t much point beginning a detailed test plan. We already know we have a fundamental problem.
That’s why you’ll hear AI coding tools suggest smoke tests so frequently. When we’re making lots of changes quickly, stopping regularly to establish that the thing basically still works is cheap insurance.
Drift
Drift is what happens when something gradually moves away from its intended or known state.
Code can drift away from the original architecture. Configuration can drift between environments. Documentation can drift away from what the application actually does. Even requirements and implementation can slowly become different versions of the truth.
The important word there is gradually. Drift doesn’t necessarily happen because someone makes one obviously bad decision. Lots of individually reasonable little changes can accumulate until what we have is no longer quite what we thought we had.
So when you hear someone talking about drift, the question underneath it is: are we still where we think we are?
Linting
Linting is automated checking of code for errors, suspicious patterns, inconsistencies and breaches of agreed coding conventions.
We’ve had linters for a long time. CSS linting, JavaScript linting and other forms of static code checking certainly aren’t inventions of the AI era. What AI-assisted development does is make linting an incredibly natural part of a very fast development loop.
Make the change, lint it, fix what the linter finds, test it and move on. A linter doesn’t prove the solution works, because that’s not its job. It catches a class of cheap, avoidable problems before they get further through the process.
That’s probably why I hear the word so much more now. AI can produce and change code quickly, and linting provides a fast way to check some of that work just as quickly.
Hydration
Hydration is one of those wonderfully visual words that modern web development has adopted for a fairly technical process.
A page can arrive from the server already containing its HTML and content. The browser then adds the JavaScript behaviour needed to make that page interactive. That process is called hydration.
The page is already there. Hydration brings it to life.
When you hear about a hydration error, it’s often because what the browser expected when it took over doesn’t quite match what was originally rendered by the server.
You don’t necessarily need to be the person fixing that problem to understand the conversation. If someone says, “This looks like a hydration issue”, you now have a pretty good idea which part of the journey they’re talking about.
Worker
Worker is a wonderfully ordinary word that has a more specific meaning when it turns up in a technical conversation.
A worker is essentially a piece of software given a job to do. Rather than everything happening inside the main application while a user waits, work can be handed off to a worker to process separately.
That job might be resizing an image, processing a queue, sending notifications, transforming data or responding to an event. Some workers run in the background, some run on a schedule and others wake up when something happens, do their job and disappear again.
You’ll hear the word used in slightly different contexts. A web worker can perform work away from the browser’s main thread. A service worker can sit between a web application and the network. A cloud worker can run code without us needing to think in terms of a traditional server sitting there waiting for requests.
The implementations are different, but the basic mental model is useful: there’s a job to do, so give it to a worker.
Once you understand that, a lot of conversations about queues, background processing and distributed applications become much easier to follow.
Canonical
Canonical means the recognised, authoritative or standard version of something when several possible representations exist.
Maybe several URLs can reach effectively the same content, but one is the canonical URL. Maybe information can arrive in several different structures, but we convert it into one canonical format before the rest of the system processes it.
In plain language, when someone asks, “What’s the canonical version?”, they’re asking: of all the ways this thing can exist, which one do we agree is the one?
That’s particularly useful when humans and AI are working together. Ambiguity creates problems quickly. Establishing the canonical representation gives everyone, human and machine, the same thing to work from.
Shape
Shape might be the least technical word on this list, which is partly why I’ve noticed it.
AI uses shape constantly. Shape the data. Shape the response. Shape the implementation. Shape the behaviour. Shape the solution around a particular requirement.
In this context, shaping something means deliberately giving it the structure or characteristics we need rather than simply accepting whatever form it happens to take.
We might receive data in one format and shape it into something our application can use. We might shape a response so it contains only the information required by the next process. Or we might shape an implementation around a set of constraints rather than allowing the technology to dictate the solution.
It’s a simple word, but it’s a useful distinction. Shape doesn’t necessarily mean create. Often the thing already exists. We’re organising, constraining or transforming it into the form we need.
And perhaps that’s why it works so well in conversations with AI. Much of what we’re doing isn’t asking AI to invent something from nothing. We’re progressively shaping an idea, requirement or implementation until it becomes the solution we actually want.
Why These Words Matter
None of these words are new, and that’s really the point.
AI isn’t inventing a new language for software development. What I think it is doing is exposing that language to a much broader group of people, while also making some existing engineering language much more common in our everyday conversations.
Someone who might previously have written requirements, designed an experience, managed a project or described what they wanted a solution to do can now sit beside an AI and progressively build that solution. Along the way, they’re going to find themselves much closer to the language and disciplines of software engineering than they might have been before.
I think that’s particularly important for the next generation coming into our industry. AI can remove a lot of the barriers to building something, but removing the barrier to writing code isn’t the same as removing the need to understand what we’re doing.
We shouldn’t learn these words because they make us sound more technical, and we shouldn’t simply repeat them because AI does. We should understand what they mean, the idea behind them and why someone chose that particular word in the first place. Once you do, many of them turn out to be remarkably good shorthand for ideas that would otherwise take a sentence or two to explain.
And there’s a slightly funny consequence I’ve noticed in myself.
After spending so much time talking to AI this way, these words have started escaping the AI conversation. I now find myself using them in my writing, in solution discussions and in everyday conversations with other people. Something has drifted. We need to shape the approach. Which version is canonical? Is the outcome deterministic?
Apparently, if you spend enough time talking to AI, it doesn’t just learn how you communicate.
You start picking up some of its vocabulary too.