Early in my career, I took a job as a software developer at a large consultancy. Turns out the work mostly involved fixing other people’s Access databases by right-clicking and hitting “repair”. I lasted about a month before I thanked them for the opportunity, handed in my resignation, and moved on.

The point is: what you spend your time on defines what you think about. What you think about is what you practice. And what you practice is what you build skill on. The title said “software developer” but the daily work said something else entirely.

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.