The AI-Native
Engineering Team:
What 12 Years of
Hiring Taught Me

I've been hiring engineers for twelve years. Across a co-founded startup, a series-A company, and now a global enterprise serving Fortune 500 retail and fuel brands across the US. I've directly hired around 25 engineers across the full stack — made great calls and bad ones, built teams from zero, and inherited teams that needed rebuilding. I thought I had a pretty clear mental model of what I was looking for.

Then AI happened. Not in the hype sense. In the practical, day-to-day tooling sense. GitHub Copilot showed up in developers' editors. ChatGPT became part of the debugging workflow. Cursor changed how people thought about code generation. Slowly, then all at once, I realized that the criteria I'd been optimizing for in engineering hiring were shifting under my feet.

This post is about what I'm actually changing in how I hire — and why. Not theoretical. Not trend-following. Based on what I've observed building and managing AI-augmented engineering teams over the past two years, including some things I got wrong early on.

What GitHub Copilot Actually Changed

The question isn't "is Copilot useful?" — it obviously is. The more interesting question is: what exactly did it change, and for whom?

GitHub's own research (Kalliamvakou, 2022) found that developers using Copilot completed tasks 55% faster than those without it. Remarkable productivity multiplier on execution speed. The caveat, buried in most coverage of this study, is what the tasks were: isolated, well-scoped coding problems measured in controlled conditions. Real engineering work includes architecture decisions, debugging complex distributed systems, understanding business context, and making judgment calls that no benchmark captures.

The more unsettling data point: Uplevel's analysis of engineering teams using Copilot found a 41% increase in bug rates in some codebases. Copilot writes plausible code confidently. It doesn't know your architecture constraints, your security requirements, or the subtle behavior of your production environment. A junior developer who might have looked up how to write a function from scratch — learning the intent in the process — now accepts generated code that looks right but isn't, and may not have the mental model to know why it's wrong.

The nuance that gets lost in both the boosters and the skeptics: Copilot raises the floor while creating new risks at the ceiling. Junior developers become significantly more productive on execution tasks. But confident-wrong code generation requires senior eyes to catch, and if your review process is weak, Copilot accelerates the rate at which incorrect code enters your codebase. The overall effect depends almost entirely on the quality of judgment on the team reviewing the output.

Jevons Paradox and the Headcount Question

Every few months there's another wave of commentary about AI reducing engineering team sizes. I'll address this directly: I don't believe it will happen in the way most people assume, and economic history gives us a clear reason why.

In 1865, the economist William Stanley Jevons observed something counterintuitive about coal and the steam engine. As steam engines became more efficient — using less coal to produce the same amount of work — England didn't burn less coal. It burned more. Because more efficient engines made coal-powered machinery economically viable in more contexts, more factories adopted steam power. Total demand for coal increased precisely because it became more efficient. This became known as the Jevons Paradox: improved efficiency of resource use tends to increase total consumption of that resource.

Software development is exhibiting the same pattern. McKinsey Global Institute's analysis "The Economic Potential of Generative AI" (June 2023) estimated that AI could add $2.6 to $4.4 trillion annually to the global economy — primarily by making software development more productive and enabling new categories of software that weren't economically viable before. If developers are 2x as productive, companies don't build the same software with half the engineers. They build twice as much software, enter new markets, automate more processes, and create more digital products. The demand for engineering work is driven by what's possible, not just what's currently being built.

We're seeing this in practice. Companies that have adopted AI coding tools aren't halving their engineering headcount — they're building more features, shipping faster, and competing in markets they previously couldn't reach. The pie is getting bigger. Not the slices smaller.

That said, the composition of engineering teams is changing, even if the size isn't. And that's where the hiring implications actually live.

The New Definition of Senior Engineer

The knowledge hierarchy in software engineering is flattening. If you define a "senior engineer" as someone who knows more syntax, more API signatures, more standard patterns — that definition is becoming less relevant. AI tools now have access to most of that knowledge and can generate it on demand. The question is no longer "do you know how to implement a binary search?" It's "do you know when a binary search is the wrong data structure for this problem?" That's a meaningful shift.

Here's what I think now constitutes genuine senior-level capability in an AI-augmented world:

Systems Thinking at Scale

AI can generate a function. It cannot understand that your caching strategy is wrong for your traffic pattern, or that your monolith needs to be decomposed in a specific way to meet your team's deployment velocity goals. Understanding how components interact at system scale — and making good architectural decisions under real constraints — is actually harder when AI makes the component-level work feel easy. The surface area of "good enough to ship" increases, which makes architectural decisions more consequential, not less.

Judgment About When NOT to Use AI

This sounds counterintuitive but it's genuinely important. AI code generation is excellent for boilerplate, glue code, standard patterns, and well-specified algorithmic problems. It's unreliable for security-critical code, performance-sensitive hot paths, novel architectural patterns, and anything where the generated code's correctness depends on implicit context that isn't in the prompt. Senior engineers need to know which category they're in — and have the discipline to not reach for AI generation just because it's available and fast. That discipline is rarer than it sounds.

Debugging AI-Generated Code

This is underappreciated and genuinely hard. When you debug code you wrote yourself, you have a mental model of what you were trying to do — the intent. When you debug code that an AI generated, you don't. The code looks coherent, may even be locally correct, but the subtle design decisions embedded in it are opaque. Debugging AI-generated code requires reading it as if it were written by an unknown third party with unknown assumptions. It's a distinct skill from debugging your own code, and most developers are still developing it.

Evaluation Design

