Seu Agente de IA Não É o Problema, Você É

Muito se tem falado sobre qual é a melhor forma de dirigir ao praticar engenharia agêntica. Algumas pessoas ainda acham frustrante por causa de suas expectativas: elas querem que o agente escreva o código o mais próximo possível (se não idêntico) ao que elas fariam.

Recentemente li o post Taming the Genie: "Like Kent Beck", do próprio Kent Beck. Neste post, ele descreveu um experimento que realizou com o objetivo de fazer um agente de coding AI (que ele chama de "o gênio") programar como ele baseado em algo que lhe foi sugerido: adicionar "like Kent Beck would" aos prompts. Considerando que ele é um desenvolvedor famoso e bem-sucedido, com livros e outras fontes que mostram suas práticas e habilidades de programação, o conjunto de treinamento do modelo que ele está usando provavelmente tem milhares de exemplos de como ele programaria, certo? Não quero estragar o conteúdo do post do Kent, você deveria lê-lo porque é uma leitura muito interessante!

O que chamou minha atenção nesta ideia é que ela arranha uma coceira que eu tenho tido! Aqui está um pouco da história: tenho desenvolvido o backend de uma aplicação, e a maior parte disso foi feita organicamente, com pouco ou nenhum uso de um agente de coding porque eu realmente queria sentir o impacto das minhas decisões, projetar cuidadosamente as abstrações e suas implementações, e assim por diante. Quanto ao frontend desta aplicação, decidi desde o início que queria usar o máximo possível de engenharia agêntica, contanto que eu impusesse duas coisas: 1) o tech stack, e 2) as práticas de arquitetura de software seguidas pelo agente fossem similares ao que eu faria.

Então, mesmo tendo sido palestrante público desde 2015 (com algumas das gravações e slides disponíveis online), e escrevendo posts no blog há um tempo também, eu sabia que não estava nem perto de ser tão conhecido quanto Kent Beck é para conseguir fazer isso como ele, mas ainda queria ensinar o agente a programar como eu.

Queria evitar a frustração de ter que apontar cada decisão tomada pelo agente e dizer "ok, pare, é assim que deveria ser feito", especialmente porque sabia que algumas dessas informações já estavam publicamente disponíveis! E foi aí que me ocorreu.

E se eu ensinasse o agente a partir das gravações das palestras onde falo sobre como escrevo código frontend?

Tentativa 1 – O agente pode aprender de um vídeo?

Minha primeira tentativa foi pegar o vídeo da minha palestra DDD on the frontend no DDD Europe 2024 e perguntar ao agente: ok, você pode aprender deste vídeo e atualizar architecture.md com o que aprendeu dele?

E isto é o que recebi de volta:

⏺ I'm not able to watch or access YouTube videos — I can only work with text, code, and files. I don't have the ability to view, listen to, or extract content from video URLs.

 If you'd like me to learn from the practices in that video, you could:

 1. Share a transcript or summary of the key points
 2. Describe the practices you found valuable
 3. Paste relevant code examples from the video

Quando li pela primeira vez que ele pode trabalhar com arquivos, considerei baixar o vídeo e alimentar o agente com ele, mas as opções que o agente me deu pareciam valer a pena tentar antes disso.

Tentativa 2 – Com que mais posso alimentar o agente?

Tentei descobrir como poderia rapidamente obter e fornecer ao agente a informação que eu queria que fosse extraída do vídeo, então a reuni de 3 fontes:

• Pedi ao Gemini para me dar os principais aprendizados e técnicas do vídeo através do botão Gemini
• Peguei o link para os slides daquela palestra
• Peguei o texto que enviei durante o CFP do DDD Europe 2024 sobre minha palestra

Não parecia muito, mas foi rápido o suficiente para valer a pena tentar.

Para minha surpresa, funcionou ainda melhor do que eu esperava! As partes centrais dos conceitos e práticas que sigo estavam lá, o agente as descreveu, tentou (na maioria das vezes com sucesso) inferir o raciocínio e as implicações das decisões. Parece que funciona!

