We are living in a time when most of the software we use on a daily basis is written by hand using archaic, hand-crafted tooling. The tools, practices, and methods developers use on a daily basis are taught to them by the “masters” of the trade in the modern equivalent of apprenticeships. The modern equivalent of guilds, engineering orders and associations like the IEEE, ACM, and OIQ here in Quebec, set the loosely-enforced standards, like the SWEBOK, which are mostly ignored by practitioners.

Our tools are compilers, toolchains, and IDEs. The equivalent of the carpenter’s wood and nails are our programming languages, which we mould into useful-but-vulnerable software. Some of us craft the equivalent of battering rams (malware) while others craft the equivalent of the castle gates (firewalls) or drawbridges (protocols), but we all use the same tools of the trade in a myriad of bespoke variations.

This is about to change, though: just like civilisation depended on the craftsmanship of the master carpenter up until a mere two or three centuries ago, depending on how generous you want to be with carpenters, civilisation’s dependency on the individual developer’s mastery of their trade will wane and wither over the coming few decades as the developer is replaced by their creation, and their role becomes one of design and coordination first, and a relic of the past after.

Before the automobile replaced the horse and buggy, the world was cleaner and the roads were messier. Being a saddle maker was a well-paying job for my great-grandfather until after the First World War. Today, horses are a rare sight on most roads, which are generally cleaner while the air is less so. In the space of less than a handful of generations, we’ve gone from “computers” being the young women who calculated difficult differential equations to them being ubiquitous machines you carry around in your pocket or around your wrist, and from programming by punching holes in cardboard to vibe-coding.

So, what’s the next step? Almost certainly, LLMs will supplant human programmers, with software engineering morphing into prompt engineering and context engineering today, and the whole definition of software engineering morphing into something more akin to functional requirements definition tomorrow. Programming languages like C, C++, C#, Java, and the other members of that family will be relegated to the dustbin of history, becoming as archaic as COBOL, ALGOL, and Fortran are considered today. Of course, people will still learn them, just like people still learn Latin, but the true skillset in software engineering will be on the extreme ends of the process: coming up with the ideas and requirements, and validation and verification.

The real question isn’t if, or even when, this will happen: it’s happening now. The real question is what guardrails we should put in place to make sure the software developed by our successor meets the needs and requirements we set for it, and what the new standards should be.

Historically, the Middle Ages were the era between the fall of the Roman Empire and the Renaissance. They were shaped by the absence of centralised control by Mediterranean hegemony, followed by disarray as the void left by that hegemony was filled by more local, North-Western European powers. The effects of those power shifts can, to a degree, still be seen today in Europe’s economic and administrative structure, and in the balance of geopolitical power up until shortly after the Second World War, when the ensuing Cold War shifted the balance of power to a new hegemony in the US.

The Middle Ages also marked the start of standardisation, the first attempts at industrialisation (which were later accelerated with the invention of the steam engine), and the organisation of labour into the aforementioned guilds.

I don’t know what the next Renaissance will look like, but I do know AI will play a big role in the upcoming decades and that, if we want the next Renaissance to be human, it is up to software engineers to make it so.