anônimo
252
22/11/2025 15h35
entre na sua conta para poder responder.
eles respondem
anônimo
22/11/2025 15h03
Muito mais importante conhecer os fundamentos de programação pra saber lidar com o tanto de lixo que a IA pode gerar. Ela acelera o desenvolvimento mas não substitui completamente. Um bom dev pode fazer o trabalho de 3 ou 4 pessoas mas a IA não o substitui.
Acho que a revolução da IA em programação é um tiro que vai sair pela culatra. O próprio Uncle Bob tem um ditado que diz "the only way to go fast is to go well" (a única forma de ir rápido é indo bem). A IA tem muitas utilidades, mas o modo como tem sido usada e a finalidade principal para a qual tem sido empregada, de acelerar times no curto prazo, requer validação completa das saídas produzidas, o que não é a prática adotada realmente por quase nenhuma equipe.
Se dev já não tem paciência para ler e entender documentação e corre para colocar a mão em código, imagine ler o código gerado por um agente LLM. Se o prompt for conciso demais, o risco de a IA tomar decisões arbitrárias aumenta, exigindo mais tentativas para acertar o resultado desejado. Se o prompt for detalhado demais, corre-se o risco de extrapolar o limite de tokens da janela de contexto e partes significativas serem ignoradas, ou, no melhor dos casos, em que a IA segue à risca o que foi especificado, a elaboração do prompt requer quase o mesmo trabalho de escrever o código diretamente.
Na prática, o que fazem é testar o código gerado pelo agente e, se julgarem que o comportamento é aceitável, fazer commit e call it a day. Mas absolutamente nada garante que isso não esteja gerando débito técnico cada vez mais impagável. A diferença é que, em vez do "fail fast, fail often", as falhas de design só serão percebidas quando for tarde demais e exigirem esforço significativo de refatoração e adaptação, e um negócio já houver investido tempo significativo na evolução e transformação do produto.
Outro problema é que, à medida que cada vez mais código é gerado por IA em vez de ser escrito por pessoas, as entradas fornecidas para o treinamento de novas IAs tornam-se cada vez mais enviesadas. No fim das contas, um LLM ainda é apenas isso: um gerador estocástico de textos baseado em estimadores e probabilidade, não em validade sintática ou semântica.
Se dev já não tem paciência para ler e entender documentação e corre para colocar a mão em código, imagine ler o código gerado por um agente LLM. Se o prompt for conciso demais, o risco de a IA tomar decisões arbitrárias aumenta, exigindo mais tentativas para acertar o resultado desejado. Se o prompt for detalhado demais, corre-se o risco de extrapolar o limite de tokens da janela de contexto e partes significativas serem ignoradas, ou, no melhor dos casos, em que a IA segue à risca o que foi especificado, a elaboração do prompt requer quase o mesmo trabalho de escrever o código diretamente.
Na prática, o que fazem é testar o código gerado pelo agente e, se julgarem que o comportamento é aceitável, fazer commit e call it a day. Mas absolutamente nada garante que isso não esteja gerando débito técnico cada vez mais impagável. A diferença é que, em vez do "fail fast, fail often", as falhas de design só serão percebidas quando for tarde demais e exigirem esforço significativo de refatoração e adaptação, e um negócio já houver investido tempo significativo na evolução e transformação do produto.
Outro problema é que, à medida que cada vez mais código é gerado por IA em vez de ser escrito por pessoas, as entradas fornecidas para o treinamento de novas IAs tornam-se cada vez mais enviesadas. No fim das contas, um LLM ainda é apenas isso: um gerador estocástico de textos baseado em estimadores e probabilidade, não em validade sintática ou semântica.
