We often treat determinism and predictability as synonyms, but they are not the same.

A system is deterministic if the same starting conditions always lead to the same result. A system is predictable if we can actually foresee that result with the tools, time, and knowledge we have.

Determinism is a system characteristic.

Predictability, on the other hand, often depends on our capabilities, and it usually exists on a spectrum. Weather is a good example. The laws of physics governing the atmosphere have not changed, and they are deterministic. Yet our ability to predict the weather has improved over decades simply because our measurements, models, and computing power improved.

But it's not always on us. Stephen Wolfram has described the concept of computational irreducibility. A system is computationally irreducible if the only way to know its future state is to simulate every step. There are also chaotic systems where tiny measurement errors grow rapidly, making them practically unpredictable.

Some systems are both deterministic and predictable, like planetary motion over short time scales. Others are deterministic but not predictably so in practice, like weather or turbulent flows. Conversely, some systems are not deterministic at the level of individual events but are still predictable statistically, such as casino games or population averages.

In essence: determinism does not guarantee predictability, and predictability does not require determinism.

Back to coding

From the perspective of someone who needs a piece of software, development has never been deterministic. When you ask a software developer to build something, you cannot predict exactly what code they will write, how long it will take (so many jokes about this…), or which edge cases will fail first. The same is true when you ask an AI agent. Both are problem-solving processes operating under uncertainty.

One can argue in favor or against the competency of humans or LLMs when it comes to coding, but determinism has never been a human trait.

In most cases, developers build software to satisfy other people's needs, and what these people really care about is whether the resulting code is predictable enough to rely on: whether the system behaves correctly most of the time, whether failures are visible, and whether they can be fixed quickly.

This distinction is important. From a software developer's pov, asking an LLM to "build a program that sorts 1000 numbers" may not have a predictable result (code). But the end user only cares if the resulting program will always sort any 1000 numbers correctly.

And then there is the environment. Modern software runs on stacks that are far more complex than any single developer can fully reason about: hardware, kernels, drivers, libraries, network conditions, configuration files, container layers, dependency versions. So, even if, as a developer, you write the code to do excatly what you want it to do, in a totally predictable way, running the code may yield less predictable results. While deterministic, the system as a whole is so complex that its behavior cannot be predicted perfectly in advance.

We have quietly accepted that bugs are a natural part of software development (i.e. there will be cases where it behaves unpredictably), because we recognize the complexity of the endeavor. Instead of expecting perfect foresight, the industry built practices around uncertainty: tests, staging environments, observability, rollbacks, reproducible builds.

So, the meaningful question is not about determinism. The meaningful question is which workflow produces more predictable outcomes under real conditions, and which human or AI is a better fit at each case/stage.

Some final thoughts

It's worth looking at how we build some of the most safety-critical software. DO-178C is the "Software Considerations in Airborne Systems and Equipment Certification". It is a key document in the aeronautic industry, providing guidelines for the development of safety-critical airborne software.

The approach of DO-178C is based on the formulation of appropriate objectives and on the verification that these objectives are achieved. The DO-178C authors acknowledged that objectives are more essential and stable than specific procedures. The ways of achieving an objective may vary between companies, and they may vary over time with the evolution of methods, techniques, and tools. DO-178C never states that one should use design method X, coding rules Y, or tool Z. DO-178C does not even impose a specific life cycle.

DO-178C is objective-oriented: the focus is on formulating objectives and verification that the objectives are achieved, a framework that could work both for human coders and LLMs.

References

1. Computational Irreducibility (Wikipedia). The image, Not Random, Blue, is inspired by the concept.

2. Software has bugs. This is normal.

3. Also depending on mood, health, work relationships and other human factors.

4. Even leaving bugs aside, there is a big discussion of which aspect of a compiler is predictable. Modern compilers tend to generate binaries that behave predictably, but are implemented in ways unexpected by the vast majority of developers. For example this article describes a case where the compiler decides to replace an O(n) algorithm written by the developer, with an O(1) one!

5. Side thought: If someone proved (not observed) that humans or LLMs can generate predictable results in some non-trivial cases, that would be really interesting. Tbh, if I had to bet that such a proof exists, I'd put my money on finding one for LLMs.

6. An introduction to DO-178C