Quando a IA Se Constrói: A Lacuna de Governança no Desenvolvimento Assistido por IA

A Cognition anunciou recentemente que usa o Devin — seu agente de codificação autônomo — para construir o próprio Devin. A recursão é poética. Uma IA que se constrói. O futuro chegou.

Exceto que a história mais importante não é a recursão. É o que acontece entre o código gerado e o código em produção.

O Artigo e Seu Contexto

Nader Dabit publicou em fevereiro de 2026 um walkthrough detalhado de como a Cognition usa o Devin internamente. O artigo é informativo. Também é importante contextualizar: Nader entrou na Cognition como líder de DevRel uma semana antes da publicação. Não é jornalismo independente — é documentação interna tornada pública por alguém com incentivo direto no sucesso do produto.

Isso não invalida o conteúdo. Mas calibra como devemos lê-lo.

O dado mais revelador do artigo é a taxa de sucesso: 67% dos pull requests gerados pelo Devin são aceitos. A Cognition apresenta isso como vitória. Mas pense no inverso: um em cada três PRs precisa ser rejeitado ou refeito. Para um agente operando dentro da própria empresa que o criou — onde o contexto é máximo e as integrações são ideais — essa taxa levanta uma pergunta incômoda sobre o que acontece em ambientes menos controlados.

O Gargalo Mudou

Durante décadas, o gargalo do desenvolvimento de software foi escrever código. Ferramentas, linguagens, frameworks — tudo evoluiu para acelerar a produção de linhas de código. A IA acelerou isso de forma dramática. O GitHub Octoverse registra que 41% do código novo já é assistido por IA. A Cognition afirma que 30% do seu código é gerado pelo Devin. A Microsoft reporta números similares com o Copilot no desenvolvimento do .NET. O Google diz que 25% do seu código novo vem de IA.

O problema é que escrever código nunca foi a parte difícil. Era a parte demorada. A parte difícil sempre foi garantir que o código está correto, seguro e sustentável. E agora temos ordens de magnitude mais código para verificar.

A Faros AI documentou o fenômeno com dados de mais de 10.000 desenvolvedores: aumento de 98% no volume de pull requests acompanhado de aumento de 91% no tempo de revisão. Mais código entra no pipeline. O mesmo número de humanos precisa revisá-lo. A matemática não fecha.

Werner Vogels, CTO da Amazon, sintetizou a mudança no re:Invent 2025: “Você vai escrever menos código. Vai revisar mais código.” A Cursor comprou a Graphite por mais de 290 milhões de dólares em dezembro de 2025, apostando que revisão de código é o próximo grande problema a resolver. Quando empresas pagam centenas de milhões para resolver um problema, o problema é real.

A Heurística do Engenheiro Júnior

A Cognition define internamente uma regra para decidir quais tarefas atribuir ao Devin: “Se um engenheiro júnior conseguiria resolver com instruções suficientes, é uma boa tarefa para o Devin.”

Essa heurística é honesta. Também revela o teto atual dos agentes de codificação. Addy Osmani descreveu o mesmo fenômeno como “The 80% Problem” — agentes completam 80% do trabalho rapidamente, mas tropeçam nos 20% que exigem contexto profundo, julgamento arquitetural e entendimento do domínio.

Kent Beck foi mais direto em “Programming Deflation” (setembro de 2025): escrever código está virando commodity. O valor está migrando para entendimento, integração e julgamento — exatamente as habilidades que a heurística do engenheiro júnior exclui.

Aqui está o paradoxo que ninguém quer discutir: se IA substitui as tarefas que formavam engenheiros juniores, quem forma a próxima geração de engenheiros seniores? Os dados já mostram o efeito. Contratação de nível inicial em engenharia de software caiu 50% entre 2023 e 2025. Estamos automatizando o degrau de entrada da escada sem considerar que a escada precisa de todos os degraus para funcionar.

O Paradoxo da Produtividade

A narrativa predominante é que ferramentas de IA tornam desenvolvedores mais produtivos. Os dados contam uma história mais complicada.

