An AI-Assisted Coding Workflow That Stays Safe

An AI coding assistant can write a feature in minutes. Speed is not the problem. The problem is code that nobody really checked: an API key in a config file, a package that does not exist, a test the agent quietly changed so that it passes. A good workflow keeps the speed and adds gates: checkpoints that every change must pass before it moves on.

This is part 5 of Level 2 in our AI Development learning path. It turns the habits from what AI coding assistants do into a repeatable workflow: plan, generate, review, test, commit. You will learn how to brief an assistant, why small diffs and tests first matter, which automated checks catch secrets and risky packages, and how to review AI-written code with a checklist.

Five steps, five gates

Every change goes through the same five steps. Each step ends with a gate: a question that must be answered with yes. If the answer is no, the change goes back, usually to the generate step and sometimes to the plan.

The gates are not red tape. Google’s DORA research points the same way: working in small batches amplifies the positive influence of AI on product performance, and frequent commits amplify its positive influence on individual effectiveness (Source: DORA AI Capabilities Model, Google Cloud, 2025, cloud.google.com).

This workflow is for code that ships. For quick experiments, lighter rules can be fine: our VibeCoding article shows how we prototype with AI — and why prototypes stay out of production.

Plan: write the task before the prompt

Much bad AI code starts with a vague request. Before you open the assistant, write the task down like a ticket for a new colleague. Five parts are enough:

Then ask for a plan before any code: “List the files you will change and the steps. Then wait.” A wrong plan takes a minute to fix. The same mistake in a finished diff takes much longer.

Two more habits belong to this step:

• Write the tests first. Turn the acceptance criteria into tests, or let the assistant write them, and review them before any feature code exists. Then ask for code that makes them pass without changing the tests. This is called test-driven development (TDD), and it gives you a clear definition of done.
• Keep standing rules in the repository. Many coding agents read a project file with instructions, for example AGENTS.md, an open format that several tools support. Put your conventions there: how to run the tests, the code style and what the agent must never do.

Generate: small diffs and limited permissions

A diff is the list of lines that a change adds, changes or deletes. Keep it small: one task, one branch, one small diff. Google’s code review guide calls about 100 lines a reasonable size for a change and 1,000 lines usually too large (Source: Google Engineering Practices, “Small CLs”, google.github.io). Small changes get reviewed sooner and more carefully, and they are easy to undo.

Commit after every working step, so you can go back when the next step fails. In the terminal, one step can look like this:

git switch -c feature/discount-code    # one branch per task
git diff                               # after each AI change: read every line
make test                              # run all tests, not only the new ones
git add -p                             # stage the change piece by piece
git commit -m "Validate discount codes at checkout (#1234)"

Agents need limits, because they act instead of only suggesting:

• Run them in a sandbox or a container, with test data and without production credentials.
• Let them ask before they run commands, install packages or push code.
• Stop when the diff touches files outside the plan, and reject any change that edits tests to make them pass.

Review and test: people and tools catch different things

Read the diff, not the chat. The assistant’s summary of what it did can be wrong. Ask it to explain risky parts, and compare the explanation with the code. Code that handles logins, payments, permissions or personal data gets a second human reviewer.

A pull request with a large AI-generated diff and no explanation is the coding version of what researchers call workslop: output that looks finished but shifts the real work to someone else. BetterUp Labs and the Stanford Social Media Lab list code without context among its typical forms (Source: BetterUp Labs, 2025). Every pull request should say what changed, why, and how it was tested, written by the person who opens it.

Then let automated checks run on every pull request. Each one catches a different kind of problem, and none catches everything:

Three of these checks deserve a closer look:

• Secret scanning. A scanner looks for keys, tokens and passwords before the code leaves your machine, as a pre-commit hook, and again in CI. Many code hosts can also block a push that contains a known key format. If a secret was committed anyway, revoke it and create a new one. Deleting the line is not enough, because the old version stays in the history.
• Dependency checks. For every new package, check that it exists, that the name is exactly right and that it is maintained. Assistants sometimes suggest packages that were never published, and attackers can register such names. Pin versions in a lock file, let a vulnerability scanner compare them with databases of known flaws, and check the license.
• Static analysis. These tools read code without running it and find insecure patterns, such as user input pasted into a database query. Models learn from public code, including its mistakes. In an early study of GitHub Copilot, about 40 percent of 1,689 programs generated for 89 security-relevant scenarios contained a vulnerability (Source: Pearce et al., “Asleep at the Keyboard?”, IEEE S&P 2022, arxiv.org). Models have improved since, but these checks are cheap insurance.

AI-powered tools can add a first pass. According to the vendor, TestDriver.ai runs pull requests in a desktop sandbox and reports regressions before a change is merged. App builders such as Emergent and Devs.ai generate whole apps from a description, which makes the gates even more important. We have not tested these tools.

TestDriver.aiApp Building & Testing · AI at the coreRuns pull requests in a desktop sandbox, finds bugs and builds regression tests. EmergentApp Building & Testing · AI at the coreBuilds web and mobile apps from a plain-language description. Devs.aiApp Building & Testing · AI at the corePlatform where teams build and run AI applications and custom agents on their own data.

Short descriptions from our tool comparison, based on the vendors' information — not tested by ABXK.

If your change touches an AI feature in your product, the test gate also includes the evals from part 4.

Commit: clear messages, current docs, a protected branch

The commit closes the loop. Write a message that says what changed and why, and link the ticket. Keep the task brief and the plan in the pull request description, so reviewers can compare the intent with the result. If your team asks for it, note that an assistant helped.

Update the documentation in the same change: the README for new setup steps, the changelog and comments that explain why the code works the way it does. Assistants write documentation fast, but check it like code. It can describe behavior that does not exist.

Finally, protect the main branch: changes reach it only through a pull request, with green checks and an approval. Then no person and no agent can skip the gates.

What benchmark data says about AI code edits

How reliable are models when they edit existing code? The Aider Polyglot benchmark tests exactly this. Like your test gate, it gives the model a second attempt after it sees the test output. These are the leaders in our LLM data:

Aider Polyglot: the top 5 models

#	Model	Released	Result
1	GPT-5 (high) OpenAI	Aug 7, 2025	88.0%
2	o3-pro OpenAI	Jun 10, 2025	84.9%
3	Gemini 2.5 Pro Preview (Jun 2025) Google DeepMind	Jun 5, 2025	83.1%
4	o3 (high) OpenAI	Apr 16, 2025	81.3%
5	Grok 4 xAI	Jul 9, 2025	79.6%

225 difficult programming exercises in C++, Go, Java, JavaScript, Python and Rust. It measures whether a model can edit existing code correctly, with a second attempt after seeing the test output. Data: Epoch AI, retrieved on October 17, 2026, licensed CC BY 4.0. All models: LLM database.

Even the best results leave part of the exercises unsolved, although every exercise has clear tests and the model gets a second try. Not every new model has been tested on this benchmark, so the newest models in our LLM database may be missing here. A high score tells you which models are worth trying. Your own repository, with its rules and history, is the real test. Level 4 explains how coding benchmarks work and where they mislead.

Checklist before you merge AI-written code

Use this list for every pull request with AI-written code. It goes further than the quick checks in Level 0: