Recomendações para codificação agêntica

• Compartilhamento de casos reais de uso sobre agentic coding
• Usa principalmente o modelo Claude Code Sonnet e prefere delegar o trabalho inteiro à IA em vez de integração com IDE
• A linguagem Go é especialmente recomendada para novos projetos de backend graças à sua estrutura amigável para agentes e à estabilidade do ecossistema
• Velocidade e simplicidade são o núcleo da codificação agêntica, e cache de testes ou um conjunto simples de ferramentas são importantes
• O código deve ser estruturado de forma simples e paralelizável, e escolher o momento certo para refatorar é muito importante para maximizar o desempenho do agente

---

Preface

• O número de desenvolvedores compartilhando experiências recentes com codificação agêntica aumentou rapidamente
• Atualmente uso o modelo Claude Code Sonnet no plano Max (US$ 100/mês)
• O peso da IDE diminuiu; em vez disso, voltei a usar Vim, delego as tarefas ao Claude e apenas verifico o resultado
• Como o ritmo de inovação é muito rápido e o conteúdo deste post pode envelhecer depressa, o foco está em conceitos com maior durabilidade

The Basics

• O comando claude --dangerously-skip-permissions foi configurado com alias como claude-yolo, removendo todas as restrições de permissão
  • Isso pode ser administrado com segurança isolando o ambiente de desenvolvimento em Docker
• Como o Claude lida bem com a maioria das ferramentas básicas, o MCP (Multi Capability Protocol) é usado apenas em casos especiais
  • Ex.: automação de navegador com playwright-mcp
• As ferramentas feitas manualmente são compostas como scripts comuns, mantendo ao máximo uma estrutura de ferramentas simples

Choice Of Language

• Depois de experimentar codificação agêntica em várias linguagens, Go se mostrou o mais ideal para novos projetos de backend
  • Sistema de Context: fornece uma estrutura de dados clara que percorre todo o código, facilitando a passagem explícita de informações para o agente
  • Cache de testes: em comparação com outras linguagens como Rust, a execução de testes e o cache são mais simples, tornando mais eficiente o loop código-teste do agente
  • Simplicidade: a própria simplicidade do Go também funciona a favor do agente
  • Interfaces estruturais: se os métodos de um tipo coincidirem, ele é reconhecido como interface, o que o LLM consegue lidar com facilidade
  • Baixa taxa de mudança no ecossistema: versões duradouras e mudanças explícitas ajudam a reduzir a geração automática de código obsoleto
• Python causa muitos problemas
  • Fixtures, tratamento de async, execução lenta etc. reduzem a eficiência no loop agêntico
• No frontend: Tailwind + React + Tanstack Query/Router + Vite
  • O símbolo $ incluído nos nomes de arquivo do Tanstack Router confunde o agente e causa problemas

Tools, Tools, Tools

• Os critérios para ferramentas são os seguintes
  • Ser rápidas
  • Fornecer mensagens de erro amigáveis
  • Continuar funcionando de forma estável mesmo quando o LLM as usa incorretamente
  • Ser observáveis e fáceis de depurar
• Com base em Makefile, são fornecidos comandos como make dev, make tail-log etc.
  • Para evitar duplicação de estados de execução, há gerenciamento de pid com uma versão fork do shoreman
  • Os logs são gravados tanto em stdout quanto em arquivo, para que o agente possa extrair informações diretamente dos logs
• Ex.: links de verificação de e-mail também são registrados nos logs, permitindo executar o processo de verificação de e-mail por automação de navegador

It's All About Speed

• A maior ineficiência da codificação agêntica está no custo de raciocínio e no uso ineficiente de ferramentas
• A velocidade de resposta das ferramentas é a chave da produtividade
• Quando o agente cria e usa por conta própria ferramentas temporárias, a velocidade de execução/compilação rápida melhora muito a eficiência do trabalho
• Em ambientes lentos, é vantajoso recorrer a alternativas como carregamento dinâmico de módulos (ex.: monitoramento de módulos de arquivo do Sentry e execução automática)
• Os logs devem ser concisos e claros, para otimizar consumo de tokens e velocidade; quando necessário, é útil oferecer uma interface para que o LLM ajuste o nível de log
• É importante projetar o sistema para gerar logs/observabilidade significativos já na etapa de geração de código

