A inteligência artificial consegue produzir código muito mais rápido do que há poucos anos. O problema é que velocidade de geração de código e velocidade de entrega de software não são a mesma coisa, e é exatamente nesse ponto que a discussão sobre uma esteira de desenvolvimento com IA fica mais interessante.
Uma esteira desse tipo é um fluxo de engenharia no qual contexto de negócio e técnico é transformado em artefatos verificáveis, com agentes assumindo parcelas crescentes da execução, mecanismos automatizados verificando o resultado e humanos mantendo responsabilidade sobre decisões relevantes e gates compatíveis com o risco. À medida que o sistema amadurece, o trabalho pode deixar de seguir uma linha estritamente sequencial e começar a ocorrer em paralelo.
No Vibbracast, Leandro Oliveira, CEO da Vibbra, e Everton Bernardes, CTO da Vibbra, colocam essa ideia no centro da discussão sobre os Squads Cognitivos da Vibbra, percorrendo uma esteira automatizada etapa por etapa, usando casos reais de clientes. Do planejamento feito pelo PO junto à base neural até a criação automática dos pull requests, o objetivo é mostrar o mecanismo por dentro, incluindo onde ele ainda depende de decisão humana.
Se você está tentando entender na prática como IA e humanos operam dentro de um mesmo fluxo de desenvolvimento, esse episódio mostra o funcionamento real, sem abstração.
O problema além da escrita do código
É tentador medir o impacto da IA perguntando quanto mais rápido um desenvolvedor programa. O problema é que os estudos disponíveis mostram que a resposta depende profundamente da tarefa, do ambiente e de quem está utilizando a ferramenta.
Em um experimento controlado publicado em 2023 por Peng e colaboradores, desenvolvedores com GitHub Copilot completaram uma tarefa delimitada: implementar um servidor HTTP em JavaScript 55,8% mais rápido do que o grupo de controle. É uma evidência de que IA pode gerar ganhos relevantes em determinadas tarefas de programação. Mas o experimento mede um problema específico, não todo o sistema de entrega de software.
Outro estudo, atualizado em agosto de 2026, analisou dados de uso do GitHub Copilot combinados com projetos open source. Os autores encontraram aumento de 5,9% nas contribuições de código no nível do projeto, acompanhado por 8% mais tempo de coordenação e mais discussões sobre código. O resultado é particularmente relevante para líderes: aumentar a capacidade de produção pode aumentar também o trabalho necessário para integrar essa produção.
A implementação pode ficar mais rápida enquanto o planejamento continua insuficiente. O volume de pull requests pode crescer enquanto a capacidade de review permanece a mesma. O agente pode gerar dezenas de testes enquanto ninguém definiu corretamente o comportamento esperado. Mais código pode chegar à fila sem que mais valor chegue a produção.
É por isso que o episódio do Vibbracast parte de uma pergunta mais útil: o que precisa mudar na esteira para que a nova capacidade de execução efetivamente diminua o ciclo de entrega?
Everton dá um exemplo interessante ao comentar a volta de artefatos que, em muitos times, foram abandonados por serem caros de produzir manualmente, como diagramas de sequência. O argumento não é que a IA tornou o diagrama tecnicamente mais importante. É que ela reduziu o custo de produzi-lo enquanto aumentou a quantidade de informação que precisa ser validada.
Esse raciocínio muda a economia da documentação. Quando uma feature é decomposta em múltiplas histórias, critérios de aceite, testes, dependências e decisões arquiteturais, o problema humano passa a ser menos “como escrever todos esses artefatos?” e mais “como entender rapidamente se eles representam a intenção correta antes de autorizar a execução?”.
Uma esteira com IA precisa transformar intenção em artefatos verificáveis
No episódio, Everton descreve o que chama de uma “mínima esteira viável”, composta por seis etapas. O fluxo descrito pode ser entendido operacionalmente desta forma:
| Etapa | O que acontece | Principal saída |
|---|---|---|
| Planejamento da intenção | PO trabalha a necessidade de negócio com apoio do contexto disponível sobre produto e sistemas | Requisito suficientemente claro, objetivo, restrições e critérios |
| Decomposição | A funcionalidade é quebrada em unidades executáveis, como user stories | Histórias e entregáveis delimitados |
| Planejamento técnico | O sistema consulta código, arquitetura, dependências e padrões para definir como executar | Especificação técnica, impacto, testes, dependências e estratégia de integração |
| Validação humana | PO e engenharia verificam se os artefatos representam corretamente intenção e solução | Aceite explícito antes da execução |
| Execução pelos agentes | A esteira gera alterações, abre pull requests e executa o trabalho previsto | Implementação versionada e rastreável |
| Verificação e liberação | Critérios de aceite, testes, CI, code review e gates confirmam se a mudança pode avançar | Código validado, merge e, conforme a política, release |
Essa estrutura tem um paralelo claro com o conceito de AI-native SDLC descrito pela Anthropic. O modelo apresentado pela empresa transforma o ciclo linear em um loop no qual IA participa de diferentes pontos, os handoffs passam a ser automatizados quando possível e cada etapa produz artefatos que podem ser examinados posteriormente. A Anthropic também defende que decisões que exigem julgamento continuem atribuídas a humanos.
O detalhe mais importante da esteira, porém, não é o agente que escreve código. É aquilo que Everton chama de base neural, a qual funciona como uma camada de conhecimento que permite que agentes consultem informações relevantes sobre sistema, negócio, arquitetura, funcionalidades anteriores e padrões de execução.
Vale fazer uma distinção técnica: “base neural” não é um termo padronizado da engenharia de software e não deve ser confundido automaticamente com o treinamento da rede neural do modelo. Trata-se, aqui, de uma forma de organizar e disponibilizar conhecimento operacional para os agentes.
Na prática, essa camada pode envolver documentação de domínio, código, histórico de decisões, padrões arquiteturais, convenções, APIs, critérios de qualidade, políticas, exemplos aprovados e fontes corporativas de verdade. Esse princípio é próximo do que o mercado vem chamando de context engineering: não basta ter um modelo capaz; é preciso controlar quais informações relevantes chegam ao modelo durante a execução.
Há uma consequência especialmente importante em sistemas legados. A Anthropic recomenda que a organização defina uma fonte de verdade para cada artefato ou, no mínimo, estabeleça ligações explícitas entre o repositório, Jira, ServiceNow, ferramentas de requisitos e outros sistemas existentes. Isso evita que o agente tenha várias versões incompatíveis da mesma realidade.
É também aqui que a experiência relatada no Vibbracast ganha profundidade. Everton descreve uma análise técnica que não olha somente para a história isolada. A esteira precisa conhecer dependências entre funcionalidades, branches, componentes que estão sendo alterados em paralelo e estratégia de merge.
Autonomia cresce com maturidade, mas decisão e responsabilidade continuam humanas
Um dos princípios mais claros defendidos por Everton no episódio é:
“Eu não tercerizo jamais a decisão para IA.”
Esse ponto diferencia uma esteira corporativa de uma demonstração de geração autônoma. O agente pode produzir o plano técnico, modificar arquivos, abrir vários pull requests, executar testes e até mesmo comparar resultados com critérios de aceite. Em cenários maduros e delimitados, pode completar praticamente toda a execução.
Mas autonomia de execução não é a mesma coisa que transferência de responsabilidade. No modelo discutido no Vibbracast, o PO continua decidindo se a definição funcional representa a necessidade do produto. O desenvolvedor continua decidindo se a abordagem técnica faz sentido. E, nos cenários apresentados como mais avançados, ainda existe code review e autorização de merge.
Esse desenho pode evoluir conforme a esteira acumula contexto e controles:
| Maturidade | Papel predominante da IA | Papel predominante do humano | Sinal de evolução |
|---|---|---|---|
| Assistida | Sugere planos, código e testes | Conduz e verifica quase todas as etapas | Primeiro baseline confiável |
| Governada | Executa tarefas delimitadas dentro de regras explícitas | Aprova artefatos e trata exceções | Menos rework e mais sucesso na primeira passagem |
| Paralelizada | Executa múltiplas tarefas ou PRs simultaneamente | Trabalha em planejamento, arquitetura e reviews | Lead time cai sem piorar qualidade |
| Seletivamente autônoma | Conduz fluxos rotineiros com intervenção por exceção | Mantém gates de risco e responsabilidade final | Autonomia aumenta onde evidência justifica |
Essa classificação é uma síntese editorial a partir dos princípios do episódio e das práticas de AI-native SDLC; não é apresentada aqui como um framework oficial da Vibbra ou de outra instituição.
O ganho sistêmico quando a execução deixa de ser linear
Talvez a ideia mais original do episódio seja menos sobre agentes e mais sobre tempo.
No desenvolvimento tradicional, o trabalho tende a ser imaginado como uma sequência: alguém especifica, alguém implementa, alguém revisa, alguém testa, alguém libera. Mesmo quando várias pessoas trabalham simultaneamente, cada item atravessa uma cadeia relativamente linear.
A capacidade de um agente trabalhar de forma autônoma por períodos mais longos muda essa arquitetura.
Everton dá um exemplo simples: se a IA leva duas horas para produzir uma implementação que antes exigiria semanas de trabalho, o desenvolvedor não precisa passar duas horas esperando. Pode utilizar esse intervalo para revisar o planejamento de outras funcionalidades, esclarecer requisitos futuros ou preparar artefatos que permitirão que as próximas execuções tenham maior assertividade.
A pergunta deixa de ser “quantas linhas um desenvolvedor consegue produzir por dia?” e passa a incluir “quantas decisões, planos e validações de qualidade uma pessoa consegue conduzir enquanto diferentes execuções acontecem em paralelo?”.
É também onde aparece um risco novo. Paralelizar geração sem paralelizar ou redesenhar os demais controles pode apenas criar filas maiores. O próprio DORA alerta para a importância de olhar o value stream para impedir que ganhos locais de produtividade terminem em desorganização nas etapas seguintes.
Nesse cenário, o PO deixa de depender exclusivamente de décadas de memória individual para produzir um requisito suficientemente contextualizado e passa a combinar seu julgamento de produto com conhecimento estruturado disponível à esteira. O desenvolvedor deixa de utilizar a maior parte do seu valor na digitação da implementação e passa a investir mais energia em intenção técnica, arquitetura, análise de impacto, critérios, revisão e exceções.
O especialista sênior deixa de ser apenas a pessoa que “sabe onde mudar a linha de código” e pode passar a transformar esse conhecimento em algo reutilizável por toda a operação. E a liderança deixa de medir sucesso pelo número de licenças de IA ou pela quantidade de código gerado.
Para um CTO avaliando uma esteira de desenvolvimento com IA, seis perguntas são mais úteis do que perguntar qual modelo está no topo do benchmark da semana:
Pergunta executiva Evidência que deveria existir
Qual gargalo queremos remover? Baseline de lead time, espera, rework, capacidade ou qualidade
Que contexto o agente precisa para tomar boas ações? Fontes de verdade, documentação, código, arquitetura, domínio e políticas identificados
Que artefato precisa estar correto antes da execução? Critérios claros de aceite funcional e técnico
Onde a IA pode agir sozinha e onde precisa parar? Matriz de risco, permissões e gates
Como saberemos que a esteira está aprendendo? Evals, redução de rework, melhoria na primeira execução e histórico versionado
Que resultado o negócio receberá se o ciclo melhorar? Time-to-market, roadmap antecipado, qualidade, custo, receita, retenção ou outro indicador ligado à tese do investimento
Esse é também o ponto em que a discussão sobre Squads Cognitivos ganha uma dimensão maior do que automação. Na formulação atual da Vibbra, pessoas, agentes, processos e conhecimento são integrados em uma operação de engenharia que busca transformar ganhos locais em capacidade de entrega e resultado de negócio
Nesse cenário, uma boa esteira de desenvolvimento com IA não elimina o humano do loop; ela elimina trabalho humano de baixo valor do caminho crítico e concentra atenção humana onde julgamento, contexto e responsabilidade têm maior valor.
A meta também não deveria ser alcançar “100% de código escrito por IA”. Esse indicador pode até desaparecer à medida que humanos e agentes utilizem as mesmas ferramentas em ambientes diferentes. O objetivo executivo é outro: reduzir o tempo entre intenção e valor entregue, com qualidade e risco controlados.
Para empresas que já distribuíram copilotos e agentes, mas ainda enxergam os ganhos principalmente na produtividade individual, o próximo passo não precisa ser comprar mais uma ferramenta. Pode ser diagnosticar o fluxo atual: onde o contexto se perde, quais decisões continuam implícitas, quais handoffs geram espera, onde o review se tornou gargalo, o que ainda depende de conhecimento individual e quais indicadores comprovam que software útil está chegando mais cedo ao negócio.
É nesse nível de transformação, com processos, conhecimento, automação, papéis e cultura trabalhando como um sistema, que uma operação humano + IA começa a fazer sentido estratégico.
