Software engineering has a problem with legacy. Whether you think it or not, whether you are intentional about it or not, we all leave a legacy from our work - including software engineers. Have you ever wondered what your work legacy will be: what you will be remembered for building, and by whom? You will ruminate on that at your leisure toward the end of your career, but it is certainly better to consider it near the start. It is my hope this article will be helpful food for thought for fellow software builders concerned about their legacy, especially in this brave new world of AI.

You might be thinking legacy is a luxury software engineers today can’t afford, because right now most are focussed on just earning a reliable income. For most people the personal legacy available to them is their children, for whom they work: to feed them, house and educate them. So for our children’s sake retaining livelihood is paramount, even if that demands doing whatever the job dictates. That can mean casting aside all lofty notions of a work legacy. However – consider this – during our career years we will spend more actual hours working than we will spend with our offspring. So it is only proper to also consider the legacy of all that time spent at the desk.

First we need to examine the peculiar characteristics of the software industry as it was before AI.

We are not the pyramid builders

The software sector has always borrowed terms from the construction industry. In the era of AI, software builders in particular are giving themselves titles like “Software Builder” – empowered vibe-coding individuals heroically assembling huge constructions alone with the assistance of agentic AI tools. There is a major difference, however, in the construction analogy as applied to software. Few products of the software industry will be sitting in the tech landscape for decades or centuries to come. Software is more ephemeral. Buildings outlive their builders; for software, it is more often the reverse. What you build early in your career – will it even exist before your career ends? Code that I have personally written on various projects has no doubt since been upgraded many times over, refactored - or even replaced – out of existence. That’s no reflection on the skill of the coder; it’s a reflection on the nature of the industry.

We can’t all be the inventors of new programming languages, like C, which act as the bedrock of an entire software development ecosystem. We can’t all develop a new operating system like Unix (or its core modules) that will – in various forms – be running on servers for decades to come. We can’t all write the compression codec that is used billions of times every day on every stream, every video call, and every podcast. (And in truth, which end user even knows – or cares about – the names of the developers who first created those things? They won’t know those names any more than we can name the pyramid architects.)

For the majority of software builders, the reach of what we build will be smaller than those examples I gave, both in terms of longevity and audience. Our legacy is more humble. We are not building monuments; we are building software for customers and users to inhabit daily. Software structures that we build are highly mutable. They change quickly and invisibly. Every new feature, every refactoring or dependency upgrade has to be done long after the building has already opened to the public, and with people running around in it! How many construction architects have had to move entire rooms around or add new stories after the needs of the inhabitants change? For software architects and engineers that’s an ask as regular as every major version release. We even design software architectures specifically to make these unknown future upheavals easier. The pace of change in software engineering can be truly dizzying sometimes.

That relative ease of mutability in software is why some software builders feel they have no substantial legacy. In the software industry, change is a feature not a bug. The IT industry as a whole has always been about trends (the half-life of each being only slightly longer than the doubling duration of Moore’s law). It’s not quite as notoriously seasonal as the fashion industry itself, but is very much governed – perhaps more than we like to admit – by trends that drive new revenue streams. We like to call those trends “innovation”, and the process – “upgrading.” We have always been a novelty-seeking bunch. It can feel sometimes that instead of building software pyramids that will be admired for generations, we are instead building low-cost software shacks fit only to be razed to the ground in the next trend cyclone and quickly replaced by another. It is a problem that will be exacerbated in the era of AI, when software can be built so cheaply. Anything cheap becomes more disposable.

Perhaps you are happy with building ephemera, and that’s ok, if it fulfils the needs of present users. Software serves the purpose it is created for at the time. As software builders, we need to remind ourselves that there is nobility in what we do. We can lose sight of that great privilege we have of making something that solves pressing problems for people, in the software they use every day. The problem for us comes when the software we build is the cause of problems for users. Many software builders who know and understand software fear that the LLM systems the industry has built are on track to become just that – a problem.

Never a builder to be found when you need one

