La, la, la

I hear the same conversation everywhere lately. In WhatsApp groups of old colleagues, over coffee with people I have built products with, at the end of dinners that started on something else. Someone shares a demo, someone answers that it is all hype, and someone says, half joking, that in five years there will be nothing left for us to do. Nobody laughs very much.

The people saying it are rarely beginners. They are veterans: people who have kept systems alive for twenty years and know the material better than almost anyone. That is precisely why the tone stays with me. When people who know the trade this well feel the floor moving, the feeling deserves more than a slogan in reply.

It also deserves a little more history than it is getting.

Two ways of covering your ears

In July, in a long thread on the kernel mailing lists about wiring an AI review tool into the kernel's patch workflow, Linus Torvalds lost patience with the people who still doubted these tools were useful:

"There are other questions around AI (like what the economy of it will actually look like in the end), but 'is it useful' is no longer one of those questions. Anybody who doubts that clearly hasn't actually used it."

— Linus Torvalds, Linux kernel mailing list, July 2026

He conceded the costs in the same email. The tools add to maintainers' workloads and keep finding embarrassing bugs. But the answer, he wrote, "is not to put your head in the sand and sing 'La La La, I can't hear you' at the top of your voice like some people seem to do."

That is the first way of covering your ears, and it is the one I hear over coffee. It is the reply that the demo is cherry-picked, that real systems are different, that it will all blow over. Some of it is true. None of it survives a week of actually using the things.

There is a second way, and it is noisier. Terence Tao described it last week in an interview with Numberphile, days after OpenAI released around three hundred machine-generated mathematical papers in one go. The dominant mood, he said, is "no one understands anything, let's just keep accelerating." It also sings to itself so as not to hear. What it refuses to hear is the question of whether anyone still knows what is going on.

The title of this piece is meant for both choirs.

Two axes

Tao has thought about this longer and more calmly than most, and his framing is the most useful I have found. He sees two axes along which mathematics can progress.

One is understanding: whether humans grasp what is going on. The other is technology: whether the work is done with pen and paper or with tools.

For thousands of years progress happened along the first axis, because the tools could not solve problems. Now they can, and the question is whether we adopt them "while holding on to our understanding" or sacrifice understanding in order to use them.

For most of history, progress ran up the understanding axis. From here, the tools can carry us far along the other one, with understanding or without it.

His analogy is the car. When the automobile arrives, you can stop walking altogether, or you can find a balance in which you sometimes drive and sometimes walk. One path, he says, is dysfunctional; the other is exciting.

I should declare an interest. I have cycled to work every day for as long as I can remember, so the analogy lands closer to home than Tao could know. The bike has never made me suspicious of cars. It has taught me things a car does not: where the slopes really are, how long the city actually takes to cross, which streets the map gets wrong. The car gets you further; the bike tells you where you are.

The bike, parked at the Dcycle office. An hour there in the morning and an hour back in the evening, every working day: two hours a day of knowing exactly where the slopes are.

The habit has leaked into how I work. With the people on my team I prefer a walk and talk to a one-to-one: we leave the office and talk while we walk and get some air. Nobody presents anything and nobody shares a screen. The conversation drifts toward what is actually happening, at the pace at which it can be understood. It is the slowest meeting format I know, and the one in which I learn the most.

What I like about the framing is that it refuses both choirs at once. It does not ask you to choose between the tool and the craft. It asks what the craft was for.

In mathematics, the answer was never the proof itself. The proof was the visible residue of understanding, and the understanding is what grew the field. Tao calls the present the passage from proof scarcity to proof abundance, and his worry is not the abundance. It is that "we're drowning in proofs, but we're not getting all the understanding that we used to get."

He is not nostalgic about it. He admits that the heroic era was slow, inefficient and full of winners and losers. His question is plainer: "what can we keep that's valuable and what can we let go of?"

The word computer was a job

Software people should recognise that question, because we have answered it before, several times, usually badly at first. Torvalds put it in its sharpest form last week. A kernel maintainer had proposed requiring hand-written commit messages, to keep machine-written ones out. Torvalds answered with a rule of his own:

"Here's a new rule just for you: don't use compilers for any of your kernel submissions.

Because if you can't show that you really understand what the machine is actually doing by writing your code in assembler, then I don't want to see your code contribution. You clearly aren't competent if you can't write it that way.

