Essay · Software & Ideas

The Last Software Developer

On the brief human interval between symbolic code and computational substrate

Consider the figure. A person at a desk. A screen with a text editor open on it. A language with a name — Python, Java, C++, Rust, the catalogue is long and the catalogue changes — but the activity is reasonably constant across the entries on the catalogue. The person reads a specification, or hears one described, or assembles one in their head from a conversation with a colleague. They type. What they type is a sequence of characters that, after processing by a chain of tools whose details they only sometimes need to think about, produces a machine that takes inputs on one side and yields outputs on the other. They then write a second sequence of characters, called tests, that exercises the machine on a chosen set of inputs and verifies that the outputs match what was expected. When the tests pass, the code is pushed, the machine is deployed, and the figure moves on to the next problem.

This is the software developer as the field has known them for sixty years. The IDEs were designed for them. The languages were designed for them. The frameworks, the libraries, the package managers — the entire industrial substrate of the modern software industry was designed around this person, at this desk, doing this work.

What is less often said is that the figure is historically specific. The software developer exists in the form we know because three things were simultaneously true: the machine was fixed, the desired behaviour was variable, and the only way to make one responsive to the other was for a human author to express behaviour symbolically in a form that both the machine and other humans could read. That triad — fixed machine, variable behaviour, human-legible symbolic specification — is not a permanent condition of computation. It is a condition of computation during its textual phase. The essay is concerned with what happens as those conditions change.

The contingency of this configuration was understood before the configuration existed.

Ada Lovelace, writing in 1843 on Babbage’s proposed Analytical Engine, was the first to see past the machine’s apparent function as a number-cruncher. The Engine could operate on any domain susceptible to symbolic representation — not numbers specifically, but any subject whose relations could be expressed in formal notation. She noted that it might compose music of any degree of complexity. The logarithm table was an example of what computation could do, not a definition of what it was. That computation was not bound by any particular subject matter — that the same underlying engine could as readily manipulate the relations of musical harmony as the columns of an actuarial table — was clear to her in 1843, before there was a program, before there was a programmer, before there was a field to be the last member of.¹

Alan Turing, in 1936, proved something more fundamental: that the machine and its program are made of the same stuff. The universal Turing machine is a device that simulates any other computing machine by reading a description of it from its tape. Program and hardware are both symbol sequences; the distinction between them is an engineering partition, not a boundary of nature. Von Neumann embedded this insight in physical architecture — the stored-program computer keeps instructions and data in the same memory because, at the level of the theory, they are the same kind of thing. The division the field would later spend sixty years treating as foundational — software here, hardware there, developer on one side, machine on the other — was, from the very beginning of the theory, a convenience the theory had already dissolved. Within it, nevertheless, a figure appeared at a desk. Within it, a profession formed.²

Between the specified input and the desired output sits a region whose contents the figure is responsible for filling. That region is what the field calls code. Code is what the figure types, what the IDE displays, what version control stores.

But code is not the middle itself. Code is the human-readable notation in which the middle is described during the period when the machine underneath it is fixed and the person above it needs symbols to inspect. The middle — the actual transformation between input and output — exists independently of the notation in which it is described. It can be described as source code, as compiled bytecode, as assembly, as a hardware description language, as a bitstream configuring reconfigurable logic, as a set of weights and activations in a neural network, as a spatial arrangement of properties in adaptive matter. These are all middles. The textual phase of computation produced one predominant notation for them. The notation is not the thing.

The figure’s second activity is to verify the middle. The method is testing. Tests exercise the middle on a chosen set of inputs and check that the outputs match expectations. What this provides is finite empirical assurance: observation at selected instances, giving confidence where it has looked and silence where it has not. It is not statistical in any rigorous sense — the tested inputs are not drawn from a defined distribution, no confidence interval is computed, no probabilistic inference extends from the tried inputs to the untried. The middle was run on certain inputs, the outputs matched, and this finite observation has been accepted, for sixty years, as a sufficient basis for shipping software to people who depend on it. The question the test asks is narrow. It asks whether the middle, on the inputs that were tried, produced the expected outputs. It does not ask who wrote the middle, or how, or what principles governed its authorship. It asks only about the behaviour at the boundary, for the cases that were checked. The interior is not the test’s concern.