Where have software builders come from? Unlike in the construction trades, there’s no formal apprenticeship route in IT, no guild system. A degree in Software Engineering or Computer Science might be essential for some jobs in IT, but by and large the industry is more interested in candidates with magically-acquired specific skills - knowledge of particular coding tools and languages, or proven experience in real-world software delivery, and maintenance of live production systems. These kinds of things are hard to acquire unless you’ve been working a job that provided them already, i.e. experience! A lot of software developers are self-taught in the tools they use. It is an unwritten rule in IT that the onus is on the individual engineer to research and determine the industry direction, and up-skill accordingly or risk becoming unemployable one day if they find their skillset no longer in demand.

To be fair, the software industry in general does have a few career supporting initiatives. Early-stage internship is one example. Those working in larger corporations, with generous training budgets, may find good career training supports from their employer even in later career stages. But most of the assistance software engineers get during their careers comes from the self-organising camaraderie of the software development community itself, particularly outside of the company you work for. Community has always been a vital force among software workers, finding expression in initiatives like pair programming, code reviews, and expertise-sharing platforms like StackOverflow, GitHub, or LinkedIn.

That aspect of my profession has always impressed me. Whereas other professional trades might see themselves as being in competition with each other for the same business (– and hence reluctant to share professional knowledge –) software developers have always displayed an “all in it together” vibe, and a willingness to share. Perhaps the greatest expression of this came with the open source movement. If you feel the code you leave from your day job to be a poor or unfulfilling personal legacy, you could always hop on an open source project and be welcomed as a contributor to leave a valuable imprint in the technology space, to be used by other professionals. In fact, such self-initiated contributions and self-acquired skills would, in time, come to be sought by many hiring employers who are only too happy to include open source contributions as a requirement in their job listings.

The importance of mentoring

All that being said, it leaves a lot on the shoulders of the individual, and we don’t really move beyond ourselves and our professional bounds unless we have people who challenge us, and guide us on our own particular professional journey. Professional apprenticeship transfers professional skills from one generation to the next. Mentoring goes beyond that. The concept of mentoring is ancient. We get the word from Homer’s The Odyssey, and the principle of personally directed education goes back even further to Socrates. Named after him, the Socratic method gives us the approach used by mentoring. A good mentor questions and challenges, leading self-discovery, helping someone develop the capacity to reason and act for themselves. The ambition of any form of education is ultimately to teach someone how to teach themselves (and eventually others.) The ultimate goal of mentoring is to educe wisdom. In an industry where, from one generation to the next, we do not know where it will be next year, never mind in a whole generation, what tools will be in use and what new challenges may be faced, then the importance of transmitting fundamental principles and how to wisely apply them becomes clear. Human mentoring has always been a vital pillar of software engineering, whether we were aware of it or not; it is essential for the continuation of practical wisdom within the profession, and we will return to it later.

I’ve met some great software mentors, both in my jobs, and in online spaces. I’ve even had an anti-mentor too! Anti-mentors can – in spite of themselves – teach you valuable things about yourself and your chosen career. One showed me that there are people in IT who specialise in obscure technologies and will happily spend the rest of their careers siloed in them. Such an approach can ultimately make you insecure in your industry, perceiving new development technologies as a threat. It became a bizarre kind of reverse-mentoring relationship where I encouraged him to believe he could upskill. Neither of us saw the day coming when all our knowledge of coding tools would become subverted by AI coding assistants! However he was a lesson to me that there will always be developers who won’t be swept along with the trends, and it is possible to carve out a career for yourself in a niche. There are technologies and products out there that none of the novelty innovation set have any knowledge of, or want any knowledge of. There is a legacy for some, in being one of the few survivors of IT innovation whose skills are still in demand for uniquely obscure reasons.

AI joins the party (and proceeds to spike the punchbowl)

Now we arrive at the topic that seems impossible to avoid in any article lately – AI. As if to reinforce, once again, that IT is a trend-driven industry, enter AI, to join the IT party. It is already leaving many with a punch-drunk hangover. AI is a device of the IT industry’s own making, imposed upon the world, whether the world likes it or not (it is increasingly telling us: it does not like it!).

The first adopter of AI, to make the case for its wider deployment in human industry, had to be – of course – the IT industry itself. The gluttonous scramble by IT companies to prove the mooted productivity and profit benefits of AI made the ultimate demand of its software builders, by firing many of them. And the ones who remain are the ones called on to prove the worth of that AI that sacrificed the careers of so many of their colleagues in the software development community.

