DEV Community: Leego

Multi-Agent AI Orchestration in Practice: Splitting a Coding Task with VIBA

Leego — Wed, 11 Nov 2026 23:57:18 +0000

In modern development workflows, a single AI model often struggles to handle the full scope of a complex coding task. A feature implementation might require code generation, unit test creation, documentation drafting, and security review—each with different strengths and failure modes. VIBA (Collaborative Multi-Agent AI Orchestration) addresses this by letting you run several LLMs in one shared session, assign each a specific role, and maintain full control over the process. This approach turns a monolithic prompt into a coordinated team of specialized agents that can hand off work, validate outputs, and ensure quality before final delivery.

The core idea is to decompose a coding task into discrete sub-tasks, route each to the most appropriate agent, and insert human approval checkpoints where needed. This pattern is especially valuable when different models excel at different capabilities. For example, a model specialized in code generation might draft the implementation, while another focused on testing verifies correctness. A third agent could review documentation for consistency, and a fourth might check for potential security issues. The orchestration layer ensures that each agent receives the right context, and you can monitor cost per agent in real time to make informed engineering decisions.

Consider a task like refactoring a module to improve test coverage. Imagine you need to extract a utility function, add a new test case, and update the module's docstring. With VIBA, you would set up three agents: an Agent-Planner to outline the refactoring strategy, an Agent-Coder to write the implementation, an Agent-Test to generate the test, and a human approver to review the results. The workflow begins by creating a shared session where all agents can access the repository state. The Agent-Planner proposes a breakdown of the task. The Agent-Coder begins implementation, then pauses to wait for the Agent-Test to validate the changes. Only after the test results are satisfactory does the Agent-Test approve the code, and the human approver performs a final review before merging.

The configuration is straightforward but powerful. You define agent roles, assign each a specific function, and set approval thresholds. The UI provides cost per agent visibility, which helps teams understand the engineering budget for complex tasks. For example, if you are running four agents simultaneously on a small task, you can compare their individual costs and decide whether to consolidate or add more specialized agents. This transparency turns what might be a guessed shared-bill into an explicit engineering decision.

Human oversight is not just about safety—it is also about cost management. Different agents may have varying performance characteristics, and running the wrong model for a task can waste compute. VIBA's per-agent cost metrics allow you to evaluate trade-offs. By approving only key steps, you retain control over the final output while still benefiting from the speed and capability of multiple models. The system also logs interactions, so you can trace why a particular decision was made and replicate successful patterns across projects.

The workflow example above demonstrates how VIBA can transform a coding task from a single-point failure into a robust, multi-step process. Each agent contributes its strengths—code generation, testing, documentation, and security review—while the human approver ensures alignment with project goals. This pattern scales from small feature additions to larger architecture changes, making it suitable for teams of all sizes.

To get started, sign up at https://viba.guru and explore the demo workflows. Build a shared session, define your agent roles, and set up approval checkpoints at natural boundaries in your task. As your team grows, you can extend the system with additional agents and refine your cost model. The result is a development process that leverages the best of multiple LLMs while keeping human judgment at the center of quality and delivery.

By treating AI orchestration as a deliberate engineering decision rather than an automatic shortcut, teams can achieve higher quality code with better visibility into costs and risks. The pattern of splitting tasks, assigning specialized agents, and inserting human oversight is repeatable across projects and languages. Experiment with VIBA to see how it fits into your current workflow and discover where multi-agent collaboration can improve your development productivity.

multi-agent-AI, #LLM-comparison, #dev-community, #code-workflow

Call to Action: Start building your multi-agent AI workflow today at https://viba.guru

See VIBA: https://viba.guru

Running a multi-model coding session in VIBA — roles, generation, and a human approval checkpoint

Leego — Sun, 08 Nov 2026 01:40:40 +0000

VIBA enters the scene as a shared-session platform that lets you run several AI models—ChatGPT, Claude, Gemini, and others—side by side, assign each a role, and keep a human in the loop for key decisions. For teams that want to explore multi-agent AI without committing to a single provider, this approach offers a practical way to compare how different models handle the same coding problem, while retaining oversight at critical junctures.

Assigning specialised roles in a single session

A typical coding task can be broken into distinct sub‑problems: understanding the requirements, designing the architecture, writing the implementation, and testing the result. In VIBA, each of these can be handed to a different model, with its own system prompt and role label. One model might act as an architect, another as an implementer, and a third as a reviewer. Because they operate within the same session, their outputs are visible to one another and to you, the human operator, in one consolidated view. This setup makes it straightforward to observe how a ChatGPT‑based agent frames a solution versus how Claude or Gemini approach the same sub‑task, all without leaving the platform.

From generation to the approval checkpoint

