The software industry is changing at a terrifying pace. Less than two years ago, AI agents were mildly useful tools—they could write code but needed careful shepherding, and were just as likely to cost us time as they were to save it. Today they're hacking companies, writing entire products from scratch, and working together in coordinated groups.
This is understandably having an impact on the people making the software. Programmers are wondering how much longer their job will exist—at least in the way it does now. As someone who has been through more than one sea-change in the software industry, I think we should take a step back and look at history to give us an indication of what is to come, and help us understand what our jobs will look like in the AI era.
What's happening right now is the industrialisation of software development—taking something that has traditionally been created "by hand" and introducing novel, powerful tools to automate the process. Fortunately, industrialisation is an area of history that we have plenty of precedent to look back on, and there are strong parallels with current events and those that shaped the Arts and Crafts movement.
The Arts and Crafts movement was a reaction to the increasing industrialisation of manufacturing, particularly in the aftermath of the Great Exhibition of 1851. Leaders of the movement included textile designer William Morris and writer John Ruskin, and their main objection was not to the use of industrial production methods, but to their impact on society and the ethos behind the products they created.
Morris in particular believed that industrialisation was detrimental to the relationship between the craftsperson and the product. Since factories could now produce goods using cheaper, lower-skilled labour, designers often had no hand in their manufacture, and the workers were underpaid and exploited.
His argument was that the creation of a product was as much part of the craft as the design, and that to produce something of quality the craftsperson should be involved in the whole process—an argument also made about the production of software by Paul Graham in his essay "Hackers and Painters".
We're already seeing the same shift in the software industry; companies are drawing the conclusion that because the tool exists, anyone can wield it effectively. As a result, they're using "AI" as an excuse to fire or outsource parts of their workforce. Anyone who has actually worked with these tools will understand how foolish this is—just because a tool can do something doesn't mean it can do it well.
Instead of seeing these tools as a way to eliminate the skilled craftsperson, they should be considered a force multiplier for them to design and make things faster and better than they could before. The care and understanding of the creator is still very much evident in the quality of the product, even when everyone has access to equally powerful tools, clearly shown by how easy it is to separate carefully created products from AI "slop".
But this argument doesn't help programmers internalise the change in the industry. If we see the act of creating code "by hand" as an inherent part of software development, we're going to struggle to adapt. That's not to say that we won't ever write code ourselves—the invention of the chainsaw didn't eliminate the need for the axe—but if programming is our profession we must be able to wield the best tool for the job at hand.
Instead, we need to see our role as the "creators" of software, using whatever methods make the most sense. The need for care, attention, and understanding is still there—just like cutting a plank with a welding torch will leave us with a flaming mess, so too will using the wrong language or architecture. AI will never understand the whole of what we need and the context in which it operates; that's our role.
A tool also lacks an inherent sense of taste and values. It's becoming common for us to humanise AI—to think that when it hallucinates it's "making a mistake", or that it chooses the "best" approach for a task. This is a dangerous fallacy—an LLM is, and always will be, a statistical inference engine. Any illusion of "taste" or "morality" is ultimately no more than the result of how the tool has been trained to behave by its creator.
We shouldn't see AI as a way to remove the programmer from the creation of software, but instead as a reframing of our role. It can help unblock us when we get stuck; speed up research and development by giving us many pairs of hands; and let us make things at a scale and pace that would previously have been impossible.
I hope that, by learning from history and understanding the direction the industrialisation of software development will take, we as programmers can change our approach to creating software accordingly, and internalise the role we'll adopt in the AI era.
We still need to do our work with care and attention, and we should align ourselves with companies that have good values and appreciate this necessity. But we also can't cling to our current model of software development—this will only end in disappointment. Instead we should look ahead to understand how we create a better future; both for the people using our software, and for ourselves.