Software builders are undergoing a collective exploration exercise to discover AI’s eventual place and shape. Despite all the predictions, the consensus seems to be that no one really knows how it will all pan out. It’s constantly shifting ground. That’s why we’re figuring it out together, as a group of software aficionados. The camaraderie of software builders is not so easily riven. Software builders are also undergoing a collective “cope”, with LinkedIn feeds having lately turned into something akin to group counselling sessions for engineers. We’ve come together, searching for any bright lights to navigate the rapid restructuring of our work sector. We are coming to terms with the changes. We are moving through the stages of grief for an industry that – as we knew it – has gone forever. It’s only when we arrive at the final stage of acceptance that we can figure out how to move forward.

Please do not leave your values in the car

In a golf course car park in Portugal I once saw a sign mistranslated into English: “Please do not leave your values in the car.” The correct word was, of course, “valuables”. Somehow the mistranslation seemed better, more appropriate, for a game of sport.

We can ask the same of our work: when we go into the office, do we leave our values in the car … or bring them into the office with us?

Our job is not our identity, and yet so many associate themselves with what they do. We all have lives outside work that, in combination, express all aspects of us. There’s more to you than just the day job. “My job doesn’t define me”, or “I am not my job,” you may hear said. In a scenario where we are paid for what we do, it is all too easy to divorce ourselves from any agency, or responsibility, in what we do on the job. We just go along to get along … and if we’ve any problem with that, with what we have to build, we just push any concerns aside. Right? We can fool ourselves by telling ourselves: “What I do is not who I am.” But what you do reflects who you are, in the choices you make, in what you bring of yourself to the work, and in what of yourself you choose to leave in the car.

AI has led many high-profile software builders to turn activist, to make a stand to highlight (based on what they saw) the dangers of untrammelled AI reach. The “Godfather of AI” Geoffrey Hinton left Google to be able to maintain his freedom to warn of the potential dangers of AI ¹. More recently, Anthropic’s Jacob Coxon left warning that AI labs are “gambling with our lives” ². There’s a conversation happening at the time of writing about how plausible and how sincere many of these claims are. Only time will tell. But assuming they believe it, one can only admire the stand taken for their presumed sincerely-held principles.

You are what you choose to do

Our conscience (or bank balance) may never allow most of us to take the ultimate sanction of leaving a job on principle. The stakes – we can tell ourselves – are smaller anyway. We are only involved in small ways, not developing AI models for apocalyptic scenarios. However, we are more aware than ever now as a society of the effects and damaging consequences of even simple software design features, such as infinite scroll, incessant notifications, and recommender algorithms. We may not be willing to object to a boss that demands such features, but we are in a position to at least speak if we have any concerns. If we do not, we lose our agency. We lose what makes us human. If there’s no human to offer an opinion, AI systems might as well be coding everything – no ethical questions asked, and no ethical ethos embedded in the software. For that very reason, demand will rise during the prescient discussions on AI regulation for guardrails to monitor (and warn) of what it is being asked of AI models. Without humans in the software building loop, we risk delegating conscience to AI too – something it simply does not have.

Are there any jobs you would avoid, or projects you would object to work with, if they don’t align with your personal values? (e.g. I’ve always avoided working on addictive gambling products.) Are there any product areas you actively seek to work on that would align with your interests and values (e.g. healthcare, or digital wellbeing?) Perhaps there’s just no software you wouldn’t build if asked … or, perhaps it’s a conversation you’ve simply never had with yourself yet.

Let’s assume most of us will never leave a legacy of a world-destroying nefarious product. Let’s assume that AI follows some middle-line (where most predicted futures tend to go), at neither extreme of the best hype or worst fears that are predicted for an AI world. Let’s assume the astroturfed economics and valuations of the AI stocks will not blow up in the face of the whole AI industry (a big assumption!) Costs of self-hosted AI models may drop, open source coding models may become more sophisticated, available, and cheaper to run.

On those assumptions then, let’s assume AI will remain in software engineering, in some form, as a new reality and a new tool available for software builders from now on.

So, in the reality, how should we think about the legacy we’ll have with the assistance of AI?

Delegators! Delegators! Delegators!

