Software Engineering

In Raising the Floor Again I wrote that the documentation is no longer a courtesy to the next human. It is load-bearing input to the thing that does the work. If the words are load-bearing, then they are the material, and engineers do not leave material to chance. We engineer it. Donald Knuth saw the shape of this in 1984. “Let us change our traditional attitude to the construction of programs,” he wrote. “Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.” He named the practice literate programming: the program as an essay, with the working code extracted mechanically from the prose (Knuth, 1984). The practice won a devoted minority and lost the field. Writing for human readers carried no enforcement, and the readers skimmed. The reader we write for now does not skim. It reads every word, resolves every ambiguity by guessing, and acts on what it reads with tools and credentials attached. The essay Knuth wanted the field to write has found an audience. It is simply not the audience he had in mind. ...

I ended this essay with a pattern rather than a prediction. Someone raises the level of abstraction so that more people can build more things with less ceremony. The people who mastered the older, lower level object that the new level hides too much and understands too little. The new level turns out to be useful anyway, its rough edges get sanded down over a few years, and it becomes the unremarkable ground that the next generation stands on. Then someone proposes to raise the floor again. I am watching the floor rise now, in my own career, and this time the pattern has a wrinkle I did not fully sit with before. Every earlier layer still expected a programmer to write the layer above it. FORTRAN expected formulas. C expected C. The compiler translated what a person had already composed. The layer arriving now inverts that. The artifact a person hands down is a description in something close to English, and the thing standing on that description and turning it into running behavior is not a junior engineer but a machine that read a great deal of code and can write more. ...

For the past week or so I have been doing a peculiar kind of engineering. I have been extending an AI assistant, and I have been doing it with the assistant. Not by feeding it into an editor as a source file, but by sitting across from it, describing what it was missing, and letting it write the code that would connect the new capability back into itself. The distinction sounds like a technicality. It is not. It is most of the point, but first, the two things I set out to give it. ...

Every era of programming has been an argument about the same thing. How much of the work should the human do, and how much should we hand to the machine? Each time we have answered “give more to the machine,” someone has objected that the machine cannot be trusted with it, that real programmers work closer to the metal, and that the new convenience is a toy. And each time, within a decade, the convenience has become the floor that the next generation of programmers stands on without a second thought. This is a story about that floor rising. It runs from a woman feeding subroutines to a UNIVAC on tape in 1952 to a teenager in 2026 building a working web application by describing it to a language model in English. The technologies could not look more different. The motive behind them is identical. ...