A IA torna o código barato de criar, mas não de manter

Antes dos agentes de programação, criar mais código exigia tempo e esforço, porque os engenheiros precisavam escrevê-lo.

Isso naturalmente nos incentivava a reutilizar código sempre que possível: usar bibliotecas e frameworks, manter as implementações enxutas e pensar duas vezes antes de recriar uma funcionalidade que já existia.

Os agentes de programação reduziram drasticamente esse custo inicial.

Hoje, gerar outra implementação custa quase nada. Mesmo assim, você ainda precisa mantê-la.

É só deixar o agente construir

Existe uma ideia cada vez mais comum de que, como os agentes conseguem gerar código rapidamente, não precisamos mais nos preocupar tanto com a reutilização.

Por que perder tempo procurando uma biblioteca existente se um agente pode recriar a mesma funcionalidade em segundos? No começo, isso pode até parecer mais rápido e melhor.

Mas imagine que você tenha seis aplicações que precisam validar endereços de e-mail de acordo com os requisitos internos da sua empresa.

Em vez de criar um pacote compartilhado, você pede ao agente de programação que implemente a validação de e-mail diretamente em cada aplicação. Desde que o prompt seja o mesmo, não há problema, certo? Não necessariamente. Você pode acabar facilmente com seis implementações ligeiramente diferentes.

Então, você encontra um bug.

Criar é barato, manter não é

Corrigir a aplicação que apresentou o bug é fácil.

Você informa o problema ao agente, ele corrige a implementação, talvez adicione alguns testes, e pronto.

Mas e as outras cinco implementações? Elas também têm esse bug?

Talvez sim, talvez não. Como cada aplicação possui uma implementação diferente, elas podem ter o mesmo bug ou apresentar problemas distintos.

Na prática, você criou uma situação em que determinado endereço de e-mail pode funcionar ou não, dependendo da aplicação. Talvez funcione em três das seis aplicações ou apenas em duas. E o que acontece se esse e-mail funcionar na página de cadastro, mas não na página de login?

Não é uma boa experiência para o usuário.

A reutilização continua sendo importante

Compare isso com o uso de um pacote compartilhado. Você escreve a funcionalidade uma vez, e todas as aplicações usam o mesmo pacote.

Quando encontra um bug, você o corrige uma única vez, adiciona os testes e publica uma nova versão.

Toda aplicação que utilizar essa nova versão receberá a correção.

Agora, seu conjunto de aplicações funciona de forma consistente. E a consistência é o que mais importa. Rejeitar um e-mail válido não é bom, mas, se isso acontecer de maneira consistente, ainda será uma experiência melhor do que funcionar algumas vezes e falhar em outras.

Essa consistência é muito mais fácil de administrar quando a implementação está concentrada em uma única biblioteca reutilizável.

Não exagere no DRY

Não use o exemplo acima para ir ao outro extremo e transformar cada conjunto semelhante de três linhas de código em uma biblioteca compartilhada. Dividir tudo em pequenas bibliotecas também gera custos adicionais.

É importante encontrar um equilíbrio entre reutilização e duplicação.

Se você está desenvolvendo algo com um comportamento complexo ou cheio de particularidades, que será usado por várias aplicações ou, principalmente, que precisa funcionar de maneira consistente entre elas, uma biblioteca compartilhada provavelmente é uma boa escolha.

Se for algo simples, específico para uma situação e com poucas chances de mudar, provavelmente não vale a pena.

Considerações finais

O custo de criar código mudou bastante. O custo de gerenciá-lo, não.

Testar, corrigir, proteger e manter as implementações consistentes se torna cada vez mais caro à medida que aumenta a quantidade de código sob sua responsabilidade.

A IA tornou a criação de código incrivelmente barata. Não confunda código barato de gerar com código barato de manter.

Autor: Benjamin Cane
Fonte: ITNEXT