Agentes de IA no desenvolvimento: do Card ao Merge

Quando a velocidade de implementação aumenta, a pressão costuma migrar para vários pontos do fluxo de desenvolvimento: requisitos, análise de impacto, code review, testes, correções e decisões de liberação. Por isso, falar em agentes de IA no desenvolvimento de software exige olhar além do IDE e observar a operação de engenharia como um sistema.

Foi exatamente essa perspectiva que levamos ao evento Esteira automatizada: do Card ao Merge, onde Leandro Oliveira e Everton Bernardes, CEO e CTO da Vibbra, percorreram uma funcionalidade real em um ambiente de homologação para mostrar como planejamento, execução, pull request, correção e QA podem ser conectados por agentes e automações. Marcelo Teixeira, CTO da Orbis, complementou a discussão mostrando o que aconteceu quando uma equipe pequena começou a trabalhar com esse tipo de estrutura.

>> Acesse o evento completo aqui: Esteira automatizada: do card ao merge

Sem slide de tendência ou previsão sobre o futuro da programação, e com os erros acontecendo em tempo real durante a demonstração. Se a sua empresa já colocou IA no desenvolvimento e a entrega não acelerou na mesma proporção, essa conversa é sobre o que está entre uma coisa e outra.

O que é uma esteira automatizada de desenvolvimento com agentes de IA?

Uma esteira automatizada de desenvolvimento com agentes de IA é um fluxo no qual uma demanda de software pode atravessar diferentes etapas com apoio de agentes especializados, contexto estruturado, automações e gates de validação. Em vez de a IA atuar somente quando um desenvolvedor pede um trecho de código, ela participa de atividades como planejamento, análise técnica, implementação, revisão, testes e correção.

Essa diferença parece pequena, mas muda a unidade de otimização. Um copiloto busca acelerar uma pessoa em uma tarefa. Já uma esteira busca melhorar o caminho percorrido pela demanda entre a intenção e uma mudança de software pronta para integração.

Durante o evento, Everton apresenta essa lógica com uma “esteira mínima viável”, a qual poderia ter backlog, planejamento, execução, code review e conclusão. Em empresas com processos mais complexos, outras etapas poderiam ser adicionadas, como review manual, cross-test, QA e validação de Product Owner. Nesse cenário, um fluxo precisa refletir os riscos, controles e gargalos da operação em questão.

Esse princípio também aparece em referências recentes sobre AI-native SDLC. O playbook da Anthropic para um SDLC orientado por IA descreve um ciclo em que intenção, especificação, revisão de pull requests, avaliações automatizadas e aprovações humanas passam a ser conectadas, em vez de tratar IA apenas como ferramenta de codificação. É uma referência de mercado que ajuda a contextualizar o movimento mais amplo observado na engenharia em 2026.

No modelo demonstrado no evento, uma peça importante desse fluxo foi o que chamamos de base neural, sendo uma camada de conhecimento e contexto que registra elementos relevantes sobre o sistema e ajuda os agentes a encontrar os caminhos adequados.

Durante a apresentação, essa camada incluía informações sobre módulos, serviços, relacionamentos, padrões, telas, código e aprendizados acumulados. Um feedback de code review, por exemplo, pode registrar que determinada implementação contrariou o guia de estilo da empresa. Em uma execução futura, esse conhecimento passa a servir como referência.

Do Card ao Merge: como a esteira funciona na prática

A demonstração do evento começou com um sistema de pedidos de importação em homologação. A interface exibia os itens de um pedido em uma lista simples. O desafio escolhido foi transformar essa visualização em uma experiência mais rica, inspirada em um carrinho de e-commerce, com cards, imagens e informações como preço e subtotal. Uma segunda demanda pedia a geração e visualização de um PDF do pedido para facilitar seu compartilhamento com o cliente.

O valor da demonstração está em acompanhar o que aconte quando um card atravessava diferentes responsabilidades.

Momento	Papel da automação	Papel humano
Demanda	Receber e estruturar a necessidade	Definir problema e intenção
Planejamento	Consultar contexto e produzir um plano executável	Validar escopo, impacto e critérios
Implementação	Alterar código e criar artefatos versionados	Avaliar coerência técnica
Review	Verificar padrões e riscos conforme regras	Julgar aspectos que exigem contexto ou responsabilidade
QA	Executar cenários, navegar no sistema e produzir evidências	Avaliar exceções e decidir sobre o avanço
Correção	Reexecutar após feedback	Explicar o erro quando necessário e aceitar ou rejeitar o novo resultado
Integração	Preparar a mudança para avançar pelo fluxo	Autorizar conforme a política de risco