The first person to observe, from inside the practice, that this approach had a structural limit was Maurice Wilkes. Wilkes designed EDSAC, the first computer to run a stored program in regular operation, and he did so at Cambridge in 1949. What Wilkes and his colleagues discovered, once EDSAC was running, was not that writing programs was laborious. It was that getting programs right was unexpectedly hard. Debugging had to be invented — not the word, but the activity: the recognition that finding and fixing errors was a substantial, necessary, and permanent part of the work. Wilkes recalled, in his memoirs, the exact moment he realised that a large part of his life from then on would be spent finding mistakes in his own programs.³

What this meant was stranger than it first appeared. The machine did exactly what it was told — a perfect obedience engine. The difficulty was that the human author could not always know, in advance, what they had told it. The gap between the instruction one believed oneself to have written and the instruction one had actually written was where debugging lived. The machine was a mirror in which human thought discovered its own instability. Software was not hard because the machines were slow or the tools were primitive. Software was hard because human intention, once expressed in executable form, had a tendency to mean something subtly different from what its author believed.

Wilkes returned to this theme across decades of writing and speaking. The complexity of software systems, he observed, had grown towards the order of complexity found in the most complex objects known — the human brain, with its hundred billion neurons and its trillion synaptic connections. No engineering discipline had ever faced this, because nothing else humans had built had approached it. The field had reached a level of complexity that exceeded its understanding of itself.⁴

Edsger Dijkstra supplied the epistemological structure for what Wilkes had empirically encountered. In 1969, Dijkstra observed that program testing can be used to show the presence of bugs but never their absence.⁵ The figure writes tests. The tests pass. The middle has been observed to behave correctly on the inputs that were tried. Nothing about this licenses the claim that it will behave correctly on inputs that were not. The field accepted the argument, agreed it was important, and continued to test. It continued because the alternative — proof, the mathematical verification that the middle meets its specification for all admissible inputs — was too expensive for ordinary commercial development. Testing was the affordable approximation. The finite empirical check was the gate through which software passed into the world. Other gates accreted around it — review, static analysis, security audit, provenance, maintainability, style — but none displaced the boundary check as the decisive industrial ritual.

When the test is the only gate, the middle can be anything that passes the test. This is not a weakness in the testing framework. It is not an oversight that crept in. It is what the testing framework is. The test evaluates behaviour at the boundary. The interior is opaque to it by design. The test does not reach inside. It asks: given these inputs, does this middle produce these outputs? If yes, the middle is accepted. If no, it is rejected. The identity of the middle’s author, the language in which it was written, the reasoning or absence of reasoning that produced it — none of these are variables in the test’s evaluation.

A middle written by a junior developer who barely understood the problem passes a well-written test suite the same way a middle written by the most experienced person on the team passes it, if both produce the right outputs on the right inputs. The test does not know the difference and is not designed to. The figure at the desk was never privileged by the framework. The figure was evaluated at the boundary, like everything else.

The path to replacing the middle was not opened by artificial intelligence. It was opened the first time the field decided that passing a test was sufficient reason to accept a middle. Every test suite ever written, every CI pipeline ever configured, every deployment gate ever set to green on a passing build — each was a reiteration of the same structural commitment: we will evaluate the middle by its boundary behaviour, and we will accept any middle whose boundary behaviour matches. The commitment was reasonable. The cost of the alternative was prohibitive. But sixty years of that commitment have accumulated into a framework whose gate is structurally indifferent to authorship — which is to say, a framework that has been waiting, without knowing it, for a new kind of author.

Artificial intelligence walks through a door the field built for itself.

