In the world of programming, we are asking ourselves questions about the future of the developer—or, more importantly, about whether developers have a future at all. What is going to happen to us?
This makes me think of the “circle of competence” discussed in the book The Art of the Good Life. The author argues that everyone should identify their area of competence and remain within it—an idea also associated with Warren Buffett.
So the question is: is there something that we programmers are particularly good at and should continue to focus on?
Faced with such a profound change, perhaps this is the question we developers need to ask ourselves. Of course, we may not even agree on what “we” means. There are many names for our profession. People talk about developers, programmers, software engineers, and sometimes software architects. To people outside the field, these roles may appear closely related. To us, they can feel like entirely different worlds. Some people write HTML pages with a little CSS and JavaScript. Some know how to write a few Python scripts. Some develop Linux drivers. Others build ERP systems in C#. The differences in competence, experience, and technical depth can be enormous.
What all these people have in common is that, in one form or another, they have earned a living by writing code—or at least that writing code represented a large part of the value they were perceived to provide. Now, however, people such as Uncle Bob and Salvatore Sanfilippo argue that, in some projects, we should not even look at the code generated by LLMs. Not merely that we should not write it ourselves, but that we should not even read it. And if Linus Torvalds says that AI is at least useful and cannot simply be excluded, then perhaps, regardless of how skeptical we were two years ago (or even six months ago) we need to start asking ourselves these questions.
Who are we, then, and what is our real competence?
I believe that, among other things, we are people who have developed the ability to describe how a system should behave in extraordinary detail. Until now, the system could not make decisions for us, so we had to make every decision ourselves. Compilers could detect inconsistencies and missing information. They helped us develop the ability, and perhaps the habit, of being extremely precise.
Over time, that precision has shifted somewhat from describing how something should be done towards describing what should be done. In the past, specifying the implementation was even more important than it is today. For example, when I wrote programs that worked directly with video memory, I sometimes needed to multiply a value by 640, because screen resolutions were commonly 640 by 480. Rather than expressing the operation as x multiplied by 640, I could calculate it as x shifted left by nine bits plus x shifted left by seven bits. In other words, I multiplied by 512 and by 128 using much faster shift operations, added the two results, and obtained the equivalent of multiplying by 640. That is an extreme example of an implementation detail, but such details still matter today. Developers still need to reason about performance: when and how to use a cache, when to invalidate it, when to use a stream, when not to use one, and so on.
But what happens if we can now afford to be less precise?
We can describe what we want to an LLM, and the model can fill in the missing pieces. It may not always fill them in exactly as we would have wanted, but it also does not necessarily make the gaps visible to us. If this becomes our normal way of working, I think it will be difficult to preserve the mental muscle required to be extremely precise.
Perhaps we will become more like analysts who gather requirements. However, in my experience of working with analysts, requirements documents were never precise enough to eliminate every open decision. I still had to make those decisions myself. It is extraordinarily difficult to be completely precise on paper without an interactive counterpart, a compiler, let’s say, that can tell you: no, something is missing here.
This leads me to several questions. Today, we possess certain skills and abilities partly because of the exercises we have repeatedly performed and the way we have worked until now. If our way of working changes, will our abilities change with it? Will we lose some skills while acquiring others? At the moment, we are much more acutely aware of what we might lose than of what we might gain.
Those of us who have been working in this field for a few decades have already experienced similar changes. There may once have been a certain pride in remembering how interrupts worked, which services were available through DOS interrupt 21h, or how different register-based and stack-based execution models operated. Yet we often forgot those details surprisingly quickly once we stopped needing them. We may still remember that we used to be good at those things. But if we had to work with them again tomorrow, many of us would struggle to return to the level we once had.
Our competence evolves according to what we repeatedly do. If we change what we do, we change what we can do, and this means changing who we are. For those who invested so much in building our professional identity, and who have pride in what we do this is painful. We can pretend it is not and keep a straight face, but here among us we can also face a little bit the pain. I wish I could program it away 🙂
If we stop writing code and stop reading code, what we are capable of doing will inevitably change. Our competence will change, and perhaps our professional identity will change with it.
I wonder whether we will reinvent our profession and discover a new way of working while still remaining programmers—or whether each of us will need to define a new circle of competence and eventually disperse into entirely different professions.
Who knows, maybe one year from now we will wonder why we worried so much. Or maybe we are the last of a glorious breed of people, who could themselves programmers.
