The Industrial Revolution of Software Engineering
The untold truth about Software Engineering: it was never engineering, it was always an artisan craft. Until now. Current developments are finally forcing it to become a true engineering discipline.
The definition of an artisan in Wikipedia:
An artisan (from French: artisan, Italian: artigiano) is a skilled craft worker who makes or creates material objects partly or entirely by hand.
Apart from “material objects”, the definition sounds exactly like the definition of a Software Engineer before ca 2024. Especially when you consider that each item was effectively a unique creation, and historically, the tolerances (defects, reliability, proximity of functionality to desired outcome) had an extremely high variability.
AI changes this. We are no longer hand-crafting every line of code. Writing code was never the only skill required of a good Software Engineer, but it was a central one. We are now moving towards one where the emphasis is wholly moving towards figuring out the why and what to build, defining inputs (specification), and verifying this against output within some tolerance. We are also dealing with a much higher volume of output than before.
This move from artisanally hand-crafted code being informally verified (hopefully with some unit-, integration- and acceptance tests + some manual testing, usually varying from team to team), to verifying high volume AI manufactured code is shifting the demands of the profession fundamentally. Writing a few tests, and clicking around a bit isn’t going to cut it anymore, when we are looking at a veritable fire hose of code.
The death of the Software Engineer is greatly exaggerated
Why do we even need Software Engineers if AI is writing all the code? All we have to do is tell the AI what sort of thing we want to build, right?
Right. This works fine for vibe-coding a small app or website. It is true that AI is democratizing software creation. Except..
For anything of non-trivial size and/or complexity, you need to make sure you specify precisely and unambiguously, in such a way that there is no room for the AI to confidently fill the gaps with bad assumptions. You must be explicit about:
Edge cases and failure scenarios.
Scalability constraints.
Interactions between the new spec and prior specifications.
Sounds a lot like engineering, huh? Add to that the fact that English, and every other language spoken by humans, are inherently lossy and ambiguous. The shift from artisanally hand-crafted code, to a fire hose of specification generated code will actually require more discipline, more structure than we have ever applied in our field before. The scale of what we now can do demands it.
Drinking from the fire hose: the verification crisis
The burden of verification is growing exponentially. Line-by-line code review will wither and die in all but the most sensitive fields (and perhaps even there). Hand-crafted test-code will go the way of hand-crafted production code, we simply won’t be able to keep it up. We can try to instruct AI to do TDD, to write tests as it goes along, but even here the AI will be incentivized to write tests that pass, rather than rigorously test its own output.
The consequence of this is, that we will be forced to come up with new, novel approaches to automating our verification, how close to our intent our output is.
What these approaches are, I can only speculate on, and we’ll likely discover things along the way as things evolve, just as we have these past few years. But I would make an early guess that some of the approaches will be a combination of:
AI-on-AI auditing: Using “Critic” models to find hallucinations in “Generator” outputs.
Property-based testing: Moving from testing specific examples (e.g., 2+2=4) to testing invariants (e.g., A+B must always equal B+A across all possible inputs).
Formal & Probability-based verification: Mathematical proofs of correctness to ensure systems stay within non-functional requirement tolerances.
Conclusion: the Expertise paradox
The great irony of Software Engineering in the age of AI, is that we will need to become even more of an expert than before. Relying on vibe-coding, or doing things “the way we used to” will only result in drowning in a mountain of garbage and technical debt. A new level of discipline, skill, and ability to create reliable feedback- and verification loops will be required.
This shift has an interesting characteristic: it will increase demand for these skills (expect more demand for software engineers), while at the same time creating a brutal shake-out of those in the industry incapable of adapting. Increased demand for higher level of skills, but reduced supply likely means those who can make the jump will be paid a handsome premium compared to today’s software engineers.
The age of the Software Artisan is coming to an end. Industrial scale production of software means we are finally crossing over into a proper rigorous discipline called Software Engineering.
The expertise paradox is right, but the transition period is the part that worries me most in enterprise delivery.
Industrial discipline takes time to build. The artisan knowledge disappears faster than the new rigour arrives. That gap is where most of the damage happens - not after the transition, but during it.