With the advent of AI coding tools1, a war is now on. It is not about productivity or efficiency - it is about the soul of programming itself.
Let’s begin with the following argument that is often made:
Why know the details ? Isn’t the high level requirements all that matters ?
I would like to answer it indirectly. By first reframing it in the following terms: doesn’t the black box behaviour of a program unambiguously define it ?
I contend, only partially. Often, it is far easier to explain how something is built from the bottom up than to enumerate every possible behaviour in every possible circumstance.
To take an overly simplistic example. Which among the following is the more satisfactory description ?
- To say that function
f(a, b)“adds two numbers together” - Or to say, that “for every combination of numbers we have tried so far, the result seems to be the sum of its inputs”
While the former appeals to what is inside (an add operation), the latter is a statement of its black box behaviour. Clearly, explaining in terms of the internals is much simpler here. The point I am trying to make is that, thinking in terms of requirements is well and good - but often times it lacks the precision and the expressiveness we expect in programming.
Now, what happens to a project when it is largely understood only in terms of the requirements it is supposed to meet ? Put in more practical terms: When 80% of the code itself is not understood by anyone whatsoever ?
When I say I understand a piece of code, I don’t just mean I can describe what it does. I mean I can clearly explain why it exists in the first place. Such an explanation situates that piece of code in the subsystem it belongs to, then situates that subsystem in the larger system, and so on, until you can explain the complete system. This is the kind of deep understanding we have always expected of engineers who built anything - until recently.
What will it profit a programmer to churn out a thousand lines of code, yet forfeits an understanding of why much of it exists ?
Or, what can a programmer give in exchange for that understanding ?
Use of AI coding tools will drastically reduce the longevity of codebases
Let’s not fool ourselves into thinking we can always use AI to develop deep understanding of any part of the codebase, at any time - on demand. To think that way is to confuse what it means to understand something.
The fundamental problem is that someone else can never do the understanding for us. What if I claimed that I understood calculus because I have a calculus text book on my book shelf - and therefore I can reference it whenever I need to.
If you don’t understand the code when it gets written, when will you ? In practice, large swathes of the code base will forever belong inside the black box.
Even codebases that predate AI coding tools are at risk. As new AI generated code gets added, they could reach a point of no return in terms of understanding. At that stage, we will have the death of the codebase itself. The reasonable thing to do will simply be to pick up the scraps and do a rewrite2, rather than try to understand what is already there.
What will it profit a project if it gains ten features in ten days, yet becomes unmaintainable by the end of the month ?
Or, what can a programmer do in exchange for his sanity ?
The process is more valuable than the product
Codebases are like icebergs. The code itself is the tip of the iceberg. It hides the inner logic, which stays, invisibly, in the mind of the programmer. That is why, when key programmers leave a software project, it often loses its potential for growth and essentially goes into maintenance. To think a project is nothing more than its code is a very reductive view of what the project really is. The most alive part of a project is invisible - in the minds of the people who worked on it.
I am reminded of the story of the Goose that Laid the Golden Eggs3. Greed prompted the owner to cut open the goose, thinking he could get all the golden eggs at once instead of waiting each day for one. Clearly, it was a grave mistake. There is no bag of eggs inside the goose. What is inside is a process that creates eggs - one at a time.
Similarly, the programmer is no warehouse of code lines, and programming is not about moving those lines from the programmer’s brain to the screen. It is a creative process. To use AI coding tools is to kill the programmer. The creative process that used to produce code ceases to exist. Once that process is gone, we can’t expect much of whatever substitute machinery we put in its place.
What will it profit an organisation if it manages to shorten the time to market, yet forfeits its ability to do so in the future ?
Or, what can a company give in exchange for its potential ?
As an individual programmer, should I embrace AI coding tools?
Despite the dangers discussed above, we still see many individual programmers embrace AI coding tools. I am not talking about the people who have economic incentives to push for its widespread adoption. I am talking about those among the user community, who seem to overlook the dangers.
When we look at the world, it is important to realise that different people who are engaged in the same activity, have different internal motivations, and consequently, different visions about their own future. So before we join the chorus, we as individuals must reflect on what our values are.
As a programmer, what do I value more - living a life dedicated to the craft of programming, or producing results that have an impact on the world ?
I hope you will choose the path that sustains life - life as a programmer. That will be a choice to preserve something real (“life”), while choosing to have an impact is to chase an abstraction (whatever the definition of “impact” happens to be on any given day). Actually, even more fundamentally, you exist first, then and only then can you even hope to have an impact.
What will it profit a man if he gains the whole world, yet forfeits his soul ?
Or, what can a man give in exchange for his soul ? - Mathew 16:26