Dear Software Engineer: It's Time to Reclaim Your Role

• December 26, 2024

Apologies, this is a long one - clearly I’ve got a lot to say on this subject!

It didn’t take long after ChatGPT was released for me to start seeing how fundamentally this technology could transform software engineering. Not just as another tool in our arsenal, but as something that could redefine what it means to be a software engineer entirely.

The discourse around this has been fascinating. Jump on LinkedIn or X and you’ll see endless debates about whether AI will augment or replace software engineers, whether it’s just another productivity tool or a paradigm shift, whether it’s overhyped or understated. But I think many are missing the real story - it’s not about whether AI will take our jobs, it’s about how it’s already changing the very nature of our profession.

This transformation has captured my attention deeply. You see, I’m a software engineer. I still call myself one even though it’s been a few years since I actively built software because I’ve been busy leading teams of software engineers for the last few years. But I still think of myself as a software engineer.

You’ll often hear me talk about how much I’ve loved my career, because I genuinely have. Perhaps I was lucky and found my calling at a very young age, but ever since I lay my little 6-year-old fingers on that Commodore 64, I was hooked. Since I believe software engineering has been a great career choice, and I want everyone to experience the same joy and fulfillment that I have, I’ve encouraged many people to consider it as a career over the years.

Until now, most changes I’ve experienced in our field felt more like evolution than revolution. I saw web technologies take off - remember when AJAX became a thing and jQuery was your ticket to building cool dynamic websites? I lived through mobile taking off, cloud computing, CI/CD, and so on. But in many ways, we were just doing the same things with newer toys: new frameworks, new approaches, much more automation.

When AI Changes Everything

What’s happening now with AI, however, feels far more like a tectonic shift than just another iteration of the same old cycle - and my Master’s research is confirming this. The data clearly shows that AI is already having a significant impact on how software engineers work. Not everyone sees it. Not everyone wants to see it. But it’s happening.

Many in our industry remain confident that our roles as software engineers are safe because software engineering is much more than coding. The prevailing argument is that while AI might help us write code faster, the “real” work of software engineering lies in designing systems, making architectural decisions, and understanding user needs. It’s a comforting thought, isn’t it? A neat way to put AI back in its box as just another productivity tool.

I totally agree that software engineering should be a lot more than just writing code. When I studied computer science at university, they taught us how to elicit requirements, write user stories, design user interfaces and apply UX principles, architect complex systems, create test plans, execute test cases and so much more. The whole shebang.

But here’s where it gets interesting: many developers today aren’t actually doing all those tasks anymore. I’m lucky enough that for the first 10 years of my career, when I was an individual contributor, I got to do all these things. I spoke to clients and stakeholders directly, gathered requirements, asked questions, made suggestions, and challenged their assumptions. Ultimately, I was given problem statements and solved them. I wrote frontend and backend code, designed database schemas and built them all from scratch, wrote and fine-tuned SQL queries, configured web servers, set up build pipelines, and monitored how things were running. I felt unstoppable - through hands-on practice, I had gained the skills to build and run software end-to-end. And god, it felt good. At my core, I was solving problems, and that’s what I love doing.

How We Got Here: The Rise of Specialisation

Looking back at that experience now, it feels like a different era. Over the last decade, I’ve watched software engineers step back from many of these responsibilities. Many now focus almost entirely on writing the code, letting others handle everything else.

Why has this happened? Well, I’m sure there are many reasons. I can’t help but wonder if at least part of the reason is that as software needs grew exponentially, the demand for software engineers grew too - and there just weren’t enough of us. So we found ways to divide and conquer through specialisation. We introduced roles like the Product Owner who speaks to the customer and collects requirements for us, so that we can focus on the part that others perceive to be the part that only developers can do - writing the code. In some organisations, there are also Business Analysts analysing requirements, Project Managers coordinating delivery, Designers doing the UI/UX, Architects doing the solution design, Quality Engineers doing the testing, and Platform Engineers setting up the infrastructure, running the pipelines, and generally keeping the lights on.

I’m not alone in noticing this shift. Alex Ewerlöf wrote about this recently in his piece on breaking roles into multiple titles. He sees what I see - how splitting up our craft this way is making us lose the very things that made software engineering special: the ownership, the synergy, the true craftsmanship.

By breaking up what used to be the role of a software engineer into all these disparate jobs, what’s really left? For a lot of software engineers, the only thing that’s really left is writing the code.

Product Engineers vs. Traditional Engineers

To prove my point, new titles like “Product Engineers” have emerged to describe software engineers who do what everyone claims software engineers should be doing - you know, all those things that supposedly keep us safe from AI.

Sherif Mansour wrote a piece describing product engineers as “not traditional engineers”. Another article distinguishes them as unique because they “care about building a solution to problems that provides value to users” - as opposed to just “writing code and shipping features” like traditional software engineers apparently do.

And here’s the kicker. An article from earlier this year describes product engineers as:

In recent years, the software industry has started to adopt the term product engineer to refer to a customer-focused, full-stack engineer who blurs the lines between product and engineering roles. I think of product engineers as generalists who can take an ambiguous problem statement, define a solution to it in collaboration with users or customers, and design, implement, and deliver that solution.