Stability and Copy/Paste

• A estabilidade do ecossistema é muito importante para reutilização de código e prevenção de confusão por parte do agente
  • Recomenda-se usar linguagens/frameworks com pouca variação e comportamento previsível, como Go e Flask
• Tenha cuidado com upgrades automáticos de bibliotecas, pois comentários deixados pelo agente ou o fluxo do código podem ser quebrados
• Sempre que possível, recomenda-se a estratégia de escrever o próprio código → minimizar dependências

Write Simple Code

• Agentes lidam melhor com código simples e explícito
• Diretrizes recomendadas
  • Preferir funções com nomes longos e descritivos; escrever mais com funções do que com classes
  • Evitar herança e truques complexos
  • Recomenda-se usar SQL puro; o agente é muito competente em SQL, e isso facilita comparação e rastreamento com os logs
  • Verificações de permissão claras devem aparecer de forma intuitiva no código (não separar em arquivos/configurações à parte)

Make It Parallelizable

• A velocidade de processamento de cada agente individual não é alta, mas a execução paralela pode aumentar a eficiência geral
  • Ex.: copiar checkouts com base no sistema de arquivos
  • É preciso pensar em formas de separar recursos compartilhados como Redis ou banco de dados
  • Ferramenta de exemplo: separação de sessões baseada em Docker com container-use
• Trabalho paralelo baseado em CI e o background agent do Cursor também são ferramentas dignas de atenção

Learn To Refactor

• No modo agêntico, refatorar no momento certo é importante
  • Quando a complexidade aumenta, o agente não consegue mais lidar bem com o código
  • Ex.: antes que classes do Tailwind se espalhem por 50 arquivos, transformá-las em uma biblioteca de componentes
• Refatorar cedo demais ou tarde demais é ineficiente, então é preciso orientar melhorias estruturais no timing adequado

What Next?

• A codificação agêntica está evoluindo rapidamente, e os princípios centrais são “simplicidade, estabilidade, visibilidade e paralelismo”
  • Mesmo que ferramentas e metodologias mudem, esses princípios continuam válidos
• O objetivo não é apenas aumentar a produtividade, mas também buscar melhor qualidade de código
• A qualidade do código escrito por agentes melhorou de forma notável em relação a alguns meses atrás
• Responder com flexibilidade às mudanças e expandir a experiência de programação

[helloppfm]

Eu também ainda só uso IA para perguntar coisas como códigos de teste simples ou exemplos, mas agora continuam surgindo pessoas tentando aplicá-la de forma mais ampla.

Talvez ainda seja cedo, mas em alguns anos isso provavelmente vai se tornar algo natural.

[GN⁺]

Opinião do Hacker News

