This is a rewrite / update of the article I first published here on dev.to back in January. Whether an AI model is classified as software or data can affect everything from export controls to copyright claims to product liability. Courts and regulators are going to have to make calls on this at some point. So - I wanted to try and cover the technical perspective as accurately as possible while not getting trapped in semantics - ie - language or definition.
April 2026
AI is so intertwined with software development today that the question feels almost absurd. LLMs and SLMs are built by engineers, shipped through software pipelines, versioned in repositories, and invoked by programs. Of course they're software — right?
At the level of a systems programmer, compiler writer, or hardware designer, the answer is less obvious. What exactly does a model file contain? Does it satisfy the technical definition of software? And what do we lose by conflating the two?
The Definition That Matters Here
For hardware and systems design, software is executable logic — a sequence of instructions with control flow (branches, loops, calls, returns) that a processor can run. A file that stores data, even if it's used by software, does not meet this definition. This isn't pedantry: the distinction between executable artifacts and data artifacts has real consequences for security, licensing, auditing, and formal verification.
What Is Actually Inside a Model File?
A trained LLM or SLM is typically distributed as a .safetensors, .gguf, or .pth file. Inside are large multidimensional arrays of numbers — weights and biases learned during training. These numbers parameterize a fixed mathematical function: they determine how strongly one neuron influences another, how features are weighted, how signals propagate through layers.
The model file contains no control flow. There are no conditionals, no loops, no instructions that say "if X then Y." It is not an algorithm — it is a parameterization of an algorithm that lives elsewhere. The safetensors format makes this explicit by design: it deliberately forbids embedded executable code to prevent remote-code-execution attacks. The people who built the format treated the model as inert data, not an executable artifact, and built that assumption into the spec.
Can a Model File Run on Its Own?
No. A CPU cannot interpret a .gguf file. A GPU cannot run it without a driver. You cannot chmod +x a model file and launch it. To produce output, the model must be loaded into an inference engine — software written in C++, Python, Rust, or similar — that knows the model's architecture, performs tensor operations, schedules work across hardware, and manages memory.
All the logic that multiplies matrices, applies activation functions, and manages KV caches lives in the runtime, not in the model. The same model file can behave differently depending on the runtime, hardware, precision, or quantization scheme. This dependency draws a clear line: the model is data, the inference engine is software.
The Strongest Test: Change the Runtime, Not the Model
Take a model file and compute its checksum — leave every byte untouched. Now change only the surrounding stack: swap PyTorch for llama.cpp, move from CUDA to CPU, quantize from fp32 to int4, or switch from AVX2 to AVX-512. The model is identical. Latency, memory usage, and even numerical results can shift by orders of magnitude.
The only thing that changed is the executable logic. The model contributed nothing to that change — because the model contains no executable logic to change. That's the falsifiability test, and the model fails it in the direction of data, not software.
The Real Counterargument: Weights as Logic
This is where the argument gets genuinely interesting — and where a lot of thoughtful people push back. In conventional programs, behavior is encoded explicitly: branches, conditionals, lookup tables. In a neural network, behavior is encoded implicitly in numerical weights. Tweaking millions of numbers can change the system's output in the same way rewriting thousands of lines of code can. In Mixture-of-Experts architectures, learned routing weights determine which expert handles which input — that's functionally conditional execution. In agentic systems, attention patterns and learned heuristics drive behavior that looks a lot like decision trees. The boundary between "parameters" and "logic" has genuinely blurred.
So the counterargument isn't wrong: weights do encode something that functions like logic. The question is whether that's sufficient to call them software.
The rebuttal comes down to executability. Weights cannot be interpreted directly by a processor. They have no instruction semantics — no opcode, no addressing mode, no execution context. The routing behavior in an MoE model is real, but it only manifests when an inference engine evaluates those weights against an input. The weights describe what values to use; the runtime defines how to compute with them. That distinction — parameters versus procedure — is what separates data from software, even when the parameters encode surprisingly complex behavior.
Does Generating Code Make a Model Software?
Much of the confusion here comes from the most visible use case: LLMs as coding assistants. But the output of a model doesn't determine the nature of the model. A compiler is software; its symbol table is data — even though that data describes executable behavior. Likewise, a model that synthesizes Python is doing something sophisticated, but the synthesis happens in the runtime. The model supplies weighted associations between tokens; the inference engine produces the output. What a system produces is separate from what that system is.
So What Is an AI Model?
In practice, models are versioned, distributed, cached, deployed, and rolled back like software components. They live in repositories, have compatibility constraints, and are monitored for regressions. It's easy to see why people treat them as software — operationally, they behave like it.
But a model in isolation is data: a trained numerical artifact that encodes the parameters of a mathematical function. It contains no executable logic, no control flow, no instructions. Only when an inference engine loads and interprets those numbers does the model become part of a software system.
Modern AI doesn't replace algorithms with something post-algorithmic. It replaces hand-written rules with learned parameters that are still evaluated by traditional code. The magic is in the training, the scale, and the emergent behavior — not in the model file having crossed some threshold into executability.
The answer, then, is no: an LLM or SLM is not software. It is a trained set of numbers that becomes part of a software system only when interpreted by executable code.
Ben Santora - More Articles @ www.bensantora.com
Top comments (0)