Hang on a second, I thought that was what software engineers did?!

Yikes. Talk about contradiction - our industry claims software engineering is about so much more than coding, yet we’ve created a special new term for engineers who actually do those things, while regular software engineers have become specialised code writers and feature shippers. So much for all those things that were supposed to keep us safe from AI!

“So what?”, you might say. Perhaps there’s room for both. After all, there’s so much demand for software engineers, and maybe some just want to focus on writing the code.

The Game-Changer: Generative AI

That argument might have held water a year ago. But then generative AI came along. Because as it turns out, LLMs (and agentic AI) are really good at writing code, and much, much faster than any human can. And here’s the problem: most “traditional” software engineers today do little more than translate almost-pseudo-code written requirements in user stories into compilable code - exactly the kind of task that AI is becoming better at every single day.

Sure, if you’re one of the rare “product engineers” who actually work on the full spectrum of software engineering, perhaps you’re fine. But remember, we just established that this has become the exception rather than the rule.

What the Data Says

AI’s impact on coding isn’t just speculation. My Master’s research so far has confirmed that AI coding assistants are already reducing the time professional software engineers spend on writing code, with a staggering 78% of 165 respondents across 28 countries feeling they’re spending less time writing code.

I wrote about the potential impacts of AI on software engineering back in February 2024 - An Early Exploration of AI-First Development - and boy has this landscape changed since then. It feels like there are new tools that do more, better and faster being released every single day. My research survey ran for a month in October / November 2024, and I was stunned to see how many AI tools software engineers are already playing with. Windsurf didn’t get a mention but it hadn’t even been released yet!

Steve Yegge and the Stubborn Developer

Steve Yegge recently wrote a follow-up to his controversial article The Death of the Junior Developer, reframing his position as The Death of the Stubborn Developer. He talks about how if you’re not adopting Chat-Oriented Programming, or CHOP, you’re getting left behind.

If you’re not using chop, then you’re plodding. You’re like one of those crusty old assembly-language holdouts still using asm in 1990 because compiler-generated code wasn’t fast enough. Stubborn bastards, the lot of ’em. Sound familiar?

I agree with everything he says in his riveting but lengthy article, except perhaps the part about autonomous software agents. I’ve spent the last month using Codeium’s Windsurf - self-described as the “first agentic IDE” - and I tell you what, it’s absolutely incredible. This is so much more than just chat, copy, paste, repeat. With Windsurf, I tell it what I want and it generates all the code. All of it. And honestly, the code is good. And if it isn’t, I just tell it to fix it and it does! Sometimes it even recognises that it’s made a mistake before I do and it goes ahead and fixes it without me having to say anything. The future is here, my friends.

Cursor is another fantastic IDE that works in much the same way. And then there are countless other web-based tools that can create entire codebases from a prompt, like Bolt, v0, and of course, Lovable.dev which is gaining traction at an incredible rate.

From CHOP to BATON

These tools are just the beginning. I think we’re rapidly moving into an era where humans no longer write code by hand. Instead, we instruct agentic AI systems that use LLMs to do it for us. But it’s not just about one-on-one interaction with AI - the future might look more like managing an entire AI development team. In From CHOP to BATON: The Evolution of AI-Assisted Development, the author explores what comes after CHOP, introducing a new paradigm called BATON - Bot-Assisted Task OrchestratioN:

With BATON, your role shifts from being a hands-on coder to something more akin to a conductor or a project manager. You’re no longer writing every line of code yourself, or even pair programming with an AI. Instead, you’re breaking down projects into well-defined tasks, delegating them to multiple AI systems, and overseeing the entire development process. Need a suite of unit tests written? Delegate it. Have a simple, but annoying feature to implement? Assign it to your AI team.

In other words, CHOP is just the beginning. With BATON, a software engineer’s role shifts from coding line-by-line to orchestrating and overseeing multiple AI “team members,” each responsible for different chunks of work. This represents a fundamental change in what it means to be a software engineer - and a clear signal that we need to expand our skill sets beyond just writing code.

So What Can You Do About It?

If you’re a software engineer and upon reflection suspect you may have fallen into the trap of specialising as a code writer, listen up. It’s time to broaden your horizons. To get started, you could try:

• Participating in all the activities involved in building software, not just writing code
• Requesting problem statements instead of accepting pre-digested solutions disguised as user stories
• Shifting yourself left - joining your Product Owner in stakeholder meetings, asking questions, challenging assumptions, and making suggestions
• Understanding the drivers behind the work by exploring the data and decisions shaping your projects
• Reading Gergely Orosz’s article on the 9 key traits of product-minded engineers and developing those skills

So dear software engineer, please take heed. If you’re not a “product engineer” and have specialised in writing code, AI may indeed take your job. But this isn’t just a warning - it’s an opportunity. It’s time to reclaim your role and return to what software engineering was always meant to be: a craft that combines technical expertise with problem-solving, user empathy, and business acumen. The future belongs to those with curiosity who can see beyond the code.