The Software Engineer and the Steam Drill
What American folklore can teach us about what happens to software engineers when AI makes implementation labour cheap, tireless and abundant.
Recently I have spoken to several engineers who have expressed concern regarding AI, about how it will change the industry, and how it will affect their roles specifically. In seeking to address this question, it helps to recognise that this is not the first time a technology has transformed the nature of labour in an industry. The Industrial Revolution is a useful analogue. Not because the advent of AI and the Industrial Revolution are identical, but because the comparison can help us understand the structural effects of automation upon the supply and demand of labour, and what those effects mean for the people whose work is being changed.
For explanatory purposes I would like to introduce the American folk hero John Henry as a vehicle for this discussion. John Henry was, as the ballads and tales tell us, a steel-driving man: an exceptionally strong and skilled worker whose job was to swing a hammer and drive steel drills into rock for railroad construction. The tale introduces the steam drill, a real historical device which automated the very same task at which John Henry excelled. John Henry, as the story goes, challenges the steam drill to a steel-driving race. He wins the contest, but dies shortly afterwards, succumbing to exhaustion.
John Henry’s tragedy is not that he loses. It is that he wins, and yet it costs him his life. John Henry can compete on competence, but he cannot compete on endurance. The machine is indifferent to fatigue. Winning the contest does not preserve the old settlement. The labour market has already shifted.
The tale of John Henry is a cautionary tale about the nature of automation. From this case we can infer some understanding of the changes and risks that automation brings.
Automation changes the economics of labour. It can take a task where labour was once scarce, gated behind hard-won skill and rare capability, and make that labour abundant, more consistent, and cheaper to supply. The machine does not need to replace the whole worker. It only needs to perform a bounded task well enough, for long enough, at low enough cost, for the market around that task to change.
When a worker’s identity is bound to the narrow task that the machine automates, the result of automation can be devastating. John Henry’s tragedy should not be read as stupidity or simple stubbornness. He is not foolish for caring about the work at which he excels. He is trapped between personal excellence and a changing labour regime. His anger at the steam drill is not merely economic. It is also an injury to identity, status, pride and purpose. The machine’s response is one of indifference and continued execution. There is little to be gained from meeting it on its own ground.
But with such changes, opportunities can also emerge. When the new machine is complex, expensive, dangerous, difficult to deploy, or dependent on surrounding infrastructure, scarcity does not always disappear, it can relocate. New value can accrue to those able to operate, maintain, direct, constrain and integrate the machine into useful work.
The lesson, then, is not that John Henry made a bad decision. His story is more tragic than that. The lesson is that excellence on the old terrain may not be enough once the ground has changed. Where possible, the worker must avoid defining their value entirely around a task whose scarcity is being mechanised. They must find better ground: not meeting the machine head-on, but learning where its power can be directed, constrained and leveraged.
We find ourselves today in a not dissimilar situation with AI. AI has made large parts of bounded implementation work cheaper, faster, increasingly parallelisable and abundant. Some forms of code production that once required scarce human effort can now be generated, revised, tested, discarded and attempted again at far lower cost.
An engineer may still be more competent than the machine on a given task, especially in domains such as kernels, key libraries, security-sensitive systems, distributed infrastructure, and performance-sensitive applications. But as with John Henry, the relevant question is not whether a strong engineer can win a single contest of implementation. Often they can. The question is whether raw implementation remains the highest-leverage place for human effort when implementation labour becomes cheap, tireless and abundant.
For those whose identity is bound to code production, this may be a painful realisation. But implementation never represented value in and of itself. This is where AI diverges from John Henry. John Henry understood steel driving, but his role was bound tightly to the execution of a physical task within a larger industrial process. The steam drill automated that task, while the decisions about whether, where, and how to use the machine sat elsewhere.
In the short term, engineers may experience AI as reduced workload and increased freedom. But that is an unstable equilibrium. AI is too salient a technology in the minds of leadership for the gains from AI to be captured solely by engineers. In time, as with other technologies, expectations will adjust, and productivity gains will be reaped by those close to strategy, capital, workflow design and decision rights.
Software engineers, at their best, sit closer to those surrounding decisions. They often decide what should be built, what constraints should apply, how trade-offs should be interpreted, how output should be evaluated, and what is safe to ship. These are skills which engineers have already developed which are gaining increasing salience and more potent applications.
The more an engineer’s role is reduced to bounded implementation work, the more exposed they are to AI. The more their role includes judgement, context, integration and ownership, the better positioned they are to use AI as leverage. In that sense, leverage migrates upward. The engineer becomes less like John Henry swinging the hammer alone, and more like the person who decides where the machine should be used, what constraints it must obey, how its output is tested and ultimately, evaluated.
John Henry’s story is not a story about stupidity. It is a story about the danger of being excellent on ground that has already changed. John Henry’s tragedy was that the machine altered the value of his labour faster than he could find new ground beneath his feet.
Software engineers should take the warning seriously, but not fatalistically. AI makes some implementation work cheaper, faster and more abundant. And the gains from cheaper implementation will not automatically accrue to the implementer in the long term. But what can be encountered as threat and competition can also be converted into opportunity and leverage, if the engineer is well positioned.
So I would say to those concerned about AI: yes, your concern is real. Your fear is legitimate. But the answer is not despair, nor doomed competition on unfavourable ground. The answer is adaptation: to hold identity more lightly, to understand where the machine changes the economics of labour, and to migrate toward the work that carries judgement, responsibility and command. My advice is to go away from undifferentiated implementation. Go upward. Go where the leverage is.