Bem… mesmo que o raciocínio das minhas práticas estivesse lá, quando o agente tentou gerar código a partir disso, ainda usou práticas que eu não usaria, muitas delas até consideradas anti-padrões pela comunidade frontend. Que pena.

Meu primeiro pensamento foi: "Bem, onde ele aprendeu a programar assim? Certamente não comigo! Espere… NÃO COMIGO!", e então me ocorreu novamente.

Tentativa 3 – Mostre para mim o código ao agente!

Palestras em conferências são muito boas para aprender novos conceitos e práticas, mas sem ver o código real, é difícil saber como isso realmente funciona numa base de código real, e agentes funcionam muito melhor quando recebem exemplos!

Por sorte minha, dei um workshop no Explore DDD 2025 sobre DDD no frontend, e uma palestra no JSConf Chile 2023 sobre arquitetura de software frontend, e para ambos, eu tinha um pequeno repositório de exemplos. Então prontamente (trocadilho não intencional) peguei os links para o código usado no workshop e o repositório de exemplo para a palestra e comandei o agente: misture o conhecimento que você obteve anteriormente com o código fonte destes repositórios e atualize architecture.md.

Ok, AGORA funciona!

Claro, ele não escreveu exatamente como eu faria, mas também não esperaria isso de qualquer pessoa ao trabalhar numa equipe, não queria ter um duplo padrão para código agêntico. Funcionou tão bem quanto eu esperaria como arquiteto de uma equipe.

Tentativa 4 – Podemos colaborar?

Quando se trata de desenvolvimento de software, você está sempre aprendendo e refinando suas técnicas, mudando suas opiniões e práticas conforme aprende como e onde elas funcionam. Desde que apresentei essas palestras, mudei a forma como resolveria alguns desafios, aprendi as limitações de algumas das minhas abordagens, e assim por diante, mas nunca consegui escrever isso. Poderia discutir isso com o agente e colaborar com ele para atualizar a documentação de práticas do projeto?

Para completar minha jornada, disse ao agente: "ok, quero misturar alguns conceitos de interfaces baseadas em tarefas com o que você aprendeu. Não quero que você substitua tudo, encontre as partes onde os conceitos se misturam bem, e onde eles conflitam, vamos discutir".

Sinto que é uma das partes mais perdidas da engenharia agêntica, as pessoas perdem a chance de discutir com o agente e aproveitar todo o processo de aprendizado pelo qual o agente passou, obter insights, feedback, críticas de uma variedade de backgrounds misturados!

No final da discussão, eu tinha arquivos documentando a arquitetura que queria impor no frontend da minha aplicação, com práticas que gostaria de impor, até aquelas que eu não havia documentado antes, e agora todo o processo de engenharia agêntica se tornou muito menos frustrante e confiável para mim.

Você pode estar se perguntando: "Bem, o agente não comete erros de vez em quando?", e eu respondo: "Sim, de forma muito similar a como um humano faria, e resolvo ambos os casos da mesma forma: com comunicação e documentação".

O que podemos aprender disso?

Neste ponto, é claro que pessoas diferentes têm workflows diferentes ao usar agentes de coding. Algumas preferem deixar o agente tomar mais decisões e agir mais como uma pessoa de produto ou arquiteto com uma visão de nível mais alto da aplicação, outras preferem usá-lo apenas em tarefas específicas, outras preferem o meio-termo, a conclusão aqui é que é importante encontrar o que funciona para você. Se pretendemos impor práticas de design e arquitetura de software como faríamos nós mesmos, há uma forma de fazer isso, use todas as informações e exemplos que puder para isso em vez de se sentir frustrado, mesmo se a informação não for pública, peça ao agente para aprender de outros projetos na sua máquina.

Afinal, dificilmente é um problema com os agentes, mas com a forma como os instruímos, ensinamos e esperamos deles.

We want to work with you. Check out our Services page!