DEV Community

Cover image for Building a Feature with Multiple AI Agents: A Practical Walkthrough
Leego
Leego

Posted on

Building a Feature with Multiple AI Agents: A Practical Walkthrough

#multiagentai #llmcomparison #developertools #aiorchestration

The Setup: Defining Roles for a Feature

Imagine you need to add a paginated, filterable user table to a React dashboard. Instead of prompting a single model to do everything, you split the work: one agent writes the API client, another builds the UI components, a third writes tests, and a fourth reviews for accessibility. In VIBA you create a session, add the models you want — say GPT-4o for architecture, Claude 3.5 Sonnet for TypeScript, Gemini 1.5 Pro for test generation — and assign each a role with a short system prompt.

session: "user-table-feature"
agents:
  - name: "architect"
    model: "gpt-4o"
    role: "Design the data contract and API surface. Output OpenAPI snippet."
  - name: "frontend"
    model: "claude-3.5-sonnet"
    role: "Implement React components using the contract. Follow project lint rules."
  - name: "tester"
    model: "gemini-1.5-pro"
    role: "Write Vitest unit tests and Playwright e2e specs for the components."
  - name: "reviewer"
    model: "gpt-4o"
    role: "Check for a11y regressions, performance anti-patterns, and type safety."
approvals:
  - step: "api-contract"
    required: true
  - step: "component-api"
    required: true
Enter fullscreen mode Exit fullscreen mode

Each agent sees the shared conversation history, so the frontend agent can reference the exact types the architect produced.

Running the Agents in Parallel

You kick off the session. The architect returns an OpenAPI fragment describing /api/users?page=&size=&filter=. The frontend agent consumes that fragment and scaffolds UserTable.tsx, useUsers.ts, and column definitions. Simultaneously, the tester drafts a Vitest suite for the hook and a Playwright scenario that paginates and filters. Because the models run in the same session, they can ask clarifying questions of each other — the tester might ask the architect to add a totalCount field, and the architect amends the contract before the frontend agent finishes its work.

Cost per agent is visible in real time. You see token counts for each model side by side, which makes LLM comparison concrete: you learn which model gives you the cleanest TypeScript for the same prompt budget.

The Human Approval Gate

Before the reviewer runs, VIBA pauses at the api-contract approval step. You open the diff, verify the pagination shape matches your backend, and click Approve. The session resumes; the frontend agent regenerates its types against the approved contract. A second gate at component-api lets you confirm the exported props before the reviewer scans for accessibility issues. This pattern — generate, pause, approve, continue — keeps you in the loop without micromanaging every line.

Consolidating and Repairing

Once all agents finish, VIBA merges the artifacts into a single pull request. The ranked repair report surfaces any lint failures, type mismatches, or flaky test selectors, ordered by severity. You can ask the reviewer agent to auto-fix the top three issues, then re-run the repo test suite inside the same session. The result is a PR that compiles, passes tests, and meets the accessibility baseline — produced by a team of specialised models you directed, not a single black-box prompt.

Try the workflow yourself at https://viba.guru and see how a multi-agent session changes the way you ship features.

See VIBA: https://viba.guru

Top comments (0)