Tem um número no relatório novo da GitLab que ficou girando na minha cabeça. Perguntaram a 1.528 desenvolvedores e compradores de tecnologia se, diante de um incidente em produção, eles conseguiriam determinar em 24 horas se algum código gerado por IA tinha contribuído. 87% responderam que sim, com confiança. Aí veio o teste de realidade. Entre as empresas que de fato passaram por um incidente no último ano, um terço não conseguiu fazer essa determinação. A confiança estava em 87%. A prática entregou 66%.
Esse buraco entre o que a gente acha que consegue rastrear e o que consegue de verdade é o assunto do artigo. Porque ele não é sobre a IA escrever código ruim. É sobre a gente perder a conta de quem escreveu, pra quê, e quem responde quando quebra.
As três perguntas que ninguém estava fazendo
A pesquisa foi conduzida pela Harris Poll para a GitLab, em seis países, e saiu no fim de junho. Ela cunha um termo que eu achei certeiro: accountability de IA. A definição é a capacidade, organizacional e técnica, de responder três perguntas sobre qualquer linha de código gerado por IA. De onde ela veio. O que ela deveria fazer. E quem responde por ela quando está em produção.
Parece básico. Só que a maioria dos times montou a esteira de geração sem montar a esteira dessas respostas. 91% das empresas já têm dois ou mais assistentes de código em uso ativo. 78% dizem que os devs commitam mais rápido. E 80% admitem que adotaram as ferramentas mais depressa do que criaram as políticas. A velocidade veio primeiro. A pergunta de quem responde ficou pra depois, e depois virou o incidente que ninguém consegue rastrear.
Velocidade sem procedência é dívida, não entrega
Quando eu olho as causas que o relatório aponta pra essa dificuldade de rastreio, elas são desconfortavelmente concretas. 43% dizem que não conseguem distinguir o que foi escrito por IA do que foi escrito por humano. 40% têm toolchains fragmentados. 39% simplesmente não têm sistema que registre a origem do código. Ou seja, o código entra no repositório sem etiqueta de procedência. Seis meses depois, ele é só código. Igual a qualquer outro. E quando dá problema, você está fazendo arqueologia num commit que ninguém lembra de onde saiu.
Eu já escrevi aqui que mais código não é mais produto. Esse relatório mostra o outro lado da mesma moeda. 83% das empresas dizem que o acúmulo de código gerado por IA já é um risco, e 82% dizem que ele arrisca criar uma nova forma de dívida técnica. Não é a dívida clássica, aquela do atalho que você tomou sabendo. É uma dívida de compreensão. Volume que entrou rápido demais pra alguém ter parado pra entender, e que agora ninguém consegue nem localizar direito. Gerar ficou barato. Carregar o que foi gerado, não.
A resposta não se compra depois
A reação mais comum a esse susto é previsível, e o próprio relatório a mede. 91% pretendem investir em ferramenta de governança de código de IA nos próximos doze meses. Faz sentido comprar rastreabilidade, ninguém vai contra instrumentar a esteira. Mas tem uma das três perguntas que ferramenta nenhuma responde sozinha. A do meio. O que esse código deveria fazer.
Essa resposta não é um metadado que você extrai do commit. É intenção. E intenção ou você escreveu antes, ou ela não existe. É exatamente por isso que eu insisto tanto em spec como fonte. Quando a especificação é o artefato que dirige a geração, a pergunta "o que isso deveria fazer" já tem resposta escrita, datada, versionada, antes de a primeira linha existir. Ela deixa de ser uma perícia forense depois do incidente e passa a ser um documento que você abre. A IA gera a implementação a partir da intenção, e a intenção fica registrada como o que ela é: a origem de verdade.
O padrão que quebra é o inverso. Promptar solto, aceitar o resultado, seguir em frente. Aí a intenção nunca virou artefato. Ela morou na cabeça de alguém por vinte minutos e evaporou. Quando o código quebra, não existe contra o que comparar, porque nunca se escreveu o que ele deveria fazer. A ferramenta de governança que você comprou vai te dizer que aquela linha veio de IA. Não vai te dizer se ela está fazendo o que devia.
O 70/30 aparecendo na conta de novo
No fundo isso é a tese 70/30 batendo na porta por outro ângulo. A IA comprimiu a execução, que é a parte visível e barulhenta. Mas o valor da engenharia nunca esteve em digitar. Ele está na intenção, na arquitetura, na especificação e na validação. As três perguntas da GitLab são, ponto por ponto, os 70% que a IA não absorve. De onde veio é procedência, é governança. O que deveria fazer é especificação. Quem responde é titularidade, e titularidade não migra pro modelo.
Esse último ponto é o que mais me incomoda quando escuto falar em delegar pra IA. Você pode delegar a digitação. A responsabilidade não. Se o código foi pra produção com o seu nome no deploy, a autoria daquela decisão é sua, tenha ela saído do seu teclado ou de um prompt. O relatório está medindo empresas descobrindo isso da pior forma, no meio de um incidente, tentando reconstruir uma cadeia de responsabilidade que elas nunca montaram. A pressa de gerar deixou um rombo exatamente no lugar onde mora o trabalho que continua sendo humano.
O que eu perguntaria antes de comprar a próxima ferramenta
Não é contra IA gerar código. Eu uso, recomendo, defendo. O erro é tratar a geração como se fosse a entrega, quando ela é só o começo da parte que importa. Antes de investir na ferramenta de rastreio, eu faria as três perguntas do relatório sobre um pedaço de código que já está rodando hoje. De onde veio. O que deveria fazer. Quem responde. Se as três têm resposta rápida, a esteira está saudável. Se alguma trava, o problema não é a próxima ferramenta. É que a gente aprendeu a gerar antes de aprender a responder. A barreira técnica caiu, gerar virou commodity. O que pesa agora é ter escrito a intenção antes, e assumir que o nome no deploy é seu.
Referências
- GitLab – AI Accountability Report: Organizations Are Generating AI Code Faster Than They Can Control It. GitLab, 23/06/2026. Pesquisa da Harris Poll com 1.528 desenvolvedores e compradores de tecnologia em seis países. 85% dizem que o gargalo foi de escrever para revisar/validar; 87% confiam que rastreariam código de IA num incidente em 24h, mas 34% dos que tiveram incidente não conseguiram; 80% adotaram as ferramentas antes das políticas; 83% veem o acúmulo como risco; 91% vão investir em governança.
- InfoQ – AI Tools Accelerates Coding, But Not Overall Software Delivery, GitLab Research Finds. Sergio De Simone, 29/06/2026. Detalha a definição das três perguntas (de onde veio, o que deveria fazer, quem responde) e as causas do rombo de rastreio: 43% não distinguem código de IA de humano, 40% têm toolchains fragmentados, 39% não registram a origem.
- The New Stack – Developers are now validating code they didn't write and may not understand. Adrian Bridgwater, 23/06/2026. Enquadra o mesmo relatório pelo lado do dev que revisa o que não escreveu.
- Martin Fowler – Structured Prompt-Driven Development. martinfowler.com. A especificação como artefato que dirige a geração e registra a intenção antes do código.
- Cory Hymel – The AI-Native Software Development Lifecycle (modelo V-Bounce). arXiv 2408.03416, 2024. Base do 70/30: a execução comprime, o valor migra para intenção, especificação e validação.