Um dos cards já tinha sido submetido ao planejamento antes do evento. O resultado estava armazenado junto ao fluxo de desenvolvimento e continha muito mais informação do que as poucas linhas originalmente escritas no ticket: objetivo, impacto técnico, referências de implementação, diagramas, critérios de aceite e elementos recuperados do contexto do sistema.

Um segundo card, relacionado ao PDF do pedido, foi enviado ao planejamento ao vivo. A entrada era curta. A função do agente era buscar contexto suficiente no sistema e produzir um artefato mais estruturado para que a equipe pudesse decidir se a execução deveria avançar.

Aqui está uma distinção importante. O agente reduzir o esforço de produzir um plano não elimina a necessidade de revisar esse plano. Na demonstração, Everton chegou a destacar que estava avançando rapidamente e pulando verificações para que fosse possível mostrar mais etapas durante o evento, sendo um comportamento de exceção para a demonstração.

Em outro exemplo, surgiu a necessidade de ordenar uma lista. Antes de transformar o pedido em implementação, um agente foi consultado para verificar o impacto da alteração sobre outras listas do sistema.

Essa etapa mostra por que automação de engenharia não deveria ser reduzida a “ticket entra, código sai”. Às vezes, a decisão correta é realizar apenas a mudança local. Em outros casos, o ticket revela uma inconsistência arquitetural mais ampla. Determinar até onde a alteração deve ir continua sendo uma decisão de engenharia e de produto.

O card referente à nova visualização foi movido para execução. Enquanto outros planejamentos continuavam acontecendo, o agente trabalhou na implementação e abriu um pull request com a alteração. Também havia um ambiente de preview para inspecionar o resultado.

Essa paralelização é uma das consequências mais relevantes de agentes no fluxo. A mesma pessoa pode supervisionar diferentes linhas de trabalho enquanto execuções computacionais prosseguem em paralelo. Isso, porém, muda o gargalo: a capacidade de produzir alterações pode crescer mais rápido do que a capacidade humana de examiná-las.

É por isso que review e gates precisam evoluir junto com a geração de código. O GitHub, por exemplo, permite exigir reviews, status checks e aprovação de code owners antes do merge em branches protegidas. Essas capacidades mostram como automação e política de integração podem coexistir tecnicamente.

Durante o encontro, discutimos tanto review automatizado quanto review manual, com foco em mostrar o PR, a validação funcional e a passagem pelo QA.

Essa distinção é importante porque “automação de code review” pode significar coisas diferentes. Um agente pode detectar padrões, inconsistências ou riscos antes que um profissional examine a alteração. Isso não obriga a organização a delegar ao agente a decisão de merge.

Na sequência, um ticket foi enviado à central de testes. O fluxo consultou os critérios de aceite e a branch, navegou pela funcionalidade e gerou um resultado organizado por cenário. Everton explicou que a navegação utilizava Playwright.

O ponto mais interessante foi a evidência. A execução podia registrar vídeo e produzir um laudo do que havia passado ou falhado. O Playwright suporta oficialmente gravação de vídeo e traces que permitem inspecionar ações, screenshots, estado da página, rede e outros elementos de uma execução.

Isso não transforma evidência em prova absoluta de qualidade. Um teste só verifica aquilo que seu cenário e seus critérios conseguem observar. Mas altera a economia do QA: parte do esforço de navegar repetidamente por fluxos conhecidos e registrar evidências pode ser transferida para automação, enquanto o profissional concentra mais atenção em cenários de borda, interpretação e risco.

Essa divisão apareceu claramente em uma resposta de Everton durante o Q&A. Quando cenários recorrentes já conseguem ser gerados e executados automaticamente, o QA passa a agregar mais valor explorando os casos que ainda não estão representados. Quando esses casos são incorporados ao contexto, o sistema de testes pode se tornar progressivamente mais abrangente.

Um primeiro teste encontrou problema de credencial. Depois, o teste da funcionalidade de PDF identificou uma falha e produziu o laudo correspondente. O feedback retornou ao fluxo e, posteriormente, uma nova execução mostrou a funcionalidade corrigida.

Esse talvez seja o trecho mais útil para quem avalia agentes de IA no desenvolvimento de software. O desenho robusto não depende de assumir que o agente não erra. Ele depende de criar mecanismos para que o erro apareça antes, gere evidência e possa retornar ao ciclo de correção.

>> Acesse o evento completo aqui: Esteira automatizada: do card ao merge

O papel dos agentes de IA e da supervisão humana

Quanto mais tarefas um agente consegue executar, mais importante se torna definir aquilo que ele não pode decidir sozinho.

Esse é o fundamento do human-in-the-loop. A participação humana não precisa significar clicar em “aprovar” depois de cada ação mínima. O objetivo é posicionar decisão e supervisão nos pontos em que erro, ambiguidade ou impacto justificam julgamento profissional.

