It’s as if, throughout our entire careers, we programmers have practiced our profession without ever knowing its true nature, and seemingly with no desire to understand it. Our sheer passion built a bubble around us (made of mechanical keyboards, agile frameworks, dual-monitor setups, clean code, standing desks, design patterns and dreams we had when we were children), that isolated us from the “real” world of work, where people don’t consider themselves lucky to be paid for doing something they would do for free anyway. This historical moment, casting us witnesses to a revolution, finally forces us to reflect.
The advent of LLMs is triggering an earthquake whose aftershocks are only just beginning to be felt. And it’s clear that it’s not about what LLMs can or cannot actually do, that’s secondary, people are not interested! It’s all about perception! And based on perception alone, it looks as though we’re doomed. Since we don’t know what the future holds, and given that perception seems to be all that matters, why not seize the moment? Let’s talk about what is being perceived within our industry and, once and for all, open a debate on the true nature of our craft, gathering some food for thought.
Programmers are craftsmen 🔗
Software developer, software engineer… different titles (often assigned based on the seniority one claims or how much a company is willing to pay) that basically describe the same job, a craftsman’s job: the programmer. And since there’s a lot of confusion, let’s do a quick recap of what our craft consists of: deeply understanding a problem, breaking it down into its atomic parts, envisioning the solution and explaining it to a computer. If we remove any of these elements, we alter the very nature of the profession. Based on that description, can you see the sheer dominance of the creative dimension?
Some argue that prompting instead of coding, simply speeds up the process by delegating the final stage of the creative journey to the machine. But anyone who has worked as a programmer, alongside other programmers, knows that deeply understanding a problem and writing specifications for a colleague will inevitably lead to an implementation different from the one originally envisioned. Why should it be any different with a machine? Consequently, relying on machines for the code means delegating the creative core to them; after all, we aren’t just talking about replacing a delivery rider’s bicycle with a scooter, are we?
This is why I find it baffling to hear so many colleagues say: “Finally, with AI, I can focus on what’s truly important in my profession and leave out all the noise”. First, because it’s sad to see them dismiss the very essence of a craft I’ve loved since my first “hello world”. And second, because they make it sound as if our job is finally evolving into its best version. Well, think again: maybe it’s not the job that’s changing… maybe it’s you changing jobs. It may be too soon to tell, but at first glance, our new role seems to have more in common with an assembly-line worker doing quality control than with a craftsman.
New job, new problems 🔗
So, after years spent trying to convince people (entrepreneurs and managers mostly, sometimes even ourselves) that we weren’t factory workers (not that there’s anything wrong with that), the irony is that we seem to be finally becoming just that. We were so good at convincing everyone, in fact, that now, as we are likely changing jobs, people still believe we are craftsmen. Consequently, they are going to blame us even for the sloppy code generated by LLMs: “If the code sucks, it just means you aren’t good enough at prompting the AI, period; and remember, you are still the owner of that code”.
It seems we are moving fast toward a condition where we won’t write code anymore, yet we will remain the owners of the code we didn’t write, and that’s interesting. So, would talking about the risk of alienation in AI-assisted coding be “too blue-collar”? I mean, no one should be offended if we borrow terminology from those who truly understand the nature of their profession. But why “AI-assisted coding” and not “vibe-coding”? Since we are still in charge, we must know and understand the code we ship; leaving the machines alone, at least for now, doesn’t seem like the smartest move.
No worries! All programmers know there are two ways to approach code: writing it and reading it. Now, reviewing code written by a machine should be no different from reviewing code written by another programmer: you didn’t write it, so you need to understand it to identify potential issues. So far, so good, nothing we haven’t done before! Except for the fact that reviewing code takes time, and one might ask what the point is of having a machine that writes code much faster than you ever could, if you end up wasting all that saved time. We’ll get to that in a moment.
The new economics of coding 🔗
Let’s be real: we’ve always known that the companies we work for (with rare exceptions) aren’t charities. So, we can’t seriously believe there’s a plot afoot to destroy our profession; it’s simply a strategic realignment of production assets, and we must be aware of that. The traditional investments companies made in tools and salaries for programmers (the priesthood in charge of the “magic”) are now being joined (gossipmongers would say replaced…) by spending on AI tokens. The use of these tokens suggests the not-so-remote possibility of overturning the software production paradigm by outsourcing the actual implementation to machines.
I mean, it’s all about ROI (Return on Investment). We know for certain that LLMs can produce code at a speed unthinkable for human beings, so, if the code works “well enough”, the investment in tokens seems like a solid one. The point is: what does “well enough” actually mean? We need this information in order to evaluate the ROI of programmers’ salaries. Are they still a good investment? Well, as you can imagine, it depends! If machines are lightning-fast at writing code, but the people in charge of leading, reviewing, or orchestrating them are slow, can you see the bottleneck?
As things stand, we can already see three groups of programmers beginning to form: the enthusiasts who trust the machines, the skeptics who don’t trust them quite as much and the luddites who despise the machines. Well, it doesn’t take a genius to realize that while luddites have no future, for companies, the enthusiasts could become the benchmark; soon enough, the skeptics could be “kindly encouraged” to fall in line. Models will become increasingly reliable and companies grow to rely on them, so it doesn’t seem crazy to think that code reviews could start to decrease in intensity, until eventually abandoned altogether.
The quality of software 🔗
Let’s be clear: with AI-assisted coding, even if programmers had the time to review the code, there’s no chance they could guarantee the quality they and their companies were once used to. Reading without writing simply isn’t the same, and programmers who stop writing code will, sooner or later, grow sloppy. On-the-job training has always been a vital part of a programmer’s growth, it forces you to test the limits of a language and to commit to memory those nuances that reading alone (be it a manual or someone else’s code) can never truly anchor.
Of course, we’ve written tons of bad code throughout our careers, it was part of the game. A programmer today is better than he was yesterday. I mean, today’s “me” would never write the kind of crap that yesterday’s “me” did. But living and breathing the code with our own fingers, no matter the smells, always allowed us to maintain oversight of the domain. And we work in teams because we complement each other! By combining our skills and our creative spark, we achieve remarkable results. So, by handing over the writing and the creative process to machines, don’t we risk undermining the very quality of that code?
Years and years spent studying design patterns, absorbing the principles of clean code, and growing as professionals… at this point, what was it all for? Is it possible that the very idea of software quality needs a total rethink? The point of quality was never about showing off, it was about maintainability. If you write good code, maintenance costs less. But with machines in charge of maintaining software, does it still make sense to strive for quality? Is it worth sacrificing part of the saved coding time to perform reviews, just to achieve quality in our software?
WTFM (Write The Fucking Manual) 🔗
Documentation has often been a programmer’s Achilles’ heel. Many open-source projects have excellent documentation, but the same can’t always be said for proprietary software. Sometimes programmers don’t have enough time to write documentation for their code, other times, they have to deal with such a complex mixture of legacy layers that, in the long run, the code simply becomes undocumentable, essentially because no one really knows how it works anymore. Fortunately, there are cases where documentation actually exists, but, and here is where it gets interesting, it is always documentation written by human beings, for human beings.
Since it seems we are going to rely on machines even for documentation, it’s the perfect use case for LLMs, and we could consider writing documentation part of “the noise that prevents programmers from focusing on what’s really important”, together with writing code. But one could say: we know how human beings write code, summarizing concepts, exposing edge cases, and pointing out nuances just to keep track of what is actually meaningful and hard to understand by just reading the code, and also easy to read, but what about machines? How do they write documentation?
Even assuming, for the sake of argument, that it’s actually important! Because if machines are writing documentation for those in charge of software maintenance, who happen to be those same machines, probably all the questions about how documentation should be written are nonsense. If documentation written by machines is used to write other documentation, the process could eventually lead to the infamous model collapse (as they say), but on the other hand, machines should not need documentation in order to understand code, so what’s the point of maintaining documentation at all?
The future 🔗
What does the future hold for us programmers? It’s hard to say, especially based on the speculations made in this article and all the arguments fueled by the hype around LLMs you can read online. For sure, things are changing for us, but, going back to one of the earlier points, right now we don’t know if our job is changing or if we are actually changing jobs; if we are changing jobs, this would mean the extinction of programmers; otherwise, we are all probably destined to transform into the Super Saiyan of programmers: the mythical 10x developer.
A lot of us are losing the job and maybe more will follow, it’s not clear. The fact that makes the news nowadays is companies (big companies mostly) moving money from programmers’ salaries to AI investments, and that’s changing our industry also because many of the software products we used to craft look set to be overtaken by new ones, AI-powered. What this means for software production is unclear, what’s clear is programming languages won’t be replaced in the short term, if only because LLMs stand for Large Language Models and, in their very essence, they are designed to deal with languages. No AGI on the horizon, it seems.
Many analysts think what we are seeing is another economic bubble, meaning a period when asset prices greatly exceed their intrinsic valuation, defined as the valuation that underlying long-term fundamentals justify (definition stolen from Wikipedia!). But what if the bubble has always been programmers? Maybe our price exceeded, for a period, its intrinsic valuation, and what is happening now is simply the bubble bursting. It’s not that knowing makes the situation any easier… but anyway, knowing things and understanding them has always been our mission, so why stop now?