A jornada de muitos profissionais com a programação em IA costuma seguir um padrão semelhante: inicia-se com uma tarefa simples, que gera uma impressão positiva, e logo após, avança-se para um projeto maior, o que resulta em uma admiração ainda maior.

Após essa fase inicial, muitos se veem inclinados a escrever sobre o impacto da IA no mercado de trabalho. Se você conseguiu avançar além desse ponto, parabéns, pois sua compreensão sobre programação em IA supera a de 99% das pessoas.

Engenheiros que utilizam IA para realizar trabalhos sérios, e não apenas projetos ocasionais, também seguem um arco de desenvolvimento previsível. A fascinação pelo potencial da IA leva a questionamentos sobre a possibilidade de tarefas ainda mais complexas. E, talvez, até mesmo aquele refactor que ninguém quer assumir.

Contudo, neste ponto, as dificuldades começam a surgir. Por um lado, a capacidade da IA de entender as solicitações é impressionante. Por outro, surgem erros frustrantes e decisões que claramente contradizem o entendimento mútuo que foi estabelecido.

A frustração com o modelo não é produtiva, e isso leva muitos a internalizar as saídas insatisfatórias, pensando: "Foi culpa minha. Meu prompt estava ruim. Não estava suficientemente especificado."

Com essa mentalidade, muitos passam a redigir especificações detalhadas em plataformas como Obsidian. Contudo, logo se percebe que o desenvolvimento baseado em especificações não é eficaz. Em um ambiente real, documentos de design e especificações são documentos vivos, que evoluem de maneira volátil durante a descoberta e a implementação. Imagine se, em uma empresa, você redigisse um documento de design para uma arquitetura complexa em uma hora, entregasse a um engenheiro de nível médio sem discutir o conteúdo e saísse de férias.

Além disso, um agente não possui a habilidade de adaptar uma especificação ao longo de semanas enquanto constrói componentes inferiores. Muitas vezes, eles tomam decisões iniciais das quais não se desviam mais e, em situações complicadas, simplesmente se rendem, embora isso seja menos comum atualmente, já que os agentes continuam a se esforçar para superar os obstáculos.

O mais preocupante é que o código gerado por esses agentes pode parecer plausível e impressionante durante sua elaboração e apresentação. Ele se apresenta bem em pull requests, pois tanto você quanto o agente estão bem treinados sobre o que constitui um bom pull request.

A verdadeira decepção surge ao abrir o código completo e analisá-lo em detalhes. O que deveria ter sido uma implementação coesa revela-se uma bagunça. "Como isso pôde acontecer? Eu revisei cada linha antes de aceitar!" Essa confusão revela que os agentes escrevem unidades de mudança que parecem boas isoladamente, mas carecem de respeito pela integridade estrutural e pelos padrões vizinhos.

A IA apenas me contou uma boa história. Como a vibração de um romance, o agente apresentou alguns parágrafos que faziam sentido e eram corretos estrutural e sintaticamente. No entanto, ao ler o capítulo completo, a incoerência se torna evidente; não se encaixa no contexto geral do livro.

Após meses lidando com códigos altamente especificados gerados por agentes, decidi: "Não vou entregar isso. Não cobrarei dos usuários por isso e não prometerei proteger os dados deles com esse código."

Estou de volta ao desenvolvimento manual para a maioria das tarefas. Curiosamente, descubro que sou mais rápido, preciso, criativo, produtivo e eficiente do que a IA, quando se considera o custo total e não apenas os tokens de código por hora.

Você pode me seguir no X @atmoio, onde compartilho algumas reflexões sobre programação com agentes. Também é possível assistir à versão em vídeo deste ensaio no YouTube. https://www.youtube-nocookie.com/embed/SKTsNV41DYg?rel=0&autoplay=0&showinfo=0&enablejsapi=0