Your Identity Is Not Your Code

There's a pattern I keep seeing with senior engineers and AI coding tools. They've tried Claude Code or Cursor, maybe six months ago, and they came away unimpressed. "It's fine for boilerplate but it writes spaghetti code." Or: "I still have to fix everything it produces."

Six months ago, that was a fair take. It's not what's happening any more, and I think the real reason some senior engineers are still saying it has less to do with the tools and more to do with something much harder to talk about: identity.

The Grief Nobody Talks About

If you've spent fifteen or twenty years refining the craft of writing code, you've built an identity around it. You're the person who writes clean, elegant, well-architected software. You take pride in your variable names, you have opinions about monads, and you can look at a pull request and feel, in your bones, whether it's right.

That identity is under threat. When your identity is under threat, the most natural reaction in the world is to protect it. The easiest way to protect it? Find reasons why the threatening thing isn't actually that good.

"It just writes spaghetti code." Identity protected. Crisis averted. For now.

The problem is that the models have gotten a lot better since then.

The Models Got Better While You Weren't Looking

I'm not going to pretend that every LLM output is production-ready. But Opus 4.6, Codex 5.4, the latest generation of coding models? They write code that is well-structured, idiomatic, and handles edge cases you might have missed yourself.

Of course they still require supervision. They still need a human who understands architecture, who can spot when the model is heading down the wrong path, who can craft the right prompts and put the right guardrails in place. That human is you, and that supervision is where your identity needs to migrate to.

What "Senior" Always Meant

Here's what I think a lot of people are missing: the core of being a good senior engineer was never primarily about the act of writing code. It was about creating high-quality, robust software that solves real user needs. The code was always just the mechanism for getting there.

Think about the trajectory. Compilers abstracted away machine code, high-level languages took care of memory management, and IDEs gave us refactoring tools and code completion. Each of these reduced the amount of raw code-writing a senior engineer had to do, and each time, the good ones adapted by moving up the stack.

Vibe coding is the latest addition to that tool chain. Yes, it moves you further away from writing code by hand, but it hasn't changed the job at all. You're still the person responsible for shipping robust, well-architected software, just with better tools.

As I wrote in Correctness Over Determinism, what matters is whether the software works, not the specific lines of code that make it work.

The Mistake That Locks You Out

The most common mistake I see is a timing problem. Senior engineers tried these tools six or twelve months ago, when the tools weren't quite there yet. And, critically, the engineer didn't invest the time to really learn them. So the experience was underwhelming, and they walked away.

Fair enough. The world didn't stop, though.

Between the new models, the new tooling, and the investment required to learn how to use them properly, there's a threshold that many engineers haven't realised has been crossed. What was a toy twelve months ago is now a serious force multiplier, and you have to show up again to find that out.

This isn't one-shotting a prompt and hoping for the best. It's about thoughtful prompting, putting together the right infrastructure and review processes, collaborating with the AI on architecture. Using these tools to amplify your engineering skills, not replace them.

Who Gets Left Behind

The engineers who struggle with this transition won't be the ones who lack technical skill. More often, it'll be the ones who don't quite have the confidence to let go of their existing identity and build a new one. The ones who are fearful of change, who cling to what they know because the alternative feels like starting over.

If your sense of professional worth is entirely wrapped up in "I write excellent code," then yes, the next few years are going to be uncomfortable. But if you can reframe it around "I build excellent software," you'll find that these tools actually make you better at the part of the job that always mattered most.

If you're curious what that looks like in practice, have a look at the companies in our directory. They're hiring for exactly this kind of engineer.

I think most senior engineers, once they get past that initial discomfort, will actually find they're better equipped for this shift than almost anyone. Twenty years of building software teaches you what good looks like, and that doesn't go away because the tools changed.