Microsoft’s Steve Ballmer’s famous meme-spawning appeal³ for more developers to drive software success is looking dated now in the era of AI. Developers are now delegators; we offload our coding tasks onto the machine. That new relationship with assistive AI coding agents and the general ease of generating voluminous amounts of code risks detaching developers from the process of software development entirely. A developer’s role shifts from efficient construction to effective delegation. We are all managers now.

Many coders lament that change in the industry. I’ve known many good software developers; all of them shared this in common: pride in their code quality and in robust, maintainable software design. In the same way good writers pore over grammar to get it “just right”, coders craft their code as a signature legacy left for other coding professionals who may come after them. When code becomes so cheap to generate, what will happen to our attitudes to code when it can just be re-written in a flash, and when there’s too much generated code to possibly review adequately? Will code quality and style matter when it’s not really meant for human eyes anymore (but instead for the eyes of a tokenising parsing machine)? There’s even talk of high-level languages becoming obsolete altogether. Why have nice wordy human-readable logic, when it’s costing you tokens every time? We’ll be back to human-incomprehensible machine code (or some new “AI code”) and humans will be locked out of the manual coding cycle entirely, requiring an AI chaperone for every little task. It is no wonder many hear the death knell for the software development profession.

So what’s a passionate software developer to do? Is our code legacy dead? Not quite.

While AI is bedding-in and the industry is establishing best practice for the new tool, we can make our positive contribution. That can be part of our legacy. As a coding orchestrator, as context & prompt engineers, we can still oversee and can ensure technical quality. That same passion we had from manual code quality (leading to software quality and stability) still applies. Coding standards, that were once optional, informal, or the choice and responsibility of individual developers, now become essential to define. Many builders agonise at the quality of code generated by the machine, about not having enough time to review what may slip through, to attend to every line personally. AI usage will demand – more so than ever – enforcement of sound engineering practices, because instead of being applied ad-hoc, or implicitly, they have to be made explicit and procedural in the AI SDLC (software development lifecycle). We need to carry forward into the age of agentic AI coding, that care for code quality, and be intentional in defining our standards, codifying and enforcing them in the context of every AI request, or else the standards will be assumed, applied inconsistently, or subject to iterative drift. We need to make the case to management and press for the space needed to do this at the outset as part of agentic coding configuration. If we don’t, we’ll learn again that the “garbage-in-garbage-out” mantra applies just as equally in the era of AI as it did in the past.

The same responsibility for quality code in the public space rests on us, even if implementing the code has simply moved “up the chain”. We need to keep in mind that AI derives its code (and therefore its coding standards) from public codebases. So, if our AI generated project code is public, it is particularly important for us as the AI standard setters to ensure the generated code is of highest quality possible. If we neglect that responsibility, we risk polluting the “gene pool” of source code that AI models are built on.

In addition to our project-level contributions, AI opens new ways for software developers to contribute to the community. We can always still keep ourselves engaged, relevant, not just with low-level open source library contributions. The models LLMs use for writing code are built on the backs of decades of work by software engineers who generously made their code publicly available. Would they have embraced the open source movement in quite the same way if they foresaw how it would ultimately be used to change their profession and, in some cases, put them out of work? Hopefully it will not dissuade us in future. In the AI era, there’s also the option to contribute higher-level contributions that aim to be genuinely useful and leave a new code legacy for fellow developers to leverage. Repositories of open source “Natural Language Programmed” libraries are emerging, containing AI skills, and plugins. These will expand in time.

The human-kept-in-the-loop

As software professionals, we should have our say in where people belong in this brave new world of AI development, where the “human in the loop” is best situated, to ensure software quality and the stability of the building process. The bottom-line is that now is the time when we figure-out AI best practices as a profession - what we should (and should not) delegate to AI, and when.

We should also maintain human eyes on what we are building. And that means overseeing the AI and keeping an eye on its activities and outputs. Will the software features, and their behaviours, always be under the strict control of humans in the specification? There is a temptation to automatically allow agentic development systems to define their own parameters and boundaries for feature behaviours, without human oversight. These are the kinds of things we must instruct AI software development systems to pass by a human for approval before it releases the feature or changes “into the wild”. We need to embed, as sound development practice, the monitoring of external link activities of agentic AI systems, especially self-improving iterative AIs that may re-define their own delivered features, or parameters of their runtime boundaries, to avoid unintended consequences of drift.

