A IA tem o potencial de acelerar o processo de desenvolvimento de software program, mas será possível que esteja acrescentando tempo adicional ao processo quando se trata da manutenção desse código a longo prazo?
Em um episódio recente do podcast What the Dev?, conversamos com Tanner Burson, vice-presidente de engenharia da Prismatic, para saber sua opinião sobre o assunto.
Aqui está uma versão editada e resumida dessa conversa:
Você escreveu que 2025 será o ano em que as organizações lutarão para manter e expandir seus sistemas co-criados de IA, expondo os limites de sua compreensão e a lacuna entre a facilidade de desenvolvimento e a sustentabilidade a longo prazo. A noção de que a IA possivelmente desestabilizaria o pipeline de desenvolvimento moderno chamou minha atenção. Você pode mergulhar um pouco nisso e explicar o que você quer dizer com isso e com o que os desenvolvedores devem ter cuidado?
Não acho que seja nenhum segredo ou surpresa que a IA generativa e os LLMs tenham mudado a maneira como muitas pessoas abordam o desenvolvimento de software program e como procuram oportunidades para expandir o que estão fazendo. Vimos todo mundo do Google dizendo recentemente que 25% de seu código agora está sendo escrito ou executado por algum tipo de IA interna, e acredito que foi o CEO da AWS quem estava falando sobre a remoção completa dos engenheiros dentro uma década.
Portanto, certamente há muitas pessoas falando sobre os extremos do que a IA será capaz de fazer e como ela será capaz de mudar o processo. E acho que as pessoas estão adotando isso muito rapidamente, sem necessariamente colocar todo o pensamento no impacto de longo prazo em suas empresas e em sua base de código.
Minha expectativa é que este ano seja o ano em que começaremos a ver realmente como as empresas se comportam quando têm muitos códigos que não entendem mais. Eles têm código que não sabem depurar corretamente. Eles têm código que pode não ter o desempenho esperado. Pode ter características surpreendentes de desempenho ou segurança, e ter que voltar e realmente repensar muitos dos seus processos de desenvolvimento, pipelines e ferramentas para considerar que isso é uma parte importante do seu processo, ou para começar a adaptar o seu processo mais fortemente, para limitar ou conter a maneira como eles usam essas ferramentas.
Deixe-me apenas perguntar: por que é um problema ter código escrito por IA que não seja necessariamente compreensível?
Portanto, o padrão atual de ferramentas de IA tem uma quantidade relativamente limitada de contexto sobre sua base de código. Ele pode examinar o arquivo atual ou talvez alguns outros e fazer o possível para adivinhar como seria um bom código para aquela situação específica. Mas não tem o contexto completo de um engenheiro que conhece toda a base de código, que entende os sistemas de negócios, os bancos de dados subjacentes, as estruturas de dados, as redes, os sistemas, os requisitos de segurança. Você disse: ‘Escreva uma função para fazer x’, e ele tentou fazer isso da maneira que pôde. E se as pessoas não revisarem esse código adequadamente, não o alterarem para se adequar a esses problemas mais profundos, a esses requisitos mais profundos, essas coisas irão se atualizar e começarão a causar problemas.
Na verdade, isso não eliminará a noção de avançar e desenvolver-se mais rapidamente se todo esse trabalho posterior tiver que ser realizado?
Sim, absolutamente. Acho que a maioria dos engenheiros concordaria que, ao longo da vida útil de uma base de código, o tempo gasto escrevendo código em vez de corrigir bugs, corrigir problemas de desempenho e alterar o código para novos requisitos é menor. E então, se hoje estivermos focados apenas em quão rápido podemos inserir o código no sistema, estamos perdendo a cauda longa e muitas vezes as partes mais difíceis do desenvolvimento de software program vão além de apenas escrever o código inicial, certo?
Então, quando se fala sobre a sustentabilidade do código a longo prazo, e talvez a IA não considere isso, como é que a inteligência synthetic terá impacto nessa sustentabilidade a longo prazo?
Acho que aí, no curto prazo, vai ter um impacto negativo. Acho que, no curto prazo, veremos encargos reais de manutenção, desafios reais com as bases de código existentes, com bases de código que adotaram excessivamente código gerado por IA. Acho que, a longo prazo, há algumas pesquisas e experimentos interessantes sendo feitos, e como incorporar dados de observabilidade e mais suggestions em tempo actual sobre a operação de uma plataforma em alguns desses sistemas de IA e permitir que eles entendam o contexto em que o código é sendo executado. Ainda não vi nenhum desses sistemas existir de uma forma que seja realmente operável ou executável em escala na produção, mas acho que a longo prazo há definitivamente alguma oportunidade de ampliar a visão dessas ferramentas e fornecer mais dados isso lhes dá mais contexto. Mas até hoje, não temos a maioria desses casos de uso ou ferramentas disponíveis para nós.
Então, voltemos à premissa authentic de que a inteligência synthetic pode desestabilizar potencialmente o pipeline. Onde você vê isso acontecendo ou o potencial para que isso aconteça, e com o que as pessoas devem ser cautelosas ao adotarem a IA para garantir que isso não aconteça?
Acredito que os maiores fatores de risco no curto prazo são questões de desempenho e segurança. E eu acho que de uma forma mais direta, em alguns casos, apenas custo direto. Não espero que o custo dessas ferramentas diminua tão cedo. Eles estão todos correndo com enormes perdas. O custo do código gerado por IA provavelmente aumentará. E então acho que as equipes precisam prestar muita atenção em quanto dinheiro estão gastando apenas para escrever um pouco de código, um pouco mais rápido, mas em um sentido mais urgente, a segurança, o desempenho problemas. A solução atual para isso é uma melhor revisão de código, melhores ferramentas e testes internos, contando com as mesmas técnicas que usávamos sem IA para entender melhor nossos sistemas. Acho que isso muda e onde as equipes precisarão adaptar seus processos se adotarem a IA com mais intensidade é fazer esse tipo de revisão no início do processo. Hoje, muitas equipes fazem suas revisões de código depois que o código foi escrito e confirmado, e o desenvolvedor inicial fez os testes iniciais e o liberou para a equipe para testes mais amplos. Mas acho que com o código gerado por IA, você precisará fazer isso o mais cedo possível, porque não pode ter a mesma fé de que isso está sendo feito com o contexto certo e a credibilidade certa. E então acho que quaisquer recursos e ferramentas que as equipes tenham para testes de desempenho e segurança precisam ser feitos à medida que o código está sendo escrito nos estágios iniciais de desenvolvimento, se eles confiarem na IA para gerar esse código.
Organizamos recentemente um painel de discussão sobre o uso de IA e testes, e um dos caras fez uma observação muito engraçada sobre talvez ser uma ponte longe demais de ter a IA criando o código e depois a IA testando o código novamente, sem ter todo o contexto de toda a base de código e tudo mais. Então parece que isso seria uma receita para o desastre. Apenas curioso para saber sua opinião sobre isso?
Sim. Quero dizer, se ninguém entende como o sistema é construído, então certamente não poderemos verificar se ele atende aos requisitos, se está resolvendo os problemas reais de que precisamos. Acho que uma das coisas que se perdem quando se fala sobre geração de IA para código e como a IA está mudando o desenvolvimento de software program é o lembrete de que não escrevemos software program só por escrever software program. Nós o escrevemos para resolver problemas. Nós o escrevemos para promulgar algo, para mudar algo em outras partes do mundo, e o código faz parte disso. Mas se não conseguimos verificar se estamos resolvendo o problema certo, se estamos resolvendo a necessidade actual do cliente da maneira certa, então o que estamos fazendo? Como se tivéssemos passado muito tempo sem chegar ao ponto de termos empregos, de escrevermos software program, de fazermos o que precisamos fazer. E então acho que é aí que temos que continuar a avançar, mesmo independentemente da fonte do código, garantindo que ainda estamos resolvendo o problema certo, resolvendo-os da maneira certa e atendendo às necessidades do cliente.