A Sane AI Coding Workflow: Plan, Implement, Review

This is the workflow I use to ship features with AI in codebases that have to be maintained, tested, and collaborated on, not throwaway weekend apps.

FOMO is real

I do have FOMO. There are many posts about super-agentic orchestration setups where one prompt triggers loops of dev agents, test agents, and reports until the task is done.

In my experience, companies do not want a magic AI dev. They want engineers who can integrate AI into an existing delivery process without breaking everything.

Those with the loudest voices are often pushing token-hungry workflows, while many teams are quietly using AI as a coding buddy with normal review, tests, and long-term maintainability in mind.

The setup I use is grounded in best practices and project-wide AI coding standards.

Plan first with action.md

I apply this pattern to medium-to-large tasks, not minor tweaks. Even if I try to split work into small pieces, that is not always realistic.

That is where action.md matters. I write the problem, a proposed solution, and relevant files, then ask AI to generate an action.md. This becomes our working contract.

In teams, that same file can also be attached to a ticket or PR so everyone sees the plan before reviewing code.

• AI drafts a plan from a short spec and provided context.
• I review and refine that plan.
• The plan includes sections like Goal, Non-Goals, Files likely affected, Success Criteria, and Risky Areas.

No code is written until the plan is final. In most cases, coding itself takes less time than getting scope and decisions right.

Implementation driven by the plan

Once the plan is stable, I ask AI to implement from action.md as reloadable context. I supervise each step and stay in the loop on behaviour and tests.

When implementation is done, I review the output with functional checks, test runs, and linting before moving to the next phase.

Fresh-context diff review

Then I switch to a fresh context, feed the same action.md, and ask AI to review the git diff against the plan. That often surfaces missing tests, type cleanups, and structural improvements.

• Review the diff, not the whole repo, with a focused checklist: bugs, typings, error handling, test coverage, and consistency.
• Use fresh context so the model is less anchored to its own earlier output and can be more critical.
• The diff-to-plan mapping also makes human review easier.

At this stage, I want AI acting like a reviewer: find logic errors, missing coverage, duplication, and poor structure.

PR + Copilot review

This is usually the noisiest phase. Copilot can surface many useful comments, but often without enough task context, which leads to nitpicks or out-of-scope suggestions.

Instead of blindly stacking fixes on fixes, I reuse the same reviewer context and triage each comment by relevance to current scope.

Noise control matters even more in teams where reviewer time is limited. This keeps PRs focused on what the task is actually trying to deliver.

With this setup, the final loop is less painful: resolve relevant concerns, rerun checks, and ship with confidence.

Feedback

This is where I am right now: experimenting, reading, and learning from developers around me. Maybe this sounds old-school to you, maybe not. If your workflow differs, I would genuinely love to hear it.

As I was writing this post, I stumbled upon Nicholas C. Zakas's post GitHub Copilot's pricing gamble, which makes me think the approach I'm using is also token-friendly. I mean, action.md gives a solid start, but it is also cached, which means it will be cheaper for AI to reuse for building, testing and reviewing.