• Estou experimentando programação agêntica no VS Code Nightly usando Copilot e Claude Sonnet 4 juntos. Mesmo com metade do meu dia tomada por reuniões, o ganho de produtividade é tão grande que ninguém perceberia isso só olhando meu histórico do git. Agora, em vez de pensar em implementações minuciosas, estou mais no nível de refletir se a mudança realmente funciona, se consigo entender este código, como estruturar melhor as coisas para facilitar o entendimento e o que mais posso adicionar ao markdown de convenções de IA para reduzir mal-entendidos do agente. Ontem à noite, deixei com o agente um arquivo que tinha 38 erros do mypy, fui conversar 15 minutos com a família e, quando voltei, ele me apresentou um resumo do que corrigiu e por quê. Houve até discussão sobre uma das mudanças, mas no fim concluí que o agente estava certo. O check do mypy também passou. Agora estou tentando fazer meu time entender o verdadeiro potencial dessa tecnologia, embora ainda haja gente cética e contrária porque IA não é perfeita. Mas, para citar um amigo, "hoje é o pior dia que você e essa tecnologia vão viver daqui para frente", e acho que isso por si só já é prova de inovação

  • Erros de type checker são, na prática, uma das partes em que menos se deveria gastar tempo no trabalho de desenvolvimento, então fico curioso para saber por que isso estava consumindo tanto tempo. Acho que toda discussão sobre uso de IA seria muito mais eficaz se pudéssemos ver coletivamente em que tarefas reais cada pessoa está usando, como no post da Cloudflare

  • Pessoalmente, confio mais no agente para código Rust do que para Python. Em Python, a análise estática não é tão boa quanto clippy ou rust-analyzer, então preciso executar manualmente todos os caminhos do código toda vez

  • Você disse que, mesmo com metade do dia em reuniões, isso não aparece no histórico do git; se eu fosse funcionário da sua empresa, eu teria em mente que em breve esse nível de entrega passaria a ser esperado de forma contínua

  • Tenho curiosidade sobre o workflow. Estou usando Claude Code em projetos pessoais como experimento e também testei o Copilot com conta corporativa no modo agent do VS Code, misturando vários modelos como 3.5, 3.7 Sonnet e 04-mini. Usei em um grande projeto em Go e, tirando a parte de testes, o resultado foi péssimo. Achei que talvez eu estivesse usando a ferramenta errado, então tentei todas as "melhores práticas mais recentes": variar contexto, trocar de modelo, definir regras, melhorar prompts, tudo isso, e mesmo assim não houve melhora

  • Você comentou sobre adicionar mais coisas ao markdown de convenções de IA para reduzir erros do agente, então queria saber se isso é um arquivo que você anexa como contexto em cada tarefa ou se é alguma convenção oficial do VS Code Copilot Agent. E também queria perguntar se você usou alguma referência para definir a estrutura do documento ou se foi algo que você mesmo foi refinando ao longo do tempo com base nos erros recorrentes da IA

• É muito animador perceber que a maior parte das técnicas que tornam a programação agêntica eficiente também aumenta a eficiência da programação humana. Antes havia a preocupação com código tipo "grande bola de lama" compreensível apenas por IA, mas na prática aconteceu o oposto. Código claro ficou ainda mais importante para a produtividade da IA, e isso faz a diferença de produtividade aparecer de forma bem mensurável. Como dá para mostrar numericamente o quanto o Claude funciona bem em cada codebase, discussões sobre se o código está bem estruturado deixam de ser questão de opinião e passam a ter base objetiva

  • A preocupação de que o código viraria uma "bola de lama" existe basicamente desde sempre na programação (veja as palestras do Rich Hickey). As pessoas escolhem o "vamos pelo caminho mais fácil agora" e acabam herdando uma dívida técnica enorme amanhã. Com LLM, também fica mais fácil produzir boilerplate sem sentido. Se a dor diminui, talvez desapareça também a vontade de corrigir isso

  • Também queria deixar registrado o ponto de que "a preocupação de o código se tornar algo que só a IA entende talvez não valha agora, mas não sabemos como será no futuro"

  • Concordo muito com essa parte. Boas mensagens de erro, ferramentas rápidas, ecossistema estável, código simples e sem "mágica", SQL intuitivo — esse sempre foi o ambiente de desenvolvimento dos meus sonhos. Como os agentes trabalham tão rápido, qualquer pequena latência vira algo perceptível, então acho que esse tipo de tecnologia pode elevar o nível da experiência de desenvolvimento como um todo

