O desenvolvimento acelerado pela IA está cumprindo a sua promessa. As equipes de engenharia estão enviando mais códigos, avançando com mais rapidez, e todos podemos ver que os ganhos de produtividade são reais.
Em uma pesquisa com 309 líderes de engenharia conduzida pela Dimensional Analysis for Flux, 67% das organizações que já usam código gerado por IA relatam aumento de produtividade, e quase 45% o têm em execução na produção. Isso é um instantâneo de um único relatório, mas mostra que as equipes estão realizando um trabalho actual com ferramentas de codificação de IA, mais rápido do que há apenas um ano.
O ecossistema de ferramentas está evoluindo
O ecossistema de ferramentas que apoiam essa mudança também está a amadurecer. A revisão automatizada de código, cada vez mais alimentada por IA, está se tornando uma ferramenta de produção padrão. A pesquisa mostrou que quase 40% das organizações já o implantaram e há boas razões para isso. Essas ferramentas detectam defeitos no envio, aplicam padrões consistentes e fornecem suggestions mais rápido do que os processos de revisão humana. Quase dois terços dos líderes de engenharia nesse mesmo relatório acreditam que a IA poderia superar os humanos na revisão de código (pelo menos em alguns aspectos). Eu concordaria com isso. Em escala, a IA é melhor do que os humanos na aplicação consistente de padrões uniformes, e isso é muito importante quando você precisa revisar mais código do que sua equipe pode lidar de forma realista.
No momento do envio, a revisão automatizada do código responde a uma pergunta específica: essa alteração apresenta defeitos que posso detectar agora? Essa é a pergunta certa a ser feita em uma solicitação pull. Mas é uma questão diferente do que realmente está acontecendo em sua base de código semana após semana, onde a complexidade está se acumulando e quais padrões estão se formando e que não se tornarão aparentes até que desencadeiem um incidente. Essas são questões de visibilidade e as ferramentas de revisão não foram projetadas para respondê-las.
Essa distinção é mais importante hoje do que há alguns anos. O desenvolvimento acelerado por IA mudou o quantity, a velocidade e as características do código que entra em produção. As equipes estão gerando mais código e mais rapidamente. Freqüentemente, esse código parece sofisticado e sofisticado à primeira vista, o que pode dificultar a detecção de problemas na revisão. E a revisão do código é inevitavelmente demorada. Nossa pesquisa descobriu que quase 80% das equipes de engenharia já gastam pelo menos 10% do seu tempo na revisão de código, e cerca de uma em cada 10 passa mais de 40% do seu tempo nisso.
A maioria das equipes simplesmente não consegue lidar com o aumento do quantity, e a capacidade de revisão não é escalonável com a saída de código acelerada por IA. Não é apenas mais código. Também é mais risco potencial. O quantity obscurece pequenas mudanças com consequências significativas a jusante. As questões de segurança passam despercebidas simplesmente porque há muito para avaliar nesse nível de detalhe. Quase metade dos entrevistados indicaram que têm dificuldade para detectar problemas de segurança semana após semana, e as mudanças de dependência e os impactos no desempenho não ficam muito atrás. Apenas 3,6% dos entrevistados disseram que os problemas introduzidos pela IA nunca chegam à produção. Para a maioria das equipes, esta é uma realidade conhecida e recorrente.
Mudanças arquitetônicas difíceis de detectar
Converso regularmente com líderes de engenharia que estão enfrentando exatamente esse desafio. Eles adotaram ferramentas de codificação de IA, observaram o aumento da velocidade, investiram em revisão automatizada para detectar problemas no momento e, meses depois, descobriram que havia problemas acumulados em sua base de código que seus processos de revisão não haviam detectado. Não se trata de um revisor que perdeu um bug, o que sempre pode acontecer. As mudanças arquitetônicas, no entanto, são difíceis de detectar, especialmente quando ninguém tem visibilidade do desvio semanal. Os incidentes que se seguem podem parecer falhas de revisão, mas na verdade são falhas de visibilidade.
A visibilidade de uma base de código significa algo específico: saber o que mudou, onde e por que, ao longo do tempo e entre equipes. Significa ver a complexidade crescer em um módulo antes que ele se torne insuportável e detectar quando a IA generativa reproduction padrões do código existente para que os antipadrões se espalhem pelos serviços sem que ninguém perceba.
Tickets, retrospectivas e problemas sinalizados por engenheiros não podem mostrar isso. Sinais contínuos do próprio código podem.
O modelo psychological certo são as camadas. A revisão automatizada de código pertence a todas as organizações de engenharia que enviam código gerado por IA – detectar defeitos antes de eles se fundirem evita muitos problemas. Mas opera em mudanças individuais no ponto de submissão.
A visibilidade da base de código opera no sistema continuamente. Significa saber que uma dependência mudou há três semanas de uma forma que sua equipe de segurança gostaria de saber, ou que um módulo vem acumulando complexidade em uma dúzia de commits de uma forma que nenhum PR pode revelar. Esses sinais não vêm da análise de pull requests individuais ou de tickets do Jira. Eles vêm da observação da mudança da base de código ao longo do tempo.
A maioria dos líderes de engenharia com quem converso já sabe que algo está faltando. Eles têm cobertura de revisão, mas não têm uma visão semanal do que a IA está fazendo com sua base de código. Obter essa imagem significa reconhecer que enviar código gerado por IA em grande escala é um problema diferente de revisá-lo e tratá-lo adequadamente.