There will be those AI providers who will offer “best practice” for the agentic engineering era ⁴. These providers are the very ones selling the tokens and compute cycles. Their solutions will perhaps (unsurprisingly) involve more of their AI and less of human developers. As another mentor once told me: the ones making money in a gold rush are the ones selling the shovels. In this case, the shovel makers are giving away some shovels for free, in the hope that the minuscule scraps of gold discovered will lead to more profits from shovel sales than gold in the future.

Morality and ethics will move to the mainstream in the era of AI. AI systems are intrinsically amoral. The morality that governs their actions and behaviours therefore can only come from us. Decisions, guardrails, ethical limits, need to be made explicit (conversations will be needed) in order to be specified to the AI systems we design and develop. Software builders need to “embed values in their projects with due seriousness” ⁵.

Finally, there will be opportunities for software builders to build software-based solutions that detect, or counteract, some of the many harms that are foreseen to be caused by AI systems. That may be the greatest option for a good legacy available in the post-AI era.

A crisis in mentoring

It is no exaggeration to say that the introduction of AI has led to fears of an emerging crisis in the mentorship legacy in our industry. Now that we have acquired all that higher-level meta understanding of software development and delegated it to the machine, the greatest concern of many software builders today is where that next generation of knowledge will come from. We fear to lose the generational human transfer of knowledge. One quote on LinkedIn illustrates the sadness and sense of loss senior software engineers feel right now. It is innate in us to share with the next generation, to want to pass on skills, knowledge, and wisdom.

“Mentoring is dead because nobody needs our skillset. I'm working with developers who haven't written a line of code in a year or more. They submit features and they don't know how they work. Some are even coding in a language they never learned [..] That's the job now and I don't know how anyone can find fulfilment from that.”

I would argue with the sentiment that nobody needs our skillset anymore. The true position is that few use that legacy skillset. There is a difference. There is a shift toward Natural Language Programming. The necessity of learning lower-level tools (below the level of AI prompting and orchestration) has lessened. It is perhaps fatally weakened. However, senior developers’ skillsets are evolving also, to encompass the new AI toolkits. Junior developers still need – and will use – seniors’ expertise of AI development skills. They also need seniors’ knowledge of best architecture practices, etc.

The bigger concern is that there will be a shortage of junior engineers to train shortly. The industry has caused a deep self-inflicted wound. It will heal, in time, as all wounds do. It will also leave scars. Fears of AI job losses have inverted the cycle of interest in software as a career again. Fewer will sign up for computer science undergraduate courses, and those who have recently graduated have been thrown under the bus, finding it impossible to get a job or work experience in IT. College admissions to computing courses are down 30%. Who can blame them? Why train for a sector in which employment is increasingly scarce? And why train for a sector that develops the means to devastate its own employment opportunities as well as ushering in work practices (like the new regime of agentic development workflows) that cause engineer burnout and even cause voluntary late-stage career exits! Can we blame anyone for eschewing that type of industry?

It won’t just be a problem of a shortage of junior software engineers. There will be a shortage of their would-be mentors too – senior engineers were initially seen as the most costly human component in the agentic AI building era, and were let go in their droves. Their experiential values were jettisoned with them, from an entire industry. Many more senior professionals (even those outside the IT industry) were simply not happy with their new role as clean-up crew for “AI slop”. At least if a human had generated it, you could mentor them, help them to improve their skills for the next time. The best you can hope for from an AI teammate is a slap on the wrist in a markdown file with an instruction not to do it again! Some may never return to the software industry at all. For some senior software builders, the legacy they leave may be … to leave … the entire industry, to abandon it … either voluntarily or involuntarily. ⁶ That is a sad loss of expertise, that the AI-ordered industry commanded be dismissed. We should reflect on that.

Sacrificing humans to the AI Gods