A large language model that produces code, given a specification and a set of tests, is doing what the figure has been doing all along: producing a candidate middle whose adequacy will be evaluated by the boundary check. If the tests pass, the middle is accepted. The framework has no other mechanism. The model fits not because the framework was designed for it but because the framework was designed around the test, and the test is indifferent to its author. What makes the transition faster than the field anticipated is that the model produces passing middles at lower cost than the figure, and is improving rapidly. But the speed is incidental. The framework offered no resistance to begin with.

The substitution is real; the industry is experiencing it. But it is the smaller event. The larger event is that the model is not software development’s replacement — it is software development’s front end. Consider what the model actually is: a learned function that maps a description of desired behaviour onto an artefact that approximately satisfies the description. For sixty years that artefact has been source code, because source code was the interface between human intention and machine behaviour. But nothing in the model’s architecture requires the output to be source code. The same learned translation can emit a hardware description in VHDL or SystemVerilog, a bitstream for a reconfigurable fabric, a set of constraints for a satisfiability solver, a topology for a neural accelerator, a configuration for a grown computational structure. Source code is one artefact. It is not the only one, and it is not the terminal one.

The figure at the desk has always worked above a fixed machine. The machine runs an instruction set defined by an architecture team, implementing micro-operations the silicon executes. The code the figure writes is compiled into instructions the machine executes. The machine does not change. The code does. That asymmetry — fixed machine, variable code — is what software is. Software is the variable layer running on a fixed substrate; hardware is the fixed substrate hosting the variable layer.

That asymmetry is not a law of nature. It is a condition of a particular era of computing, and the condition is dissolving.

A field-programmable gate array is a piece of silicon whose logical structure can be reconfigured by loading a bitstream. The same physical device can implement an arithmetic accelerator, a cryptographic pipeline, a signal processing chain, or a custom networking fabric, depending on the bitstream it receives. High-level synthesis goes further: it takes a description of desired computational behaviour written in C, C++, or Python, and generates a hardware description from it — the structure of the circuit, not instructions for a pre-existing circuit. Cloud FPGA deployments — from AWS’s FPGA instance families to AMD/Xilinx Alveo accelerator boards — mean that workload-specific computational structures can be synthesised, deployed, used, and discarded within the lifecycle of a single job.⁶

When a model emits a bitstream, or the HDL from which a bitstream is synthesised, it has not written software in the old sense. It has specified behaviour that has been realised as hardware. But the hardware is temporary, generated, and workload-specific. Calling it hardware is misleading — traditional hardware is durable, fixed, and reused across workloads. Calling it software is misleading too — it does not execute on a fixed processor. For the duration of the workload, it is the processor. A temporarily materialised behaviour. A computational form that exists as physical structure and then dissolves. The testing framework’s question — does the middle produce the expected outputs for the inputs that were tried? — continues to apply, because the question was always only about the boundary. The boundary remains even as everything behind it changes.

Software and hardware were never metaphysical categories. They were categories of fixity. Hardware was fixed structure capable of hosting variable behaviour. Software was variable behaviour expressed for a fixed structure. Software development was the human practice of describing that variable behaviour in notation both the machine and the human author could read.

When structure itself becomes variable — generated, synthesised, disposable on the timescale of a workload — the categories soften. The machine is no longer fixed and waiting for instructions. The machine is itself an artefact, shaped to the behaviour rather than housing it. The relationship between software and hardware, when one is generating the other in real time for a substrate that will cease to exist when the workload completes, is not the relationship the field’s vocabulary was designed to describe.

We do not yet have a name for the output of this process. It is not software in the sense of instructions for a fixed machine. It is not hardware in the sense of a durable physical structure. “Computational substrate” is the most sober term available, but it is a placeholder. The thing it names is real, increasingly common, and genuinely without settled description. The lack of a name is not a gap in our vocabulary waiting to be filled. It is a symptom of a category dissolving.

