When you can't press undo again
What happens when errors are expensive?
During my PhD, I wrote quite a lot of code in Mathematica. If you’ve ever used Mathematica, you’ll know that it used to have a pretty big quirk when it came to errors. Namely, you could only undo once. So if you rapidly changed a bunch of things in the code, then realised something was wrong, you’d only ever be able to unwind the last edit.
Over time, I noticed this constraint had a big effect on how I coded. If you know that you can’t rewind history, you become much more careful about decision making in the present. Coding becomes much more like a chess game, planning several moves ahead.
A few years after my PhD undoing adventures, Michael Lewis published a piece about software developers in investment banks. He noted that one group in particular stood out:
“Russians had a reputation for being the best programmers on Wall Street, and Serge thought he knew why: they had been forced to learn programming without the luxury of endless computer time. “In Russia, time on the computer was measured in minutes,” he says. “When you write a program, you are given a tiny time slot to make it work. Consequently we learned to write the code in a way that minimized the amount of debugging. And so you had to think about it a lot before you committed it to paper. . . . The ready availability of computer time creates this mode of working where you just have an idea and type it and maybe erase it 10 times.“
This efficiency of design can be traced to the earliest days of computing. If you’ve seen The Imitation Game, the film about Alan Turing’s work during the Second World War, you may have spotted a massive methodological error. In the film, they start the Enigma-cracking machine – known as the Bombe – as if it could somehow churn through all of the Enigma’s 10²³ possible settings in a matter of hours. It’s only later in the film that the eureka moment arrives, and they add a crib, i.e. a guessed fragment of plaintext. For example, they’d look for WETTER (‘weather’ in German) in a daily weather report.
But in reality, entire decryption process was designed around cribs. The Bombe was then set to test millions of possible rotor combinations against a crib, systematically ruling out the vast majority until only a handful remained. Far from running pointlessly on hope, and then hitting on some inspiration, it was purpose-built to reduce an otherwise astronomical problem to something human cryptanalysts could finish by hand.
The undoing project
Over time, the price of running – and iterating – code has become cheaper. As well as access to better software environments and easier computation, we have seen the rise of AI tools that can help write and edit the code itself.
But is this a good thing? Ultimately, the hardest part of building software or models isn’t writing code; it’s deciding what to build and how to build it. That’s why the rise of AI code generation doesn’t mean machines are suddenly great software engineers. The real work is architectural: validating methods, shaping inputs and outputs, ensuring efficiency, anticipating failures, and planning tests. And much of this thinking happens before fingers touch a keyboard.
The thought process that happens before writing a line of code is generally where the skill lies. It is also where there are most opportunities to learn how to make tools more efficient and effective.
In a recent piece, Daisy Christodoulou highlighted the risks of humans offloading mental effort when it comes to learning simple tasks, especially if the hope is to get better at advanced projects:
“You also shouldn’t pretend that by cognitively offloading a task, you will magically get smarter because you can focus on more advanced and complex skills. More advanced and complex skills are based on simpler ones. If you don’t have the simpler skills, you can’t develop the more advanced ones. You can’t think strategically about chess unless you know how the pieces move. And the cognitive offload makes it less likely we will get the practice that lets us acquire the basic skills.”
Ironically, the era of AI-assisted coding is resurfacing the hard-to-undo problem. Without strict instructions, close guardrails and careful reviews, coding agents can quickly turn a neat code base into a spaghetti tangle of new functions and files. In some cases, tools have even wiped out entire databases – effectively allowing zero undo steps.
Overall, I’m glad for the rise of AI-assisted coding options, as well as for platforms like GitHub, which can manage different versions of code and their histories, even with numerous collaborators. Now more than ever, it’s possible to rapidly prototype new ideas – as well as look back and work out what went wrong. But I’m glad that my early PhD experiences also forced me to develop the habit of looking ahead before that happens.
Cover image: Bob Lord via WikiCommons
Another example that I think is similar. Recently spoke to a friend who is an editor at an academic publisher about AI concerns in publishing. He made a comment to the effect of, “the table of contents is the most important part of writing a book. An author has to decide what goes in and what is left out. And, in what order should you organize the ideas. That’s where expertise lies.” Designing a project is different than writing code, and designing the ToC is different than writing a book (as in putting words on a page). Right now LLMs would do a crap job on both of those first steps where true expertise is needed. And, related to another point you make, you develop expertise in part by the second steps of coding and writing.
Getting it right the first time is even more important in another field: the architectural level of engineering. That means high level conceptual design before coding begins. That's what I did for many years. The architecture spec MUST be correct. Otherwise, errors show up later when they are MUCH more expensive to fix. If you get it right the results are amazing.
The alternative is what we call BITIFY: build it, try it, fix it.
(There's a British expression that something is "a bit iffy.")
BITIFY tends to produce suboptimal or simply wrong solutions.