And btw, you had better not use an editor to write that commit message either.

Because I need you to show me that you can actually write a good commit message without using tools that make it easy to backspace and hide the mistakes you made while typing.

Ok?

Because otherwise those tool-assisted commits of yours clearly aren't showing that you know what you are doing.

Do you not see how UTTERLY STUPID those kinds of rules would be?"

— Linus Torvalds, Linux kernel mailing list, October 2026

The joke works because it is a history lesson. Every generation proposes some rule of the form "don't use the new tool for X," and the next one finds it as strange as a ban on compilers. The compiler was the new tool once. Before it, even the computer was a person.

Until the 1950s, that was literally true. NASA's predecessor employed rooms of them, mostly women, who did by hand the calculations that flight research needed. When electronic machines arrived, the job title passed to the machine. Some of the people passed somewhere else. Dorothy Vaughan, who had supervised the West Area Computers at Langley, "became an expert FORTRAN programmer," in NASA's own words. The work did not vanish. It climbed a floor.

Computers at NACA Langley, 1951, testing a handbook of methods for their Monroe calculators. The job title would soon belong to a machine. Photo: NACA / NASA Langley Research Center (Bill Taub), public domain.

Grace Hopper had a working compiler in 1952. "Nobody believed that," she recalled decades later. "I had a running compiler and nobody would touch it. They told me computers could only do arithmetic." Compilers were not yet called compilers. They were called automatic programming, and the promise was exactly what it sounded like. The 1954 report that announced FORTRAN said it "should virtually eliminate coding and debugging."

Grace Hopper at the UNIVAC I with colleagues from Remington Rand's Automatic Programming Department, 1957. The department's name was the promise. Photo: Smithsonian Institution (SI Neg. 83-14878), CC BY 2.0, via Wikimedia Commons.

John Backus, who led that project, revisited the report in 1978 with an honesty I wish were more common in our trade. He quoted the line about eliminating debugging and added, simply, "[!]". He also described what programmers thought at the time: they "rightly regarded their work as a complex, creative art that required human inventiveness," and they were convinced that "efficient programming was something that could not be automated."

They were right about the art and wrong about the automation, and both things turned out to matter. FORTRAN automated a layer. The art moved to the layer above.

An IBM 704 at NACA Langley, 1957: the machine FORTRAN was written for, in the same laboratory that had employed rooms of human computers. Photo: NASA, public domain.

The pattern repeated with every generation of tools.

In 1982 James Martin published a book whose title would fit comfortably in any of those conversations: Application Development Without Programmers. Its preface predicted that "many DP professionals and, not surprisingly, programmers will instinctively resist" its methods. Four years later Fred Brooks, quoting David Parnas, offered the deflating summary: "automatic programming always has been a euphemism for programming with a higher-level language than was presently available to the programmer."

The cover of Martin's 1982 book. Each brick of the wall between user and programmer has a name: specification freeze, multi-year application backlog, slow programming in COBOL. The tools changed; the wall is still a good description of most backlogs.

And the profession, meanwhile, did not shrink. The US Census counted about 450,000 computer workers in 1970 and 4.6 million in 2014. That figure covers every computer occupation, not only programmers, and I would not hang much on its precision. The direction is enough.

The ones who walk in

At the Open Source Summit in Prague this month, Torvalds added something to the July email that I had not heard from him before. He started programming around 1981, he told Dirk Hohndel, when computers were simple enough to understand and the programs you compared yours to were simple too. "The bar in software engineering has grown so high that it's hard to see your own small efforts as worth anything." For someone starting now, he said, vibe coding is "a wonderful way to find joy in programming," and he likes the idea of AI as a gateway drug.

That is the half of the story the coffee conversations miss. The people who feel the floor moving are the ones who stand on the current floor. The people who welcome a new layer are usually the ones for whom the old layer was a wall. I suspect it has always been so: an abstraction looks like a threat from above and like a door from below.

The same talk contains the other half. Torvalds described using AI for a toy project of his own, a guitar pedal whose interface, written in C, looked "like something from the '80s." He gave the model the prompt everyone gives after watching the videos, and the result "was horrendous." What worked was the next step: "Hey, look! I already did this in C. I did it the right way. It's just ugly." He brought the understanding; the tool brought the part he was bad at. "I think that you need to be very careful using AI when you're doing something real and important," he added. Gateway and caution in the same conversation, from the same person. That is Tao's balance, told by an engineer.

