A workflow that actually ships.

AI pair programming works when you run a tight loop: agree on a plan, let the agent take one small step, run it, review it, and commit it. You own the goal, the plan and the review. The agent does most of the reading, typing and test running.

Every green step gets its own commit, so a bad turn costs one command to undo instead of an afternoon. The loop is simple. The ways it breaks are less obvious, and they are where most lost days go.

01What AI pair programming means now

With a coding agent, the roles are lopsided. The agent is a tireless, very fast driver that knows a lot of code and nothing about your users, your deadlines or why the system looks the way it does. That makes you the navigator by default.

The job of the navigator is to keep the work pointed at the goal and to catch mistakes while they are small. An agent makes that job both easier and more important, because it produces code faster than you can read it.

Google’s DORA research team found that frequent commits amplify the benefit of AI for individual developers, and that working in small batches does the same for product performance. The workflow below is built on those two habits.

02The loop: plan, one step, run, review, commit

1. 01

   Plan together

   Ask the agent to read the relevant code and propose a plan before it writes anything. Cut and reorder it until every step is a change you could review in about five minutes. Save the plan to a file such as PLAN.md, so it survives a fresh session. Our prompts for coding agents include a plan-first prompt you can copy.

2. 02

   Take one small step

   Ask for exactly one step: “Do step 2 only, then stop and show me the diff and the test output.” One step at a time keeps each diff readable and each mistake local.

3. 03

   Run it

   The agent runs the tests. You run the thing a user would touch: the page, the endpoint, the command. Try one unhappy path too, such as an empty form or a bad input.

4. 04

   Review it

   Read the diff against the step you asked for. Anything outside that step needs a reason. Read every line of risky code, such as login, payments, deletion or migrations. Our guide to reviewing AI-written code has the full method.

5. 05

   Commit it

   Green and reviewed means commit, with a message that says why. Then go back to step two with the next item on the plan.

The commands behind the loop are ordinary Git. Work on a branch per task, and look at what changed after every step:

# One branch per task
git switch -c agent/orders-pagination

# After each step: what changed, and do the tests pass?
git diff --stat
git diff
npm test

# Green and reviewed: checkpoint it
git add -A
git commit -m "feat(orders): add cursor to the orders query"

# Wrong direction: set the attempt aside (recover it with git stash pop)
git stash push --include-untracked -m "failed attempt: cursor in query"

The stash line is the safe way to discard a bad step. It clears your working folder but keeps a copy, in case the failed attempt had one good idea in it.

This same loop scales up to larger jobs. Our guide to migrating a codebase with AI applies the same plan, batch and test approach to a whole framework upgrade.

03Who does what

A pair works when each side knows its job. Here is a split that works:

The tests row is the easiest to skip. When you decide what must be true and the agent writes tests for it, the tests become a contract you can check in a minute. That is the core of test-driven development with AI.

04How to give the agent context

An agent starts each session knowing only what it can read. Give it three layers of context, from the most permanent to the most temporary.

Standing context lives in an instruction file such as AGENTS.md: how to install, test and lint, your conventions, and what never to do. Write it once and every session starts smarter.

Task context goes in the first prompt of a session. Point to files instead of pasting them, and name an existing example to copy:

Goal: [one sentence].
Relevant files: [paths]. Follow the pattern in [an existing file that does something similar].
Done means: [the tests or behavior that must pass].
Out of scope: [what not to touch].
Work in small steps. After each step, stop and show me the diff and the test output.

Session context is everything said so far, and it goes stale. Keep one task per session. When you switch tasks, start a fresh session and let the plan file carry what matters.

05When to take the keyboard back

The agent should not drive all day. Take over, or change how you steer, when you see any of these:

• Two failed corrections. A thread full of failed attempts tends to produce more of them. Start a fresh session with a sharper prompt that includes what you learned.

• The same error keeps coming back. Circling is a sign the agent lacks a piece of context, and more tries will not supply it.

• You already know the fix. If typing it takes less time than describing it, type it.

• The code is high risk. For authentication, payments, data deletion and migrations, write the core yourself or review every line.

• You cannot explain the diff. If you could not defend it to a teammate, do not commit it.

• The agent starts cutting corners. It skips a test, loosens a type or adds a package just to get past an error.

06Anti-patterns that waste a day

Lost days tend to come from a handful of habits. Here they are next to the habit that replaces each one.

07FAQ

Next, set up the instruction file every session reads with our AGENTS.md guide, or learn how context engineering keeps an agent on track.