In the late 1990s, Kent Beck introduced Extreme Programming (XP) with a simple premise: take good engineering practices and push them to the extreme. If code review is good, review constantly through pair programming. If testing is good, write the tests first. XP became one of the foundational frameworks of the Agile movement, and Beck was among the original authors of the Agile Manifesto in 2001. Where frameworks like Scrum focus on how work is managed, XP focuses on how code is actually written.

More than twenty-five years later, AI can generate code faster than any of us can read it, which makes reading it carefully more important, not less. While many teams shifted their focus toward Scrum's management structure over the years, XP's core technical practices are exactly what we need right now.

The problem with "just use AI"

Most conversations about AI coding focus on speed. But speed without discipline just produces defects faster. AI output can look right and still be subtly wrong. It drifts outside the scope of the task. And junior developers who lean on it risk never building the judgment they need to catch its mistakes.

These aren't new problems. They're exactly what XP's practices were designed to solve.

The model: a junior–senior pair with AI as the implementer

Here's the setup I'd propose:

  • The junior drives the AI. They write the pseudocode, propose the tests and prompt the AI. This keeps them thinking through the problem instead of watching.
  • The senior navigates. They question the design, catch what the AI got subtly wrong, and explain why. That "why" is where the real knowledge transfer happens.
  • The AI implements. It turns agreed pseudocode and tests into working code.

The flow follows XP closely: pseudocode first to surface misunderstandings early, then test-driven development, then implementation, then refactoring over successive iterations.

Guardrail 1: humans own the tests

If the AI writes both the tests and the code, the two can agree with each other and still both be wrong. In TDD, the tests are the specification. So the pair writes them, or reviews them closely, before any implementation begins.

Guardrail 2: explain it before it merges

Before any AI-generated code is accepted, the junior explains it to the senior. If they can't, it doesn't merge. This one rule catches AI errors and gaps in understanding at the same time.

This is the four-eyes principle behind XP's pair programming: every line of code is seen by at least two people. And it runs both ways. Senior engineers aren't infallible, so the junior should feel free to challenge the senior's calls too. If the senior can't explain a decision, that's just as much a signal to stop as when the junior can't.

Guardrail 3: watch the scope

AI has a habit of "helping" beyond what was asked: refactoring a neighboring module, touching files nobody mentioned. Tests alone won't catch this, because a test only proves the new behavior works. It says nothing about what else changed.

A few simple defenses:

  • Keep the full regression suite running, not just the new tests.
  • Add characterization tests (tests that lock in existing behavior) around modules that shouldn't change.
  • Define the allowed scope for each story and run a diff check that flags changes outside it.

That last one can be as simple as a few lines in CI comparing changed files against an allowed list. Start by warning rather than blocking, and use each warning as a prompt for the question every pair should ask: "Why did this file change?"

It fits the process you already have

None of this requires abandoning Scrum or Kanban. Those frameworks govern how work flows. This is a micro-level practice for how code gets written.

  • In Scrum, add "tests human-reviewed" and "junior can explain the code" to your Definition of Done, and tune the practice in retrospectives.
  • In Kanban, apply it as a policy for risky or core work items, and let cycle time tell you whether it's paying off.

Try it on a handful of items. Let the data decide whether to expand.

Why this matters

The biggest long-term risk of AI in software isn't bad code. It's a generation of developers who never learned to recognize bad code. Pairing juniors with seniors, with AI doing the typing, turns AI from a shortcut into a teaching tool.

AI can handle most of the work, but the hardest problems, like a race condition that only shows up under load, still need someone who can step back and see the whole system. That judgment is learned, not prompted.

XP's values were communication, simplicity, feedback, courage and respect. None of them are outdated. If anything, AI makes them more necessary.

How is your team pairing with AI? I'd love to hear what's working, and what isn't.

#ExtremeProgramming #Agile #SoftwareEngineering #AI #PairProgramming #TDD