• Ouço dizer que, ao usar agentes, você acaba sendo naturalmente levado para Go e Tailwind. Como há muito dado de treino, a IA consegue lidar bem com isso. Então também fico preocupado se, num futuro em que todo mundo use essas ferramentas, não ficará mais difícil surgirem novas linguagens, frameworks e bibliotecas. Competir com soluções já estabelecidas pode ficar mais difícil, e comunidades humanas como Stack Overflow podem até desaparecer

  • Não concordo com a preocupação de que novas linguagens ou frameworks deixariam completamente de surgir. LLMs são extremamente fortes em tradução, então, mesmo sem dados de treino, elas conseguem aprender rapidamente olhando a codebase de um framework peculiar mas estruturalmente claro. Já vi isso acontecer com o meu framework C# idiossincrático, que ninguém nunca viu, e ainda assim os LLMs lidaram muito bem. Claro que características muito particulares, como lifetimes em Rust, talvez não sejam assimiladas imediatamente, mas algo simples como Go é absorvido rápido. Talvez no futuro até seja preciso criar novas linguagens já pensando na compatibilidade com LLMs — design, tooling, documentação etc.

  • Essa é uma pergunta realmente importante. Em outras palavras, à medida que a internet for sendo coberta por dados gerados por LLM, a disponibilidade de dados de treino de alta qualidade vai cair, e desenvolvedores mais orientados a LLM talvez sejam atraídos por tecnologias antigas com menos "radiação", como JS/React. No futuro, JavaScript/React pode virar o COBOL do amanhã, só que sem a necessidade de consultores caros, porque a manutenção ficará toda nas mãos dos LLMs. Se quiser evitar a onda de IA, desenvolver uma nova linguagem — especialmente algo excêntrico como Lisp+DSL, que LLM não aprende de imediato — pode ser uma aposta relativamente segura até a era da AGI

  • O ciclo tradicional do stack de software é o seguinte: (1) o stack existente fica complexo ao tentar abraçar todos os nichos, e especialistas passam a proliferar "artotecture" desnecessária; (2) por isso surge um stack novo, muito mais simples e claro, resolvendo melhor a nova tendência, e ele ganha popularidade; (3) com o tempo, esse novo stack também fica pesado pelo mesmo motivo, e o ciclo se repete. Como a expansão de contexto na programação com IA está avançando rápido, acho difícil esse ciclo ser quebrado tão cedo

  • A afirmação de que Go e Tailwind são praticamente impostos na verdade reflete bastante a inclinação pessoal do autor. Só porque o Sonnet tem problemas com a CLI do cargo test não significa que Rust, cargo ou a IA como um todo sejam o problema. Em testes com PHP também acontece de o Junie não usar bem o runner embutido, mas, se você cria um script bin/test-php, ele passa a usá-lo direitinho. Explicitar requisitos em guidelines ajuda, mas a diferença real é essa tendência de insistir nas ferramentas padrão. E, sobre a experiência no Stack Overflow, meu assistente de IA pelo menos não fecha perguntas como duplicadas. As tentativas de curadoria do SO têm seu valor, mas também é fato que afastaram muitos usuários

  • Ontem mesmo pedi ao Claude (usando Zed) para criar um projeto novo em Elixir Phoenix apenas com algumas condições, e ele fez tudo sem problemas. Acabou usando Tailwind no CSS, mas provavelmente porque o próprio Phoenix já configura isso por padrão. Não concordo com a ideia de que a IA empurra você para Go. Quando se pergunta algo sem muito contexto, ela até tende a sugerir Python com frequência, e mesmo com Elixir, cuja comunidade é menor, minha experiência tem sido boa

• Testei por cerca de uma semana Claude Code Sonnet 4.0 com código Rust, mas o resultado ficou abaixo das expectativas (e ainda por cima, usando via Bedrock, o custo foi alto). Ele passa muito tempo no planejamento inicial e, no fim, muitas vezes conclui só metade do que precisava. Queria entender se estou deixando passar alguma coisa

  • Tenho quase a mesma impressão. No modo Edit/Agent do Cursor, as mudanças quase sempre saem certas de primeira, então a eficiência é enorme, mas no ambiente CLI é desconfortável demais. Fico curioso se você usa o Claude Code deixando uma tarefa de 10 a 15 minutos rodando e revisando só o diff, ou se realmente faz code review completo

  • Tive exatamente a mesma experiência. Mesmo saindo deliberadamente à procura de casos de uso em que ele fosse útil, nada funcionava direito, então achei isso muito estranho

  • Não deveria parecer caro. O plano Pro custa 20 dólares por mês e o Max custa entre 100 e 200 dólares, o que ainda sai mais barato do que usar API e acabar gastando mais de mil dólares por mês

