Este artigo apareceu originalmente em Médio. Tim O’Brien nos deu permissão para repassar aqui no Radar.
Uma das mudanças mais inesperadas no desenvolvimento de software program atualmente vem da geração de código. Todos sabemos que isso poderia acelerar certos tipos de trabalho, mas o que está ficando claro é que também remodela a economia das bibliotecas, das estruturas e até mesmo da maneira como pensamos sobre o código aberto.
Só para deixar claro, não vejo isso como uma ameaça ao emprego de desenvolvedores. Acho que acabaremos precisando de mais desenvolvedores, e também acho que mais pessoas começarão a se considerar desenvolvedores. Mas acho que existem práticas que estão expirando:
- Compra de software program—Será mais desafiador vender software program, a menos que ele forneça um produto atraente e difícil de reproduzir.
- Adotando estruturas de código aberto—Não me interpretem mal, o código aberto continuará a desempenhar um papel, mas haverá mais e haverá menos projetos em “estágio estrela”.
- Arquitetos de software program—Novamente, não estou dizendo que não teremos arquitetos de software program, mas o processo humano de considerar alternativas de arquitetura e de ter discussões muito caras sobre abstrações já está começando a desaparecer.
Por que você está pagando por isso?
Tomemos como exemplo as bibliotecas pagas. Durante anos, os desenvolvedores pagaram por categorias específicas de software program simplesmente porque resolveram problemas que pareciam tediosos ou complexos de recriar. Um renderizador de tabela com paginação, renderização de células personalizadas e filtragem pode ter justificado uma taxa de licença devido à economia de tempo. Qual desenvolvedor deseja parar e reescrever a lógica de paginação dessa biblioteca de tabelas React?
Ultimamente, comecei a responder “eu”. Em vez de atualizar a licença e pagar uma taxa ridícula por desenvolvedor, por que não pedir a Claude Sonnet para “renderizar este componente com uma tabela HTML que também suporte paginação sob demanda”? A princípio, parece um erro, mas depois você percebe que é mais barato e rápido pedir a um modelo generativo para escrever uma implementação personalizada para aquela tabela — e é mais simples.
A maioria dos desenvolvedores que compra bibliotecas de software program acaba usando um ou dois recursos, enquanto a maior parte da superfície da biblioteca permanece intacta. Apertar o botão e mudar para uma abordagem personalizada mais simples torna sua construção mais limpa. (Sei que alguns de vocês pagam por uma biblioteca de componentes React muito widespread com uma implementação de tabela generalizada que recentemente aumentou os preços. Também sei que alguns de vocês começaram a perguntar: “Eu realmente preciso disso?”)
Se você puder apontar seu IDE para ele e dizer: “Ei, você pode implementar isso em HTML com um JavaScript simples?” e gera código perfeito em cinco minutos. Por que você não faria isso? A próxima questão é: os criadores de bibliotecas começarão a adicionar novas cláusulas legais para prendê-lo? (Minha previsão: é a próxima.)
O fosso em torno de bibliotecas específicas e especializadas continua diminuindo. Se você puder responder “Posso substituir isso?” em cinco minutos e depois substitua-o.
Você precisava daquela biblioteca?
Essa mesma mudança também afeta o código aberto. Muitas das bibliotecas que utilizamos resultaram de esforços comunitários de longo prazo para resolver problemas simples. O registro ilustra bem isso: pacotes como Log4j ou Winston existem porque os desenvolvedores precisavam de registro consistente em todos os projetos. No entanto, a maioria das equipes utiliza apenas uma fração dessa funcionalidade. Hoje em dia, gerar uma biblioteca de log leve com exatamente os níveis e a formatação necessária costuma ser mais fácil.
Embora a adoção de uma biblioteca compartilhada ainda ofereça benefícios de interoperabilidade, a balança pende para soluções personalizadas. Eu só precisava formatar os logs de maneira padrão. Em vez de adicionar uma dependência, escrevemos uma biblioteca interna de 200 linhas. Feito.
Cinco anos atrás, isso poderia parecer loucura. Por que reescrever Winston? Mas quando você vê o nível de complexidade que essas bibliotecas carregam e percebe que Claude Opus pode gerar a mesma biblioteca de registro de acordo com suas especificações exatas em cinco minutos, toda a discussão muda. Novamente, não estou dizendo que você deveria largar tudo e criar sua própria biblioteca de log. Mas observe as 100 dependências que você tem em seu software program – algumas delas adicionam uma complexidade que você nunca usará.
Diga adeus ao “Vamos pensar sobre”
Outra mudança sutil aparece na forma como resolvemos problemas. No passado, um novo requisito significava fazer uma pausa para considerar a arquitetura, as interfaces ou os padrões antes de implementar qualquer coisa. Cada vez mais, delego essa etapa de “pensar” a um modelo. Funciona em paralelo, propondo soluções enquanto avalio e aprimoro. O tempo entre a ideia e a execução continua diminuindo. Em vez de escolher cuidadosamente entre estruturas ou bibliotecas, posso pedir uma implementação personalizada e iterar a partir daí.
Examine isso com cinco anos atrás. Naquela época, você reuniu seus engenheiros e arquitetos mais experientes para debater uma abordagem. Isso ainda acontece, mas hoje com mais frequência você acaba discutindo o resultado de cinco ou seis modelos independentes que já geraram soluções. Você discute resultados de modelos, não ideias para abstrações.
A implicação maior: categorias inteiras de software program podem perder relevância. Passei anos trabalhando em bibliotecas de código aberto como Jakarta Commons – coleções de utilitários que resolveram inúmeros problemas menores. Esses projetos podem não ter mais importância quando os desenvolvedores podem escrever funcionalidades simples sob demanda. Até mesmo as ferramentas de construção enfrentam essa mudança. Maven, por exemplo, certa vez justificou um ecossistema de treinamento e documentação. Mas no futuro, documentar seu sistema de construção de uma forma que um modelo generativo possa entender pode ser mais útil do que ensinar as pessoas como usar o Maven.
O fio comum
O padrão em tudo isso é simples: a geração de software program torna mais difícil justificar o pagamento por soluções pré-embaladas. Tanto as bibliotecas proprietárias quanto as de código aberto perdem valor quando é mais rápido gerar algo personalizado. A automação direta substitui ferramentas e estruturas. Existiam estruturas para capturar código padrão que os modelos generativos agora podem produzir sob demanda.
Como resultado, o futuro poderá conter mais códigos personalizados e menos compromissos para se adequar a sistemas pré-existentes. Resumindo, a geração de código não apenas acelera o desenvolvimento — ela muda fundamentalmente o que vale a pena construir, comprar e manter.