A Atlassian publicou em 2025 que 99% dos desenvolvedores usando IA relatam economizar mais de 10 horas por semana. Simultaneamente, não houve redução mensurável na carga total de trabalho. Os desenvolvedores estão mais rápidos, mas não estão entregando mais. Para onde vai o tempo economizado?

Um estudo do METR — organização independente de avaliação de IA — mediu o efeito real e encontrou algo perturbador: ferramentas de IA resultaram em 19% de desaceleração líquida, apesar dos usuários acreditarem que estavam 20% mais rápidos. A percepção e a realidade divergiram em quase 40 pontos percentuais.

Isso não significa que IA é inútil para desenvolvimento. Significa que estamos medindo errado. A velocidade de gerar código não é a métrica que importa. A métrica que importa é a confiança no código que chega a produção. O CEO da Sonar capturou isso com precisão: “O valor não é mais definido pela velocidade de escrever código, mas pela confiança em deployá-lo.”

A Lacuna de Governança

É aqui que a história da Cognition se torna relevante para qualquer organização usando IA no desenvolvimento.

A Cognition pode se permitir usar o Devin para construir o Devin porque opera em condições ideais: contexto total sobre o próprio produto, equipe de engenharia sênior capaz de revisar output de IA, incentivo direto em detectar e corrigir falhas. Mesmo assim, 33% dos PRs são rejeitados.

A maioria das organizações não tem essas condições. E os riscos são concretos.

A Veracode testou código gerado por IA e encontrou falhas de segurança em 45% dos casos. Empresas Fortune 50 reportaram aumento de 10x em findings de segurança após adoção ampla de ferramentas de codificação assistida por IA. A CodeRabbit documentou que código gerado por IA produz 1,7 vez mais issues do que código escrito por humanos.

A lacuna de governança é a distância entre a capacidade da IA de gerar código e a capacidade da organização de verificá-lo. E essa lacuna está crescendo, porque a geração acelera enquanto a revisão permanece limitada pela capacidade humana.

Quem Revisa o Código do Não-Engenheiro?

O artigo de Nader menciona, quase de passagem, que equipes não técnicas na Cognition também usam o Devin para contribuir código. Product managers, designers, profissionais de marketing — todos gerando pull requests com assistência de IA.

Essa é uma mudança estrutural que merece mais atenção do que recebe. Se uma pessoa sem formação em engenharia pode gerar código funcional, quem revisa esse código? Quem avalia as implicações de segurança? Quem entende as dependências arquiteturais que o PR afeta?

A democratização do acesso à geração de código sem a correspondente democratização da capacidade de revisão cria um vetor de risco novo. Não porque não-engenheiros são irresponsáveis — mas porque o sistema pressupõe que todo código passa por revisão qualificada, e mais código entrando no pipeline sem mais revisores qualificados quebra essa premissa.

Dogfooding Como Sinal — E Suas Limitações

A Cognition usar o Devin para construir o Devin é frequentemente citado como prova de confiança no produto. E é, em alguma medida. Se você não usa sua própria ferramenta, por que alguém usaria?

Mas dogfooding tem um viés de sobrevivência que raramente é discutido. Sabemos os casos de sucesso porque são publicados. Não sabemos as taxas de falha, os PRs que quebraram builds internos, as regressões que o Devin introduziu e a equipe corrigiu silenciosamente. A narrativa é curada.

A Microsoft faz dogfooding do Copilot. O Google usa seus próprios modelos internamente. A Cognition usa o Devin. Todos reportam sucesso. Nenhum publica dados granulares de falha. Isso não é conspirativo — é natural que empresas destaquem seus sucessos. Mas significa que dogfooding como evidência deve ser tratado com o mesmo ceticismo que qualquer dado auto-reportado.

O ARR da Cognition cresceu de 1 milhão de dólares em setembro de 2024 para 73 milhões em junho de 2025. Com avaliação de 10 bilhões de dólares e parcerias com Cognizant, Infosys e Goldman Sachs como cliente, a empresa tem incentivo significativo em manter a narrativa de sucesso. Isso não significa que estejam mentindo. Significa que devemos ler os dados com contexto.

A Confiança Está Caindo Enquanto o Uso Sobe