• Fiquei feliz em ver contêineres sendo mencionados. Eu participo do dagger/container-use, e no time temos ex-membros da Docker e até o fundador da Docker. Acho que executar agentes em paralelo será um grande ponto de inflexão no avanço da tecnologia, quando conseguirmos fazer isso de forma confiável. Até lá, se você quiser tocar outras coisas enquanto o agente trabalha, ou se estiver preocupado com ele mexer em partes erradas, containerizar o ambiente de desenvolvimento é extremamente útil. O uso de contêineres para isso ainda está no começo, mas está evoluindo muito rápido, e hoje o foco está em melhorar estabilidade, reduzir conflitos de git e fortalecer a interação entre humanos e agentes

• Minha opinião sobre escolha de linguagem é a seguinte: 1) Java é a mais abrangente para LLMs por causa da enorme escala e da antiguidade do dataset disponível como referência (isso não quer dizer necessariamente que seja a mais precisa). 2) Acima de tudo, você deve trabalhar na linguagem que conhece melhor, para conseguir detectar rapidamente quando o LLM errar no raciocínio, cometer erros ou alucinar

  • A opinião de que Java teria o maior e mais antigo dataset claro parece um conselho válido apenas quando o LLM não consegue usar ferramentas para consultar APIs, documentação e código-fonte de terceiros. Se a ferramenta consegue descobrir automaticamente o que usar, então pouco importa qual linguagem você escolhe, desde que o agente consiga ler o código-fonte. Mas concordo totalmente com o segundo ponto: revisão humana cuidadosa continua sendo indispensável, e numa linguagem conhecida é muito mais fácil julgar os erros

  • Por que Java teria o maior dataset? Será que Java é a linguagem com mais projetos open source (talvez por causa de toda a suíte Apache)? Ou isso se deve à documentação muito rica das bibliotecas open source em Java?

  • Sempre achei que Python tivesse o maior dataset. Quando não se dá contexto, a maioria dos LLMs tende a recomendar Python primeiro

• Houve crítica à ideia de que o sistema de context do Go (projetado para passar dados explicitamente ao longo do fluxo de execução) oferece simplicidade para agentes de IA, dizendo que "colocar dados no context.Context, exceto tracing data, é na prática uma má convenção"

  • Concordo. No chromedp (driver headless do Chrome para Go), context.Context é usado como primeiro argumento, mas a estrutura exige que se use um context vindo de uma factory específica, e não apenas context.Background(). O timeout é tratado separadamente com context.WithTimeout, então na prática ele acaba sendo usado quase como um ponteiro void*

  • Não sou especialista em Go, mas na prática muitas bibliotecas colocam no context dados como conexão com banco, configuração, rate limiter e backend de cache, então neste momento isso não me parece um problema tão grande

• Escrever "código simples o suficiente para a IA entender" não era exatamente o ponto de inovação que eu esperava. Também tenho curiosidade sobre como isso entra em conflito com meu texto anterior sobre código feio

  • Esse tipo de escrita de código simples e claro, na prática, sempre ajuda em trabalho em equipe. Existem momentos em que vale a pena escrever algo extremamente focado ou criativo, mas isso é exceção e precisa estar muito ligado ao valor de negócio. Na maior parte do código, a resposta é simplesmente "o que for obviamente claro para qualquer um". O gargalo do desenvolvedor não é digitar, e sim a quantidade de "conceitos" que ele precisa manter na cabeça ao mesmo tempo. Não faça overengineering de interfaces, adie abstrações, permita copiar e colar e composição simples, siga patterns só como estão na documentação oficial e nunca tente ser inteligente demais. O ponto central é que o código deve ser organizado não para ficar bonito, mas para ser claro e simples, e que a parte realmente difícil não é o código em si, e sim o "produto"