The titans of the AI industry cheerled the dismantling of the social mentorship contract. They sacrificed both younger and older generations of engineers just to astroturf AI product. If we do not transfer that institutional knowledge to human minds, where will it sit in years to come – in a bunch of markdown files, or embedded in AI skills? Perhaps that is the game-plan of the tech titan: lock developers into a dependency on AI, even for their tutoring and mentoring. The few juniors that are hired (at lower cost than seniors) were expected to shoulder the burden of learning architecture level skills ⁷ without experience or the guidance of senior level mentors. Juniors that were thrown to the wolves of AI tutors to develop their understanding of IT systems risk being left with a shallow, and ultimately brittle, expertise ⁸. It is understandable that tech workers acquainted with AI tools would turn first to AI also for their untrustworthy, uninspired mentoring services. The shovel-makers must be rubbing their hands in glee at human mentors displaced by AI.

Why is that human-to-human mentor relationship so important? Why am I emphasising it? Can’t we just run the new order of AI software development without? In a word: no. Here’s why. The goal of apprenticeship is to produce skill, and even an LLM can provide (or at least mimic) skill. Mentoring is different. You can not mentor an LLM; you can only mentor a person. Human mentoring as practiced for millennia, involves asking questions of the mentee to get them to consider and question their own assumptions, inspire their thinking, and open lines of thought not previously considered. The ultimate aim is to inculcate a sense of self-questioning and critical thinking that will serve them career-long and that they can convey to their own mentees during their career. Each generation mentors the next to leave a legacy - a generous, no obligation, investment in which we hope to be ultimately surpassed by our continuation. If there is an ultimate aim, it is that future generations should improve, should learn to look past the era of AI, and all its promises (both achieved and broken) and build something better beyond it.

If the ultimate goal of mentoring is to educe wisdom, it is something essentially human, beyond the capability or understanding of any mechanical devices, no matter how sophisticated they appear to be. Wisdom can pre-empt what the machine can never even foresee. Only an experienced, wise human can know when an automated system may do something stupid, or foresee the pitfalls it may encounter before it does. Only a human can pursue a hunch, request a cost-benefit analysis, that may save millions in sunk AI costs before the self-refining automated-coder even leaves the traps.

AI agents are just the latest iteration of a succession of tools that all promised to be the “silver bullet” for software development difficulties: High Level Languages, Object Oriented Programming, 4GLs, code generation systems. The complexity of software development always remains, and there is no silver bullet, only the tools for dealing with that complexity change, and each comes with its own particular set of challenges. What is needed to recognise and address those challenges is a firm understanding of the foundational principles of computing and software and a knowledge of users (i.e. an understanding of people).

Without human involvement, without human inspiration and human curation of ideas (before they are sent to the AI code presses), there is no true innovation, no novelty, just bland vibe-coded re-hashed copies of existing apps, features, and code (as we are now beginning to discover when we start to see the shape of the software landscape that AI is building). As Brooks stated about AI in his seminal 1986 paper (which still holds valid today) ⁹: “The hard thing about building software is deciding what one wants to say, not saying it.”

The passion we felt for software that set us on that journey, from the first moments we coded a program that made a computer do something, can still be engendered in the next generation. We can spark interest in the hope there’ll be enough next generation engineers for the industry when their time comes again. The many coding club initiatives out there are one way. Though the coding tools may have changed, isn’t it so much easier now with AI for children to create an app that does what they want, just by asking for it? Curiosity and understanding of how it all works will follow. It is easier now than ever to spark that passion for building software.

The self-learning route that starter developers once followed to acquire skills has perhaps become hampered in a world where learning development skills means having an expensive personal token budget to experiment with larger app code bases and with full agentic development workflows – that is hard to acquire for most trainee developers, especially if they have to do so outside of a corporation. It signifies a move away from the open and free availability of tools to (again) needing expensive paid-up subscriptions just to run development systems on hosted AI platforms. While the availability and computer power needed to run open coding models might improve in future, for now the industry should look to return to providing student subscriptions, for tools critical to train themselves for the future of software.

A final point I’d like to make on mentoring in the era of AI is that there are opportunities provided to us today to mentor those outside of our professional circle. With our specialist technical knowledge as software builders and our insider insights in AI we can educate and inform the general public, friends and family. We can contribute with our specialist knowledge and leave a legacy to friends and family either by warning them of the actual dangers (e.g. the nature of interactions with an LLM, hallucinatory responses, etc.) or by assuaging the FUD by clarifying what the characteristics of an LLM actually are, and how they behave (probabilistic inference, etc.) Warning about guardrails, security, data privacy, and all precautions needed in the age of agentic AI (such as AI generated actors phishing) is a noble legacy too. That protective advice could avoid catastrophic personal outcomes.

