Habr AI: Como Pipeline Triad Monta um Pipeline de Agentes IA em Vez de uma Equipe de Desenvolvimento

A ideia de um único desenvolvedor IA universal está gradualmente cedendo lugar a um esquema mais prático: em vez de um "superagente," propõe-se um pipeline de trios especializados, onde um agente cria o resultado, o segundo procura erros e o terceiro toma uma decisão. É exatamente assim que funciona o Pipeline Triad Pattern — um modelo de desenvolvimento projetado não para demonstrações, mas para tarefas enterprise típicas onde requisitos, padrões e regras já estão descritos, e o humano permanece no controle em vários dos pontos mais caros do processo. O esquema é construído sobre três papéis: Criador, Crítico e Árbitro.

O primeiro gera um artefato, o segundo verifica lógica, qualidade e riscos, e o terceiro decide se passa o resultado adiante ou o envia de volta para revisão. Esta abordagem se baseia em uma ideia simples: modelos de linguagem são ruins em corrigir seus próprios erros sem verificação externa, então é mais confiável não fortalecer um agente infinitamente, mas construir um trio independente com funções diferentes. O autor do padrão transfere o familiar princípio enterprise de maker-checker-approver para desenvolvimento com agentes e o estende por todo o SDLC.

Ao mesmo tempo, Pipeline Triad não é proposto como substituição para CI/CD. Pipelines automáticos continuam a construir, testar e implantar código, mas acima deles aparece outra camada — uma camada de delegação de agentes, onde decisões são tomadas não por script rígido, mas levando em conta contexto, regulamentações e regras de negócio. O esquema completo consiste em 14 passos da declaração da tarefa até a produção.

Sete deles executam estágios de agente: análise, desenvolvimento, revisão de código, testes, regressão, segurança e preparação de artefatos de lançamento. Outros quatro pontos permanecem com o humano: validação de requisitos, aprovação de prontidão, confirmação de implantação e verificação final pré-produção. Em cada estágio, o trio deve entregar não apenas uma resposta em texto, mas um pacote formalizado: o artefato em si, critérios PASS ou FAIL, um registro de observações do Crítico, bem como a decisão do Árbitro — passar, devolver ou conduzir parcialmente.

Graças a isso, o pipeline se transforma de um conjunto de prompts em um processo reproduzível com rastreamento de decisões. O próximo estágio não inicia até receber entrada válida, o que significa que você pode construir auditoria, medir qualidade e analisar erros retrospectivamente. O valor prático do padrão é melhor visto em uma tarefa típica.

Por exemplo, o autor pega um endpoint bancário para congelamento de conta: primeiro, o trio esclarece requisitos e casos extremos, depois trios separados escrevem código, verificam direitos de acesso, adicionam testes para condições de corrida, executam verificações de regressão e segurança, após o que uma pessoa apenas confirma algumas decisões-chave. Em tal cenário, a participação humana é estimada em aproximadamente uma hora de tempo total versus duas a três semanas em um processo enterprise clássico. Em termos de custo, o autor estima uma execução completa através da API em aproximadamente 42–84 chamadas de modelo, 1–2 milhões de tokens de entrada e 200–400 mil tokens de saída, o que dá uma estimativa de ordem de grandeza de $6–12 por tarefa.

Para pilotos e configurações pessoais, uma assinatura pode ser mais barata, mas para um fluxo de produção estável, você ainda precisará contar limites, orçamento e consumo real de tokens. Ao mesmo tempo, o modelo tem limites rígidos. Funciona bem para solicitações de mudança, correções de bugs, tarefas CRUD e API, integrações e mudanças de infraestrutura, onde o domínio é formalizado e o resultado pode ser verificado por testes e artefatos.

Pipeline Triad funciona pior onde há muita incerteza: em descoberta, arquitetura greenfield sem padrões maduros, P&D e grandes refatorações entre equipes. Riscos também são bem terrenos: um agente pode inventar uma regra de negócio inexistente, um Crítico mal configurado deixará erros passarem ou rejeitará tudo em fileira, e trabalho paralelo em múltiplas tarefas rapidamente encontrará conflitos de contexto, migrações e branches. Uma seção separada é a segurança do próprio pipeline.

Se agentes receberem acesso ao repositório, segredos e implantação sem restrições rigorosas, o novo processo se torna uma superfície de ataque adicional. Portanto, o autor insiste no princípio de menos privilégio, acesso baseado em papel separado, registro de auditoria completo, um mecanismo de política para uso de ferramentas e filtragem de dados sensíveis antes de entrarem no contexto do modelo. O que isso significa na prática: a ideia de uma "equipe de agentes" se torna não uma fantasia sobre um funcionário IA universal, mas um modelo de engenharia mais fundamentado, onde a aceleração é alcançada através de especialização, entradas formalizadas e controle em etapas caras.

Mas o material honestamente mostra os limites da abordagem: não elimina alinhamento organizacional, não resolve o problema de especificação pobre de requisitos e não remove responsabilidade de pessoas fortes que devem validar o resultado. Se tais pipelines se tornarem um padrão de trabalho, será primeiro em domínios enterprise previsíveis onde o custo do erro é alto e regras já podem ser transformadas em um processo verificável.