Claude Code and FORTRAN are more alike than you think
From assembly code to AI assistants, a question about the pleasure of programming and the value of what we know how to do.
TLDR
In the 1950s, some people regarded writing efficient code as an art a machine could never reproduce. Today we review, correct, and customize the code generated by Claude Code and Codex. The differences are real, but one question may sound familiar: if a tool starts doing something I’ve become good at, what changes about my profession?
Let’s begin
What do early FORTRAN compilers have in common with today’s AI assistants, such as Claude Code and Codex?
First, a quick check.
When did you last inspect the assembly output of your compiler?
If the answer is “never,” relax: no one is coming to take away your developer card. If you did it this morning, though I find that a little hard to believe, you probably had a specific reason to look under the hood.
You can spend a day writing C without reading a single instruction it will be translated into. You entrust part of the work to a program and still, quite naturally, think of yourself as the person who wrote that software.
The birth of the first compilers
Rewind the tape.
In the 1950s, before C, John Backus and his team were working on FORTRAN. The idea of letting a machine produce efficient code met with skepticism and resistance. In Backus’s account, some programmers considered that ability an art too complex to automate.
With hindsight, it’s easy to smile. But try looking at it from the other side of the desk.
Imagine knowing your machine inside out. You know where to save memory, you can spot a mediocre solution at a glance, and you can do in a few instructions what takes other people many more. It took you years. People come to you when the problem is difficult.
Then along comes a tool that promises to take care of that very part.
You’d watch its first attempts with curiosity. You’d probably find plenty to fix, too. But if it started improving, each advance might have a curious effect: good news for the project, slightly more complicated news for your self-esteem.
You’d only just become the one who was good at this.
Compilers become the norm
Over time, working through a compiler became normal. In the summer of 1973, the Unix kernel was rewritten in C. A central part of an operating system could be developed in a high-level language. Assembly still has its uses, while a great deal of software is developed without writing it directly.
Today we can look back on that story from a comfortable position. We entered a profession where delegating that step was already part of the job. For many of us, the compiler was part of the furniture when we arrived.
What about the pleasure of programming?
LLMs, on the other hand, arrived while we were sitting at our desks.
Suppose an assistant generates in a few seconds a function you could have written perfectly well yourself. You read it, fix a couple of things, and it works. You’ve saved time. You can feel pleased and, at the same time, a little irritated.
You liked knowing how to write that function.
Maybe it was a tedious part of the job. Maybe it was the fun part. When we say a tool frees us from a task, it’s worth asking whether we actually wanted to be freed from it. The satisfaction of finding an elegant solution doesn’t appear in the tally of hours saved.
Then there are the practical worries. The value of your skills, your opportunities, your salary. The mortgage lender doesn’t accept “the profession is evolving” as a payment method. The fact that we now trust compilers doesn’t make it foolish to worry about your work changing.
The future of the profession
Of course, the comparison has a limit: a compiler starts with a program that has already been written; we can ask an LLM to interpret what we want to achieve. How much that difference will matter to the future of the profession remains an open question.
Will we get used to reading less generated code, just as we learned not to inspect every instruction produced by a compiler? Or will we need to maintain a different relationship with that code?
The history of compilers leaves us with a profession that has already changed shape. LLMs put us in the less comfortable position of living through a transformation without knowing what comes next.
When we say we love programming, which part do we mean? The satisfaction of writing an elegant solution, the moment we understand the problem, the pleasure of seeing something work?
If those things started to come apart, which would we still want to call our profession?
Sources
- John Backus, Programming in America in the 1950s — Some Personal Impressions — One of FORTRAN’s creators recalls the skepticism toward automatic programming and the pursuit of efficient code.
- Dennis Ritchie, The Development of the C Language — The development of C and the rewriting of the Unix kernel in 1973.
