The Software Engineering Identity Crisis

• March 21, 2025

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.

The irony cuts deep: for years, we’ve said that software engineering transcends mere coding. Requirements, design, testing, operations - these were all supposedly part of our craft. Yet the industry pushed us in the opposite direction. We handed these responsibilities to specialists - Product Owners, Architects, Quality Engineers, Platform Engineers - while we doubled down on our coding expertise. We became masters of our code, proud wielders of a modern magic.

And now, just as we’ve perfected this craft, AI is threatening to take it away from us.

The Joy We’re About to Lose

Let’s be honest about what’s at stake here. Many of us don’t just write code - we love writing code. Our identity is woven into every elegant solution we craft, every test we make pass, every problem we solve through pure logic and creativity. It’s not just work, not just a craft - it’s who we are.

Think about those moments of deep satisfaction: when you finally track down that elusive bug that’s been haunting production, when you work out how to optimise that slow algorithm and watch response times drop from seconds to milliseconds, when you transform a maze of legacy code into something clean and maintainable. These aren’t just achievements - they’re expressions of who we are as engineers. They’re the moments that remind us why we chose this path.

Now imagine AI taking over these moments of craftsmanship. The creators of these tools paint an optimistic picture - they say we’ll spend more time on defining intent, high-level architecture, and systems thinking. But listen carefully to what they’re really saying: we’ll become overseers rather than creators, managers rather than builders.

This shift raises important questions about our identity as builders: Is oversight what drives us? Is it what makes us leap out of bed in the morning, eager to solve the next puzzle?

The Identity Shift: It’s Already Here

This isn’t some theoretical future we’re debating - it’s the reality we’re living right now. When Google recently revealed that AI generates more than a quarter of their new code, it was just the beginning. Y Combinator CEO Garry Tan reveals that for about a quarter of their startups, 95% of their code is now written by AI - marking a truly significant shift. My own Master’s research revealed a similar picture: 77% of us are spending less time writing code, and almost half believe our core skill might become secondary to prompt engineering. Think about that transition: from crafting solutions to crafting prompts.

When asked how to develop prompt engineering skills, software engineers emphasise refining communication skills. Getting an AI to do what you want means being able to articulate things well - providing just the right amount of context along with a clear description of the task. The better you can communicate with Gen AI, the more likely the output will match your expectations. Some even suggest being polite to these tools, treating them like team members - as if you’re leading another human being to do something for you.

The changes run so deep that we’re inventing new terms just to describe who we’re becoming. Take vibe coding, a term that Andrej Karpathy recently coined in a tweet. It captures a profound shift in how we write software.

At one end of the spectrum lies the traditional way - the craftsperson’s way. We write each line with intent, every function name and architectural decision reflecting our deep understanding of the system.

At the other end? We let AI fill in the blanks, “vibing” with its suggestions. We focus on the what, not the how. As Karpathy puts it: “fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

That last part gives us pause - are we still engineers if we forget all about the code?

In a recent pairing session, engineering thought leaders Gene Kim and Steve Yegge demonstrated what this looks like in practice. Using an AI coding assistant, they ported a 3,500-line legacy Ruby script to Kotlin - a task that would normally take a week - in just one hour. The AI didn’t just translate the code; it improved it, adding the modular architecture and unit tests they’d wanted for years but couldn’t justify the time for.

Even Patrick Debois, the godfather of DevOps, sees this transformation reshaping our identity. In his recent analysis of AI Native Development patterns, he outlines four fundamental shifts in how we work:

These patterns reveal a profound shift: we’re moving from producers to managers of AI systems, from detailed implementation to expressing intent, from delivery to discovery through rapid experimentation, and from content creation to knowledge curation. Our role is evolving to blend creation with orchestration, building with oversight.

Overall, I think it’s fair to say that the nature of our professional identity is changing at its core.

The Craft That Shaped Our Identity

To understand this identity crisis, we need to look at how deeply the craft of coding has shaped who we are. At its core, writing code is about mastery and control - skills we’ve spent years perfecting. Modern programming languages are much higher-level than those of days gone by, but they still require deep technical understanding. Few developers today deal with the nitty-gritty of pointers and memory management, yet we still take pride in knowing how things work under the hood. Even as frameworks do more heavy lifting, we’ve maintained our identity as artisans who understand our tools intimately.

