A Anthropic declarou publicamente que a maioria do código produzido internamente agora é escrito pelo Claude Code. A Stripe implantou ferramentas de coding em IA para 1.370 engenheiros, de todos os níveis de senioridade. Um time completou uma migração de 10.000 linhas de Scala em quatro dias, trabalho estimado em duas semanas-engenheiro. A Ramp integrou IA ao fluxo de desenvolvimento e reduziu o tempo de investigação de incidentes em 80%.
Esses números não estão no domínio das previsões. São fatos de 2025 e 2026, verificáveis nas páginas de clientes das próprias ferramentas.
A pergunta que ficou sem resposta satisfatória na maioria das organizações que adotaram IA no desenvolvimento é mais simples, e mais incômoda: quando a IA escreve o código, quem garante que ele funciona? E o que significa “funcionar” quando o software está em produção, sob carga real, com dados atípicos, e precisa ser mantido por um time que não escreveu nenhuma linha?
O problema específico do código que “parece certo”
Código gerado por IA é, tipicamente, código que compila, que passa nos testes óbvios, e que resolve o problema imediato de forma plausível. O problema não é o que ele faz de errado de forma visível. É o que ele faz de forma sutil, de forma invisível.
Um desenvolvedor sênior que escreve código carrega anos de contexto situacional: sabe que aquela abstração vai criar acoplamento problemático em seis meses, que aquela query funciona agora mas vai travar com volume dez vezes maior, que aquele padrão viola convenções do time e vai causar confusão na próxima revisão. Esse conhecimento raramente está documentado. Está incorporado no julgamento de quem já sofreu as consequências de decisões técnicas ruins.
A IA não carrega esse contexto. Ela resolve o problema especificado no prompt, com competência crescente em 2026, mas sem a visão de longo prazo que emerge de ter sido responsável pelo que vai para produção.
O resultado é uma categoria específica de risco: código que parece correto, passa em revisões superficiais, e manifesta problemas semanas ou meses depois, quando o volume escala, quando um caso extremo aparece, ou quando um desenvolvedor que não participou da geração precisa modificar algo.
“Plausível não é o mesmo que correto. Correto não é o mesmo que sustentável. E sustentável não é o mesmo que seguro.”
O que o “vibe coding” revelou sobre esse risco
Entre 2024 e o começo de 2025, proliferou um estilo de desenvolvimento que ficou conhecido como “vibe coding”, aceitar o código gerado pela IA sem revisão crítica sistemática, confiando na percepção de que estava funcionando. A justificativa era pragmática: velocidade de entrega, democratização do desenvolvimento, founders sem background técnico construindo MVPs reais.
O risco não era teórico. Aplicações construídas inteiramente nesse modo acumularam dívida técnica em velocidade recorde: código duplicado sem necessidade, dependências desnecessárias que expandiam a superfície de ataque, ausência de tratamento de erros em caminhos críticos, ausência de validação de input, vulnerabilidades que nenhum teste de aceitação detecta.
A OWASP (Open Web Application Security Project) documentou as categorias de vulnerabilidades mais frequentes em código gerado por LLMs: prompt injection em sistemas que incorporam input do usuário sem sanitização adequada, exposição acidental de variáveis de ambiente, dependências com vulnerabilidades conhecidas introduzidas sem auditoria, e ausência de controles de acesso granulares em código gerado para sistemas com múltiplos perfis de usuário.
Nenhuma dessas vulnerabilidades é exclusiva do código gerado por IA. Todas elas existiam antes. O que mudou é a velocidade com que esse código chega à revisão, e, sem processos adaptados, a velocidade com que vai para produção sem o nível de escrutínio que o volume exige.
Não pague a IA é ruim. Porque ninguém especificou que o código precisava ser seguro, testável, eficiente e manutenível, não apenas funcional. E porque os processos de revisão não foram redesenhados para a nova velocidade de geração.
O que os dados dizem sobre como os engenheiros estão usando IA na prática
A Anthropic publicou pesquisa baseada em análise de mais de 200.000 transcrições de sessões do Claude Code com 132 engenheiros. Os resultados apontam para desenvolvedores usando a ferramenta viram um aumento de 67% em pull requests merged por dia. Mais relevante: 27% do trabalho assistido por IA envolveu tarefas que os engenheiros não teriam tentado sem a ferramenta disponível.
Esse segundo número é o mais significativo. Engenheiros não estavam apenas codificando mais rápido. Estavam expandindo o escopo do que estavam dispostos a tentar. Migração de codebase legado. Refatorações que antes pareciam arriscadas demais para o tempo disponível. Experimentação com arquiteturas que exigiriam semanas de trabalho exploratório.
A mesma pesquisa documentou um padrão na forma como usuários mais experientes interagem com a ferramenta: interrompem ações automatizadas com mais frequência, interrompem mais. Usuários novos interrompem o Claude Code em cerca de 5% dos turnos. Usuários experientes, em torno de 9%. Mais experiência com a ferramenta produziu mais supervisão ativa, não menos.
Esse padrão contraria a narrativa de que a automação leva inevitavelmente a menos controle humano. O que ele sugere é que os engenheiros que entendem o que a ferramenta faz bem, e onde ela erra, a supervisionam mais ativamente, não menos.
O que muda na engenharia, e o que não muda
O que muda é a distribuição do trabalho. Escrever código, transformar uma especificação clara em linhas que executam corretamente, se torna cada vez menos o gargalo. A IA faz isso com velocidade e consistência crescentes para tarefas bem definidas.
O que não muda é a necessidade de julgamento técnico em pontos específicos do processo.
Arquitetura. Decidir como os componentes se relacionam, onde colocar os limites entre serviços, quais abstrações vão envelhecer bem, essas decisões ainda exigem raciocínio contextual sobre a organização, os dados, o time, e as restrições de longo prazo. A IA não tem esse contexto porque ele é específico de cada ambiente.
Especificação. A qualidade do output da IA é diretamente proporcional à qualidade do input. Um prompt vago produz código vago. Especificar o comportamento esperado com precisão suficiente, incluindo casos extremos, tratamento de erros, restrições de performance, e requisitos de segurança, é um trabalho que exige compreensão técnica profunda do problema.
Revisão. O desenvolvedor que recebe código gerado por IA e o revisa com o mesmo ceticismo que aplicaria ao código de um júnior está tomando um risco que não é imediatamente visível. A velocidade de geração não reduz a necessidade de revisão, ela aumenta o volume de código que precisa ser revisado.
Testes. Testes automatizados são o mecanismo que transforma confiança subjetiva em evidência objetiva. Um código que “parece funcionar” com cobertura de testes robusta é genuinamente diferente de um código que parece funcionar sem ela. A diferença aparece em produção.
A Anthropic descreve seus próprios engenheiros como trabalhando em “arquitetura, pensamento de produto e orquestração contínua: gerenciando múltiplos agentes em paralelo, dando direção, e tomando as decisões que moldam o que é construído.” Isso não é menos trabalho técnico. É trabalho técnico com ênfase diferente, julgamento sobre execução.
O caso real do Claude Code em produção na Anthropic
Em abril de 2026, a Anthropic publicou um postmortem detalhado de um bug de qualidade no próprio Claude Code, relevante precisamente porque envolve código gerado e revisado internamente.
O bug se originou de uma linha adicionada ao system prompt para reduzir verbosidade: uma restrição de comprimento de resposta que causou queda de 3% em benchmarks de inteligência. A mudança passou por múltiplas revisões humanas, testes unitários, testes de ponta a ponta, verificação automatizada e dogfooding interno, e ainda assim chegou a usuários em produção.
A causa foi uma combinação de fatores: dois experimentos independentes ativos ao mesmo tempo obscureceram a regressão, e o bug se manifestava apenas em sessões estagnadas (corner case difícil de reproduzir). A Anthropic reverteu a mudança em quatro dias e redefiniu processos, períodos de soak, avaliações por modelo antes de qualquer mudança de system prompt, rollouts graduais.
O postmortem é instrutivo não porque demonstra falha da IA, mas porque demonstra que o problema de qualidade de software sob pressão de velocidade não desaparece com IA, ele muda de forma. O mesmo escrutínio que se aplica a código humano precisa ser aplicado a mudanças que emergem de sistemas de IA, incluindo mudanças de configuração e prompt.
A nova divisão de trabalho que está emergindo
As organizações que estão usando IA no desenvolvimento com consistência em 2026 não são as que eliminaram a supervisão humana. São as que reorganizaram onde e como a supervisão é aplicada.
O modelo que está emergindo em times maduros:
- A IA executa tarefas bem definidas, implementação de features especificadas, migração de código, geração de testes para código existente, investigação de bugs com contexto fornecido.
- O engenheiro define o escopo, revisa o output com ceticismo estruturado, e é responsável pelo que vai para produção.
- Arquitetura, decisões de segurança, e design de sistema permanecem com humanos, não por restrição filosófica, mas porque essas decisões dependem de contexto organizacional que a IA não tem acesso.
O que muda para times que adotam esse modelo é onde o tempo de engenharia é gasto: menos na execução de tarefas bem definidas, mais na especificação precisa do que precisa ser construído, na revisão de output com mais volume para processar, e na definição da arquitetura que vai conter e direcionar o que a IA produz.
O que isso muda para quem contrata desenvolvimento
Para empresas que terceirizam desenvolvimento, para agências, freelancers ou times distribuídos, a era do código gerado por IA cria uma questão nova de due diligence.
Não basta perguntar “o produto funciona?”. As perguntas relevantes são:
Existe cobertura de testes automatizados? Em que nível, unitário, integração, ponta a ponta? A arquitetura foi documentada e revisada por um humano com responsabilidade nominal sobre as decisões? Como as decisões de segurança foram tomadas e por quem? Existe processo de revisão de código independente do processo de geração? Como o time lida com a manutenção de código que foi gerado, não escrito?
Um software funcional entregue sem respostas claras para essas perguntas é um software que funciona hoje e falha de formas inesperadas quando escala, quando recebe dados atípicos, ou quando precisa ser modificado por alguém novo da equipe da criação.
A velocidade que a IA oferece no desenvolvimento não reduz a importância dessas perguntas. Em alguns casos, ela as torna mais urgentes, porque o volume de código que chega à produção no mesmo tempo de maturação que código escrito linha a linha tende a ser maior.
O que acompanhar
O debate sobre qualidade de software com IA vai evoluir rapidamente em 2026 à medida que ferramentas de revisão automatizada também melhorem. A própria Anthropic anunciou melhorias ao seu Code Review interno como resposta ao postmortem citado, com intenção de disponibilizar versão melhorada para clientes.
A tendência mais relevante a observar não é se a IA vai escrever mais código. Vai. É como os processos de revisão, teste e auditoria vão se adaptar à nova velocidade de geração, e quais organizações vão construir esses processos antes de aprender por incidentes em produção.
Aplicações bem construídas, com ou sem IA no processo de desenvolvimento, precisam de infraestrutura que responda de forma previsível sob carga, com uptime garantido e capacidade de escalar quando o tráfego não segue o padrão esperado. A qualidade do código e a qualidade da infraestrutura são variáveis independentes. Problemas em qualquer uma das duas chegam ao usuário final da mesma forma.