Na prática, isso pode acontecer ao validar a interpretação da necessidade do cliente, escolher o alcance de uma alteração arquitetural, aprovar o planejamento técnico, avaliar uma exceção de segurança, construir cenários de borda ou autorizar a integração em uma branch crítica.

Durante o evento, Leandro foi explícito ao diferenciar automação granular de uma operação robusta completamente autônoma. Algumas tarefas delimitadas já podiam percorrer diferentes passos sem intervenção, mas uma operação na qual uma demanda complexa entra e software é publicado em produção sem qualquer responsabilidade humana não foi apresentada como realidade atual.

Essa cautela é compatível com práticas consolidadas de engenharia segura. O Secure Software Development Framework do NIST recomenda que práticas de segurança sejam incorporadas ao SDLC, em vez de tratadas como uma verificação isolada no final. Para agentes de programação, o próprio NIST também vem discutindo formas de estruturar restrições explícitas e manter especialistas do domínio no ciclo.

A relevância do julgamento humano também começa a aparecer na pesquisa empírica. Um preprint de 2026 analisou 278.790 conversas de code review em 300 projetos open source e encontrou diferenças entre agentes e revisores humanos. Os humanos adicionavam mais feedback relacionado a entendimento, testes e transferência de conhecimento, enquanto sugestões de agentes tinham menor taxa de adoção. Os autores concluem que agentes podem ampliar a triagem, mas a supervisão humana continua importante para qualidade e contexto.

O papel humano, portanto, não desaparece. Ele muda de posição.

Quando a execução é mais acessível e paralelizável, aumenta o valor de formular corretamente o problema, estruturar contexto, criar critérios verificáveis, avaliar riscos, decidir entre alternativas e reconhecer quando o resultado tecnicamente válido ainda não resolve a necessidade de negócio.

O case da Orbis: automação em um time pequeno

A experiência relatada pela Orbis é relevante porque mostra um contexto diferente das grandes operações de engenharia. A Orbis é uma empresa com seis anos de atuação no segmento de governo, produto especializado e uma equipe pequena que precisava aumentar sua capacidade sem simplesmente ampliar a estrutura.

A base técnica também não era um projeto novo e isolado. Segundo Marcelo Teixeira, CTO da Orbis, havia um monólito PHP que se relacionava com sete repositórios, alguns assumindo funções semelhantes a microserviços, proxies e aplicações complementares. Antes da implantação, ele próprio havia usado um agente para produzir uma visão preliminar do sistema, material que serviu de insumo para a estruturação posterior.

A implementação inicial levou aproximadamente quatro a cinco semanas. E esse período não foi composto apenas por configuração de agentes. Marcelo relatou mudanças de infraestrutura de servidores, organização do sistema e adaptações necessárias para que o fluxo pudesse receber as demandas.

Esse ponto ajuda a corrigir outra expectativa comum: uma esteira automatizada não é necessariamente uma camada que pode ser colocada sobre qualquer processo sem preparar o ambiente. Repositórios, ambientes, credenciais, dados de teste, padrões, conhecimento, responsabilidades e mecanismos de feedback precisam estar disponíveis de forma suficientemente organizada.

A reação da equipe também foi parte da implementação. O profissional mais experiente começou reticente. Ao mesmo tempo, era justamente ele quem possuía conhecimento suficiente para identificar quando o sistema estava interpretando algo de maneira incorreta. Com o avanço do projeto, seu papel passou a ajudar a transformar conhecimento tácito em referência reutilizável.

Isso é especialmente relevante para sistemas legados. Na rodada de perguntas, Everton explicou que, quando a documentação é incompleta e o conhecimento está concentrado em poucas pessoas, esses profissionais podem ajudar a indicar caminhos, padrões e exceções que precisam compor o contexto. O objetivo não precisa ser apenas reproduzir para sempre o padrão antigo. A mesma estrutura pode registrar quais práticas do legado devem ser preservadas e quais novos padrões devem orientar código futuro.

Na Orbis, o QA também mudou. Marcelo relatou que havia poucos testes e muito trabalho manual antes da implantação. Com a nova estrutura, parte desse processo passou a ser automatizada e a quantidade de cenários aumentou.

A equipe não ficou apenas consumindo o fluxo recebido. Começou a modificá-lo. Foram criados subagentes, skills e um estágio anterior de análise das demandas. A Orbis também passou a utilizar um critério interno de confiança para decidir quando determinada solicitação poderia avançar com menos intervenção. Quando o planejamento era considerado adequado, o fluxo podia executar uma sequência maior de etapas automaticamente.

