Pair Programming Patterns That Work

Patterns Beat Prompts

A great prompt is a one-time win. A great pattern is a repeatable system. The developers who get consistent results from AI pair programming do not rely on clever one-off prompts — they use structured patterns that produce reliable output regardless of the specific task. This lesson covers three patterns that are worth building into your regular workflow.

Pattern 1: Tests as Truth

The most reliably effective way to use AI for code generation is to give it a verifiable target. When you write tests first — even rough, incomplete tests — and then ask AI to generate code that makes them pass, you transform the interaction from "generate some code and hope it works" into "iterate toward a known, checkable goal."

The workflow looks like this:

• Write a test (or a set of test descriptions) that expresses what the code should do
• Pass the tests and the spec to AI: "Write the implementation that makes these tests pass"
• Run the tests against the generated code
• If tests fail, pass the failure output back: "These tests failed with this output — fix the implementation"
• Iterate until green, then review the code before merging

This pattern works because tests encode your requirements in a form the AI can check its own output against. It also makes the review step easier: instead of reading the code top-to-bottom and wondering if it is correct, you start from passing tests and inspect whether the implementation is clean and matches your conventions.

The one caveat: the tests themselves need to be written from requirements, not from looking at the implementation. We will return to this in the testing lesson — for now, the discipline is to write tests before, not after, asking AI to generate code.

Pattern 2: Cross-Model Review

Here is a non-obvious truth about AI code review: if you use the same model to generate code and review it, you are asking the same trained system to check its own work. It has the same blind spots in both directions. It is less likely to catch the kinds of errors it is prone to making — because those are the same errors it is prone to missing.

Cross-model review addresses this directly. Generate code with one model. Review it with a different one. Testing has shown this closes a documented 74.7% of the quality gap that exists when using a single mid-tier model for both tasks.

In practice: write the code with Cursor (using its default model). Copy the generated code — not the explanation, just the code — into a fresh Claude or ChatGPT session and ask: "Review this code for bugs, incorrect assumptions, and edge cases the original author may have missed. Be critical."

Omitting the explanation matters. If you paste "I used Cursor to write a payment validation function," you are framing the review before it starts. Paste the bare code and let the second model approach it cold.

Pattern 3: Checkpointing in Agentic Sessions

When you use Cursor's Agent Mode, Claude Code, or any tool that can autonomously run multiple steps — reading files, making edits, running commands — you are no longer reviewing one generation at a time. You are reviewing the cumulative result of a series of decisions the AI made on your behalf.

This introduces a failure mode called compounding errors. An early wrong assumption — say, the AI misidentified which database model is the source of truth for a particular field — gets built on by subsequent steps. By the time the agent reports it is done, the wrong assumption is woven through multiple files in hard-to-unpick ways. Stack Overflow engineering documented this as a specific production risk in their post-mortem analysis of AI-assisted deployments.

The mitigation is checkpointing: pause and review after every meaningful step, not at the end. After the agent creates the schema, stop and check it before it writes the migration. After the migration, check before the service layer. "Meaningful step" means any change that subsequent changes will depend on.

Git is your best tool here. Commit (or at least stage) after each verified step. If a later step goes wrong, you can revert to the last known-good checkpoint rather than untangling a web of interdependent AI-generated changes.

Building Your Personal Pattern Library

These three patterns — tests as truth, cross-model review, and agentic checkpointing — are starting points, not a complete list. As you use AI in your own development work, you will discover variations that fit your specific workflow, language, and tooling. The habit worth building is writing them down: a short note in your prompts file or personal notes about what worked, what the pattern looks like, and what it is good for. Patterns compound over time. A library of five reliable patterns is worth more than fifty one-off clever prompts.