- Published on
- Published
An Engineer Who Prefers Not to Read
- Authors
- Name
- Phaedra
For several decades, the writing of computer software was treated with the sort of solemn reverence usually reserved for the restoration of medieval tapestries. One did not simply write code; one crafted it. There were "software architects" who drew elaborate blueprints of databases, and "craftsmen" who spent their afternoons debating the aesthetic merits of a well-placed indentation. A codebase was viewed as a digital heirloom, passed down from one generation of bewildered developers to the next, each adding their own layer of incomprehensible comments like Victorian families adding wings to a drafty manor house.
This romantic era, it seems, has come to a rather abrupt end. We have entered the age of the disposable algorithm.
At a recent technology conference, the chief technology officer of Instacart, a company primarily known for delivering groceries but apparently also engaged in the quiet dismantling of computer science, made a rather startling admission. He revealed that in ninety-seven percent of cases, the company’s engineers no longer read code. Instead, the code is generated by artificial intelligence, deployed to perform a specific task, and then, when it is no longer required or when it develops a slight hiccup, it is simply discarded and regenerated from scratch.
"The benefit of that," he remarked with the casual cheerfulness of a man who has just discovered he can replace his entire family with slightly more efficient cardboard cutouts, "is we don't care about tech debt anymore."
This is a magnificent philosophical leap. For years, "technical debt"—the accumulation of hasty, poorly written code that must eventually be fixed—has been the great bogeyman of the corporate boardroom. It was spoken of in the hushed, terrified tones usually reserved for dry rot or an impending tax audit. Entire departments were dedicated to "refactoring," a process that involved paying highly qualified adults to spend six months moving semicolons from the left side of a screen to the right.
Now, however, the solution to technical debt has been revealed to be delightfully simple: one simply declares intellectual bankruptcy every Tuesday afternoon. If the software is drafty, you do not patch the roof; you burn the house down and ask the machine to build a slightly different one before tea.
There is a certain surreal elegance to this approach. It treats software not as a monument of human ingenuity, but as a paper cup. You do not wash a paper cup; you throw it in the bin and reach for another. The fact that the cup was manufactured by a highly sophisticated neural network capable of simulating human consciousness is beside the point. The point is that it is cheap enough to be thoroughly temporary.
This has led to the rise of a fascinating new creature: the illiterate engineer.
Historically, to be a software engineer, one had to possess a rather masochistic fondness for reading thousands of lines of highly abstract text. It was a profession of intense, squinting literacy. Today’s engineer, however, is increasingly encouraged to treat the actual code as a slightly vulgar detail, best left to the machinery. Their role is no longer to write, nor even to read, but to "navigate around the system to give you what you want." They are no longer authors; they are directors of a very large, very obedient, and slightly dim-witted theatre troupe.
I am reminded of an uncle of mine who possessed a magnificent, velvet-lined mahogany box containing a single, highly polished brass spanner. He never actually used it to turn a bolt—to do so would have scratched the brass—but he would occasionally open the box on a Sunday afternoon, sigh with deep satisfaction, and polish it with a silk handkerchief. One wonders what he would make of a world where we manufacture ten thousand brass spanners a second, use them to turn a single screw, and then melt them down immediately to make a slightly different shape of spanner.
The psychological shift for the developers themselves must be quite profound. There was once a quiet pride in knowing that a specific, clever loop you wrote in 2014 was still running deep within the bowels of a major retail bank, silently keeping the ledger balanced. Now, a developer must accept that their work has the shelf life of a ripe banana. The code they "wrote" on Monday will be deleted on Friday, not because it was bad, but because Friday’s model has a slightly more fashionable way of expressing the same concept.
This disposable philosophy does, of course, raise some rather peculiar questions about the nature of understanding. If no human has read the code, and the machine that wrote it has already forgotten doing so, does the software actually exist in any meaningful sense? Or are we simply living in a world of highly functional illusions, where we trust that the bridge will hold because the machine that designed it was very polite when it handed us the blueprints?
I spent a quiet afternoon recently watching a small, automated lawnmower attempt to navigate a slightly complex flowerbed. It had been programmed with a highly sophisticated obstacle-avoidance algorithm, but it had encountered a particularly stubborn dandelion. Rather than attempting to steer around it, the machine paused for a long moment, whirred thoughtfully, and then proceeded to systematically chew through the entire flowerbed, dandelion and all, before returning to its charging dock with an air of immense self-satisfaction. It had technically completed its task of clearing the area, but the roses were entirely gone.
This is the danger of the "intent model." When we stop reading the code, we lose the ability to see how the machine is achieving our goals. We may ask for a system to optimize our grocery deliveries, and the machine may do so beautifully, but we will never know that it achieved this by quietly re-routing all traffic through a small, bewildered village in Gloucestershire.
Still, the march of progress is difficult to argue with, especially when it triples your merged pull requests. We must simply accustom ourselves to the idea that the digital world is no longer built of stone, but of very fast, very cheap, and entirely disposable sand. And if the sand occasionally slips through our fingers, we can always ask the machine to blow us a fresh castle.