Programming today is much more about stitching together APIs, frameworks, and libraries in creative ways to build something meaningful. In fact, recent research at Google suggests that creativity in software engineering centres on the concept of clever reuse over pure novelty. This makes sense to me - I’ve often commented that we’re all just ‘integration’ engineers nowadays, really.

Still, there’s a strange pride that we take in knowing all the weird syntax required to build something. It’s like a secret language that only we understand. Becoming proficient with a programming language gives you a lot of control to make it do precisely what you want it to do. It’s so detailed - just one wrong character will break the entire thing and it can take a lot of time and patience to make it do what you want.

First, one must perform perfectly. The computer resembles the magic of legend in this respect, too. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn’t work.

— Frederick P. Brooks, The Mythical Man-Month, Chapter 1, Addison-Wesley, 1975

The other 99% of the population thinks we’re magicians for understanding code and indeed, it can take years of deliberate practice to master it. Those who master more than one programming language have the privilege of being referred to as polyglots. Many of us take great pride in writing clean, elegant code. We passionately argue over different styles and best practices, often taking it all too seriously.

A Reluctant Manager’s Tale

Let me share a story about identity evolution that might resonate.

After a decade of being an individual contributor, I hit the infamous ceiling of the technical track. Senior Lead Software Engineer - that was as far as the technical track went. Staff+ Engineering wasn’t a thing yet, and the sole Architecture position at the company I was working for was filled. I faced a choice that would change who I was: stay a builder or become an overseer.

I chose management. Reluctantly. That’s where the path led me. I told myself it was still engineering, just at a different level. That managing systems wasn’t so different from managing people. That I could still keep my hands in the code in between other tasks.

Sound familiar? The parallels are uncanny. Just as I had to trade direct problem-solving for meetings and documentation, we’re now being asked to trade coding for prompt engineering. The skills that defined us as engineers - mastering syntax, architecting our code elegantly, catching and handling the edge cases, debugging complex issues - are being relegated to AI. Instead, we’re told to focus on skills that sound suspiciously like management: clear communication, systems thinking, problem definition.

But here’s what no one’s talking about: the identity crisis. That deep sense of loss when you realise you’re no longer building things with your own hands. When your technical mastery becomes less relevant than your ability to “manage” the tools. When your craft becomes oversight.

Can orchestrating AI ever give us that same sense of identity? Of being a builder, a creator, a problem solver?

When Machines Challenge Our Identity

By now the source of our identity crisis becomes clear. The craft we spent years perfecting - the one that gave us purpose, meaning, and pride - is now being done faster, cheaper, and at scale by a machine. Sure, the quality isn’t as good as your hand-written code (yet). But the speed at which code can now be written is staggering and businesses are tripping over themselves to get in on the action.

This is where a glimmer of hope emerges. Remember that irony - how we gave away the broader aspects of our craft to specialists? AI is pushing us to reclaim what we once knew: that software engineering transcends mere coding. That core truth remains - ultimately, software engineering is about solving problems, creating solutions, building things that matter.

These broader skills - what Addy Osmani calls “durable engineering skills” in his article on the human 30% of AI-assisted coding - have always separated great engineers from good ones. Communication, big-picture thinking, handling ambiguity - these become even more crucial in an AI-driven world.

Yet this emphasis on broader skills has sparked debate in our community. For some, it sounds suspiciously like management repackaged. And they’re not entirely wrong - a recent CIO article confirms that development teams are already being restructured to focus on oversight rather than creation. The article envisions future teams consisting of a product manager, a UX designer, and a software architect who primarily uses AI to generate prototypes. These architects, or senior developers, must “understand the content… who the customer is and what we’re trying to achieve” - classic management responsibilities repackaged as technical work.

This evolution raises fundamental questions about our identity as engineers: As the traditional career ladder transforms, how will the next generation of software engineers develop their skills? How do we preserve the deep technical understanding and craftsmanship that shaped our profession while embracing these new tools? And perhaps most unsettling - as AI capabilities advance exponentially, will our role as craftspeople become as obsolete as the manual weaver’s did during the Industrial Revolution?

The Path Forward