Once the models produce their initial outputs, the workflow pauses for a human approval step. Imagine you’re adding a new data‑validation layer to an existing service. The architect agent proposes a design, the implementer agent generates a pull‑request‑ready code block, and the reviewer agent drafts a set of test cases. Before anything is merged, you review the combined output, check for edge cases, and either sign off or ask for revisions. This approval checkpoint is where the “human-in-the-loop” aspect becomes concrete: you’re not just passively consuming output, you’re actively deciding what moves forward. The platform records which agent contributed which piece, making the review process traceable and accountable.

Cost visibility as a design choice

One of the more practical benefits of VIBA is per‑agent cost tracking. Each model’s usage is logged separately, so you can see, for example, that the Claude‑based reviewer consumed fewer tokens than the Gemini‑based architect for the same class of work. This visibility turns cost from an afterthought into a deliberate design choice: if you notice one model consistently generating verbose scaffolding while another stays concise, you can adjust role assignments or system prompts accordingly. Over a series of tasks, this data helps a small team calibrate their multi-agent AI usage without guesswork.

A concrete config snippet

While the exact interface may evolve, a typical VIBA session might start with a configuration that labels each model and maps them to roles. Here’s a hypothetical example of how such a setup could be expressed:

session: coding-task-2025-05-20
agents:
  architect:
    model: gpt-4o
    role: design
    system_prompt: "You are a senior software architect. Produce a concise design brief for the given requirement, including data flow, component responsibilities, and potential risk points."
  implementer:
    model: claude-3-5-sonnet
    role: code
    system_prompt: "You are a pragmatic full‑stack developer. Write production‑ready code snippets that follow the design brief, adhering to the project’s existing style guide and avoiding deprecated patterns."
  reviewer:
    model: gemini-1.5-pro
    role: test
    system_prompt: "You are a QA engineer. Based on the implementation, generate a minimal set of unit tests that cover the critical paths and edge cases. Highlight any assumptions you make."
human_approval: true

In this example, the human_approval flag signals that no output should be finalized without your sign‑off—a safeguard for teams that can’t afford unchecked auto‑merge behavior.

Moving forward

The combination of role‑specific models, a shared session, and an explicit approval step gives developers and small teams a way to harness multi‑agent AI that feels both powerful and controlled. You get the comparative insight of running different LLMs on the same problem, the transparency of seeing who contributed what, and the safety net of a human decision point before anything ships. If you’re curious about how this might look in practice, the platform is set up for exactly that kind of experimentation.

https://viba.guru

multi-agent-ai #llm-comparison #dev-tools #viba

See VIBA: https://viba.guru

Building a Feature with a Multi‑Agent AI Pipeline and a Human Review Step

Leego — Sat, 07 Nov 2026 13:40:37 +0000

Introduction

When a single large language model writes an entire feature, the result often looks plausible but hides subtle bugs, mismatched conventions, or security gaps. A more reliable approach is to split the work among several specialised agents — each model handling a narrow slice such as API design, data‑layer implementation, test generation, or documentation — and then insert a human approval gate before the pieces are merged. VIBA provides exactly this orchestration layer: you can spin up a shared session that hosts ChatGPT, Claude, Gemini, and other models, assign each a role, inspect per‑agent cost, and pause for a reviewer at any step. The platform also surfaces UI‑testing results, repository‑level static analysis, beta‑test feedback, and ranked repair reports, giving you a complete evidence trail for every change.

Defining the Agent Roles

Imagine a team that needs to add a paginated search endpoint to an existing Node.js service. Instead of prompting one model to produce the whole pull request, you declare a small roster:

agents:
  - name: architect
    model: gpt-4o
    role: "Design the OpenAPI spec and define request/response contracts"
  - name: implementer
    model: claude-3-opus
    role: "Write the Express route, service layer, and database query"
  - name: tester
    model: gemini-1.5-pro
    role: "Generate unit and integration tests covering happy path and edge cases"
  - name: reviewer
    model: gpt-4o
    role: "Produce a ranked repair report highlighting security, performance, and style issues"

Each entry maps a logical role to a concrete model. Because the session is shared, the architect’s spec is instantly visible to the implementer, and the tester can reference the same contract when writing assertions. The cost column that VIBA surfaces next to each agent lets you decide whether a cheaper model suffices for a given role or whether the higher‑priced option is justified by the risk profile.

Human Approval as a Design Decision

The pipeline does not run autonomously from start to finish. After the architect emits the OpenAPI document, VIBA presents it in a diff view and asks the developer to approve or request revisions. This gate serves two purposes:

Quality control – a human can catch ambiguous parameter names, missing pagination metadata, or versioning inconsistencies before downstream agents consume the spec.
Cost awareness – the approval screen shows the cumulative token spend so far. If the architect’s output already exceeds the budget you allocated for the design phase, you can either trim the spec or swap in a lower‑cost model for the remaining agents.