The beginning of the end, or the end of a beginning?

A question is facing the whole of society right now, not just software builders: do we prioritise investment in AI, or prioritise investment in people? What – or who - is software ultimately built for? Is it built for corporations, or for people, to aid human activity and flourishing, or are humans being asked to build themselves around their AI systems, to be used by the AI systems that are assembling slowly, silently, all around us, absent of human guidance?

What if the apocalyptic fears for AI prove true? If the legacy of the software industry is not to leave admirable monuments to human technical ingenuity for centuries to come, but is rather to destroy the architecture of civilisation and usher in some new dark age (as the naysayers would have us believe), then perhaps it would be best that the economics of AI do implode, that the trillion-dollar deficit be called due, and the grand AI experiment proven financially unviable and the whole house of cards tumble. Maybe we need to learn the hard way that there’s no benefit to people in society of subsidising vast amounts of computation so runaway agents can build lots of agents that just talk to lots of other agents, that bears no relation to human needs or wants.

Though I don’t use AI generated text in my writing, on this occasion it seemed only fair to let AI chime-in on its own legacy. I asked an LLM whether it can leave a legacy and what that legacy might be. Here is what it said (the emphasis is mine):

“An LLM doesn't have a personal life, intentions, or experiences, so it doesn't leave a legacy in the human sense of being remembered for what it chose to do. But an LLM can leave a legacy through its lasting impact.” “So perhaps the fairest answer is: my legacy won't really be mine to choose. It will be the sum of what people do with the help I provide—and whether, overall, that help leaves the world a little better than it was.”

There you have it: the critical difference in our legacy over the legacy of an AI system is: choice.

AI will have a legacy (which even it can not say whether it will be good or bad), but AI is aware that its legacy will be determined by the choices of us humans. And AI’s legacy becomes our legacy, the builders and the users, of AI software.

The fate of AI is really out of the hands of most of us humble developers. It’s a train already coming down the tracks. Most of us don’t drive the evolution of global AI models or unleash malicious AI agents upon the internet, but we are charged with picking up the pieces of this latest transformational trend shift in the IT industry. Software development began decades ago, but that nursery period is over. On the assumption that AI in software development is now a permanent fixture, here to stay, we need to draw a line under the old ways and understanding and embrace the new, as we have always done, and finally decide what professional legacy we each choose to leave.

So the legacy of your work – what you will be remembered for – may no longer be the code you wrote (munged as it will be into one source for AI to draw upon, losing all personal attribution), but how and what you used AI for.

Will you use it to displace other software builders, and eliminate aspiring ones? We are not AI. We have choices. If we treat each other the way we treat AI, if what comes after doesn’t matter to us, then our choices now don’t matter. But if it does, then they do. The choice is ours whether to be intentional or not.

It’s a tumultuous time but there is no need to panic. No need to fear AI will destroy our legacy as software builders. The fundamentals of humanity haven’t changed. Satisfaction at a job well done, quality software that improves the lives of customers and users, and valuable influence on those we have worked with and for… Perhaps, ultimately, the real legacy for us – one we can internalise – is how we feel about the work we have left behind. It’s not about leaving technical product behind. Technology is only a means to an end. What software does for people, the satisfaction of a job well done, and the positive influence we’ve had on those we’ve worked for and with. Nothing can alter that, even if everything else we’ve built gets swept away someday. That has always been a software builder’s true legacy.

References

[1] ‘Godfather of AI’ leaves Google, warns of tech’s dangers

[2] ‘Gambling with our lives’: Anthropic researcher quits, warns against self-improving AI

[3] Steve Ballmer at NET Conference going crazy about Developers!

[4] The New SDLC with Vibe-Coding: From ad-hoc prompting to agentic engineering

[5] Magnifica Humanitas: Responsibility, transparency and the governance of AI

[6] Software developers are not okay

[7] Junior engineers are skipping straight to architect-level thinking: Junior engineering apprenticeships need a redesign.

[8] AI Coding will Prevent Expertise: The need for ongoing friction in long-term skill formation.

[9] No Silver Bullet: Essence and Accidents of Software Engineering