Perhaps the answer lies not in resisting this transformation, but in understanding it through the lens of history. These identity crises - these fundamental shifts in how we define ourselves through our work - aren’t new. They’re part of a pattern that repeats whenever technology reshapes a profession.

During the Industrial Revolution, craftspeople faced a similar crisis. Their traditional skills - honed over generations - were being replaced by machines. But what happened next is fascinating: many adapted, becoming specialist professionals who could fix and improve these same machines that threatened to replace them. Others found ways to apply their deep understanding of materials and processes to improve overall factory operations.

If we draw this parallel to our AI era, a similar path emerges. The core of software engineering - solving problems and creating value - remains unchanged. Our tools are evolving, and with them, the skills needed to wield them effectively.

The question isn’t whether we’ll become managers of machines - it’s whether we can find the same satisfaction in this evolution of our craft.

The Engineer’s Dilemma

So where does this leave us? Are we all destined to become overseers of AI agents rather than writers of code? Is this a future to resist or embrace?

The truth, as always, is nuanced. Just as some engineers naturally gravitate toward management while others prefer to remain hands-on, we’ll likely see a similar spectrum emerge in how we interact with AI. Some will excel at orchestrating AI systems, focusing on high-level design and making these systems more efficient and reliable - conducting a technical symphony rather than performing solo. Others will find their calling in domains where human expertise remains crucial - perhaps in security-sensitive applications, novel areas where AI lacks training data, or systems where performance and reliability are paramount. The key isn’t to resist this evolution, but to find our place within it.

What’s clear is that the definition of “software engineer” is expanding, not contracting. The skills that make someone valuable are diversifying. And this creates both challenges and opportunities.

For those who love the craft of coding, this shift can feel threatening. But remember that AI tools are still just that - tools. They don’t understand the “why” behind the code, the business context, or the human needs being served. They can’t innovate in the true sense of the word, at least not yet. And as far as we know, they can’t feel the satisfaction of solving a complex problem or the joy of creating something new.

Perhaps the most valuable skill in this new landscape isn’t prompt engineering or systems architecture, but adaptability - the willingness to evolve, to learn new skills, and to find your unique place in a rapidly changing field.

The Bright Side

Despite these challenges, there’s something important we need to acknowledge: these AI tools can be incredibly empowering. With agentic IDEs like Windsurf and Cursor taking software development to a whole new level, it’s like having a supportive pair-programming partner who’s always there, ready to help you tackle problems that might have seemed daunting before.

For junior developers or those of us who might feel a bit rusty, AI assistants can be a confidence booster - helping you get started when you’re staring at a blank file, validating your approach when you’re unsure, or explaining complex concepts in a way that makes sense to you. For experienced developers, they’re like having a tireless assistant who can handle the routine tasks while you focus on the more challenging aspects of the problem.

The speed at which we can now prototype ideas, explore different approaches, and learn new technologies is truly remarkable. What might have taken weeks of research and trial-and-error can often be accomplished in hours or even minutes. It’s like having a superpower - the ability to amplify our capabilities and turn our ideas into reality faster than ever before.

The Reality Check

But with great power comes great responsibility. A recent comprehensive GitClear study analysing 211 million lines of code revealed some concerning trends as AI code generation tools became more prevalent:

• A 17.1% increase in copy-pasted code, marking the first time AI-assisted code duplication surpassed refactored (moved) code.
• An 8-fold rise in duplicated code blocks, with 6.66% of commits now containing repeated code sections.
• A 26% increase in code churn, with 5.7% of all code changes being revised or deleted within two weeks.

While we’re producing code faster than ever, we’re also spending more time fixing AI-generated mistakes and dealing with code that’s harder to maintain. This isn’t just about speed - it’s about the craft of writing sustainable, maintainable software.

The Hidden Identity Crisis

Yet beneath these surface-level changes lies a deeper challenge - one that strikes at the heart of who we are as engineers. The emerging field of Human-AI teaming is revealing uncomfortable truths about our future. A 2024 study shows that when humans and AI work together, the results often fall short of expectations. Not because AI lacks capability, but because trust works differently with machines than with humans.

We don’t build trust with AI the way we do with human teammates.