Outro sinal de apropriação foi a mudança de interface. Marcelo relatou que a equipe passou a trabalhar cada vez mais a partir do VS Code, utilizando skills para interagir com o processo e inclusive automatizar registros operacionais. A esteira deixava de ser apenas um quadro que os desenvolvedores movimentavam e começava a se tornar uma camada orquestrada pelo próprio ambiente de trabalho.

Os indicadores apresentados também merecem uma leitura cuidadosa. Marcelo mostrou uma linha de base em torno de 100 a 110 entregas mensais e relatou que setembro, após a entrada do novo fluxo em produção, chegou a um patamar próximo do dobro. Em outubro, ainda em andamento no momento do evento, parte relevante da capacidade da equipe estava sendo utilizada para aperfeiçoar o próprio ambiente.

Há uma segunda nuance ainda mais interessante. Everton observou que o lead time da Orbis havia aumentado em determinado recorte. Isso poderia parecer uma piora. Ao investigar, porém, perceberam que tarefas antigas e complexas, antes paradas porque poucas pessoas tinham capacidade de executá-las, estavam finalmente avançando. O conhecimento colocado no fluxo permitia que outras pessoas participassem desses trabalhos.

É um bom exemplo de por que medir uma transformação com agentes exige mais do que acompanhar uma única métrica. Aumento de throughput, recuperação de backlog antigo, mudança no mix de complexidade e tempo de treinamento da própria esteira podem alterar indicadores em direções diferentes.

>> Acesse o evento completo aqui: Esteira automatizada: do card ao merge

O que aprendemos para o futuro da engenharia de software

A principal conclusão do evento não é que todo processo de desenvolvimento deveria ser automatizado do mesmo modo. É quase o oposto: quanto mais agentes assumem execução, mais importante se torna desenhar o fluxo de acordo com o contexto da organização.

Se gerar código já é rápido, mas pull requests ficam esperando review por dias, um novo agente de programação pode aumentar a fila em vez de melhorar o tempo de entrega. Se QA é a restrição, a automação precisa criar capacidade de teste e evidência. Se o problema é requisito inconsistente, o ganho pode estar antes da implementação.

Essa lógica também aparece em outros conteúdos que produzimos sobre como escalar IA no desenvolvimento de software: uma operação orientada por IA precisa ser medida pelo fluxo entre intenção e resultado, e não apenas por tokens, linhas de código ou quantidade de ferramentas adotadas.

Contexto deixa de ser documentação passiva

Padrões arquiteturais, conhecimento de domínio, critérios de aceite, decisões anteriores e exemplos aprovados passam a ser insumo operacional. Quanto maior a capacidade de ação dos agentes, maior o custo de oferecer a eles um contexto incorreto, conflitante ou desatualizado.

Uma organização que multiplica a capacidade de produzir código sem ampliar review, testes e mecanismos de correção apenas muda o endereço do gargalo. A experiência demonstrada no evento mostra uma alternativa: aproximar planejamento, execução, QA e feedback no mesmo circuito.

Um ajuste repetitivo e bem delimitado pode admitir um ciclo muito automatizado. Uma mudança de arquitetura, autenticação, faturamento ou dado crítico pode exigir mais gates. O desenho maduro não pergunta apenas “o agente consegue fazer?”. Pergunta também “qual evidência precisamos antes de permitir que faça sem intervenção?”.

Isso não significa que conhecimento técnico deixa de importar. Pelo contrário. Para reconhecer uma implementação inadequada, construir um bom cenário de borda ou transformar conhecimento legado em regra operacional, a pessoa precisa compreender profundamente o sistema.

Na Vibbra, entendemos que esse é um dos pontos mais importantes da transformação. A automação que realmente muda a capacidade de entrega não nasce apenas da instalação de agentes. Ela exige revisão de processo, contexto, responsabilidades, governança, infraestrutura e cultura de trabalho.

A demonstração do Card ao Merge mostrou uma versão concreta dessa lógica: uma demanda pode ser enriquecida, planejada, implementada, testada, rejeitada e corrigida dentro de um fluxo conectado. O case da Orbis mostrou a outra metade da equação: para isso funcionar em uma empresa real, o time precisa aprender a operar, criticar e evoluir o próprio sistema.

Agentes de IA no desenvolvimento de software podem assumir uma parcela crescente da execução. Responsabilidade, decisão e capacidade de verificar o que foi produzido continuam sendo questões de engenharia.

Para empresas que já usam IA na codificação, mas ainda encontram gargalos em planejamento, review, QA ou previsibilidade, o próximo passo pode ser olhar para a esteira como um todo. Converse com nosso time sobre o seu desafio de engenharia.

Nossa atuação é estruturada como consultoria estratégica de tecnologia, com foco em decisões, processo, governança e capacidade de entrega.