What history does not promise

It would be easy to stop here and tell my friends to relax. That would be the first choir again, in a more learned key.

The history of automatic programming shows that the work moved up. It does not show that it moved up by itself. Every layer of abstraction left behind a layer that someone still had to understand. Compilers did not abolish the need to know what the machine was doing; they concentrated it in fewer people, who wrote the compilers, tuned the kernels, chased the bugs nobody else could reproduce.

Edsger Dijkstra saw the general point in the late 1970s, in a note against the dream of instructing computers in plain English:

"In order to make machines significantly easier to use, it has been proposed (to try) to design machines that we could instruct in our native tongues. this would, admittedly, make the machines much more complicated, but, it was argued, by letting the machine carry a larger share of the burden, life would become easier for us.

It sounds sensible provided you blame the obligation to use a formal symbolism as the source of your difficulties. But is the argument valid? I doubt. We know in the meantime that the choice of an interface is not just a division of (a fixed amount of) labour, because the work involved in co-operating and communicating across the interface has to be added.

We know in the meantime —from sobering experience, I may add— that a change of interface can easily increase at both sides of the fence the amount of work to be done (even drastically so)."

— Edsger W. Dijkstra, On the foolishness of "natural language programming" (EWD667)

Somebody has to stand at the interface and understand both sides.

The right criterion is in the same email from Torvalds: "I expect people to understand what they are doing. But that understanding has very little to do with what tools they use."

I agree with every word. The difficulty is that understanding does not keep itself either. Tao's interview is, among other things, a list of the ways it erodes. The companies optimise for "speed and output and performance… above everything else."

The cost of checking the output falls on people who did not ask for it: of three hundred papers he had read about ten, some brilliant, many "still incomprehensible," a couple already retracted, and nobody from the company helping. "We have this pile of stuff to go through," he said, "which we didn't ask for." Any kernel maintainer would recognise the sentence. So would anyone who reviews pull requests for a living.

Walking

The most interesting example of the week came from a physicist. Emre Onur Kahya, a professor at Istanbul Technical University, asked an AI model to re-derive, step by step, a quantum gravity calculation he had published with Richard Woodard in 2007. It was the work of his doctorate.

The model found a sign error and a missing term, and confirmed that the physical conclusion survived. He published everything in an open repository, with a method I would happily frame and hang in any engineering team: the printed equations were used as "inputs, not targets," compared only after the derivation was finished. The repository even has a section on what a human expert should still review.

That is what walking looks like with a car parked outside. Kahya did not refuse the tool, and he did not hand it his understanding. He used it to test what he understood, and he wrote down where the testing stops. His own question on social media was what the word effort will mean in academia from now on. I suspect it will drift toward this: less the hours spent producing a result, more the care spent knowing whether it is true.

There is a part of Tao's interview that should worry the software industry more than any benchmark. Mathematics, he explains, used to reserve a certain kind of problem for students: medium difficulty, solvable by a senior person, but left alone so that the next generation could learn on it. Those are the problems the machines now take first.

Our trade has the same reserve. It is called the junior ticket: the small feature, the modest bug, the migration nobody senior wants. It is where people learn how systems actually behave. If we automate that layer without designing a different path into the craft, we will not run out of work. We will run out of people who understand the layer below.

Tao's answer for education is old-fashioned and correct. We teach children arithmetic by hand before we give them calculators. Hand arithmetic is not how adults should compute. It is how they come to understand what the calculator is doing. Every software organisation will need its own version of that rule, and very few have written one.

Back to the coffee

The next time the conversation comes up, I will not tell my friends that everything will be fine, because I do not know that, and nobody does. I will not tell them that the tools are hype either, because they are not.

I will ask them something closer to Tao's question. Not whether there will be work for us in five years, but which part of what we do we actually understand, and which part we only knew how to type. The first part travels with us to whatever the next layer is. The second was always going to be automated by somebody.

And since I will probably have arrived by bike, I will offer the only practical advice I have, which is about transport.

Take the car when the distance is long and the road is well known. Walk when you need to see the street. And now and then, on the days when it costs you a little, pedal: up the slope you could have avoided, through the problem you could have delegated, only to keep knowing where the slopes are.

Hopper, Backus and Martin would recognise the conversation. Sixty years on, it is a little late to sing over it.