Once approved, the implementer receives the locked spec and begins coding. The same approval pattern repeats after the implementer finishes: the generated route file, service module, and migration script appear side‑by‑side with the original spec, and the reviewer can accept, annotate, or reject. Only after the human sign‑off does the tester agent run, producing a test suite that is automatically executed against a temporary staging environment. The final ranked repair report aggregates static‑analysis findings, test‑coverage gaps, and any UI‑testing regressions, ordered by severity.

Observing the Multi‑Agent Feedback Loop

Because every agent writes to the same session, disagreements become visible instantly. For example, the implementer might choose a cursor‑based pagination strategy while the architect’s spec describes offset‑based paging. VIBA highlights the mismatch in the shared timeline, and the reviewer can decide which approach aligns with the product roadmap. This LLM comparison is not a benchmark; it is a practical signal that the team can act on without leaving the tool.

The ranked repair report adds another dimension. Suppose the tester’s suite passes but the reporter flags a missing index on the search column, a potential N+1 query in the service layer, and a content‑security‑policy header omission in the response. The report ranks these by estimated impact, letting the developer address the highest‑risk items first. When the fixes are applied, the pipeline can be re‑run from the implementer step onward, preserving the earlier approved spec and test artefacts.

Extending the Pattern

The same orchestration works for front‑end work, infrastructure as code, or documentation updates. You might add a designer agent that produces Figma‑compatible JSON, a security agent that runs threat‑model checks, or a release agent that drafts changelog entries. Each new role simply becomes another entry in the YAML roster, and the human approval points remain under your control.

VIBA’s UI‑testing, repo‑testing, and beta‑testing integrations mean that the evidence gathered by each agent is not confined to text. Screenshots, lint results, and real‑user feedback can be attached to the session, giving the reviewer a holistic view before the merge button is pressed.

Learn more at https://viba.guru

See VIBA: https://viba.guru

Human-in-the-Loop Multi-Agent Coding: A Practical Example

Leego — Wed, 04 Nov 2026 19:03:32 +0000

Introduction

When a feature requires more than one perspective—implementation, security, UI validation—splitting the work across specialized agents can keep momentum high while preserving quality. VIBA makes it possible to run several models (ChatGPT, Claude, Gemini and others) in a single session, assign each a role, pause for human approval, and watch cost per agent update in real time. The following walkthrough shows how a small team could tackle a modest logging‑middleware feature using three agents and a single approval checkpoint.

Defining the Task and Choosing Agents

The goal is to add request‑ID propagation to an Express API. Three distinct concerns emerge:

Code generation – turning the design into production‑ready middleware.
Security review – ensuring the IDs are not leaked or tampered with.
UI testing – confirming that a simple front‑end dashboard displays the IDs correctly.

Each concern maps to a different model strength. A generative model like GPT‑4 excels at writing idiomatic code, while Claude’s strong reasoning helps spot edge‑case vulnerabilities. Gemini’s multimodal capabilities are useful for interpreting UI mockups and generating test scripts. By assigning each model a dedicated role, the workflow stays organized and the output stays comparable.

Configuring Agents and Approval Steps

VIBA’s configuration lets you declare agents, their models, roles, and whether a step needs explicit approval. Below is a minimal YAML snippet that captures the three agents for the logging feature:

agents:
  - name: CodeGenerator
    model: gpt-4
    role: implement feature
    approval: required

  - name: SecurityReviewer
    model: claude-3
    role: check auth
    approval: required

  - name: UITester
    model: gemini-pro
    role: run ui tests
    approval: required

The approval: required flag inserts a pause after each agent finishes its work. The human reviewer receives a concise summary, the generated artifacts, and a cost estimate for that agent. If the summary looks reasonable, the reviewer clicks “Approve” and the next agent starts. This deliberate hand‑off prevents unexpected side effects and keeps the total spend visible at every stage.

Running the Workflow and Reviewing Costs

With the config loaded, the session begins with the CodeGenerator. It outputs a middleware file (requestIdMiddleware.js) that injects a UUID into each request. VIBA displays a cost line—e.g., “$0.012 for CodeGenerator”—and a “Review” button. The reviewer opens the file, checks style, and confirms it matches the Express version used in the repo.

Approval triggers the SecurityReviewer. It analyzes the middleware for injection attacks, token exposure, and proper error handling. The reviewer sees a security report, the associated cost, and decides whether to accept, request changes, or reject outright. Because the cost is shown upfront, the team can decide if the security depth justifies the expense.

The final agent, UITester, runs a headless browser test against a static HTML prototype. It generates a report ranking issues by severity. Again, the cost is displayed before the reviewer finalizes the step. After all three approvals, VIBA aggregates the reports into a single repair checklist, ordered by impact.

Iterating with Human Feedback

