Who Should Lead Your AI Engineering Transformation?

Every week we’re inside engineering organizations helping them figure out how to ship faster with AI. And lately we keep getting the same question: who do we hire to lead this?

Someone will say, “We want to bring someone on for this role — what should the job title be?”

And honestly, that question itself tells us a lot about where they are in the journey.

Not a New Role. A Evolved One.

When someone asks about the job title, there’s often an assumption baked in — that this is some new, emerging category. AI Engineer. Head of Agentic Tooling. Director of AI Transformation.

No.

This is a principal engineer. That’s the title. This is just what software engineering is becoming, and you need someone who’s senior enough to understand that and lead the team through it.

Here’s the framing that changed how we think about it: our job as engineers used to be to write code. Now our job is to build systems that write code. That’s a fundamentally different thing, and not every engineer is ready to make that mental shift. But a principal-level engineer? That’s been their job all along.

Think about what a principal engineer actually does at most companies. They design architecture. They work across the stack. They improve the developer experience. They care about the full software development lifecycle — not just their slice of it. They influence how the team works, not just what the team ships.

Insert AI into each one of those responsibilities and nothing really changes structurally. What changes is the tooling, the leverage, and the speed.

The Six-Month Rule

Here’s the filter we’d put in any job description for this role:

Has written code professionally for 10-20 years, but hasn’t written a line of code in the past six months.

That sounds like a paradox, but it’s not.

What you’re looking for is someone who has so much experience — who has built enough trust in the systems they’ve put in place — that they no longer need to write code themselves. They’ve already made the transition. They built something, probably over the past year or two, that does the building for them. And they’re comfortable with that. They’re not attached to writing code for its own sake.

That’s actually harder to find than it sounds. Most engineers, even senior ones, still feel the pull of the keyboard. They want to be in the code. There’s identity wrapped up in it. The people who’ve genuinely extracted themselves from that and shifted to operating at the system level — those are the people who can lead this transformation.

The proof is in what they bring to the interview: not a GitHub repo of code they wrote, but a GitHub repo of the system they built to write code. That’s a different thing entirely.

DHH and Linus Already Figured This Out

Six months ago, both DHH — creator of Rails — and Linus Torvalds said they didn’t want AI-written code in their projects. DHH was pretty vocal about it. Linus said the same about the Linux kernel.

Now? Linus has said publicly that AI writes code better than he does. And AI-written code is in the Linux kernel.

If the creators of two of the most influential software projects in history have made their peace with it, the debate is over. The question isn’t if your engineering organization adapts — it’s who leads that adaptation and how fast it happens.

This is why we think the title should be principal at minimum. Some organizations will want a staff engineer. At larger shops, maybe a distinguished engineer who can drive culture change across the entire org. But whatever the level, it needs to be someone with the credibility and the experience to shift how an entire engineering team operates — not just someone who’s good at prompting.

The Problem With “AI Engineer”

When someone asks about hiring an “AI Engineer” for this role, it signals they think of this as a narrow technical specialty — a sliver of the engineering organization.

It’s not a sliver. It’s the whole thing.

Leading agentic engineering at your organization isn’t one team’s concern or one platform’s responsibility. It touches every product, every service, every workflow. Frontend, backend, infrastructure, CI/CD, code review, testing — all of it. That’s why you need someone who’s seen the full SDLC, not someone whose resume says “prompt engineering” or “LLM integration.”

This connects to something we’ve written about before: the AI Champion playbook works at the grassroots level for spreading adoption, but you also need someone with organizational authority to set the direction. A champion convinces teammates. A principal engineer changes how the whole organization builds software. Those are different levers.

Iterating vs. Rewriting

There’s always this impulse, when things feel broken, to throw everything out and start fresh. We understand it. We’ve both been through 20 migrations over our careers and we know the pattern: the first 80% goes well, then the last 20% nearly kills the project, and by the time you ship, the thing you built is about as messy as the thing you replaced.

The instinct to rewrite is often fear dressed up as pragmatism. Engineers are afraid to touch the old system — afraid they’ll break it — so they convince themselves the only path forward is a clean slate. We’d push back on that.

The better approach is iterative improvement. Take your existing SDLC, find the bottlenecks, and insert AI into each stage. You don’t need a revolution. You need a series of targeted upgrades that compound over time. The right principal engineer will know how to sequence that — which things to fix first, which legacy systems to route around, and which ones are actually worth rebuilding from scratch.

We’ve written about this more directly in velocity engineering — the idea that you’re not trying to do the same things faster, you’re redesigning the system that produces software.

How to Interview for This

The interview format needs to evolve alongside the role.

The old technical interview — whiteboard a sorting algorithm, solve a LeetCode problem under pressure — tells you almost nothing about whether someone can lead an AI-native engineering org. You’re evaluating the wrong skill.

Here’s what we’d look for instead:

Technical deep dive: show me what you built. Not what code you wrote — what did you build? How does the system work? Walk us through the architecture. How did you make the decisions you made? This tells you how deeply they understand their own system, how involved they actually were, and whether they can articulate engineering tradeoffs. Even with AI in the loop, you should still be able to go deep on what you shipped.

Live planning session. Give them a real problem — something with actual scope, not a toy example. Ask them to research it, plan it, and produce a planning document. See how they work with AI to structure the approach. A good candidate will know what a strong plan looks like and be able to defend the choices in it. You’d probably know pretty quickly whether they’re operating at the right level.

The execution phase is genuinely tricky to simulate in a one-hour interview — when Claude’s running in the background, there’s not much for the candidate to do but watch and confirm. So lean on the planning phase. A solid planning doc tells you a lot about how someone thinks.

The key question underneath all of it: did they build this by writing code, or by building a system? If the answer is the former, they’re probably not your candidate.

Get Out of Their Way

Once you’ve hired the right person, the last thing you want to do is micromanage them.

We see this pattern constantly: organizations go to the trouble of bringing in a senior technical leader, and then management bogs them down in approval chains, status meetings, and org politics. It kills momentum and drives good engineers out.

The value of a principal or distinguished engineer in this role is that they can move fast and drive change across the whole organization. That requires autonomy. Real autonomy — not the “we trust you” speech followed by weekly check-ins where nothing gets approved.

If you’re hiring someone to transform how your engineering org builds software, your job as leadership is to set the goal, give them the runway, and get out of the way. This is the kind of role where micromanagement doesn’t just slow things down — it makes the role impossible.

The AI adoption mistakes we see most often come down to exactly this: the right idea, the wrong execution, because leadership can’t let go of control long enough to let the change take root.

The Bottom Line

If you’re trying to lead an AI engineering transformation at your company, here’s the job description in plain English:

Senior enough to have seen the full SDLC, including infrastructure and platform
Has shipped a lot of code over a long career
Hasn’t written a line of code in the past six months — but has built systems that do
Can drive culture change across an entire engineering organization
Shows up to the interview with a system, not a portfolio

Title? Principal engineer at minimum. Staff or distinguished if your org has the scale to support it. And whatever you call them, give them the authority to actually do the job.

The engineers who are going to lead this transition aren’t the ones still attached to writing code by hand. They’re the ones who built the system, stepped back, watched it run, and said — that works.

That’s your hire.

This post is based on Episode 6 of The Velocity Lab. Listen on Apple Podcasts.