With humans, trust grows gradually, through shared success. Each problem solved together strengthens the bond. Even failures can deepen trust when handled well. With AI, trust often starts high and erodes fast.

Every incorrect response, every hallucinated bug fix, every misplaced confidence weakens our faith in the machine. Unlike human relationships where trust typically grows over time, AI trust often peaks early and declines.

And when trust erodes, so does productivity.

The research reveals why:

• There’s an inherent unpredictability in how AI interprets our intentions
• It lacks the contextual awareness that makes human collaboration fluid
• Its decisions often lack transparency, making it hard to rebuild trust once lost

These challenges mirror what many of us experience when transitioning into technical leadership. Just as new engineering managers must learn to trust their team’s work without doing it themselves, we now face a similar transition with AI - learning to guide and verify rather than write every line ourselves.

The reality is stark: despite AI’s raw capabilities, teams often perform worse with AI than without it. Just as a team’s productivity suffers under ineffective leadership, our effectiveness diminishes when we don’t understand how to work with our AI tools.

Reclaiming Your Identity

Drawing from both my journey as a reluctant manager and my research into this AI transformation, I see three ways we might preserve our identity as builders:

1. Resist - Some will choose to focus on domains where human creativity and deep technical expertise remain essential
2. Adapt - Others will embrace AI orchestration, becoming conductors of a new kind of technical symphony
3. Balance - And many, like myself, will seek a middle path - using AI for routine tasks while preserving the joy of direct problem-solving

Then I had a realisation that changed my perspective: We don’t have to choose just one path.

The Identity Pendulum

Perhaps the answer to our identity crisis lies in the Engineer/Manager pendulum. My own journey between these roles taught me something crucial about identity:

• Management didn’t replace my engineering identity - it expanded it
• Returns to hands-on work weren’t steps backward - they were identity renewals
• The pendulum swing itself became part of who I am - adaptable, growing, evolving

And that’s when it hit me: This is exactly the model we need for the AI age.

Instead of being forced into permanent “AI managers,” what if we could swing between:

• Deep technical work where we write and refine code directly
• Strategic orchestration where we guide AI systems
• Creative problem-solving that combines both approaches

This balanced approach resonates deeply with what I’m hearing from fellow engineers. My research shows a clear message: maintaining strong engineering fundamentals is more crucial than ever. We need deep technical knowledge to effectively review, verify, and adjust AI-generated code - because it’s often not quite right. When asked about their concerns with AI coding assistants, software engineers ranked code quality and security well above job security.

That tells me something profound: we see ourselves as guardians of engineering excellence, ensuring that AI-generated solutions adhere to solid software engineering principles. We’re not looking to delegate our expertise to AI - we’re evolving to apply our craft in new ways.

Your Move

As we navigate this transformation, a fundamental truth emerges: our identity crisis isn’t really about AI at all. The research into Human-AI teaming, the parallels with management transitions, the pendulum of roles - they all point to something deeper. Beyond choosing between builder or overseer lies the heart of who we are: creators.

And now we come full circle: AI isn’t taking our jobs; it’s giving us a chance to reclaim those broader aspects of our role that we gave away to specialists. To return to a time when software engineering meant more than just writing code. When it meant understanding the whole problem space, from user needs to business impact, from system design to operational excellence.

The pendulum metaphor offers us wisdom here. Just as many of us have swung between engineering and management roles, we can embrace a similar fluidity with AI. Some periods we’ll dive deep into the code, experiencing that thrill of crafting elegant solutions. Other times we’ll step back to guide AI systems - not as overseers, but as master builders who understand every part of their craft. Like the Industrial Revolution’s workers who became experts at optimising the machines that transformed their craft, we can master these AI systems - making them instruments of our creativity, not replacements for it.

In the AI era, what matters most is preserving the essence of who we are: that pure joy of building things, of solving hard problems, of making something work exactly right. Our engineering excellence runs deeper than just verifying AI’s work - it flows from knowing systems so intimately that we can shape them, improve them, transform them.

The choice isn’t whether AI will change our industry - it already is. The real choice is how we evolve with it. Will we cling to an outdated sense of what it means to be an engineer? Or will we reclaim our craft, not as mere coders, but as master builders of AI-augmented systems?

The pendulum is swinging - will you hold your ground, or move with it?