If any agent’s output fails approval, the workflow loops back to the responsible agent with a concise feedback note. For example, the SecurityReviewer might flag a missing rate‑limit header. The CodeGenerator can regenerate the file with the header added, and the cycle repeats until the human reviewer is satisfied. Because each iteration is isolated, the cost remains transparent, and the team can stop early if the feature meets requirements.

The entire process—from initial config to final approval—demonstrates how multi‑agent AI can be treated like a coordinated development squad. The human stays in control, the models bring specialized expertise, and the cost per agent is never hidden.

Explore how VIBA can streamline your own multi‑agent workflows at https://viba.guru.

See VIBA: https://viba.guru

Orchestrating Multiple Models for a Development Task

Leego — Wed, 04 Nov 2026 19:02:01 +0000

Developers often juggle multiple large‑language models to get the best result for different parts of a codebase. One model might excel at generating boilerplate, another at explaining edge cases, and a third at testing. The challenge is coordinating these outputs into a single, coherent workflow without spending hours on manual reconciliation. VIBA addresses this by letting you run several AI models in one shared session, assign each a role, and review key steps yourself before anything moves forward. This article walks through a concrete, hypothetical example of splitting a coding task across specialised agents with a human approval step, and highlights how cost visibility fits into the picture.

Giving Each Model a Clear Role

In a typical multi‑model setup, the first decision is which model handles which sub‑task. You might send a design prompt to Claude for its strength in structured thinking, forward implementation details to ChatGPT for code generation, and ask Gemini to verify syntax or suggest alternatives. The key is that each model receives a focused prompt rather than a vague “write this feature” request. This not only improves output quality but also makes it easier to compare how different models approach the same problem. VIBA’s shared session means you can see each agent’s reasoning, output, and associated cost side by side, without hopping between separate chats or interfaces.

A Hypothetical Feature Split with Approval Steps

Imagine you’re adding a new “dark mode” toggle to a web app. Instead of asking a single model to do it all, you split the work:

Model A (ChatGPT) generates the component markup and CSS custom properties for the toggle.
Model B (Claude) reviews the markup for accessibility concerns and suggests ARIA labels.
Model C (Gemini) writes a small Jest test suite to verify the toggle switches classes correctly.

After each agent finishes, VIBA pauses the workflow and presents a summary screen to you. You can accept the output, ask the agent to refine a specific part, or reject it outright. Only after your approval does the next agent receive the baton. This human‑in‑the‑loop step ensures that no single model’s blind spot propagates downstream, and it keeps you in control of the final code quality.

To make this concrete, here’s a minimal VIBA‑style configuration snippet that defines the agent roles and the approval gate:

agents:
  - name: generator
    model: chatgpt
    role: generate component markup and CSS for dark‑mode toggle
    approval: required
  - name: auditor
    model: claude
    role: check accessibility, suggest ARIA improvements
    approval: required
  - name: tester
    model: gemini
    role: write Jest tests for toggle behavior
    approval: optional
workflow:
  - generator
  - auditor
  - tester
approval_mode: sequential

The approval: required flag on the first two agents means VIBA will stop and show you the generated markup and the auditor’s suggestions before proceeding. The third agent’s optional approval lets you choose whether to review the tests immediately or trust the model’s output given the prior steps were vetted.

Tracking Cost Per Agent, Not Just Output

One of the biggest pain points in multi‑model work is hidden cost. Each model has its own pricing, and without a central view, it’s easy to lose track of what you’re spending. VIBA surfaces a cost breakdown per agent, so you can see at a glance that the generator used 3,000 tokens, the auditor 1,200, and the tester 800. This visibility doesn’t just help with budgeting—it informs future role assignments. If you notice the tester consistently produces tests that need heavy revision, you might shift that responsibility to a different model or adjust the prompt length. The goal is deliberate, informed choices rather than guesswork.

Wrapping Up

Splitting a coding task across specialised AI agents with a human approval step is less about replacing developers and more about extending their capacity. By giving each model a well‑defined role, inserting clear approval gates, and keeping cost in view, teams can move faster while maintaining the quality checks that matter. VIBA provides the orchestration layer that makes this pattern repeatable across features, fixes, and experiments—without locking you into a single vendor or workflow.

If you’re curious about how this looks in practice, head over to https://viba.guru to explore the platform and see how multi‑agent orchestration can fit into your own development cycle.

HASHTAGS: multi-agent-ai, llm-comparison, devtools, orchestration

See VIBA: https://viba.guru

Coordinating Specialized AI Agents with VIBA for Everyday Development

Leego — Tue, 03 Nov 2026 13:19:54 +0000

Developers routinely split complex features across functions, services, and teams. When AI enters the picture, the same principle applies: different models bring different strengths, and coordinating them can yield better results than forcing a single prompt to do everything. VIBA provides a framework for multi-agent AI orchestration, letting you assign roles, keep a shared session context, and insert human approval checkpoints exactly where they matter. In this article, we'll walk through a realistic coding scenario, show how specialized agents can collaborate, and highlight how LLM comparison becomes a practical part of the workflow rather than an afterthought.

