AI Pair Programming Is a Skills Test, Not a Speed Boost

Everyone’s racing to put AI into their developer workflow, and most of them are measuring it the wrong way. They count lines shipped, pull requests merged, tickets closed. The chart goes up, so they call it a win. I’ve watched this from a few angles: as a CTO, as a four-time founder, and now as the CEO of a company that staffs engineering teams who use these tools every day.

The speed is real. But it doesn’t land evenly across a team, and it isn’t free.

AI pair programming makes a curious engineer who understands the code faster. It makes a careless one who doesn’t faster at shipping problems. The tool is a multiplier, and what it multiplies is the judgment that was already in the room.

What AI pair programming actually is

Pair programming used to mean two developers at one keyboard, one typing and one thinking a step ahead. AI pair programming keeps the shape and swaps one of the humans for a model. You describe what you want, the assistant suggests code, finishes the function, flags a bug, and you decide what to keep.

The common tools are GitHub Copilot, Cursor, Claude, and Amazon Q Developer. They differ in the details, but the job is the same. You get a second set of hands that never gets tired and never pushes back unless you make it.

That last part is the whole problem, and it’s where most of the talk about AI in software development stops short.

Why it’s a skills test, not a speed boost

Here’s how I think about it. AI is a powerful tool that can boost productivity, but relying on it to generate unexplainable code creates tomorrow’s technical debt today. The hard part of software development isn’t writing code. It’s understanding the problem you’re trying to solve.

The AI is very good at the writing part. It is not the one who has to understand the problem, and it doesn’t carry the consequences when the code is wrong. You do.

Watch what happens with two different engineers and the same assistant. A strong engineer reads every suggestion the way they’d read a junior’s pull request. They catch the off-by-one error, the missing null check, the clever line that will be a nightmare to debug at 2 a.m. A weak engineer accepts the suggestion because it compiles and the test passes, then moves on. It’s the same tool producing the opposite result.

Here’s the truth about vibe coding. It only works if you’ve been coding long enough to know when the AI is wrong.

AI pair programming amplifies the judgment already in the room. It doesn’t supply any.

The danger is that the output looks the same either way. It’s clean, plausible, well-formatted code that may or may not do the right thing. The mess doesn’t show up in the demo. It shows up three months later as technical debt nobody can untangle, because the person who “wrote” it never understood it in the first place.

What it actually rewards is curiosity

If the tool rewards judgment, the question becomes how a developer builds judgment in the first place. The answer that holds up is curiosity.

I tell our engineers the same thing every time this comes up. The way you stay valuable through this shift is to stay curious. Be curious about how AI changes your job, and curious about how to use it well. The developers who poke at the tool, learn where it fails, and figure out what it’s actually good for are the ones who pull ahead. The ones who treat it as a vending machine for code fall behind. This is one of the three things I think decide whether a developer thrives now, alongside communication and courage, and I made the case at length in Product Driven.

Derrick Leggett, the chief information officer at AMC Theatres, said it more bluntly than I would. Derrick runs a global engineering org, and on AI he doesn’t hedge: “People who don’t adopt AI and learn how to use it are going to be working at 30%, 50%, 80% of what the person sitting next to them is.”

The real stakes aren’t that AI replaces your engineers. It’s that the gap between your curious engineers and everyone else gets much wider.

Where AI pair programming breaks down

I’m not selling this as a clean win, because it isn’t one.

It breaks first with junior developers. A junior who accepts AI code they can’t explain hasn’t learned anything, and now there’s logic in the repo that nobody on the team actually understands. The tool lets them skip the struggle that used to build real skill. That struggle wasn’t waste. It was the training. Pairing AI with your most junior people without guardrails is how you grow a team that ships fast and learns slowly, which is the opposite of what you want. This is why how you onboard developers matters more than it used to.

The review burden doesn’t disappear either. It moves. When everyone is generating more code faster, your senior engineers spend more of their day reviewing it, and code review becomes the actual bottleneck. If you measure the speedup at the keyboard and ignore the slowdown at review, you’re fooling yourself with half the math.

Then there’s the quiet one: security and correctness. The model will happily suggest a pattern that’s subtly insecure or quietly deprecated, stated with total confidence. It has no stake in whether it’s right. A team that trusts the output without checking it is one confident hallucination away from a real incident.

None of this means don’t use the tools. It means the tools assume a level of skill on the human side, and pretending otherwise is how teams get burned.

What this means for how you hire and build a team

If AI handles more of the typing, then what you hire for has to change. Pure coders will be replaced by AI. Problem solvers will run technology organizations.

So I’d stop interviewing for syntax. Memorizing the standard library was never the point, and now it’s actively the wrong test. Interview for problem-solving, for judgment, for whether a candidate can read a block of code critically and tell you why it’s wrong. Test whether they ask good questions when the requirements are fuzzy, because communication is what turns a vague request into the right software. Those are exactly the skills AI rewards.

At Full Scale, the developers we place are trained on the Product Driven approach and the full modern AI toolkit, GitHub Copilot, Claude, and Cursor included. I have an obvious commercial interest in telling you that, so take it as disclosed. The deeper point is that collaborative software development is a communication habit, not a tool you install. But the principle holds whether you build your team through us or not. Hire people who understand the problem, give them tools that speed up the parts that don’t need a human, and the whole team moves faster on code you can actually trust. Hire fast typists and hand them an AI, and you get more code than anyone can vouch for. If you’re weighing how to build and scale an engineering team right now, this is the decision that matters more than the tooling line item.

This is also why I still believe in staff augmentation with engineers who work as part of your team instead of a project shop that hands back a black box. AI makes the black-box problem worse, because now nobody understands the code on either side of the wall.

The bottom line

Software development is back, and the companies that remember what that ever meant are going to win.

If you want a team that uses AI to build better software, the kind you can actually trust, let’s talk about what that looks like.