Szymon Wilczek

The Cycle of New Software: On Operative Simulacra

Published: Reading Time: ~10 min read · 1886 words Category: Philosophy Tags: philosophy, epistemology, ontology, ai, software-engineering

The Operative Simulacrum and the Confession at the Buffer#

Let me begin by dismantling the moral pedestal before anyone else has the satisfaction of doing it for me.

I am not an off-grid ascetic crafting software on an unnetworked terminal. I use modern large language models daily. I prompt Claude, I explore neural code generation, and I appreciate the astonishing mechanical leverage these systems provide.

If anyone wishes to cross-reference this with my recent reflections on unavoidable hypocrisy and accuse me of pontificating from a compromised pulpit - by all means, take the shot. I accept the contradiction with open arms.

Yet acknowledging leverage does not dissolve the quiet, persistent unease that settles over the room when the terminal screen goes still.

When Jean Baudrillard articulated his genealogy of the simulacrum 1, he examined signs that had severed their relation to underlying physical reality. In Baudrillard's taxonomy, the simulation precedes and determines the real. Yet his analysis remained bounded by a classical media ontology: representations were passive. A broadcast, an advertising billboard, or a suburban theme park could manipulate human perception, but none possessed autonomous causality.

Generative software invalidates this passivity.

What emerges when I prompt an LLM is an operative simulacrum. It exhibits every formal signifier of deliberate human design: strict typing, asynchronous concurrency primitives, cryptographic assertions, and schema definitions. It compiles; it binds to physical network interfaces; it consumes electrical wattage; it mutates persistent state across disks.

Yet it refers to no underlying act of human deliberation. No engineer wrestled with the physical constraints of the domain; no user necessitated its existence; no living mind weighed its structural trade-offs.

It is necessary here to distinguish the operative simulacrum from both traditional automated compilation and technical debt:

  • A compiler performs deterministic, mathematical transformations of explicit human intent from high-level semantics to machine instructions. The intentionality remains strictly anchored in the human author.
  • Technical debt represents conscious compromises made by human engineers who understand the ideal architecture but defer implementation due to economic constraints. The debt is recognized, measurable, and conceptually bounded.
  • The operative simulacrum, by contrast, incurs what must be termed Epistemic Debt: the compounding distance between the operational behavior of an executing program and the capacity of any living mind to account for its internal necessity.

Epistemic Debt is not the presence of bugs; it is the presence of functioning code whose correctness cannot be verified through reason, but only through empirical observation of its failure to crash.

Rule-Following Without a Form of Life#

To grasp why the operative simulacrum destabilizes engineering, one must turn to the rule-following paradox formulated by Ludwig Wittgenstein in Philosophical Investigations 2.

Wittgenstein demonstrated that no course of action could be determined by a rule, because every course of action can be made out to accord with the rule. What anchors a rule - what prevents interpretation from collapsing into arbitrary divergence - is participation in a shared form of life (Lebensform). A rule is sustained by a community of practitioners who correct errors, share stakes, and establish normative agreement through collective practice.

A neural model does not participate in a form of life.

It possesses no physical embodiment, experiences no vulnerability, and bears no exposure to the consequences of execution. When a model emits an algorithm for a distributed consensus protocol or an inverted index, it is not "following a rule" in the normative sense. It is producing a statistical continuation across a high-dimensional latent space.

When we deploy code generated in this vacuum, a profound displacement occurs:

In the absence of a shared form of life between the generator and the execution environment, the concept of correctness ceases to be normative. It collapses into mere operational persistence: the code is treated as correct simply because no unhandled exception has yet terminated the process.

We no longer evaluate software through semantic justification. We observe it behaviorally, as one might observe the weather or an uncontacted biological organism.

The Dissolution of Brooks' Dichotomy#

For nearly forty years, software architecture relied on the foundational distinction proposed by Fred Brooks in No Silver Bullet 3: the separation between accidental complexity (the mechanical friction of syntax, compilers, and manual memory management) and essential complexity (the conceptual essence of the domain entities, relationships, and invariants).

Brooks assumed that accidental complexity was a contingent tax on human cognition. By automating accidental friction, the engineer would finally be liberated to engage with pure essential complexity.

The reality of generative computing shatters this assumption.

Generative models do not simply eliminate accidental friction; they fabricate synthetic essential complexity.

When an engineer prompts an entire backend architecture, the model does not merely write the syntax - it invents the domain entities, specifies their relationships, constructs the middleware validation rules, and designs the persistence schema.

The developer does not engage with the essential complexity of the problem. Instead, the developer is presented with an already materialized conceptual framework that appears coherent, but whose internal trade-offs were never deduced from real-world requirements.

Historically, comprehension preceded implementation: you understood the domain, and therefore you wrote the code. In generative engineering, implementation precedes comprehension: the system exists, runs, and functions, leaving the human in the bizarre position of having to reverse-engineer an architecture they theoretically "authored".

Epistemic Bankruptcy at the Ninety-Percent Cliff#

Why does the contemporary developer universally abandon generative projects at the ninety-percent mark?

Tom Cargill's Ninety-Ninety Rule 4 - stating that the last ten percent of the code accounts for ninety percent of the development time - is typically treated as an empirical quip about project management.

In the era of generative scaffolding, the Ninety-Ninety Rule is an ontological threshold: the point at which accumulated Epistemic Debt suddenly comes due.

During the initial phase of a generative project, development velocity is asymptotic. The developer prompts, the model emits, and hundreds of files materialize without cognitive friction. Epistemic Debt is incurred with every token: dependencies are imported without architectural review; database constraints are established without operational testing; failure states are glossed over by default exception handlers.