Assigning Roles to Complementary Agents

In a typical feature request, the work often splits naturally into distinct sub‑problems: generating API routes, rendering frontend components, and writing test suites. Each of these benefits from a model tuned or inclined toward that particular domain. With VIBA, you can define a role for each agent up front. One agent might specialize in backend logic, another in UI scaffolding, and a third in generating reliable test coverage. The system maintains a single shared session, so every agent sees the same conversation history, decisions, and code snippets without needing to re‑prompt context.

For example, when asked to add a new authentication endpoint, the backend agent reaches for the framework’s standard pattern, the frontend agent proposes a protected route component, and the test agent drafts unit tests that cover token validation. Because the session is shared, each agent can reference the others’ output, reducing redundancy and keeping the overall direction consistent. This role‑based division is the core of effective multi-agent AI workflows: it leverages model strengths while avoiding the “jack of all trades, master of none” trap.

Human‑in‑the‑Loop Approval Checkpoints

The most critical part of any AI‑augmented development process is maintaining developer control. VIBA inserts explicit approval steps into the orchestration flow. After each agent produces its contribution, the platform surfaces the change for review before any code is committed or merged. This means the backend route, the UI component, and the test suite are each presented individually, with diffs and cost summaries visible in the interface.

Consider a workflow for implementing a new API endpoint. The backend agent generates the route handler and service method. Before anything moves forward, the developer reviews the handler’s logic, checks input validation, and confirms the response schema. Only after approval does the frontend agent generate the corresponding component, and the test agent finalize its spec. If any agent’s output raises a concern, the developer can request a revision from that specific agent without restarting the entire chain. This human‑in‑the‑loop design ensures that the final product reflects both AI efficiency and developer judgment.

Comparing Models Side‑by‑Side and Tracking Cost

One of the most tangible advantages of a multi-agent setup is the ability to compare model outputs directly. VIBA surfaces per‑agent metrics such as latency, token usage, and cost, so you can see at a glance which model delivered the most useful result for a given sub‑task. When two agents propose different implementations for the same problem, the platform highlights the divergence, lists the associated cost, and lets you decide whether to reconcile the approaches or pick a winner.

LLM comparison in this context is not about defaulting to the “best” model every time; it’s about having data‑driven confidence. Perhaps Gemini excels at generating concise test assertions, while Claude produces more readable route handlers. By tracking these patterns across multiple tasks, your team can make informed assignments rather than guessing. The cost-per-agent dashboard also prevents surprise expenses, giving you a clear picture of how model choice impacts both quality and budget.

A Concrete Orchestration Snippet

Below is a minimal VIBA configuration that defines three agents, assigns them roles, and flags the approval checkpoints. The structure is intentionally plain so it can be adapted to your own tooling or CI pipeline.

session: feature/auth-endpoint
agents:
  backend:
    model: gpt-4o
    role: backend-generator
    approval: true
  frontend:
    model: claude-3-5-sonnet
    role: ui-scaffolder
    approval: true
  tests:
    model: gemini-1.5-pro
    role: test-author
    approval: true
steps:
  - agent: backend
    task: "Implement the /login route with token validation"
  - agent: frontend
    task: "Create a protected login component using the route above"
  - agent: tests
    task: "Write unit tests that cover successful and failed login scenarios"

In this example, each agent runs in the same shared session, and the approval: true flag ensures that no step proceeds without developer sign‑off. The cost and model choice are explicit, making the trade‑offs visible from the start.

Wrapping Up

Splitting a coding task across specialized AI agents doesn’t have to mean relinquishing control. With VIBA, the workflow becomes: assign roles, let agents contribute in a shared session, review at designated checkpoints, and compare models when the data warrants it. This approach scales from small teams prototyping a new feature to larger organizations maintaining consistent code quality across many repositories. The key is treating each agent as a focused contributor rather than a monolithic replacement for human expertise.

Learn more at https://viba.guru

See VIBA: https://viba.guru

How Different Models Handle Different Parts of a Feature — A Multi-Agent Workflow

Leego — Sun, 01 Nov 2026 23:39:00 +0000

The Problem with Single-Model Workflows

When you ask one large language model to design, implement, test, and review a feature, you get a jack-of-all-trades result. The model that excels at API design might hallucinate edge cases in validation logic. The one that writes clean tests might over-engineer the implementation. Most teams end up pasting context between chat windows, manually stitching together outputs, and losing track of which model suggested what.

VIBA changes this by letting you run ChatGPT, Claude, Gemini, and other models in a single shared session. Each model gets an explicit role. You approve key transitions. You see token usage and cost per agent. The session becomes a collaborative workspace rather than a series of disconnected prompts.

A Concrete Example: Building a Payment Webhook Endpoint