• Como o autor escreveu sobre Claude Code, na prática já existem várias alternativas diferentes (OpenCode, goose, Codex, Devin, Cursor background agent etc.). Houve uma pergunta sobre soluções open source + LLM local parecidas com Claude Code

  • No momento, não há exatamente uma solução open source + LLM local que eu recomendaria com entusiasmo. Ainda assim, o OpenCode da SST está evoluindo rápido na parte de UX, e acho que, quando surgirem modelos locais melhores, será fácil encaixá-los ali. O maior problema é que quase não existem bons modelos realmente excelentes em "uso de ferramentas". O motivo de o Sonnet ser surpreendentemente bom é justamente o treinamento focado nisso. Gemini ainda está bem atrás; no fim, parece um problema que será resolvido assim que surgirem modelos melhores

  • No caso do Aider, ele está quase lá, mas deliberadamente não é totalmente agêntico. Ele já consegue executar testes e análise estática automaticamente, corrigir erros de forma automática e até lidar com especificações de projeto inteiro baseadas em lista de tarefas. Hoje existe um limite hardcoded de três iterações de reflexão, mas isso pode ser hackeado para aumentar à vontade, e, se receber self prompting, já vira um agente totalmente automatizado

  • Acho que meu aplicativo, que será lançado em breve, também pode ser uma boa alternativa. Será um download de arquivo único, sem necessidade de instalação, funcionando em Mac, Windows, Linux e Docker. Poderá usar qualquer modelo compatível com a API da OpenAI, inclusive executado localmente, será baseado em navegador e tão confortável quanto Claude Code, além de permitir criar apps de console baseados em comandos. Também será possível abrir diretamente o terminal e conectá-lo ao serviço. Por enquanto está em alpha fechada, mas, se quiser usar, pode me contatar por e-mail

  • Quase todos os dias surge uma nova alternativa (ou tentativa), então espero que em breve exista uma opção "sob medida". Por exemplo, app.build foi lançado recentemente pela equipe do Neon (hoje Databricks) e parece bem promissor

  • O plugin CodeCompanion para Neovim também está evoluindo recentemente para uma direção mais agêntica. Ele já oferece auto-submit loop, ferramentas embutidas e integração com MCP. Não é uma ferramenta CLI independente, mas a vantagem é justamente poder usar imediatamente um ambiente de editor completo, o que é ainda melhor para quem gosta de hackear, customizar ou prefere um editor leve

• 100 a 200 dólares por mês é caro demais para uma IA de geração de código ainda não comprovada. Minha experiência pessoal não foi tão satisfatória, e ainda existe toda a controvérsia ética, o que acaba virando uma barreira de entrada

  • Claude Code pode ser usado com chave de API ou com a assinatura Pro de 20 dólares por mês

  • Recomendo experimentar o Aider no modelo de cobrança por API. Dá para controlar o tamanho do contexto (/clear, /add, /drop) e limitar algo em torno de 25K. Você também pode usar o modelo que quiser (por exemplo, Sonnet 4 ou Gemini 2.5 Pro). Scripts simples geralmente saem por menos de 1 dólar, e mesmo ao criar uma ferramenta bem grande, somando prompt + código + cerca de 100 testes, consegui ficar abaixo de 6 dólares. Quando você se acostumar a programar com IA, aí sim vale migrar para Claude Code, que é mais poderoso, mas pode sair mais caro se você não usar com frequência

  • Com uma assinatura de 20 dólares por um mês, já dá para testar alguns projetos pequenos o suficiente para decidir se vale considerar o plano de 100 dólares. Ou então esperar mais alguns meses e acompanhar relatos de uso real de outras pessoas também pode ser uma boa ideia