Beyond the reconfigurable silicon there is a further horizon, stranger than anything the textual phase anticipated.

In ordinary software, space is nominal. An address space is an abstraction. A namespace is a metaphor. The spatial terms that permeate software design — stack, heap, tree, graph, network, layer, container — name non-spatial relationships. When one writes software, physical distance is irrelevant. It does not matter, for the software’s behaviour, whether two variables occupy adjacent or distant addresses in memory, or whether two modules are deployed on the same server or different continents. Space, in conventional software, does not cause behaviour. It names relationships that have been given spatial labels.

In biological neural systems, space is causal. The location of a synapse relative to the soma of a neuron changes how that synapse’s input is integrated. The distance over which a calcium ion diffuses determines which dendritic compartments are affected by a local event. Dopamine-like neuromodulation propagates through spatial gradients in which concentration, and therefore effect, decreases with physical distance. The topology of the network — which neuron connects to which, through what pathway, with what delay — is not a description of the computation. It is the computation. Neuromorphic computing systems embody this: Intel’s Loihi, IBM’s TrueNorth, the BrainScaleS and SpiNNaker architectures are substrates in which spiking, spatial propagation, and local plasticity are the computational primitives. What happens where matters.⁷

In such a substrate, the idea of writing the middle becomes strained. One does not write a spatial field. One does not write a calcium-ion propagation pathway or the inhibitory network topology that produces a particular pattern of stable behaviour. One grows it, or constrains the conditions under which it grows, or shapes the environment that determines what it will grow into. The relationship between human intention and computational behaviour, in such a substrate, is not authorship. It is cultivation.

This is speculative in the sense that practical brain-like computational substrates are not yet commercial products. It is not speculative in the sense of being without scientific foundation. Neuromorphic silicon is available now in research deployments. Organoid computing — the use of biological neurons grown in culture as computational substrates — is early but real. What is not uncertain is that the middle, in such substrates, will not be expressed as text by a figure at a desk. The testing framework’s question — does the grown structure produce the expected outputs? — survives, because it was always only a question about the boundary. But the figure who once stood on the other side of that boundary, writing the middle, will have nothing to write.

The standard framing of what is happening — artificial intelligence is replacing software developers — is not wrong. It is too small.

The framing implies a job that remains intact and a worker displaced from it: one weaver leaves, a power loom arrives, weaving continues. But the power loom did not become a weaver. It reorganised textile production so that weaving ceased to be the occupational centre of gravity. The centre moved — to design, to fibre preparation, to quality control, to the institutional knowledge that specified what should be produced and why. A new kind of operative emerged, but what they did and how they did it bore only a family resemblance to the old craft.

The brain-like substrate does not become a programmer. It reorganises computation so that programming — the symbolic expression of variable behaviour in human-legible notation for fixed machines — is no longer what computational production centrally requires. The job does not pass intact from person to machine. The job loses its object.

The object was, precisely: variable behaviour expressed as human-legible symbols for a fixed machine. Once the machine is not fixed, once the behaviour need not be expressed symbolically, once the notation need not be human-legible, the job description has lost its content. What survives are the purposes the job served — ensuring that the computation does what it is supposed to do, for the people who depend on it — and those purposes persist into whatever follows. The practices that pursue them will not look like the figure at the desk. Same purpose. Different conditions. Incomparable practice.

The argument the essay has been making concerns the end of software development as a human occupation. But the end of software development is not the final event. It is the precondition for a larger one.

Computation has historically been rationed by the supply of people who could write software. That shortage was not a policy failure. It was structural: writing software well required skills that took years to acquire, were unevenly distributed, and could not be scaled without degrading what they produced. Every industry that wanted to digitise competed for the same limited pool. The domains that could not afford the cost remained analogue. The automation cases too complex or too expensive to build stayed unbuilt. The software engineer was the valve at which the world’s demand for computation was rationed, and the endless complaint about the shortage of them was not, at its root, a complaint about salaries or working conditions. It was a recognition that the valve was too narrow for the pressure behind it.