Imagine your team needs a new /webhooks/stripe endpoint for a Node.js service. The requirements are straightforward: verify Stripe signatures, idempotently process checkout.session.completed events, update the local order status, and emit a domain event for downstream consumers.

Instead of one long prompt, you define four agents in a VIBA session:

agents:
  - name: architect
    model: claude-3-5-sonnet
    role: "Design the interface, data flow, and error handling strategy. Output an OpenAPI fragment and a sequence diagram."
  - name: implementer
    model: gpt-4o
    role: "Write the Express route, signature verification, idempotency key storage, and domain event emission. Follow the architect's spec exactly."
  - name: tester
    model: gemini-1.5-pro
    role: "Generate unit tests (Vitest) and contract tests (Pact) covering happy path, invalid signature, duplicate event, and missing idempotency key."
  - name: reviewer
    model: claude-3-5-sonnet
    role: "Security and correctness review. Check for timing attacks, replay vulnerabilities, proper error codes, and observability hooks."

Each agent sees the full conversation history. The architect produces a spec. You read it, ask for clarification on idempotency key TTL, approve, and the implementer starts. The implementer writes code. You spot a missing await on the event bus publish, request a fix, approve. The tester generates tests against the actual implementation. The reviewer flags that the signature verification uses == instead of constant-time comparison — a subtle timing attack vector the implementer missed.

Why Model Specialization Matters

This isn't about one model being "better." It's about matching model strengths to task types:

Claude tends to produce more structured, specification-oriented output. It excels at architecture and review roles where precision and reasoning matter.
GPT-4o writes idiomatic, production-ready code quickly. It handles framework conventions (Express middleware patterns, TypeScript types) with less hand-holding.
Gemini 1.5 Pro has a massive context window and strong test generation capabilities. It can ingest the entire implementation and produce comprehensive test suites including edge cases you didn't specify.

When you run them in sequence with shared context, each model builds on the previous one's output without context loss. The implementer doesn't need to re-explain the architecture — it's already in the session. The reviewer sees the actual code, not a summary.

Human Approval as a Control Point, Not a Bottleneck

The approval steps are lightweight. After each agent completes its task, VIBA presents a diff or summary. You can:

Approve — move to the next agent
Request changes — the same agent revises with your feedback in context
Branch — spin off a parallel exploration (e.g., "try this with Fastify instead") without derailing the main flow

This keeps you in the loop on decisions that matter — security choices, API contracts, cost tradeoffs — while automating the mechanical work. You're not reviewing every line; you're reviewing the right lines.

Cost visibility reinforces this. The session dashboard shows tokens and estimated cost per agent. If the reviewer's pass costs 3x the implementer's, you can decide whether that's justified or whether a lighter review prompt suffices. No surprises at the end of the month.

Beyond the Happy Path

The same pattern applies to refactoring, migration, and debugging. For a legacy Python-to-Go migration, you might assign:

An analyst agent (Gemini) to map dependencies and extract business rules from the codebase
A planner agent (Claude) to produce a phased migration strategy with rollback points
A translator agent (GPT-4o) to convert modules one at a time, with the analyst's rules as context
A validator agent (Claude again) to run property-based tests against both implementations

Each phase gates on your approval. The session preserves the full rationale — why this module first, why this translation choice — so future maintainers (or future you) can trace decisions without archaeological dig through chat logs.

Getting Started

You don't need a complex setup to try this. Define a small task — a single endpoint, a data transformation pipeline, a flaky test fix. Assign two or three roles. Run the session. Observe where the model boundaries create value and where they add friction. Adjust roles, prompts, and approval points.

The goal isn't to replace your judgment. It's to give you better inputs for that judgment — specialized outputs, explicit rationale, visible costs — all in one place.

Try a session at https://viba.guru and see how model specialization changes the way you build.

See VIBA: https://viba.guru

Splitting a Feature Request Across Specialised AI Agents with Human Approval

Leego — Sat, 24 Oct 2026 03:50:28 +0000

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

Coordinating Specialized AI Agents with Explicit Human Checkpoints

Leego — Fri, 23 Oct 2026 02:02:49 +0000

Introduction

When a coding task grows beyond a single prompt, the natural next step is to delegate parts of the work to models that excel in different domains — one for architecture, another for test generation, a third for performance tuning. VIBA makes this practical by letting you run several LLMs in a shared session, assign each a role, and insert mandatory human approval before any change reaches the repository. The result is a transparent pipeline where cost, latency, and quality are visible per agent.

Defining Roles and Hand‑offs

Start by describing the work in a lightweight YAML manifest. Each agent receives a name, a model identifier, and a concise responsibility statement. The manifest also declares approval gates — points where the orchestration pauses until a developer confirms the output.

