Writing Code With an AI Pair: A Workflow That Keeps You in Charge

AI coding assistants have gone from autocomplete to something closer to a junior colleague who can read your whole repository, run your tests and propose changes across a dozen files. Used well, they're a genuine multiplier. Used carelessly, they produce large volumes of plausible code that nobody on the team fully understands.

The tool matters less than the workflow. Here's one that keeps you in charge.

1. Plan before you prompt

The most common mistake is opening a chat and typing "add user invitations." The assistant will happily generate something — but it will make dozens of decisions you didn't make.

Instead, spend five minutes writing a short plan:

• What's the goal, in one sentence?
• Which files or modules should change, and which shouldn't?
• What existing patterns should it follow? Point to an example.
• How will you know it works? Name the tests.

Many assistants have a planning mode that proposes an approach before writing code. Use it, read the plan, and correct it. Fixing a plan takes seconds; untangling a wrong implementation takes an afternoon.

2. Work in small, reviewable steps

Ask for one coherent change at a time — something you could review as a normal pull request. "Add the invitations table and migration" is reviewable. "Build the invitations feature" is not.

Small steps also make it obvious when the assistant drifts. If a change meant to touch two files touches nine, stop and ask why.

3. Let tests do the arguing

Assistants are far more reliable when they can check their own work.

• Ask for tests first, or alongside the change, and read them carefully — tests encode intent.
• Let the assistant run the test suite and fix failures.
• Watch for "fixes" that weaken tests to make them pass. That's the single most important thing to catch in review.

// A good prompt includes the check:
// "Add rate limiting to POST /api/invite.
//  Follow the pattern in lib/rate-limit.ts.
//  Add a test that the 6th request in a minute returns 429.
//  Run the tests and show me the output."

4. Review like it's a colleague's code — because it is

You are responsible for every line that ships, regardless of who typed it. Review AI-written code with the same care you'd give a new team member's pull request:

• Does it follow our conventions? Naming, error handling, file structure.
• Did it invent anything? Non-existent library functions and configuration options are a classic failure.
• Is there hidden scope? New dependencies, changed configuration, unrelated "cleanups."
• Security basics. Input validation, authorisation checks, secrets, SQL built from strings.
• Can I explain it? If you can't explain a block of code to a teammate, don't merge it.

5. Give it the context a new hire would need

Assistants perform dramatically better with good project context. Most tools support a project instructions file. Fill it with what you'd tell a new developer in their first week:

• How to install, run and test the project.
• Architectural rules ("all database access goes through the repository layer").
• Conventions and preferences.
• Things to never do ("never edit generated files in /gen").

Keep it short and current. Outdated instructions are worse than none.

6. Know where it shines and where it doesn't

AI pairs are excellent at:

• Boilerplate, migrations and repetitive refactors.
• Writing tests for existing code.
• Explaining unfamiliar code and libraries.
• First drafts of scripts and internal tools.
• Debugging with a clear error message and reproduction.

They need much closer supervision for:

• Core domain logic with subtle business rules.
• Security-sensitive code: authentication, permissions, payments.
• Performance-critical paths.
• Decisions about architecture and data models.

7. Keep your own skills sharp

There's a real risk of becoming a reviewer of code you could no longer write. Counter it deliberately: write tricky pieces yourself, read the code the assistant produces until you understand it, and use it to learn new areas — ask it to explain, not just implement.

The workflow, condensed

Plan → small step → tests → review → commit. Repeat. It's the same discipline good teams always used. The assistant just makes each loop faster, which means the discipline matters more than ever.