Getting existential about AI and my profession.
Over the pastāI would sayāyear and a half, Iāve watched artificial intelligence transform the way software engineers work at what feels like an exponential rate. When AI coding tools first appeared in my workplace, they were optional. A few developers were given licenses to experiment with them. They gradually became normal, then expected, and now, measured.
Each month, a leaderboard gets posted on Slack showing the number of tokens each developer has used. Naturally, a significant portion of my day is now spent writing prompts instead of code.
My views on these tools have also changed over time. Early on, it was easy for me to dismiss their utility. The models constantly hallucinated. They misunderstood context. They produced convincing but subtly broken solutions. I often compared it to working with a junior developerāexcept one engineered to exhibit the DunningāKruger effect.
But the ecosystem around them kept improving. Context windows grew. Tooling improved. Non-LLM infrastructure became more tightly integrated: debuggers, retrieval systems, agent frameworks, and MCP servers feeding structured context into models.
Agentic coding tools today are vastly more capable than they were a year ago. And if the last year is anything to go by, they will keep getting better.
Software engineering as a profession has never been centred purely around writing code. At least, thatās what weāve always told ourselves. The real skill, we say, is understanding problems: the ability to break them down, anticipate edge cases, consider trade-offs, and design robust, scalable systems. Code is just our medium.
For a while, this way of looking at software engineering worked to comfort me. If AI could generate the code, that was fine. Someone still had to design the system, reason about constraints, and guide the process. Software systems are complicated, and turning ambiguous human needs into working systems still requires human judgement.
But thereās another perspective that matters just as much: business.
If an AI-assisted workflow appears to produce working software faster than a traditional one, then from a business perspective the decision is fairly straightforward. What matters is that it worksāor at least that it appears to workāand that it was delivered quickly.
After spending some time in the corporate world, you quickly learn the importance of optics. Businesses value visible outcomes: progress that can be demonstrated in a demo, summarised in a metric, or displayed on a dashboard.
AI tools are exceptionally good at creating that impression. Even when the results are imperfectāwhen the software works on the surface but underneath is built on shaky assumptionsāthey dramatically increase the apparent speed at which software can be produced.
So while us engineers debate the philosophical limits of AI, organisations will continue adopting the tools that maximise throughput and, just as importantly, the appearance of throughput.
Slowly, almost imperceptibly, the job begins to change.
Iāve noticed that some engineers are thriving in this new age of software engineering. They build sophisticated agent workflows, integrate custom MCP servers, and design elaborate prompt chains and tool pipelines. They orchestrate multiple systems at once while jumping between tasks, constantly refining their setups as new tools and models appear. Keeping up with the latest developments in AI has become part of their craft.
It feels like a different profession than the one I thought I was entering. Iāve realised that I donāt particularly enjoy talking to a chatbot all day. Learning about MCP and the surrounding infrastructure has been interestingāthese parts of the system feel closer to traditional engineeringābut the centre of gravity has clearly shifted elsewhere.
And in an industry that moves this quickly, thereās always the unspoken pressure to adapt before the next round of layoffs reminds you what happens if you donāt.
When I first learned to program, there was something magical about it. The idea that you could sit in front of a computer, write a few lines of text, and watch an idea turn into something real. I found deep satisfaction in writing code that was efficient, logically sound, and clean.
For a long time, I used to say that I was lucky to have found a passion that also happened to be my career. Lately, though, Iāve started to wonder if that belief was a little naĆÆve. I chose a profession defined by constant change.
Software engineering has always been a discipline built on abstraction. Each generation invents tools that make the previous layer disappear. Assembly gave way to high-level languages. Those gave way to frameworks. Frameworks gave way to platforms. AI may simply be the next layer.
Maybe the future of software engineering isnāt about writing lines of code anymore. Maybe itās about orchestrating the systems that produce them. Yet, even as the tools advance, I wonder how much of the path before us is truly set, and how much we still get to define.
The future might be more powerful. More efficient. More economically rational.
But Iām still trying to figure out what it means for those of us who fell in love with the craft of writing the code ourselves.
