Skip to content
Phuongnamsoft
How we build

AI-assisted delivery, with a person at every gate

Every new product we build runs through one workflow. AI agents do the drafting, planning and implementation. A named person approves each stage, and nothing is specified, planned, merged or shipped on an agent’s say-so.

Request a call → Where it runs today
At a glance
Human gates3, then release
Agents doDraft · plan · build
Agents neverApprove · merge · ship
The recordSpec, plan, evidence
Step 01 · Intake

Receive and analyse the requirement

A request arrives in whatever form it takes. Before anything is designed, it is turned into a brief the client recognises as their own business, with the open questions written down rather than guessed at.

01 · What arrives

A problem, not a ticket

A call, a brief, a spreadsheet of complaints, or a system that must be replaced. Interviews with the people who feel the problem, plus access to the data and tools they use today.

02 · What the agent does

Structure it

Drafts a requirements brief: actors, use cases, constraints, integrations, what is explicitly out of scope. Flags contradictions, missing decisions and the assumptions it had to make.

03 · What the person does

Confirm the problem

Checks that the brief describes the real workflow and names the outcome that will show it is solved. The brief is not accepted until you recognise your business in it.

Step 02 · Design documents

Five documents before any code

Each is drafted by an agent from the approved brief, reviewed and approved by a person, and versioned in the repository beside the code it describes. Later work may refine them; it may not silently contradict them.

01 PRD What the product must do, for whom, and how success is measured. The invariants no later change may break.
02 System design Modules, boundaries, trust zones and integrations. The architecture decisions a plan is not allowed to reopen.
03 Data schema Tables, columns, constraints and the migrations that create them, portable across the databases the product will run on.
04 ERD The entity-relationship diagram, kept in the repository as text so it stays in step with the schema instead of a slide.
05 Roadmap Releases, epics and their order, with the gate each must pass. Delivery status lives in one machine-readable file, never in prose.
Step 03 · Implementation

Eight stages, three human gates

One feature at a time. Each stage produces an artifact the next depends on, and a rejected gate sends the work back, never forward. Editing an approved document invalidates every approval downstream of it.

Who acts
Agent Person Pipeline
Why the gates are round

A round marker is a person approving one exact revision: the spec, the plan, then the branch. Passing tests, a finished report or a confident agent never opens a gate on their own.

  1. Brainstorming

    Agent Person

    The agent asks what a senior engineer would ask: alternatives, trade-offs, what the design must not do, what already exists in the codebase. Decisions and the options rejected are recorded, not only the winner.

    OutputDecision record with alternatives and rationale

  2. Spec / Design

    Agent

    A dated design document written from the brainstorm: what exists today, the decisions taken, the schema changes, the trade-offs accepted and the tests that will prove the behaviour.

    OutputVersioned spec in the repository, one per feature

  3. Review and approve the spec

    Person

    A person reads the spec and approves that exact revision. Findings are appended to the document rather than lost in chat. A rejection returns the work to brainstorming with the findings attached.

    GateApproval bound to the spec revision · rejected → back to 01

  4. Implementation plan

    Agent

    The approved spec becomes independently testable tasks with explicit interfaces, test-first steps, the files each touches and the command that verifies it. Small enough that a fresh reviewer can judge each one.

    OutputVersioned plan with a task graph and verification commands

  5. Review and approve the plan

    Person

    Sequencing, scope and risk are checked before an agent is allowed to run the plan. The approval binds the plan to the approved spec: change either and both must be approved again.

    GateApproval bound to spec and plan revisions · rejected → back to 03

  6. Implement / execute

    Agent Subagents, optional

    Tasks run test-first with frequent commits. Either one agent works the plan in sequence, or a controller dispatches a fresh implementer per task and an independent reviewer after each attempt. Progress is durable, so a lost session never re-runs finished work.

    OutputCommits, a report per task, real test output

  7. Review PR / codebase

    Person Reviewer agent

    A whole-branch review with the evidence beside it: which tests ran, which findings were fixed or explicitly accepted, and nothing described as done that the tests do not support. Merging is a human action.

    GateAcceptance bound to a commit range and evidence · rejected → back to 04

  8. CI/CD

    Pipeline Person releases

    The pipeline re-runs the suite, formatting and static checks on the merged commit and deploys to the agreed environment. Release to production remains a decision a person makes on a green build.

    OutputA deployment tied to the commit, the checks and the person who released it
Authority

Who holds what

The split is a rule of the workflow, not a habit. An agent cannot approve its own work, another agent’s work, or lower a verification bar to make a task look finished.

AI agents draft
Requirements briefs and the five design documents Feature specs, implementation plans and task briefs Code, migrations and tests, written test-first Review findings on another agent’s work
People decide
Whether the brief describes the real problem Approval of every spec and plan revision Merge, release and closing the work Any change to what counts as verified
The pipeline proves
The test suite on every commit Formatting, static analysis and security checks Deployment to the agreed environment A build record tied to the commit
Stage 04, two ways

With or without subagents

An approved plan is executed by one of two strategies. Neither changes the gates: both produce the same task reports, evidence and review record, so the person reviewing the branch sees the same thing either way.

One agent, in sequence A

One agent works the plan task by task in a single session, pausing for a review checkpoint after each. The person sees the whole branch at the end with every checkpoint recorded.

Plans of a few tightly coupled tasks Work inside one authorisation boundary or one migration When shared context between tasks matters more than fresh eyes
Subagent-driven B

A controller dispatches a fresh implementer per task with only that task’s brief, then an independent reviewer with a bounded fix loop, then a final review of the whole branch before it reaches a person.

Larger plans with many independent tasks Parallel work in separate worktrees When a fresh context per task keeps quality steady across a long plan
What it changes for you

The weeks go to the decisions only you can make

Drafting and implementation compress. Review, approval and the judgement about what the business actually needs do not, and the workflow is built so they never get skipped to save time.

You keep the documents PRD, system design, schema, ERD, roadmap, every spec and every plan live in your repository as versioned text, readable without us.
Every decision has a trail Alternatives considered, the option chosen and who approved it are written down at the time, so a question six months later has an answer.
Nothing ships on an agent’s word Every claim of done carries test output, a review verdict and a commit range. Where a claim cannot be evidenced, the report says so instead of rounding up.

See the workflow on one of your own requirements

Bring a single feature to a Blueprint. It goes through intake and the design documents, and you keep every document whether or not we build it.

Request a call → 30 minutes. We will tell you if we are not the right fit.