Cinco recursos de criação lançados entre 2 e 16 de abril de 2026. Zero recursos de manutenção. Essa proporção diz tudo sobre onde o mercado de AI coding realmente está — e o que ele se recusa a precificar com honestidade.
Cursor 3 (2 de abril) lançou Agent Tabs paralelas — múltiplos agentes de IA escrevendo código simultaneamente em branches separados. GitHub Copilot (4 de abril) adicionou o modo Autopilot — agentes que aprovam suas próprias chamadas de ferramentas sem perguntar pra você. Windsurf 2.0 (10 de abril) lançou um Agent Command Center. Claude Code (14 de abril) introduziu Routines — agentes agendados em background que geram código a partir de triggers. O Codex da OpenAI (16 de abril) ganhou workflows multi-agente. Nenhum anúncio sequer menciona o que acontece com o código depois que ele vai pro ar.
Isso não é descuido. É estratégia de produto.
Os 60% que ninguém vende
Barry Boehm estabeleceu em 1976 que manutenção consome 60–80% do custo total do ciclo de vida do software. A IBM confirmou isso repetidamente nas décadas seguintes. Nada em cinquenta anos de engenharia de software derrubou essa proporção.
A IA parece estar aumentando ela.
Um estudo publicado no arXiv em 8 de abril de 2026 analisou dez projetos grandes gerados pelo Cursor, com média de 17.000 linhas de código cada. Correção funcional: 91% — o código funcionava. O CodeScene, uma ferramenta de análise de saúde de código, encontrou 1.305 problemas de design nesses projetos: 28,4% de código duplicado, métodos com média de 171 linhas (boas práticas limitam a 20–30), e complexidade ciclomática — uma contagem de caminhos de ramificação dentro de uma função — com média de 17, quase o dobro do teto recomendado.
A demo funciona. O codebase é estruturalmente hostil a qualquer um que toque nele depois — incluindo a própria IA que escreveu.
Todo grande benchmark de AI coding reforça esse ponto cego. O SWE-bench testa correção de bugs. O HumanEval testa geração de funções. Nenhum benchmark pergunta "esse modelo consegue adicionar um recurso com segurança ao codebase emaranhado que ele gerou três meses atrás sem nenhuma documentação de design?" Sem esse benchmark, os vendors têm zero incentivo de mercado para otimizar aquilo que realmente custa dinheiro.
Por que a IA estruturalmente não consegue manter o que cria
Manutenção exige três capacidades que criação não exige: decisões de design consistentes entre sessões, compreensão de por que o código existe (não apenas o que ele faz), e a disciplina de refatorar em vez de duplicar.
As ferramentas de IA atuais falham nas três.
Cada nova sessão começa com zero memória de decisões de design anteriores. O modelo gera qualquer padrão que se encaixa no prompt atual, não o padrão que usou na terça passada. É por isso que o estudo do arXiv encontrou 28,4% de duplicação — a IA resolve o mesmo problema de forma diferente toda vez porque não lembra de ter resolvido antes.
O ensaio controlado randomizado da METR — publicado em julho de 2025, ainda o único estudo controlado do tipo — quantificou a distância entre percepção e realidade: 16 desenvolvedores experientes em seus próprios repositórios trabalharam 19% mais devagar com ferramentas de IA, porém acreditavam que estavam 20% mais rápidos. Um delta de 39 pontos percentuais entre o que os desenvolvedores acham que está acontecendo e o que de fato está. Em codebases familiares. Em código gerado por IA e desconhecido, ninguém mediu, porque ninguém construiu o benchmark.
O que uma ferramenta focada em manutenção realmente exigiria
Se você projetasse uma ferramenta de AI coding para os 60–80% do trabalho que realmente custa dinheiro, ela não se pareceria com nada que está sendo lançado hoje.
Justificativa de design como metadado. Não apenas o que o código faz — por que ele é estruturado daquele jeito. Toda função gerada por IA deveria carregar um registro das restrições, alternativas consideradas e decisões de design que a produziram. O CLAUDE.md do Claude Code é a aproximação mais próxima: contexto de projeto persistente entre sessões. Mas é um arquivo de texto que você mantém na mão, não um registro arquitetural automatizado.
Consistência entre sessões com enforcement. Uma ferramenta focada em manutenção detectaria quando o modelo introduz um padrão que contradiz um existente e bloquearia o conflito antes do código ser gerado — não depois de um humano revisar. A indexação de codebase do Cursor (até 500MB, consultas em sub-segundo) fornece a camada de retrieval que isso exige. Retrieval sem enforcement é uma biblioteca sem bibliotecário.
Refatoração como modo padrão. As ferramentas atuais otimizam para código novo. Uma ferramenta de manutenção priorizaria modificar código existente — localizar o lugar certo para adicionar lógica em vez de gerar um arquivo novo. Ela mediria e minimizaria duplicação como métrica primária, junto com correção funcional.
Gates de degradação. Quando a complexidade ciclomática ultrapassa limites, quando métodos passam de 30 linhas, quando taxas de duplicação sobem — a ferramenta se recusa a commitar. Não como um plugin opcional. Como padrão. Da mesma forma que um type checker bloqueia código inválido, uma ferramenta focada em manutenção bloqueia código não-mantenível.
O estudo longitudinal da JetBrains publicado em 14 de abril de 2026 rastreou 800 desenvolvedores ao longo de 151,9 milhões de eventos registrados e revelou um sinal que nenhuma ferramenta de coding atua sobre: desenvolvedores passam mais de um terço do tempo verificando sugestões de IA, e revertem cerca de uma em cada cinco completions aceitas deletando o código depois. Esse padrão de deleção é um sinal de treinamento gratuito — um corpus de "o modelo achou que estava certo, o humano provou que estava errado" — parado na telemetria de toda IDE. Alguém poderia construir um feedback loop que ingere essas reversões e aprende a gerar código mantenível desde o início. Ninguém fez, porque demos de criação vendem. Um screencast de 30 segundos de um agente montando um app a partir de um prompt tem milhões de views. Um screencast de um agente decompondo cuidadosamente um método de 171 linhas em seis funções limpas rende uma palestra em conferência, talvez.
A realidade do preço
Se você aprovou um projeto feito com IA neste trimestre, aqui vai o que nenhum vendor vai te cotar: orce três vezes o custo de criação para o primeiro ano de manutenção. Se seu agente de IA escreveu 17.000 linhas em uma semana, seus engenheiros vão gastar três semanas desembaraçando problemas de design antes de conseguirem estender o código com segurança — e depois repetir o ciclo a cada novo recurso adicionado.
A abordagem mais honesta: trate código gerado por IA como um protótipo descartável com prazo de validade de seis meses. Faça a demo, valide a ideia, e depois reconstrua as partes que provaram seu valor com engenheiros que entendem a arquitetura.
Todo vendor de AI coding em abril de 2026 precifica e vende criação como o produto. O verdadeiro centro de custo em software nunca foi criação. Até que um vendor construa — e cobre por — um multiplicador de manutenção, você está comprando a fase mais barata do processo e pagando preço cheio por tudo que vem depois.

