Our Claude Code Development Workflow: 10 Steps, Human Gates
Summary: VAON uses Claude Code across 10 steps of a client project, from requirements to release. AI drafts, reviews and writes tests. Senior engineers lock the spec, approve the plan, approve the code and decide on release. Clients test against a checklist with screenshots, and each version passes a security check before it ships.
Contents
- What is Claude Code, and why does it need a process?
- The 10 steps from request to release
- Before any code: analysis, spec, screens
- Why the plan gets attacked before coding starts
- From code to pull request: tests included, three reviews
- How do clients test when AI wrote most of the code?
- What does the pre-release security check cover?
- What do senior engineers decide?
- When this workflow is not a good fit
- FAQ
1. What is Claude Code, and why does it need a process?
Claude Code is Anthropic's AI coding tool. It runs in the terminal and in editors, reads a whole codebase, edits files, runs commands and opens pull requests. It is powerful. Powerful is not the same as safe for a client's project.
One of the three questions clients asked VAON most in 2026 was: "Who checks the code the AI writes?" The answer is not a tool. It is who approves what, at which step, and what record is left behind.
So VAON does not answer with "we use AI". We answer with a 10-step workflow that states, for every step, what the AI does and what a responsible person decides. This is the standard VAON applies to most projects today, not yet to all of them.
2. The 10 steps from request to release
VAON's Claude Code development workflow has 10 steps, and none of them lets the AI decide on its own.
| # | Step | AI does | A person decides | You receive |
|---|---|---|---|---|
| 1 | Analyze the request | Lists questions and vague points | Engineer picks what to ask you | Question list |
| 2 | Lock the spec with you | Drafts the requirements document | You and VAON agree | Signed-off requirements |
| 3 | Screens (when needed) | Drafts wireframes and mockups | You approve each screen | Wireframes, mockups |
| 4 | Implementation plan | Splits work, lists files and risks | Tech Lead approves | Phased plan |
| 5 | Challenge the plan | Plays the attacker, asks questions | Tech Lead revises | Revised plan |
| 6 | Coding | Writes code to the plan | Engineer checks each part | Code with unit and e2e tests |
| 7 | Pull request review | Self-review, AI review | A second person approves the merge | Review record |
| 8 | Deploy to test | CI/CD runs | Engineer tests first | A test environment for you |
| 9 | Client testing | Writes a user-view checklist | You test and capture results | Checklist with screenshots |
| 10 | Security check, release | Reviews the changes for security | A person reads the findings and decides | Release notes |
The "A person decides" column matters most. Remove it and the workflow is just a chain of AI commands.
3. Before any code: analysis, spec, screens
Before coding, VAON uses AI to find gaps in the requirements, not to guess on your behalf. The first three steps serve one goal: both sides understand the same thing.
In analysis, the engineer and Claude read your initial request together. The AI is good at listing questions: where the old data lives, who approves what, what happens on failure. The engineer filters the list and keeps only the questions you can answer.
Next, the AI drafts the requirements document from meeting notes. The engineer edits it and sends it to you for written confirmation. On new projects this happens in VAON's Spec Lock Phase (仕様確定フェーズ), usually 1 to 2 weeks.
When it helps, the AI drafts wireframes and mockups so you see real screens early. Why the spec is where most offshore projects break is covered in why offshore development fails: the spec, not the code.
4. Why the plan gets attacked before coding starts
The plan gets challenged before coding because fixing a line in a plan costs far less than fixing a finished module. With AI this matters more. AI writes code fast, so a wrong plan becomes wrong code fast.
Once the spec is locked, the engineer uses Claude to write an implementation plan: phases, files to change, done criteria and risks. Claude Code has a plan mode in which it only reads and proposes, and edits nothing until a person approves.
Then come two rounds of challenge:
- Red team: the AI plays someone trying to make the plan fail. If a data migration stops halfway, how do we roll back? Does any access right get wider than it should?
- Validate: the AI checks the plan against the spec with questions. Anything the spec cannot answer goes back to you. Nobody guesses.
A Tech Lead or senior engineer reads both rounds and decides what to change. The plan moves to coding only after someone other than its author has challenged and confirmed it.
5. From code to pull request: tests included, three reviews
At VAON, AI-written code does not reach the main branch without tests and a second reader. The main branch is protected: no merge without review.
Claude writes code phase by phase, following the plan. Unit tests and e2e tests (end-to-end tests that walk through the app like a real user) sit in the same pull request as the code. The engineer runs them, reads them and fixes them before pushing.
Every pull request gets three reviews:
- Self-review: the author reads the whole diff again.
- AI review: Claude reads the diff against the project's review criteria.
- Second reader: another engineer reviews, and the team lead decides on the merge.
Alongside that, every pull request runs automated gates on every project: secret scanning, dependency scanning and static analysis. How we read AI-written code is covered in what humans check when reviewing AI-generated code.
6. How do clients test when AI wrote most of the code?
Clients test against a checklist written from the user's side, not the developer's, and every item has a screenshot of the result. This step is easy to skip because automated tests feel like enough.
After the merge, CI/CD deploys to a test environment. VAON engineers test first. Only then do we tell you it is ready.
Claude drafts the checklist from the locked requirements and an engineer edits it. A typical item looks like this:
| Item | Action | Expected | Actual | Screenshot |
|---|---|---|---|---|
| Create order | Leave the phone field empty, press Save | Error shown under the phone field | (you fill in) | (attach) |
Screenshots do two jobs. A bug is described clearly the first time, so nobody has to ask "what did you click before that?" And later, both sides have proof of how each version was accepted.
7. What does the pre-release security check cover?
The pre-release security check is a separate gate that runs before every version on projects using this workflow. Claude Code includes a /security-review command that reviews the changes on the current branch.
The gate has two parts. The AI reviews all changes in the version for security issues. Then a person reads the findings, separates real issues from false alarms, and decides to release or fix first.
It sits on top of a baseline that runs on every project:
- secret scanning, dependency scanning and static analysis on each pull request;
- an AI security review of each pull request's changes, with a person reading the results (when you allow code in AI tools);
- checking package names the AI suggests before installing, because AI can invent package names;
- a company-managed Claude Code configuration (blocked commands, sandbox, approved MCP servers);
- no real keys in development environments.
AI security review adds to human review. It does not replace it. It raises false alarms and it can miss things. The process references NIST SSDF (SP 800-218); VAON does not claim compliance with any framework.
8. What do senior engineers decide?
Senior engineers at VAON decide the things that are expensive to get wrong: scope, architecture, trade-offs and whether to release. The CTO and a Tech Lead are involved in every project.
| Area | AI is good at | Seniors keep the decision on |
|---|---|---|
| Spec | Listing questions, spotting contradictions between documents | Which questions to ask, where scope ends |
| Plan | Splitting work, finding risks | Architecture, order, trade-offs |
| Code | Writing fast, generating tests | Whether the code matches the business rule |
| Security | Reviewing every change quickly | Which findings are real, whether to ship |
AI adds speed. Seniors hold the standard. Every project keeps review and test records that the client can see.
9. When this workflow is not a good fit
The 10-step workflow does not fit every job, and VAON does not apply it rigidly. Three cases are worth stating:
- Very small changes. Fixing a label does not need a red-teamed plan. The workflow scales down with the size of the change.
- You have not allowed code to go into AI tools. Then the AI review and AI security steps do not run. Only the automated gates and human reviewers remain.
- Nobody on your side can answer business questions. AI cannot replace the person who knows the work. Without that person, the spec turns into guesswork.
VAON also has 15 full-time staff. A project that needs dozens of people at short notice may be beyond what we can take on.
10. FAQ
Does using Claude Code make a project cheaper? Some parts, not all. AI speeds up drafting, repetitive code and test writing. Business analysis, spec work, review and client testing still need people, and VAON does not cut those steps. That is why VAON does not promise a general cost-reduction percentage. Quotes are based on the scope in the locked requirements document.
Will my source code be used to train AI? Before work starts, VAON agrees with you which data may be used, who may see it, and whether code may go into AI tools. If you have not given permission, VAON does not put your code or data into any AI tool. How we handle permissions in Claude Code is covered in permission, sandbox and data rules for Claude Code at work.
Who is responsible if AI-written code has a bug? Responsibility is set by the contract for each project. VAON does not treat "the AI wrote it" as a reason for responsibility to change. AI-written code goes through the same review, testing and security checks as human-written code, and both sides have records to check against when something goes wrong.
Do I need to know Claude Code to work with VAON? No. You work with requirements documents, mockups, a test environment and checklists, as on any project. The difference is that you get more records: the approved plan, review records, test results with screenshots, release notes. You can look at them whenever you want.
Does this workflow work for a system that is already running? Yes, but the first steps differ. For an existing system, VAON reads the source code, interviews the people who run it and measures the current state before locking the spec for the change. AI reads code faster. But code shows what a system does, not why, so the business users still have to confirm.
One thing you can do today: if you work with a team that uses AI, ask them one question. "At which step does one of your people read the AI-written code, and where can I see that record?" The answer tells you whether they have a process or only a tool. The full list of questions is in 12 questions to ask before outsourcing AI-driven development.
To see how this workflow would apply to your project, book a free 60-minute consultation. Our CEO joins, you need no documents, and there is no commitment.
Author: Dang Van Luan, Founder & CEO, VAON. Graduate of HEDSPI (Hanoi University of Science and Technology). Worked at FPT Software, then 5 years at Digital Plus (Tokyo) on a system with 10 million users. 8 years as COO of a 120-person IT outsourcing company, where he built the management system to ISO 9001 and ISO 27001. 15 years in the industry.
