I’m writing this having just landed back in New Zealand after a very long journey home from Utah. On the final leg from Houston to Auckland, I found myself wedged between a retired industrial chemist and a theoretical physicist who was reading a C++ book. I couldn’t not say anything.

We ended up in a brief conversation about the future of software engineers. He was learning memory management for a trading firm. He thought AI-generated code was “pretty crap”. He’d also noticed, though, that engineers around him were losing their jobs.

Last year I wrote that 2024 was a “massive year” and that “even that feels like an understatement”. I had no idea what was coming.

2025 was bigger. It challenged me in ways I hadn’t expected, opened doors I didn’t know existed, and at times left me wondering how I was going to fit it all in. I felt constantly busy, rushing from one thought to another, building on momentum, but at a pace that sometimes caught me off guard.

In the years I’ve been building software, I’ve lived through more than a few waves. My first taste of code was in the mid‑80s, typing BASIC into a Commodore 64 where you couldn’t even save your work to a hard drive. In the mid‑90s, scripting in mIRC and hand‑rolling simple HTML sites felt cutting edge. The early 2000s were all about desktop apps, then web apps that suddenly got a lot more dynamic - yet for a while, Flash was still the only way to refresh part of a page without the user hammering the browser’s refresh button. Then AJAX arrived and changed that.

When I came across a recent Harvard Business Review article on the hidden penalty of using AI at work, it wasn’t the AI part that stood out to me, even though I’m studying this very topic as part of my Master’s of Engineering. Yes, the AI findings were interesting, but what stopped me in my tracks was something else: the “competence penalty” women pay.

The research put numbers to it:

The competence penalty was more than twice as severe for female engineers, who faced a 13% reduction compared to 6% for male engineers.

The experiment was simple: engineers reviewed the exact same piece of Python code, with the only difference being whether they were told it had been written with the assistance of AI. Turns out women are essentially carrying a heavier burden of doubt for the same contributions.

A few weeks ago, I had a conversation that’s stayed with me. A colleague from another department said: “I’ve always been able to read and understand code, even debug it, but I could never write it.”

Something about this revelation stayed with me. Most people I’ve met outside the software engineering world tend to describe code as unintelligible - like hieroglyphics. I guess that’s why I’ve always assumed: if someone couldn’t write code, they probably couldn’t read it either.

The recent releases of Claude Code and OpenAI Codex caught my attention, but not for the reasons you might expect. I was puzzled by the enthusiasm they’ve generated. These are, after all, terminal tools. In an era where graphical IDEs dominate, with tools like Cursor, Windsurf, and VSCode evolving toward ever-more seamless integrations, like ‘Design Mode’, why are we getting excited about terminal-based AI coding tools that feel like a step backwards?

We don’t talk enough about the feeling of learning something deeply - the slow, sometimes frustrating and painful process that forges real intuition.

As software engineers, we know this feeling intimately. The slow burn of mastering a new concept or language. The pressure and anxiety of resolving your first production issue. The endless hours spent debugging a complex system that just won’t work - until, at last, it does. And how that struggle itself is the point: it’s what transforms a beginner coder into a software engineer with real intuition.

Many of us became software engineers because we found our identity in building things. Not managing things. Not overseeing things. Building things. With our own hands, our own minds, our own code.

But that identity is being challenged.

AI coding assistants aren’t just changing how we write software - they’re fundamentally transforming who we are. We’re shifting from creators to orchestrators, from builders to overseers. From engineers to something that looks suspiciously like… managers.

In an era where tech stacks grow ever more complex and teams become increasingly specialised, there’s profound wisdom to be found in looking back at simpler, more effective approaches.

I’ve been meaning to write about my experience at Trade Me for years. Earlier this week, I attended the launch of Rowan Simpson’s new book, How to Be Wrong. Rowan hired me into his team at Trade Me back in 2006, and to my delight, I even earned a mention in his book! That unexpected recognition, along with recently reading this article about Trade Me’s journey toward a “thinnest viable platform”, finally motivated me to reflect on what remains one of my best professional experiences to this day.