There are two stories about AI and code. One is the one everyone talks about: that language models write programs for us. The other is the one that is more important, but that almost no one talks about: that code keeps language models in check.
The two stories are the same story. But you have to tell them together to understand where the field is actually heading.
What the model does for the code
The first half is well known. I write code every day with a language model. It knows syntax better than I do, remembers the standard library better than I do, and can write a test faster than I can formulate what needs to be tested.
This is not trivial. It's not "autocomplete on steroids," as the boring version of the narrative goes. It's like having a colleague with an encyclopedic overview sitting next to me, and I can ask for a draft of a function, a refactoring, a guess as to why a test is failing. Eight out of ten times, it's reasonably accurate. Two out of ten times, I know more than it does, and I correct it.
This is the division of labor. Not replacement. Not magic. Division of labor.
What the code does for the model
The second half is less visible, but it's the reason AI systems are starting to work in production.
A language model alone is unreliable. It hallucinates, it forgets, it chooses words based on probabilities, not facts. If you ask it to calculate an accounting statement, it guesses. If you ask it to find a file, it might invent the path.
The answer is not to make a better model. The answer is to stop asking the model to do everything.
Instead, you give it a tool. A piece of code that calculates correctly. A function that actually retrieves the file. A database that actually has the right numbers. The model becomes the orchestrator, not the engine. It decides what needs to be done, and the code does it.
This is where the symbiotic relationship becomes concrete. The model is flexible but unreliable. The code is rigid but correct. Put them together, and you get a system that can both understand language and deliver accurate results.
Nushell as an example
I use Nushell as my daily shell. For those who don't know it: Nushell is a shell where everything is structured data. Instead of sending text streams between programs, Nushell sends tables and records with types.
ls | where size > 10mb | sort-by modified is not text being parsed. It's a table being filtered and sorted. Each column has a type. Each operation is a transformation of the structure.
This means two things in the interaction with a language model.
First: the model can write Nushell code that almost always works, because fault tolerance is low and the structure is explicit. When it writes from csv | where amount > 1000, it knows exactly what the columns are called and what their type is. Less guesswork, fewer hallucinated field names.
Second, and more importantly: when the model needs to work with my data, I can give it Nushell as a tool. It expresses its intention in a small script, the script runs against actual files, and the result comes back as structured data the model can work with further.
There's nothing magical about this. It's just choosing a tool where the structure is visible enough for the model to understand it, and rigid enough that it can't make things up.
Compound AI systems
There's a name for this. It's called compound AI systems — composite systems where one or more language models are integrated with databases, tools, retrievers, code, and other models. It has become a research field in itself, partly because Berkeley and several others began to show that the combination often outperforms a single large model, even on benchmarks where the latter should be best.
The point is not academic. The point is that the most valuable AI infrastructure in the coming years will not be the next generation of models. It will be the architecture around them. How you connect a model to your data, what tools it can call, how you validate its output, how you make it fail gracefully when it's unsure.
MCP — Model Context Protocol — is an example. RAG systems are an example. Agentic frameworks with typed tools are an example. All of these are essentially the same pattern: the model is one component, the code is the rest.
Where code sets the framework
The interesting part happens at the interface. The model can do anything, but it can't be trusted. The code can do nothing, but it can be trusted. What do you do?
You write the code so that it defines what the model is even allowed to attempt. A typed function call with three parameters. A validated JSON schema definition. A database query where the columns are known in advance. A permissions model that says no to destructive operations without confirmation.
These are not limitations on the model. They are the scaffolding around it. The framework that allows you to trust the result without trusting the model.
And the model actually gets better by working within a framework. An open-ended question yields vague answers. A closed question with a typed function call yields either a correct call or a clear error. Limitations are not the model's enemy — they are what make it usable.
What this means in practice
I advise companies on AI, and I see the same mistake over and over again. Some people believe that AI transformation is about finding the right model. Or the right vendor. Or the right chatbot.
It's not. It's about what code you have around the model. What data it can access. What tools it can call. What framework you have put in place for what happens when it makes mistakes.
A company with messy data and no internal systems will gain no benefit from the world's best language model. A company with a clean data foundation, clear internal APIs, and a culture of documenting things will gain enormous benefit even from a mediocre model.
The symbiosis is asymmetric. The model is commercial infrastructure you can buy access to. The code is something your organization must build itself — or have built. And it's the code that determines how far you can go.
What it's not about
It's not about writing more code. It's about writing the right code.
It's also not about the model "understanding" your code. It understands nothing. It's a probabilistic text generator with an enormous amount of training data. But it's good enough to be the flexible part of a system, if you build the rigid part properly.
This is the symbiosis. Not a new programming paradigm. Not the end of software engineering. Just a new division of labor, where the part we're worst at — remembering vast amounts of detail and formulating plausible text — is outsourced, and the part we're still best at — defining frameworks, validating correctness, deciding what applies — is where we focus our energy.
This is what works. And this is what will work for many years to come.