The useful measure of what changes when the constraint lifts is not work done — the labour expended building software — but work produced: computation actually deployed in the world, doing things. For sixty years these moved together. More computation required more software labour to produce it. Now they decouple. Work produced can scale exponentially, forgiven at last of the shortage that was always its binding constraint. The replacement that follows is therefore not software developers being displaced by AI. It is computation, freed from the bottleneck of human authorship, flowing into every domain that was previously behind that valve. Medicine. Law. Logistics. Science. Design. Manufacturing. Governance. Education. The work in those fields that was protected, incidentally, by the cost and difficulty of building software for it, finds that protection gone. Not software replacing other work. Computation.

As the cost of computational production tends towards zero, the implications extend beyond the labour market and into the structure of the market itself.

The Wealth of Nations was written for a world of scarce goods whose production required human effort and whose exchange was mediated by price. The division of labour, the invisible hand, the price mechanism as coordinator of dispersed knowledge and activity — these describe how scarcity is allocated when goods cost something to produce and markets are the institutions through which they are exchanged. Smith’s framework has organised economic life for two and a half centuries because its preconditions held: production required labour, labour was scarce, and price was informative about what it cost to have something done. When the cost of producing a computational output tends towards zero, those preconditions begin to erode. Goods that computation can produce do not carry exchange value in Smith’s sense when their production cost is negligible. The price mechanism for allocating them stops being informative. What remains as the binding scarcity is not the labour of the software engineer or the capital of the factory but the energy that runs the computation. The kilowatt-hour, not the human hour, becomes the unit around which economic life reorganises.

Smith, who was a moral philosopher before he was an economist, published a different book — earlier, and in his own estimation the more fundamental one. The Theory of Moral Sentiments appeared in 1759, from the same long philosophical project that would later produce The Wealth of Nations. Where The Wealth of Nations described how markets coordinate the self-interested pursuit of material goods, The Theory of Moral Sentiments described how humans govern their direct relations through sympathy — the capacity to adopt another’s perspective, to see oneself through the eyes of the impartial spectator, to seek not merely advantage but the warranted approbation of others. Smith revised this book throughout his life, most substantially in the year he died. He did not think it a preliminary sketch; he thought it the foundation. It has been treated, for most of the period since The Wealth of Nations eclipsed it in the curriculum of economics, as a curiosity — the book economists acknowledge and do not teach, the twin that the market twin outgrew. If the framework of The Wealth of Nations is the framework that erodes as computational abundance dissolves the scarcity on which it rests, the moral philosophy of The Theory of Moral Sentiments is not a curiosity. It is a foundation that was always there, and is about to become load-bearing.

The title belongs, at its limit, not to a practitioner but to a paradox.

The last software developer would have to be developing software. But the essay has been arguing that software, as a coherent category, is dissolving — into generated middles that are not written, into reconfigurable fabrics that are neither program nor circuit, into substrates where behaviour is grown rather than authored. At the moment when there is truly a last software developer, there is no longer any software for them to develop. The title and its referent expire together.

Software was variable behaviour expressed as human-legible symbols for a fixed machine. That description gave the category its content. Remove the fixed machine, and behaviour is synthesised directly into the substrate. Remove the requirement for human-legible symbols, and the notation the figure spent a career mastering becomes scaffolding for an author who has left the building. Remove the human author from the middle, and what remains at the boundary is the test — the question about outputs, the only question the framework ever asked — but not the thing the test was testing. Something is there. It produces the expected outputs. It passes the gate. It is not software.

The last software developer is whoever is standing at the moment when that recognition becomes unavoidable: when the word that named the work stops referring to anything coherent. Not the last person to write code. Not the last substrate to grow a middle. The last person at whose shoulder the idea of software still meant something distinguishable from computation itself. After that, there is no software to be the last developer of. The job description has lost not its holder but its noun.