If your team is using AI to generate tests, write documentation, summarize code, or produce any output you then rely on — someone needs to be able to evaluate whether that output is correct. Evaluation design is the skill of defining what "correct" means for a given AI task and designing test cases or metrics that reliably detect failures. This is borrowed from ML engineering and it's becoming relevant for all software engineers who work with AI tools. It's also a skill that's hard to hire for right now, because most engineers haven't had to think about it before.

The Irreducible Core

I want to be clear about what I'm not changing in my evaluation of engineering candidates, because the temptation to throw out everything in response to AI hype is real and wrong.

Deep Domain Expertise

An AI can tell you general best practices for building a loyalty platform. It cannot tell you the specific edge cases in how fuel retail loyalty programs differ from traditional retail ones, or why a particular promotional mechanics design will fail with NASCAR fans vs. general consumers. Domain expertise — the deep, accumulated knowledge of how a specific problem space actually works — remains irreplaceable. If anything, it becomes more valuable as generic execution tasks get automated. The ceiling on domain knowledge keeps rising even as the floor on basic coding rises too.

Debugging Complex Distributed Systems

Tracing a performance regression through five microservices with inconsistent logging, a mis-configured tracing system, and production traffic that can't be paused — this is still a deeply human skill. It requires holding a complex mental model, forming and testing hypotheses, and knowing which signals to trust when signals conflict. AI tools can assist (they're actually quite useful for parsing log formats and suggesting hypotheses), but the reasoning and judgment are human. I haven't seen any tool get close to replacing this.

Understanding Business Context

The best engineers I've worked with are the ones who understand why a feature matters — who the user is, what business problem it solves, what the risk is if it breaks. That context shapes every technical decision they make, from error handling to performance trade-offs to API design. AI cannot give an engineer business context. That comes from conversations, domain exposure, and genuinely caring about outcomes beyond the code itself.

Stakeholder Communication

Explaining a technical trade-off to a non-technical stakeholder, managing expectations during an incident, knowing when to escalate and how to frame it — communication and judgment skills that remain deeply human. AI can help draft a status update, but it can't read the room, understand the political dynamics, or know when blunt honesty is appropriate versus when diplomacy is needed.

How I'm Changing My Hiring

Enough theory. Here are the specific, concrete changes I'm making in how I evaluate engineering candidates:

Less LeetCode, More "Show Me a Hard Problem You Debugged"

LeetCode-style algorithmic problems test a narrow, increasingly automatable skill. They tell me almost nothing about how someone thinks about systems, handles ambiguity, or debugs production issues. I've largely replaced them with problem-solving discussions: "Tell me about the hardest production bug you've ever debugged. Walk me through your reasoning." This reveals how they think, how they communicate, whether they go to first principles, and whether they learn from hard experience. It also surfaces something I care about a lot: can they tell the story of a failure without deflecting?

AI Pair Programming Sessions

I now include a session where the candidate is explicitly encouraged to use AI tools while solving a problem. I watch how they interact with the tool. Do they verify the output critically or accept it uncritically? Do they know what to ask? Do they spot when the AI is wrong? Can they explain why a generated approach works or doesn't work? This reveals the judgment layer on top of AI usage that distinguishes a strong AI-augmented engineer from someone who is just an AI prompter. The difference is enormous.

Prompt Engineering as a Signal — But Not a Primary One

I care whether someone can write an effective prompt. But I care more about whether they know when a prompt is the wrong tool. The engineers I most want to hire have a clear mental model of what AI is good at (pattern matching, generation from examples, summarization) and what it's bad at (precise numerical reasoning, novel architectural judgment, maintaining coherent state across long reasoning chains). That mental model separates tool users from tool thinkers.

Valuing Cross-Domain Knowledge More

The most valuable engineers I've seen in AI-augmented environments combine engineering depth with domain knowledge. Someone who understands both software systems and the financial regulatory environment can build compliance tools that actually work. Someone who knows both ML and retail can design AI features that solve real business problems rather than technically-impressive ones that nobody uses. As AI raises the floor on pure coding execution, the premium shifts to people who bring combinations of knowledge that AI cannot synthesize on its own.

Learning Velocity Over Current Inventory

The AI tooling landscape is changing every six months. The specific tools that matter today will be different in a year — that's not speculation, that's what we've watched happen repeatedly. I care more about whether a candidate learns quickly, adapts their mental models when confronted with new evidence, and has a track record of picking up new domains effectively, than whether they currently know the specific stack we're using. Knowledge inventories depreciate fast. Learning velocity compounds.

The Judgment Problem

The best engineering teams in an AI-augmented world won't be the ones that adopted AI tools fastest. They'll be the ones that built the best judgment about when to trust those tools.

Speed of adoption without judgment is how you get the 41% bug rate increase from the Copilot data. Teams adopting AI tools enthusiastically and uncritically are building technical debt at an accelerated rate — they just don't know it yet, because the code looks fine and the features ship quickly. The reckoning comes when that code hits production edge cases, security review, or maintenance cycles six months later.

For hiring, this means looking for engineers who have a healthy skepticism about AI output. Not rejection — calibrated skepticism. People who can articulate when they'd trust AI generation and when they'd write something by hand and why. People who think about how to verify AI output as carefully as they think about how to generate it.

These people exist. They're often the same people who were already careful, methodical, and curious about first principles before AI tools existed. The disposition was already there. AI just raised the stakes for having it.

After twelve years of hiring and around 25 direct hires, my most durable insight hasn't changed: the best engineers are the ones who know what they don't know, and who build systems to compensate for that. In an AI world, that means building verification loops around AI output, staying curious about failure modes, and never fully outsourcing judgment to any tool — including the newest, most impressive one. That last part is harder than it sounds when the tool is very good and moving very fast.