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.

Quick Answer: AI pair programming is coding alongside an AI assistant like GitHub Copilot, Cursor, or Claude that suggests code, completes functions, and spots bugs in real time, replacing one human in the old two-person pairing model. It doesn't replace developer judgment, it amplifies whatever judgment is already in the room: a curious engineer who reviews every suggestion gets faster and better, while a careless one just ships mistakes faster. Full Scale hires and trains engineers on exactly that judgment, not just familiarity with the tools.

What AI pair programming actually is

AI pair programming is coding alongside an AI assistant that suggests code, finishes the function, and flags bugs while you decide what to keep. Pair programming used to mean two developers at one keyboard, one typing and one thinking a step ahead. The AI version keeps that shape and swaps one of the humans for a model.

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

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. It also cuts the other way: plenty of mechanical edits are faster by hand than by prompt, which is why a developer fluent in Vim’s search and replace reshapes a file before the prompt is even written.

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. That kind of sustained watching is exactly what developer flow state looks like now.

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

The research on speed is split, which is part of the point. In a 2022 GitHub experiment, 95 developers building a simple HTTP server in JavaScript finished 55% faster with Copilot. In a 2025 METR trial, 16 experienced open-source developers took 19% longer to close 246 real issues with AI tools, and afterward they still believed the tools had made them about 20% faster. METR’s February 2026 update says that slowdown is now outdated and speedups look likely, but it calls its own new data very weak evidence of how big. The METR result is the one I would put on a wall: developers who were slower still felt faster. Nobody can judge that from the inside, so measure the output at review, not at the keyboard.

AI pair programming amplifies whatever judgment is already in the room. The judgment still has to come from your engineers.

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

Curiosity is how a developer builds the judgment this tool rewards. We get into how that judgment actually gets built in our piece on upskilling developers on real work.

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 here are widening gaps. AI doesn’t replace your engineers so much as it pushes your curious ones much further ahead of everyone else.

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.

Ground rules for working with an AI pair programmer

Treat an AI pair programmer like a new hire who has read every programming book ever written and has never once been paged at 2 a.m. Read its work the way you would read a pull request, and merge nothing that the author cannot explain. The table below sorts the problems above by who is at the keyboard.

Who is at the keyboard	What goes wrong	The rule
A senior engineer who reads every suggestion	Little. They catch the off-by-one error and the missing null check.	Keep it up, and budget their review time, because review is now the bottleneck.
A junior engineer	They accept code they cannot explain and skip the struggle that builds skill.	Pair every AI session with senior review.
Anyone writing security-sensitive code	The model suggests a pattern that is subtly insecure or deprecated, with total confidence.	Check it against the docs and get a human review before it ships.
A team measured on volume	Lines written and pull requests merged climb while the review queue backs up.	Measure what survives review, not what got typed.

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. It mirrors how AI is changing software testing, where the human still owns the judgment the AI cannot.

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 the team model 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.