Assumi uma tarefa bastante desafiadora. Isso é pegar um código C# corporativo feio e traduzi-lo para Python. Antes de me aprofundar, sinto que preciso dar algumas explicações.

Este projeto C# serve como uma camada de canalização de dados para alguns modelos de aprendizado de máquina. Veja você ouvir os dados, a primeira coisa que deve vir à sua mente é Python. Infelizmente não foi esse o caso e, para melhorar, está usando a extensão .NET para Apache Spark. Migre para Python faz sentido, já que ele usa uma tecnologia bastante fora do padrão para o problema, o que torna bastante difícil a contratação de futuros talentos. E há outros problemas óbvios, comuns também em outras linguagens OOP corporativas, como vários níveis de abstração, herança em todos os lugares, inversão de controle e, novamente, coisas que você não faz no encanamento de dados. E para alimentar ainda mais o diabo, a equipe original de empreiteiros/consultores (porque quem mais usaria C#, do que algum consultor empresarial) vai sair no próximo mês.

Aliás, eu uso o Neovim e uso o Github Copilot há quase dois anos, também o Copilot Chat (tecnicamente ChatGPT) desde que coloquei as mãos na versão de visualização, então não sou de forma alguma um novato total, quando trata de LLMs e código.

A carne!

Qual é a sensação de codificar com Claude 3.5, bem, existem algumas partes boas, ruins e feias. Mas principalmente você não tem ideia do que está acontecendo, mesmo que seja capaz de escrever a mesma funcionalidade do zero.

O bom

Claude 3.5 tende a produzir resultados surpreendentemente corretos, no entanto, às vezes ele tenta ser inteligente e falha, mas você pode orientá-lo para corrigir os problemas. No geral, é um bom companheiro para fazer perguntas e, para mim, como tive um fluxo de trabalho rígido e me esforcei muito para criar um prompt sofisticado com muitos exemplos e casos extremos, fiquei mais do que satisfeito. Eu poderia fazer uma aula de C# e traduzir as partes importantes para Python que exigiam muito poucas instruções adicionais.

O ruim

Eu normalmente consigo escrever código por 12 horas, com pausas ocasionais para ir ao banheiro e para reabastecer meu cantil de água. E sim, não sinto fome quando realmente entro nisso. Com Claude entrei no fluxo, mas depois de cerca de 3 horas me senti morto. Durante essas 3 horas eu produzi muito código e me senti produtivo, mas foi como fazer revisões de código sem parar, pedir alterações e, na maioria das vezes, ou não consultar a documentação para ver se o que foi gerado é válido.

Feio

Se você é um programador, provavelmente está familiarizado até certo ponto com o código que escreveu. Essa familiaridade tende a desaparecer com o tempo, mas se você trabalhar por tempo suficiente com uma base de código, você saberá como lidar. Com o código gerado pelo LLM isso simplesmente não acontece. Eu tinha muito pouca compreensão do que estava acontecendo. Durante dias produzi muito código, revisei cada linha, de vez em quando solicitei algumas alterações, mas no final tinha pouca ou nenhuma ideia do que realmente estava acontecendo. No final, a base de código parecia estranha, algo que não escrevi. E para piorar as coisas, o estilo de código real era inconsistente, você poderia dizer quais arquivos foram escritos no mesmo dia. Parecia que pessoas diferentes os escreveram.

Conclusão

Passei muito tempo revisando, reformulando e ajustando essa abordagem completa de codificação LLM, no entanto, o resultado na maioria das vezes é apenas código, que funciona de alguma forma, mas você não tem ideia de por que ou como. A grande questão é:

Vale a pena acabar com uma base de código à qual você tem pouco apego, que imediatamente parece que você a escreveu há um ano com colegas imaginários.

Só para resumir, senti que produzi mais código, porém a qualidade estava inferior ao normal. Em alguns casos essa qualidade inferior é justificável, principalmente se você não se importa. Mas o que temo é que esteja chegando o momento em que cada base de código se tornará "legada" em tempo recorde.