As long as the project remains in local development, this debt is costless. The application runs in a vacuum of simulated utility.

The ninety-percent cliff is the exact moment the system touches reality:

  • When real network partitions violate the generated assumptions of consistency.
  • When an edge case in user input exposes an untested data model invariant.
  • When production state mutations require an idempotent migration that cannot be prompted away.

To cross the threshold requires paying the accumulated Epistemic Debt in the only currency that exists: deep, unhurried, manual cognitive labor.

Yet because the builder invested no personal friction in the construction of the system, they possess no emotional or cognitive equity in its survival. Abandoning the repository is therefore not an act of laziness; it is an entirely rational economic default on unpayable epistemic debt.

Opening a new tab and prompting a fresh repository is the technical equivalent of filing for cognitive bankruptcy.

Radical Reversal: Myth of Prior Mastery#

At this point, a critical objection must be confronted - one that destabilizes the very foundation of the traditional engineering critique.

The classical narrative laments that AI is destroying the engineer's deep mental model of the machine. But this complaint rests upon an unexamined historical fiction: did the software engineer ever truly possess a total mental model?

Consider the modern computing stack in its brutal material reality:

  • A contemporary x86 or ARM CPU is not a deterministic instruction executor; it is an asynchronous, speculative supercomputer running proprietary, closed-source microcode that dynamically rewrites machine instructions, speculates on branch paths, and manages out-of-order execution across hidden register files.
  • The Linux kernel comprises tens of millions of lines of C and assembly, coordinating millions of concurrent state transitions across heterogeneous memory topologies. As a kernel contributor, I know intimately that no single contributor, maintainer, or subsystem architect comprehends the totality of its execution paths.
  • Compilers such as LLVM perform dozens of layered optimization passes whose collective interaction is mathematically intractable to any individual human mind.

The belief that the pre-AI engineer possessed complete cognitive mastery of their systems was always an illusion. It was a useful, comforting fiction sustained by the slow pacing of manual syntax construction.

Manual coding did not grant total comprehension; it just provided cognitive compression. Writing a C loop, designing font metrics, or allocating a buffer by hand gave the practitioner the subjective sensation of control, even while executing on hardware and operating systems whose complexity had long since surpassed human cognitive bandwidth.

Generative AI did not destroy human mastery over computing. It dismantled the slow, ritualized pacing that allowed us to pretend that mastery was real.

Antiquarian Trap and the Final Aporia#

This realization forces the low-level craftsman into an uncomfortable self-interrogation.

When I retreat into my custom Emacs configuration, or audit pointer arithmetic in C, am I genuinely defending human agency - or am I seeking refuge in an antiquarian coping mechanism?

To claim that manual syntax construction possesses intrinsic moral superiority is indistinguishable from claiming that hand-carving wooden gears possesses intrinsic moral superiority over industrial metallurgy. It confuses an authentic personal aesthetic with a systemic virtue. It is the digital equivalent of spinning wool on a hand loom while industrial automated mills clothe civilization.

If software systems can be generated, optimized, and patched by stochastic models at velocities and scales that human coordination cannot match, then the human programmer is no longer the indispensable cognitive linchpin of technical progress.

We are approaching an inflection point where the insistence on individual human comprehension becomes an operational bottleneck.

This is the ultimate aporia of contemporary software engineering:

We are compelled to use these tools because the systemic scale of modern computing demands them. Yet the more we rely upon them, the more we accelerate the evacuation of human reason from the technical infrastructure of civilization.

For me, the personal dividing line remains narrow but uncompromising.

I will continue to use large language models. I will continue to prompt them for AST transforms, build pipeline optimizations, and boilerplate acceleration. But I refuse to confuse generative throughput with authentic creation.

The true test of a tool is not whether it was prompted in fifteen seconds or hammered out over sleepless nights.

The test is whether, long after the initial dopamine of the prompt has dissolved, there remains a human being who understands why the system exists, accepts direct accountability for its execution, and possesses the quiet fortitude to stand behind it when the server fails at two in the morning.

As always:

Signed-off-by: Szymon Wilczek <[email protected]>

Footnotes

1

Jean Baudrillard, Simulacra and Simulation (Paris: Éditions Galilée, 1981; translated from French by Sheila Faria Glaser, Ann Arbor: University of Michigan Press, 1994).

2

Ludwig Wittgenstein, Philosophical Investigations (Oxford: Basil Blackwell, 1953; translated by G. E. M. Anscombe).

3

Frederick P. Brooks Jr., "No Silver Bullet-Essence and Accidents of Software Engineering," IEEE Computer, Vol. 20, No. 4 (April 1987).

4

Tom Cargill, "The Ninety-Ninety Rule," as quoted by Jon Bentley in "Programming Pearls: Bumper-Sticker Computer Science," Communications of the ACM, Vol. 28, No. 9 (September 1985).


Plain Text Source: the-cycle-of-new-software
Open raw buffer Download .org
M-x 0/0

[ Keybindings & Navigation ]

M-x / Alt+x Open Emacs command runner
Shift + W Jump to writings & essays (/writings)
Shift + P Jump to software projects (/projects)
Shift + F Jump to files & archives (/files)
Shift + T Cycle color theme
Shift + B Cycle serif font
j / k Scroll down / up
g g Scroll to the top of page
Shift + G Scroll to the bottom of page
? Toggle this keybindings help cheat sheet
Esc / C-g Dismiss modal or close active menu