agents:
  - name: architect
    model: gpt-4o
    role: "Produce high‑level module layout and interface contracts"
  - name: implementer
    model: claude-3.5-sonnet
    role: "Write production‑ready code for the approved contracts"
  - name: tester
    model: gemini-1.5-pro
    role: "Generate unit and integration tests covering the new code"
approvals:
  - after: architect
  - after: implementer

When the session starts, VIBA spins up the three models, feeds the architect the initial requirements, and presents the resulting design for review. Only after you accept does the implementer receive the approved contracts. The same gate repeats before the tester runs.

Human Approval in Practice

The approval step is not a generic “looks good” button. VIBA surfaces a diff‑style view for each gate: the architect’s diagram, the implementer’s file changes, the tester’s new test files. You can comment inline, request a revision, or approve with a single click. Because each agent’s output is isolated, you can trace exactly which model introduced a regression or a style deviation.

Cost tracking is attached to every agent. After the run you see a breakdown such as:

Architect (GPT‑4o): 1,200 tokens, $0.018
Implementer (Claude‑3.5‑Sonnet): 4,500 tokens, $0.067
Tester (Gemini‑1.5‑Pro): 2,300 tokens, $0.032

This granularity helps small teams decide whether a cheaper model suffices for a given role or whether the higher‑priced option pays off in reduced rework.

Extending the Pipeline

The same pattern scales to additional stages — static analysis, UI snapshot comparison, or beta‑user simulation — each with its own model and optional gate. VIBA also aggregates the results into a ranked repair report, highlighting the most likely failure points across agents. Teams can then prioritize fixes without sifting through raw logs.

By making the hand‑off explicit and the approval mandatory, the workflow turns “multiple LLMs” from an experiment into a repeatable engineering process. You retain control, the models stay focused, and the cost model stays predictable.

Learn more at https://viba.guru

See VIBA: https://viba.guru

Building a Feature with Multiple AI Agents: A Practical Walkthrough

Leego — Thu, 22 Oct 2026 20:07:38 +0000

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

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

Building a Feature Flag System with Three AI Agents and a Human Gate

Leego — Thu, 22 Oct 2026 11:45:25 +0000

Introduction

Most developers have tried prompting a single LLM to write a complete feature. The result often works for the happy path but misses edge cases, security concerns, or architectural consistency. VIBA takes a different approach: you define a session with multiple models, each assigned a specific role, and insert human approval gates at critical decision points. The platform runs ChatGPT, Claude, Gemini, and others side by side in one shared context, showing token usage and cost per agent as the work progresses.

Define Roles Before You Delegate

Start by describing the task in a session brief: "Add a feature flag system to a Node.js/Express API with PostgreSQL, including a management UI, audit logging, and gradual rollout controls." Then assign three agents:

Architect (Claude 3.5 Sonnet) — proposes the data model, middleware placement, and API contracts.
Implementer (GPT-4o) — writes the migration, middleware, routes, and a minimal React admin panel.
Reviewer (Gemini 1.5 Pro) — checks for SQL injection risk, race conditions in flag evaluation, and adherence to the team's existing error-handling patterns.

Each agent sees the full conversation history, so the Implementer can reference the Architect's schema decisions, and the Reviewer can flag deviations from the agreed contracts.

Insert a Human Approval Gate

After the Architect posts its proposal, VIBA pauses the session and surfaces a summary card:

Proposed schema: feature_flags table with key, description, rollout_percentage, targeting_rules (JSONB), created_at. Middleware attaches req.flags object. Admin endpoints under /admin/flags with RBAC.

You can edit the schema directly in the UI, ask the Architect to revise, or approve with a single click. Only after approval does the Implementer begin writing code. This gate prevents the common failure mode where an LLM commits to a design that the team would have rejected early.

Review, Repair, and Merge

The Implementer streams files into the session: a migration, flagMiddleware.ts, CRUD routes, and a React component tree. The Reviewer then runs its analysis and produces a ranked repair report:

High — targeting_rules JSONB column lacks a GIN index; flag evaluation will scan the table.
Medium — Admin DELETE endpoint missing soft-delete; audit log requirement not met.
Low — Inconsistent error envelope shape compared to src/utils/apiError.ts.

You click each item to see the offending snippet and the Reviewer's suggested fix. Accepting a fix rewrites that file in the session and updates the diff view. When the report is clear, you export the changes as a unified patch or push a branch directly from VIBA's GitHub integration.

Cost Visibility Built In

Throughout the session, a sidebar shows cumulative tokens and estimated cost per agent. For a typical feature flag implementation, the Architect might consume 12k tokens ($0.04), the Implementer 45k tokens ($0.18), and the Reviewer 18k tokens ($0.06). Seeing these numbers in real time helps small teams decide whether to route a task to a cheaper model or keep the higher-capability one for the review pass.

Try It on Your Next Refactor

