A pergunta que chega à mesa dos líderes de tecnologia já não é se a inteligência artificial vai entrar na engenharia de software, pois já está presente. O desafio agora é descobrir onde ela realmente merece investimento, autonomia e escala, e onde existe apenas uma demonstração tecnicamente interessante sem impacto proporcional no negócio.
Os números mais recentes ajudam a entender a tensão. O Gartner projeta US$ 2,59 trilhões em gastos mundiais com IA em 2026, mas reconhece que muitas empresas ainda favorecem iniciativas táticas de eficiência e produtividade e que CIOs seguem pressionados a demonstrar resultados concretos. A McKinsey encontrou algo semelhante em sua pesquisa global publicada em agosto de 2026: 80% dos respondentes percebem melhora na própria produtividade com IA, mas apenas 37% atribuem algum impacto positivo em EBIT à tecnologia.
A IA pode deixar alguém mais rápido sem deixar a empresa proporcionalmente mais rápida, assim como também pode gerar mais código sem antecipar o roadmap. Pode reduzir esforço em uma etapa enquanto o gargalo migra para especificação, revisão, segurança ou produto, e também pode produzir uma demonstração impressionante sem conseguir sobreviver às exigências de produção.
A tese do episódio 11 do Vibbracast é que o próximo estágio exige trocar a obsessão por ferramentas por uma disciplina de decisão. Na prática, isso significa redesenhar o processo, organizar contexto, tornar confiança mensurável e aproximar os indicadores da engenharia dos indicadores que o negócio realmente sente.
Confira o episódio completo onde Leandro Oliveira, CEO da Vibbra, conversa com Mário Galvão, diretor de tecnologia da Zup, empresa do grupo Itaú, que participou recentemente de um encontro global de executivos promovido pelo Gartner sobre o futuro da engenharia de software.
A produtividade do desenvolvedor não é o mesmo que resultado de negócio
Há evidências de que ferramentas de IA conseguem melhorar tarefas específicas de desenvolvimento. Em um estudo controlado conduzido pelo próprio GitHub com 202 desenvolvedores experientes, participantes com acesso ao Copilot tiveram maior probabilidade de passar todos os testes da tarefa proposta, além de pequenos ganhos estatisticamente significativos em critérios de qualidade avaliados no experimento. É uma evidência útil, mas precisa ser interpretada pelo que é: um estudo do fornecedor, em uma tarefa delimitada, medindo desempenho técnico específico.
Quando o contexto muda, os resultados também podem mudar. A METR encontrou, em seu experimento realizado entre fevereiro e junho de 2025 com desenvolvedores experientes trabalhando em seus próprios projetos open source, uma desaceleração no tempo de conclusão das tarefas com as ferramentas de IA disponíveis naquele momento. Ao tentar atualizar o experimento para ferramentas mais novas, a organização informou no início de 2026 que a nova amostra havia adquirido vieses de seleção relevantes, com muitos desenvolvedores já não queriam participar se precisassem trabalhar sem IA, e concluiu que os dados não permitiam uma estimativa confiável do efeito atual.
A própria METR também alerta contra interpretar percepção de produtividade como produtividade medida: em sua pesquisa de 2026, lembrou que participantes do experimento anterior haviam superestimado em cerca de 40 pontos percentuais o efeito da IA sobre o tempo gasto nas tarefas. Pesquisas de percepção, experimentos controlados, benchmarks e dados de produção medem coisas diferentes e possuem limitações diferentes.
Isso significa que produtividade precisa deixar de ser tratada como um número universal atribuído à ferramenta, e é justamente aí que a experiência trazida por Mário ao Vibbracast se torna relevante. O estágio de copiloto, autocomplete e assistência individual pode produzir ganho real, mas local. Quando uma etapa da cadeia acelera, outro ponto pode se transformar no gargalo.
O desenvolvedor termina código mais rápido, mas espera especificação. O agente implementa mais rápido, mas a revisão não acompanha. Os testes são gerados rapidamente, mas ninguém estabeleceu quais comportamentos são aceitáveis. Assim, a capacidade técnica aumenta, mas o roadmap continua priorizado segundo a restrição de capacidade do ano anterior, com a engenharia ganhando velocidade sem afetar o indicador que chega ao board.
Esse diagnóstico está alinhado à pesquisa DORA de 2025, que descreve a IA essencialmente como um amplificador: ela tende a ampliar tanto forças quanto fragilidades do sistema organizacional existente. Segundo o DORA, os maiores retornos não vêm da ferramenta isoladamente, mas de atenção ao sistema organizacional no qual ela está inserida.
Para uma liderança, a pergunta precisa subir de nível: o que ficou diferente para o negócio?
O Gartner recomenda exatamente essa mudança ao tratar de agentes: priorizar produtividade empresarial, não apenas aumento de capacidade em tarefas individuais, e avaliar valor a partir de dimensões como custo, qualidade, velocidade e escala. Seu roadmap de IA também coloca alinhamento com objetivos de negócio e acompanhamento contínuo de valor como fundamentos para sair de projetos isolados e formar um portfólio sustentável de iniciativas.
Em engenharia, isso pode significar olhar para time-to-market, frequência com que oportunidades do roadmap chegam ao cliente, adoção das funcionalidades, qualidade, incidentes, custo total de entrega, retenção, receita ou outros indicadores coerentes com a tese econômica daquela iniciativa.
Quando a execução acelera, o processo de engenharia precisa mudar
A segunda mudança é mais desconfortável: não basta automatizar o processo que já existe. Esse é um dos pontos em que a visão apresentada no episódio encontra evidência externa particularmente forte.
Na pesquisa da McKinsey com líderes de produto e engenharia, organizações que redesenharam seus processos antes de incorporar IA foram mais de duas vezes mais propensas a relatar ganhos superiores a 20% do que aquelas que simplesmente adicionaram IA à forma existente de trabalhar. Entre os grupos classificados como maiores aceleradores, 93% haviam incorporado IA aos workflows.
O Gartner chega a recomendação semelhante ao discutir projetos agênticos: mais de 40% desses projetos deverão ser cancelados até o fim de 2027, segundo sua previsão, devido a custos crescentes, valor de negócio pouco claro ou controles de risco inadequados. A recomendação não é colocar agentes em todos os lugares, mas selecionar casos com valor claro e, quando necessário, repensar o workflow desde a origem em vez de inserir agentes em estruturas antigas.
Na fase de intenção, humanos precisam explicitar o que o sistema deve alcançar: problema, regras, critérios de aceite, restrições, arquitetura, riscos, políticas e limites. Na implementação, agentes podem assumir uma parcela crescente da execução dentro desses limites. Quanto mais barata e rápida fica a execução, maior tende a ser o custo relativo de uma intenção mal definida.
Durante anos, equipes conviveram com requisitos incompletos porque a própria lentidão da implementação criava tempo para corrigir decisões ao longo do percurso. Quando um agente consegue transformar uma especificação em código, testes e alterações em uma velocidade muito maior, ambiguidade deixa de ser apenas um inconveniente de produto e vira uma fonte de automação errada em escala.
É por isso que práticas associadas a spec-driven development estão ganhando peso. O artefato central deixa de ser somente a tarefa no backlog e passa a ser uma especificação suficientemente rica para orientar tanto humanos quanto sistemas artificiais.
A Anthropic chama essa disciplina mais ampla de context engineering: gerenciar e selecionar o conjunto de informações que estará disponível para o modelo durante a execução. Esse contexto pode incluir instruções, ferramentas, dados externos, histórico de mensagens e conexões via MCP. A empresa chama atenção para um detalhe relevante: contexto é um recurso finito; simplesmente despejar mais informações no modelo não garante melhor comportamento. O problema passa a ser entregar o conjunto de sinais mais relevante para a tarefa.
Aplicado à engenharia de software, isso significa que o contexto útil pode incluir arquitetura atual, decisões anteriores, documentação do domínio, padrões de código, APIs disponíveis, políticas de segurança, definições de métricas, dependências, histórico de mudanças e restrições específicas do produto.
No episódio, o Mário relata que sua operação vem incorporando mecanismos para manter documentação e contexto atualizados periodicamente ou a partir de eventos do próprio processo, como pull requests. A lógica é direta: se um agente vai tomar decisões sobre uma base de código a partir daquilo que conhece, documentação obsoleta deixa de ser apenas uma dívida de conhecimento e passa a degradar diretamente a qualidade da execução automatizada.
Esse movimento também aparece em outros episódios e conteúdos da própria Vibbra. No case Dígitro, por exemplo, o ganho mais estrutural foi associado justamente à capacidade de reunir contexto de sistemas, documentação e domínio, e não somente à geração mais rápida de código; no relato da Senior, uma parcela crescente do trabalho migrou para contextualização de negócio e definição do que deveria ser feito.
Por isso, uma operação AI-native tende a deslocar o gargalo. O cenário anterior era:
demanda -> especificação suficiente -> muito esforço de execução -> teste -> deploy.
Com agentes mais capazes:
demanda -> contexto e intenção muito mais precisos -> execução acelerada -> verificação rigorosa -> deploy.
Esse novo modelo significa que o valor humano migra para as partes em que julgamento, contexto, arquitetura e responsabilidade são mais difíceis de automatizar, onde o trabalho repetitivo começa a migrar para agentes, enquanto pessoas assumem uma parcela maior do caminho entre intenção, release e operação.
A pergunta estratégica, portanto, deixa de ser “qual ferramenta acelera meu desenvolvedor?” e passa a ser: como eu desenharia este fluxo se soubesse, desde o início, que parte relevante da execução pode ser feita por agentes?
Contexto, evals e governança transformam confiança em engenharia
Quanto mais autonomia a IA ganha, menos razoável fica tratar confiança como uma sensação. Mário resume esse princípio no episódio com uma frase particularmente forte: “confiança vira artefato de engenharia, não esperança.”
Essa talvez seja uma das mudanças mais importantes para empresas que estão saindo de copilotos e entrando em agentes. Em software tradicional, uma implementação pode ser submetida a testes unitários, integração, análise estática, testes de segurança e outros mecanismos relativamente determinísticos. Sistemas baseados em modelos acrescentam outro problema: o comportamento pode variar entre execuções, e as tarefas podem envolver respostas abertas para as quais não existe apenas uma string correta.
A resposta que vem se consolidando é o uso sistemático de evals. A Anthropic define uma eval como um teste de um sistema de IA: oferece-se uma entrada e aplica-se alguma lógica de avaliação ao resultado. Para agentes, isso pode envolver não apenas a resposta final, mas chamadas de ferramentas, estados alterados, trajetórias de execução e o resultado efetivamente produzido no ambiente.
Isso aproxima o conceito mencionado por Mário no episódio, de um eval-driven development: critérios de qualidade deixam de entrar apenas depois que o agente está pronto e passam a fazer parte da definição de sucesso desde a especificação.
Além disso, a IA como avaliadora (frequentemente chamada de LLM-as-a-judge) é útil quando o resultado possui nuances que regras determinísticas não conseguem representar bem. Mas ela também é não determinística e precisa ser calibrada contra julgamento humano para usos em que qualidade subjetiva importa.
Na prática, uma arquitetura confiável usa determinismo onde determinismo funciona, avaliação probabilística onde ela é necessária e revisão humana onde o impacto ou a ambiguidade justificam o custo.
Essa lógica também corrige uma simplificação comum sobre sistemas multiagentes. No episódio, Mário usa um exemplo matemático para mostrar como erros podem se acumular quando várias decisões probabilísticas são encadeadas. O ponto conceitual é válido, mas não deve ser transformado em uma taxa universal de acurácia: agentes e tarefas têm taxas diferentes, dependências entre etapas variam e alguns sistemas possuem mecanismos de recuperação.
A agenda do CTO muda: times, orçamento e arquitetura entram na equação
Depois que produtividade, processo e confiança mudam, a discussão inevitavelmente chega a pessoas e orçamento, sendo também a parte em que previsões simplistas merecem mais cuidado.
No episódio, Mário recorre ao paradoxo de Jevons para levantar uma hipótese: se a IA reduz significativamente o custo unitário de produzir software, o resultado pode não ser simplesmente “a mesma quantidade de software com menos desenvolvedores”. A redução de custo pode tornar economicamente viáveis projetos que antes nunca entrariam no roadmap, aumentando a demanda total por software.
O Gartner prevê que, até 2030, plataformas de desenvolvimento AI-native levarão 80% das organizações a evoluir grandes equipes de engenharia para times menores e mais ágeis, aumentados por IA. A própria descrição do Gartner sugere que essas equipes menores poderão construir uma quantidade maior de aplicações com uma base semelhante de desenvolvedores.
A pesquisa da McKinsey oferece um sinal semelhante no nível do squad: entre as organizações classificadas como maiores aceleradoras, 79% dos respondentes disseram que os squads ficaram menores depois da implementação de IA, com mediana caindo de aproximadamente dez para sete pessoas; quase 20% dos líderes desse grupo já trabalhavam com equipes de uma a quatro pessoas.
Mas squad menor não é sinônimo automático de organização menor, ou seja: a direção estrutural parece mais clara do que o efeito líquido sobre headcount. Essa distinção importa para o orçamento do CTO, onde a pesquisa global mais recente da McKinsey mostra que custos operacionais de IA, incluindo tokens, já restringem o uso para cerca de um quinto dos respondentes. Mesmo assim, 60% esperam aumentar o investimento em IA no próximo ano.
O planejamento, portanto, não deveria começar com a premissa de que “IA = redução imediata da folha”. Uma pergunta mais madura é: qual é o melhor destino econômico para a capacidade que a IA libera?
Em alguns processos, a resposta será redução de custo, antecipar roadmap, aumentar qualidade, atacar uma nova receita, desenvolver internamente algo que antes precisava ser comprado. Aliás, esse último movimento já aparece nos dados. Na pesquisa global de 2026, 32% dos respondentes disseram que suas organizações deixaram de comprar pelo menos um produto ou funcionalidade de software porque conseguiram construí-lo internamente com coding agents.
Isso não comprova um “SaaSpocalypse”, mas sim algo mais interessante: a fronteira econômica entre build e buy está começando a se deslocar.
Sistemas maduros, complexos e profundamente integrados ao negócio continuam carregando anos de produto, compliance, suporte, confiabilidade e conhecimento de domínio. Mas funcionalidades periféricas ou soluções mais delimitadas podem ficar economicamente interessantes para desenvolvimento interno quando o custo de implementação cai.
No fim, o filtro que Mário foi buscar fora pode ser transformado em cinco perguntas bastante práticas antes de escalar qualquer iniciativa:
| Antes de escalar | Pergunta |
|---|---|
| Valor | Qual indicador de negócio deve mudar se esta iniciativa funcionar? |
| Contexto | O agente possui contexto atualizado e confiável para executar a tarefa? |
| Verificação | Temos evals capazes de detectar regressão e provar que o resultado está correto? |
| Risco | O grau de autonomia é coerente com criticidade, permissões e impacto potencial? |
| Adaptabilidade | Conseguiremos trocar modelos, agentes ou componentes sem reconstruir toda a solução? |
Se a primeira resposta ainda é “vamos aumentar a quantidade de código produzido”, provavelmente o problema ainda está mal formulado.
Essa talvez seja a mensagem mais marcante do episódio do Vibbracast para quem lidera tecnologia agora. O desafio deixou de ser colocar IA na engenharia, e passou a ser reconstruir a engenharia para uma realidade em que a capacidade de execução aumentou, mas contexto, julgamento, confiança e prioridade continuam escassos.
É também onde o conceito de Squads Cognitivos defendido pela Vibbra ganha sentido: combinar humanos e agentes dentro de um fluxo redesenhado, concentrando julgamento humano em intenção, arquitetura, contexto, decisão e validação, enquanto a IA assume parcelas crescentes de execução.
Para empresas ainda presas entre pilotos promissores e resultados organizacionais difíceis de demonstrar, o ponto de partida talvez não seja comprar outra ferramenta. É diagnosticar onde o processo atual perde contexto, acumula handoffs, depende de trabalho manual verificável ou mede o indicador errado,e só então decidir onde IA, agentes e autonomia realmente merecem entrar.
Quer entender mais sobre essas possibilidades para a sua empresa? Converse com o time da Vibbra.
