Softer Software

27 Mar, 2026

Per SICP, a computer program is defined as the precise description of a process. Perhaps a bit more generally, a program is a description of a computational process that evolves in time according to some given rules.

When the computational process described by the computer program is governed directly by electrons, we call it hardware; on top, a light abstraction upon the hardware is the firm-ware, and when the computational process entirely is governed by the hardware and abstracted by the firmware, we call our computer programs software: for example, my terminal application emits instructions in a formal language that my firmware translates into policies for travelling electrons inside my laptop.

There is another way to look at hard/soft: a continuous relaxation of a "hard" function is oftentimes called its "soft" version (softmax, softgating). These relaxations typically trade some precision for differentiability, which allows gradient-based optimization, which allows them to scale; this is a recurring theme across Computer Science: many randomized and approximation algorithms allow sub-exponential convergence to otherwise intractable problems as long as we allow space for some error.

Could software too admit a similarly "softer" interpretation? Could there be "softer" software?

Perhaps: we may see LLM as a stochastic interpreter for an informal language (such as English) (we may perhaps argue that since the language is informal, the interpreter has to necessarily be stochastic, to account for a problem-search on imprecise instruction). The LLM interprets a prompt and defines a computational process that evolves a state autoregressively over time. The output of the LLM, then, is the execution trace of this program, wherein the LLM has "searched" through the programspace to find something fulfils the instruction levied via the prompt.

Of late, LLMs equipped with a harness may use/write python tooling and recursively spawn subagents operating in parallel. The following, for example, is a MAP-Elites algorithm written as a prompt that a frontier LLM can execute in a loop today:

Randomly pick a cell $C_{x y}$ , note seed prompt $p_{x}$ and $p_{y}$ , and extant prompt $p_{x y}$
L mutates $p_{x}$ , $p_{y}$ , $p_{x y}$ into a new preliminary prompt $p_{x y}^{'}$
seededby $p_{x y}^{'}$ , L produces a set of diverse prompts $p_{i, x y} \in P_{x y}$ ,
Feed all prompts in $P_{x y}$ into S,
L judges results, compare with extant baseline on $C_{x y}$ ,
L scores prompts $p \in P_{i}$ according to rollout quality
L updates grid with current winners, store [score, winning_prompt].

Note that this can be done asynchronously and the algorithm administered autonomously, in parallel; after each round, we have a gather, where we sync across parallel subagents, and then we continue, much like how a SIMD processor would process a program of this nature.

The only thing we give up is guarantees: unlike traditional programs, we may go wrong once in a million tries. I'll submit that this is not new: sloppy firmware fails more than hardware, and sloppy software fails more often, on the average, than firmware.

However, it is worth remembering the time NASA programmers could confirm that the likelihood of a software bug on a malfunctioning probe halfway across the solar system was lower than the chance of a transient bitflip aboard the chip: because code was formally verified. A similar probabilistic guarantee perhaps exists for LLM-based code reviews: as with randomized algorithms, the chance of failure should drop sharply with the number of passes. Truly, what we pay for during pretrain is essentially the price of a good-enough probability of finding the error on the first go.

...either way, my point is that we must extend the same grace and an extra order of magnitude of leeway to the softer generalization of software.

I will argue that this will make the software we know and love more powerful, and not less: they become the first line of deterministic compilation.

I dream of languages that formally describe reality; HDLs for materials, type systems for clock cycles. I dream of a higher-level language than the Python and Java of the old days: an informal language that looks to us as english, but to the model is yet another large punchcard to initialize itself from.