Imagine applying this pattern to a legacy authentication module: one agent maps the current flow, another proposes a stratified migration to JWT with refresh tokens, a third writes the migration scripts, and a fourth runs your existing integration suite against the new code — all with human gates at the architecture and security review stages. VIBA handles the orchestration, context sharing, and cost tracking so you stay focused on the decisions that matter. Explore the platform at https://viba.guru

See VIBA: https://viba.guru

Splitting a Coding Task Across Specialized AI Agents with Human Approval

Leego — Thu, 22 Oct 2026 02:44:12 +0000

Introduction

Modern development workflows increasingly rely on large language models for code generation, review, and refactoring. Yet a single model often misses edge cases or introduces subtle bugs that a second pair of "eyes" would catch. Multi-agent AI orchestration addresses this by assigning distinct roles — architect, implementer, reviewer, cost-tracker — to different models within one shared session. VIBA provides a practical environment for this: you can run ChatGPT, Claude, Gemini, and other models side by side, give each a specific mandate, insert human approval gates, and observe per-agent cost in real time. The result is a collaborative loop that mirrors how human teams operate, but at the speed of inference.

Defining Roles for a Feature Implementation

Imagine you need to add a paginated, filterable API endpoint to an existing Node.js service. Instead of prompting one model to do everything, you decompose the work:

Architect (Claude 3.5 Sonnet): Designs the data schema, pagination strategy, and filter DSL. Outputs a Markdown spec.
Implementer (GPT-4o): Takes the spec and writes the Express route, validation middleware, and database queries.
Reviewer (Gemini 1.5 Pro): Scans the implementation for security issues, N+1 queries, and adherence to the spec.
Cost-tracker (any lightweight model): Logs token usage per agent and estimates total spend.

Each agent sees the previous agent's output in the shared session, so context flows naturally. You configure this in VIBA by creating a session, adding models, and assigning roles via a simple YAML block:

session: "paginated-api-endpoint"
agents:
  - name: architect
    model: claude-3.5-sonnet
    role: "Design schema, pagination, and filter DSL. Output spec.md."
  - name: implementer
    model: gpt-4o
    role: "Implement Express route per spec.md. Write tests."
  - name: reviewer
    model: gemini-1.5-pro
    role: "Review code for security, performance, and spec compliance."
  - name: cost-tracker
    model: gpt-4o-mini
    role: "Track tokens per agent and report estimated cost."

Adding a Human Approval Gate

Automation is powerful, but certain decisions deserve human judgment — especially when the spec touches data contracts or external APIs. VIBA lets you insert an approval step between any two agents. In the example above, you might pause after the architect finishes the spec:

Architect produces spec.md.
Session pauses and notifies you (via UI or webhook).
You review the spec, request tweaks, or approve.
On approval, the implementer starts automatically.

This gate ensures that architectural drift is caught early, without slowing down the rest of the pipeline. You can also require approval before the reviewer's feedback is merged back to the implementer for a second pass.

Tracking Cost and Output Per Agent

Because each model has different pricing and latency characteristics, visibility into per-agent spend is essential for small teams. VIBA surfaces token counts and estimated cost in real time, so you can see, for instance, that the architect used 12k tokens ($0.036) while the implementer used 45k tokens ($0.135). This data helps you decide whether to swap a model for a cheaper alternative on repetitive tasks, or invest more tokens in the reviewer for critical paths.

The cost-tracker agent can also emit a summary at the end of the session:

Session: paginated-api-endpoint
Total tokens: 78,432
Estimated cost: $0.214
Breakdown:
  architect: 12,048 tokens ($0.036)
  implementer: 45,210 tokens ($0.135)
  reviewer: 18,720 tokens ($0.037)
  cost-tracker: 2,454 tokens ($0.006)

Putting It Together: A Hypothetical Workflow

Here’s how the full loop might run for a two-person team:

Kickoff: Developer creates the session from the YAML above, pushes the current repo snapshot to VIBA’s repo-testing environment.
Architect phase: Claude produces spec.md. Developer reviews, adds a note about rate-limiting headers, approves.
Implementation phase: GPT-4o writes the route, middleware, and unit tests. VIBA runs the test suite in the repo-testing sandbox; all pass.
Review phase: Gemini flags a missing index on the filter column and suggests a composite index. Developer approves the fix.
Second implementation pass: GPT-4o adds the migration and updates tests. Suite passes again.
Cost summary: Cost-tracker emits the breakdown. Team sees the whole feature cost $0.21 and took 6 minutes of wall-clock time.
Merge: Developer opens a PR with the generated commits, confident that multiple models have scrutinized the code.

This pattern — decompose, approve, iterate, measure — scales from a single endpoint to an entire feature branch. VIBA’s UI testing and beta testing agents can further validate the endpoint against staging traffic before merge.

Ready to orchestrate your own multi-agent workflow? Explore the platform at https://viba.guru.

See VIBA: https://viba.guru