Talvez o dado mais revelador sobre o estado atual da codificação assistida por IA não venha de nenhuma empresa vendendo o produto. Vem dos próprios desenvolvedores.

A confiança dos desenvolvedores em ferramentas de codificação assistida por IA caiu de 43% para 29% em 18 meses — no mesmo período em que o uso subiu para 84%. Os desenvolvedores estão usando mais IA e confiando menos nela. Isso não é contradição. É adaptação pragmática: a ferramenta é útil o suficiente para usar, mas não confiável o suficiente para delegar sem supervisão.

Essa divergência entre uso e confiança é o sinal mais claro de que o problema de governança é real. Se os próprios usuários técnicos — as pessoas que melhor entendem o que a ferramenta faz e não faz — estão reduzindo sua confiança, organizações sem essa expertise técnica deveriam prestar atenção redobrada.

O Que Isso Significa na Prática

A questão não é se IA deve ser usada no desenvolvimento de software. Já é, e vai ser cada vez mais. A questão é se as organizações estão construindo a capacidade de governar o que a IA produz.

Três implicações concretas emergem dessa análise.

Primeira: revisão de código precisa ser tratada como infraestrutura, não como custo. Se o volume de código gerado por IA cresce exponencialmente e a capacidade de revisão cresce linearmente, o resultado é inevitável: código não revisado adequadamente chega a produção. Investir em processos, ferramentas e capacidade de revisão não é opcional — é a diferença entre adoção sustentável e dívida técnica acelerada.

Segunda: a heurística do “engenheiro júnior” não é temporária. A tendência de delegar tarefas simples para IA e reservar tarefas complexas para humanos assume que sempre haverá humanos formados para as tarefas complexas. Se o pipeline de formação seca porque não há mais tarefas juniores para treinar novos engenheiros, a heurística se torna uma armadilha. Organizações precisam pensar sobre formação de talento como parte da estratégia de adoção de IA, não como problema separado.

Terceira: métricas de produtividade precisam mudar. Linhas de código geradas, PRs criados, velocidade de entrega — todas essas métricas são de output. A métrica que importa é confiança no que chega a produção. Quantos PRs foram revertidos? Quantos bugs em produção vieram de código assistido por IA? Qual é o tempo médio de revisão e ele está crescendo? Se você não está medindo isso, está voando cego.

A Recursão Que Importa

A Cognition usar o Devin para construir o Devin é uma boa história. Mas a história que importa não é sobre recursão. É sobre a distância crescente entre o que a IA consegue gerar e o que as organizações conseguem verificar.

Essa distância é a lacuna de governança. E ela existe em toda empresa que adotou ferramentas de codificação assistida por IA — o que, segundo os dados, é a maioria.

Fechar essa lacuna não exige abandonar IA. Exige tratar revisão, verificação e governança com a mesma seriedade que tratamos a geração. Exige métricas que meçam confiança, não velocidade. Exige reconhecer que o gargalo mudou, e que infraestrutura de revisão é tão importante quanto infraestrutura de geração.

A pergunta não é “a IA pode se construir?” Já pode, com limitações documentadas. A pergunta é: quando a IA se constrói, quem governa o construtor?

Se a sua organização não tem resposta para essa pergunta, o problema já começou.

Na Victorino Group, ajudamos organizações a fechar a lacuna entre geração e governança de código assistido por IA. Se você está escalando adoção de IA no desenvolvimento e precisa de estrutura para manter a confiança no que chega a produção, vamos conversar: contato@victorino.com.br | www.victorino.com.br

Fontes: “How Cognition Uses Devin to Build Devin” de Nader Dabit (Substack, fevereiro 2026); Faros AI — dados de produtividade com 10.000+ desenvolvedores; Werner Vogels, keynote re:Invent 2025; Cursor/Graphite — aquisição de dezembro 2025; Kent Beck, “Programming Deflation” (setembro 2025); Addy Osmani, “The 80% Problem”; GitHub Octoverse 2025; Atlassian Developer Survey 2025; METR — estudo independente de produtividade com IA; Veracode — análise de segurança de código gerado por IA; CodeRabbit — dados de qualidade de código; Sonar CEO — declaração sobre confiança em deploy.