Não queres dizer extinto?
As afirmações de que os engenheiros de software que se recusam a usar modelos de linguagem de grande dimensão vão “ficar para trás” desencadeiam um debate mais amplo sobre o que realmente significa produtividade em programação. Os comentadores contrapõem a velocidade e o volume de geração de código à qualidade a longo prazo, à manutenção, aos testes e ao design, com alguns a relatar ganhos reais de ferramentas assistidas por IA e outros a verem mais bugs, expectativas irrealistas da gestão e pouco benefício líquido. Por trás disto está a ansiedade sobre segurança no emprego, perda de autonomia para plataformas de IA proprietárias e se a abundância de software medíocre impulsionada por IA é uma boa troca para a sociedade.
Âmbito da Discordância Sobre “Ficar para Trás”
- Muitos veem “aqueles que se recusam a usar LLMs vão ficar para trás” como vago, agressivo e implicitamente ameaçador, especialmente em contextos onde os devs não são avaliados pelo volume bruto de produção.
- Outros argumentam que é óbvio: se dois engenheiros de habilidade semelhante diferem 5x na velocidade de entrega devido a ferramentas, o mais lento será visto como tendo baixo desempenho em muitas organizações.
- Alguns relatam casos concretos em que a gestão duplicou as expectativas de velocidade e, na prática, tornou o uso de LLMs obrigatório; outros dizem que as suas empresas não têm qualquer pressão desse tipo.
- Vários participantes criticam a retórica de “adaptar-se ou morrer” como marketing de FOMO ou insegurança, em vez de um argumento fundamentado.
Impacto na Qualidade, Bugs e Testes
- Os entusiastas dizem que os LLMs libertam tempo para testes, tooling, builds reprodutíveis e caça a bugs em código legado; agora conseguem construir ferramentas ad hoc sofisticadas e harnesses de análise que antes nunca teriam sido viáveis.
- Os céticos relatam o oposto: colegas fazem merge de grandes patches gerados por IA e pouco testados, levando a mais bugs e falhas em produção.
- Há a preocupação de que os LLMs amplifiquem um desequilíbrio já existente: criar código desorganizado já é mais rápido do que limpá-lo; tornar toda a gente “duas vezes mais rápida” pode piorar isso.
- Vários observam que desenhar bons testes é intelectualmente difícil; testes gerados automaticamente muitas vezes espelham a implementação em vez do comportamento real.
Onde os LLMs Ajudam Mais vs. Menos
- Amplamente elogiados por: navegar codebases desconhecidas, explicar arquitetura, depurar problemas estranhos, analisar logs, pesquisar, escrever/atualizar testes e fazer prototipagem rápida ou ferramentas internas.
- Há muito menos consenso de que acelerem código de produção que os engenheiros têm de compreender profundamente e manter; o tempo de revisão e compreensão pode anular os ganhos de digitação.
- Uma orientação recorrente: aprende LLMs bem, mas não externalizes o pensamento.
Open vs. Proprietário e Valores Hacker
- Existe forte desconforto com o facto de os modelos-chave de programação estarem atrás de paywalls, centralizados e controlados por grandes empresas; isso é visto como diferente de ferramentas anteriores (compiladores, calculadoras) e em desacordo com uma ética “hacker”.
- Alguns defendem lutar por modelos abertos e acesso universal; outros descartam os LLMs como algo que nem vale a pena defender.
Preocupações Sociais e Culturais Mais Amplas
- Analogias com carros: tecnologia que começa por ser opcional pode tornar-se de facto obrigatória e aumentar a vigilância e o controlo.
- Temores de desvalorização do ofício (VFX, tricô, animação manual) e de developers reduzidos a “revisores ortográficos de IA”.
- Vários dizem que a IA não resolveu problemas da vida real para eles, apenas acrescentou conveniência marginal enquanto consome capital massivo e possivelmente prejudica a cultura e os empregos.