Splitting a Feature Request Across Specialised AI Agents with Human Approval

When a feature request lands — say, adding a paginated, filterable audit log to an existing admin dashboard — the usual flow is: one developer (or one LLM) writes the backend endpoint, the frontend components, the tests, and the migration. That works, but it also bundles very different concerns into a single context window. A different approach is to treat the request as a small project and delegate each concern to a model that excels at it, with a human gate before anything lands in main.

1. Define the roles and the handoff points

Start by writing a short spec that names the deliverables and the acceptance criteria for each. For the audit log example:

• Architect — produces the OpenAPI diff, database migration, and a one-paragraph risk note.
• Backend engineer — implements the endpoint, pagination, filtering, and unit tests.
• Frontend engineer — builds the React table, column sorting, and the filter bar.
• QA engineer — writes Playwright scenarios covering empty state, pagination boundaries, and filter combinations.
• Reviewer — you. You approve each artifact before the next agent starts.

The spec lives in a shared session so every agent sees the same requirements and the previous agent's output.

2. Run the agents in sequence with approval gates

A VIBA session for this workflow might look like:

session: audit-log-feature
agents:
  - name: architect
    model: claude-3-5-sonnet
    role: "Design the API contract and DB migration. Output: openapi.patch, migration.sql, risks.md"
  - name: backend
    model: gpt-4o
    role: "Implement the endpoint per openapi.patch. Output: route.ts, route.test.ts"
    depends_on: architect
    require_approval: true
  - name: frontend
    model: gemini-1.5-pro
    role: "Build the audit log page per the approved backend. Output: AuditLogPage.tsx, AuditLogPage.test.tsx"
    depends_on: backend
    require_approval: true
  - name: qa
    model: claude-3-5-sonnet
    role: "Write e2e tests against the running preview. Output: audit-log.spec.ts"
    depends_on: frontend
    require_approval: true

Each require_approval: true pauses the run and surfaces the agent's output in the UI. You read the diff, run the tests locally if you want, then click Approve or Request changes. The next agent only starts after approval.

3. Compare models on the same sub-task

Because the session runs multiple models, you can optionally duplicate a role to see how different LLMs handle the same prompt. For example, run both gpt-4o and claude-3-5-sonnet as backend in parallel, then compare:

• Lines of code and cyclomatic complexity
• Test coverage of the generated unit tests
• Adherence to the OpenAPI contract (VIBA can diff the generated route against openapi.patch)
• Estimated token cost per agent

This side-by-side LLM comparison is useful when you're deciding which model to standardise on for a given class of task.

4. Merge with confidence

Once the QA agent's tests pass in the preview environment, you have a complete, reviewed implementation:

• Migration reviewed by you after the Architect step
• Backend reviewed after the Backend step
• Frontend reviewed after the Frontend step
• E2E suite written and passing

You open a single PR that contains only the approved artifacts. The history shows each agent's contribution, the approval timestamp, and the model used — useful for audits and for improving future specs.

---

This pattern scales down to a two-agent flow (e.g., coder + reviewer) and up to whatever complexity your feature demands. The key idea: small, well-scoped roles, explicit handoffs, and a human checkpoint before code becomes permanent.

See how it works at https://viba.guru

See VIBA: https://viba.guru