Working with AI Coding Assistants: A Repeatable Workflow for Real Codebases

Set up the project for the assistant

Assistants read files to understand a codebase. Give them good material: a README that explains how to install, run and test the project, and a short contributor or agent instructions file that states conventions, such as the test command, folder structure, naming rules and anything that must not be changed. Many tools read such files automatically. Keeping these documents current helps human newcomers just as much.

Choose tasks the assistant is good at

Assistants are strong at well-specified, bounded work: implementing a function against tests, writing boilerplate that follows an existing pattern, explaining unfamiliar code, drafting tests for known behaviour and making mechanical changes across files. They are weaker at decisions that depend on context outside the repository, such as product trade-offs, production incidents or team agreements. Use them for the first group and keep the second with people.

Write a task specification

Before asking for code, write a short specification: the goal from the user's perspective, the files and existing patterns involved, constraints such as libraries or security rules, and the checks that define done. For anything larger than a small change, ask the assistant to propose a plan first. Reviewing a plan takes minutes and prevents hours of reviewing the wrong implementation.

Work in small, test-anchored loops

Implement one behaviour at a time. Start with a failing test, ask the assistant to make it pass without changing the test, then run the full suite and review the diff. Commit when it is green. Small loops keep each change understandable and make it cheap to discard a bad attempt. When a session becomes long or confused, summarise decisions in writing and start a new one.

Review generated code deliberately

• Confirm every changed file belongs to the task and revert unrelated edits.
• Verify library functions and options against the versions in your lock file.
• Check error handling, empty inputs, timeouts and permission failures.
• Look for common security problems: string-built queries, missing authorisation, unsafe file handling and secrets in code.
• Read the tests and confirm they would fail if the feature were broken.

Protect data and secrets

Follow your organisation's policy on which tools may access which repositories. Never paste credentials, production data or personal information into prompts. Use environment variables and secret stores in code, and run secret scanning in CI, because generated code sometimes includes placeholder keys that later get replaced with real ones in the same file.

Keep learning while you delegate

The risk with assistants is not only bad code but shallow understanding. For anything you merge, you should be able to explain how it works and why it was written that way. Ask the assistant to explain unfamiliar parts, then check the explanation against documentation. For learners, alternate between solving a problem yourself and comparing your solution with an assistant's, rather than always starting with generated code.

Measure whether it helps

Track a few simple signals over several weeks: time from task start to merged pull request, review comments per change and bugs found after release. If speed improves but defects rise, tighten specifications and reviews. The goal is reliable software delivered sooner, not more lines of code.

Checklist

• README and contributor instructions describe how to run and test the project
• Tasks are bounded and specified before generation
• Work proceeds in small, test-anchored loops
• Every change is reviewed with an AI-specific checklist
• No secrets or personal data go into prompts
• You can explain every change you merge