AI workflow for software development • Jan Adrian Hafskjold

This post will cover my AI workflow and explain how I utilize AI day-to-day as a Software Developer. I use Codex with GPT 6.1 Sol to plan, hand the implementation to Claude Opus 5.5, then return to Codex with GPT 6.1 Sol for a review. After that, me and another developer review the pull request in Azure DevOps before merging to develop.

Different models, different jobs. Still a human developer making all the important decisions. AI can’t replace us! (yet?)

The workflow at a glance

Plan Codex · GPT 6.1 Sol create A lean plan
Implement Claude · Opus 5.5 implement Code changes
Review Codex · GPT 6.1 Sol review-implementation Reviewed code + manual checks
Human review Me and another developer Azure DevOps → develop

I use three skills to keep the handoffs consistent and control code quality: create, implement and review-implementation, so I don’t have to type out the same prompts every time.

1. Plan with Codex

GPT 6.1 Sol · create

I start by describing what I want to build or change. Before any code is written, I use Codex to explore the relevant code and explain the decisions that actually matter: where the behaviour belongs, which existing patterns fit and what tradeoffs come with the suggested approach.

The create skill turns that discussion into a lean implementation plan. It keeps the reasoning alongside the steps, so the next model gets both the task and the correct context.

An excerpt from my create skill:

Turn the user’s implementation idea into a straightforward plan that a sub-agent can execute. Help the user understand the architecture and practice making technical decisions before finalizing the plan. Do not implement the task or start a sub-agent as part of this skill.

Keep implementation steps lean and retain the decision rationale separately within the plan so it remains understandable without the preceding chat. Prefer the simplest standard implementation that fits the codebase. Do not add unrequested architecture, abstractions, design patterns, features, or broad refactors.

The handoff: a plan that Claude can follow without having to guess what we decided.

2. Implement with Claude

Claude Opus 5.5 · implement

Next, I give Opus 5.5 the plan. The implement skill keeps the work focused: make the requested change, use the existing structure and make routine implementation choices without over-engineering.

The instructions from my implement skill:

Implement the following plan: “$ARGUMENTS”

Constraints:

Keep it simple, elegant, and concise. Make routine implementation choices yourself without over-engineering.
Surgically edit existing files where possible. Do not rewrite entire files unless strictly necessary.
Avoid redundant code comments. Only add short, meaningful comments in plain language if the logic is genuinely non-obvious.

The advice to make targeted edits came from a comment on r/ClaudeAI. The skill also asks for comments only where the logic needs explaining. A small feature shouldn’t come back with its own framework and a five-year roadmap.

The handoff: the code changes, ready to compare against the plan.

3. Review with Codex

GPT 6.1 Sol · review-implementation

Then I bring the work back to Codex. The review-implementation skill checks the implementation against the agreed plan and traces the changed behaviour through the surrounding code.

The focus is on functional gaps, regressions and missed edge cases. If a different solution is straightforward and meets the goal, that’s fine. Working code doesn’t need a rewrite just because another model would have written it differently.

Codex patches confirmed gaps, runs relevant checks and gives me a short list of things to verify manually.

An excerpt from my review-implementation skill:

Review the work produced from the implementation plan in this chat. Preserve code that is already functional and simple. Correct genuine gaps with the smallest clean change that fits the repository.

Focus on functional gaps, regressions, missing edge cases, and tests needed to verify changed behavior. Leave working, straightforward code alone. Avoid style-only rewrites, speculative improvements, new architecture, and unrequested features.

Give a short result summary, the corrections with their reasons and material tradeoffs, the verification performed, and a brief bulleted list of manual checks for the user. Call out any remaining functional gap that could not be corrected and why. Do not commit, publish, or open a pull request unless separately requested.

The handoff: reviewed code, an explanation of any corrections and a few concrete manual checks.

4. A human gets the final say

Me and another developer · Azure DevOps

The AI review isn’t the approval to merge. Myself and at least one other developer still review the pull request in Azure DevOps before it is merged to develop.

This is where we make the final call: does the change solve the actual problem, does the behaviour make sense and are we comfortable maintaining it? More importantly: do we understand the generated code and its effects? The plan, the diff and the AI’s review are useful inputs to that decision. AI helps me get from an idea to reviewed code. Developers still own the decision to merge it.

That’s my current setup: create, implement, review-implementation, then review again, but manually. For now, this is how I keep the kanban board moving like the subway traffic in Tokyo, while staying involved in the decisions and maintaining code quality.