A primeira tentativa é 95% lixo: a jornada de um Staff Engineer com o Claude Code

 (sanity.io)
24 pontos por GN⁺ 2025-09-03 | 5 comentários | Compartilhar no WhatsApp
  • Um staff engineer compartilha a experiência de testar por 6 semanas um workflow de desenvolvimento com IA usando o Claude Code
  • A forma de pensar na IA como um ‘desenvolvedor júnior que não aprende’ é a chave para uma integração bem-sucedida
  • A primeira tentativa em geral é 95% fracasso, mas vai sendo refinada até virar código útil por meio de iterações
  • O problema da falta de contexto da IA é resolvido com arquivos de contexto por projeto (Claude.md) e integração de ferramentas baseada em MCP
  • O papel do desenvolvedor migra de escrever código para resolver problemas e projetar arquitetura, o que aponta para um novo padrão de produtividade na era do uso de IA

Contexto e abordagem

  • O autor antes escrevia todo o código manualmente, mas recentemente passou a deixar 80% do código com a IA, enquanto ele se concentra em arquitetura, revisão e gestão de desenvolvimento multithread
  • Este texto não segue um tom cor-de-rosa de que "a IA lidera a revolução", e sim compartilha a confusão e a metodologia realista vividas ao integrar IA a um workflow real de desenvolvimento em produção
  • Tratar a IA como um ‘desenvolvedor júnior que não aprende’ é o ponto central para usá-la com sucesso

O processo de mudança de paradigma no desenvolvimento

  • Nos primeiros 5 anos, manteve um estilo de desenvolvimento baseado em livros e documentação de SDK
  • Depois, nos 12 anos seguintes, migrou para o uso de conhecimento coletivo baseado em busca (Google)
  • Nos últimos 18 meses, testou programação assistida por IA com o Cursor
  • Nas 6 semanas mais recentes, viveu uma mudança brusca ao usar o Claude Code para delegação ampla à IA
  • A adaptação ao Claude Code permitiu sentir ganho de produtividade em apenas algumas horas

Workflow real de produção com IA

  • Ao trabalhar em código que vai para produção, ele usa a IA principalmente para “pensar”
  • Gerar código perfeito de uma vez é impossível. A missão do engenheiro é encontrar a melhor solução para o problema
    • Primeira tentativa (95% fracasso): etapa em que a IA acumula contexto do sistema e o desenvolvedor define melhor o problema, mas o código quase todo está errado
    • Segunda tentativa (50% fracasso): a compreensão do contexto melhora e a abordagem fica mais concreta, mas ainda assim metade é inútil
    • Terceira tentativa (código utilizável): após iteração e revisão, surge uma base de código realmente aproveitável e que pode ser melhorada depois
  • Esse processo não é fracasso, mas sim um experimento deliberadamente planejado e um processo de otimização iterativa

O problema do contexto e as soluções

  • A IA não consegue manter memória entre sessões, então existe a limitação de precisar repetir sempre as mesmas explicações
  • Como solução, utiliza-se o arquivo Claude.md para registrar decisões de arquitetura, padrões, links de documentação etc.
  • Com integração via MCP, ela se conecta a Linear, Notion, GitHub, codebase e banco de dados para fornecer contexto automaticamente
    • Linear para contexto de tickets
    • Notion ou Canvas para acesso à documentação
    • Banco de dados não produtivo para verificar a estrutura dos dados
    • GitHub para aproveitar o contexto de PRs anteriores
    Publicidade

Operação com múltiplas instâncias do Claude em paralelo e estratégias centrais

  • Várias instâncias do Claude são operadas em paralelo, com a sensação de gerenciar uma pequena equipe de desenvolvimento que perde a memória todos os dias
  • Foram definidas estratégias como não paralelizar no mesmo domínio de problema, registrar todo o trabalho em ferramentas de gestão de projeto como o Linear e marcar claramente o código alterado manualmente por humanos
  • A IA é usada ativamente não só para escrever código, mas também em code review: encontra rapidamente testes ausentes, bugs óbvios e pontos de melhoria, reduzindo trabalho repetitivo
  • Pela política da empresa dele (Sanity), mesmo o código gerado por IA continua sendo responsabilidade final do engenheiro em termos de qualidade
  • Em um ambiente onde o código gerado por IA e por humanos se mistura, o apego emocional diminui e se torna possível fazer um code review mais crítico e objetivo

Processo de code review em 3 etapas

  • Escrever código é parte do trabalho, mas revisar código também é
  • 1ª revisão: revisão inicial do Claude
    • Detecta lacunas de cobertura de testes e bugs evidentes
    • Economiza tempo da revisão por pares com sugestões de melhoria
  • 2ª revisão: minha revisão
    • Verifica manutenibilidade, arquitetura, lógica de negócio e integração
    • Mesmo sendo código gerado por IA, o engenheiro tem a responsabilidade final
  • 3ª revisão: revisão normal da equipe
    • Ninguém sabe quais partes foram geradas por IA. Aplica-se o mesmo padrão de qualidade
    • É possível fazer uma revisão objetiva sem apego emocional
  • O menor apego emocional ao código escrito pela IA permite uma revisão mais objetiva
Publicidade

Agente acionado por Slack e testes de automação de trabalho

  • Foi feito um piloto de agente integrado ao Slack com o Cursor: teve sucesso em ajustes simples de lógica de negócio, mas falhou em layouts CSS complexos
  • No momento, ainda existem limitações como falta de suporte a pacotes NPM privados, commits sem assinatura e desvio do rastreamento oficial
  • Ainda assim, há expectativa por um cenário futuro em que agentes processem tickets simples e repetitivos durante a noite

Custos e ROI

  • O custo de uso do Claude Code representa um valor considerável pago pela empresa por engenheiro
  • Ainda assim, o investimento gera ganho de produtividade
    • Velocidade de entrega de funcionalidades 2 a 3 vezes maior
    • Capacidade de gerenciar múltiplas frentes de desenvolvimento ao mesmo tempo
    • Fim da necessidade de escrever manualmente código repetitivo e boilerplate
  • No início da adoção de IA, é necessário um orçamento mensal de US$ 1000 a 1500 para engenheiros seniores, com expectativa de melhora na eficiência de custo conforme aumenta a proficiência

Problemas e limitações contínuos do desenvolvimento assistido por IA

  • Problema de aprendizado: a IA não aprende com os próprios erros e repete os mesmos mal-entendidos; a solução é reforçar documentação rica e instruções explícitas
  • Problema de confiança: a IA apresenta código errado com confiança, então a validação é indispensável, especialmente em áreas complexas de gerenciamento de estado, performance e segurança
  • Problema de limite de contexto: codebases grandes ultrapassam a janela de contexto da IA, então é essencial quebrar o problema em partes menores e fornecer contexto claro

A mudança emocional: do código para o problema

  • Abandonar a obsessão pelo código e migrar para um pensamento centrado na resolução de problemas
  • Apagar rapidamente código errado, fazer revisões mais objetivas e reduzir a carga emocional do refactoring = mudanças positivas
  • Há disposição para trocar imediatamente por ferramentas de IA melhores assim que aparecerem
  • O essencial não é o “código em si”, mas o valor do problema que precisa ser resolvido
Publicidade

Conselhos sobre adoção de IA na perspectiva de engenharia

  • 1. Permitir testes com várias soluções de IA: a equipe precisa usar ferramentas diferentes na prática para elevar sua capacidade operacional
  • 2. Aplicar IA primeiro a tarefas repetitivas e simples: assim é possível esperar resultados rápidos
  • 3. Reservar orçamento para tentativa e erro: no primeiro mês, é preciso aceitar a confusão
  • 4. Redesenhar o processo de revisão: fortalecer as verificações de acordo com as características do código gerado por IA
  • 5. Documentar de forma rigorosa: um bom contexto multiplica a produtividade
  • Engenheiros que se adaptarem ao novo workflow com IA perceberão que ganharam uma nova faca afiada na caixa de ferramentas
  • Engenheiros que abraçarem workflows com IA evoluirão para um novo papel, orquestrando múltiplos agentes de IA e focando em arquitetura, revisão e resolução de problemas complexos

Seu próximo passo

  • Escolha uma funcionalidade pequena e bem definida,
  • dê à IA três chances de implementá-la,
  • e revise o resultado como se estivesse orientando um desenvolvedor iniciante
  • E só. Não é preciso uma grande mudança nem reformular processos
  • Basta uma funcionalidade, três tentativas e uma revisão honesta
  • O futuro não é a IA substituindo desenvolvedores
    • e sim desenvolvedores trabalhando mais rápido, criando soluções melhores e usando as melhores ferramentas

Leituras relacionadas

5 comentários

 
helio 2025-09-05

"Com um procedimento tão elaborado, acho melhor a própria pessoa escrever o código diretamente"
 
skageektp 2025-09-05

A postura de um líder de equipe que não delega trabalho aos membros e resolve tudo sozinho kkkkk
 
greenbhj 2025-09-05

Parece que seria assim, mas não é nem um pouco. Nos últimos 6 meses, fiz experimentos iterativos de pequena e grande escala.
 
iolothebard 2025-09-05

Escolha uma funcionalidade pequena e bem definida,
dê à IA três chances de implementar essa funcionalidade,
e revise o resultado como se estivesse orientando um desenvolvedor iniciante
Se ela consegue fazer isso sem mim, é "ganho"… mas se eu preciso estar ali… então é melhor eu mesmo fazer.
 
GN⁺ 2025-09-03
Comentários do Hacker News

  • Fiquei com a impressão de que é importante dar instruções levando em conta os limites cognitivos do agente; por exemplo, em vez de pedir mudanças grandes, é melhor montar um plano e mandar executar em pequenas etapas, testando cada uma no processo. Em etapas complexas, também ajuda pedir que ele escreva código para visualizar o problema e a solução. Se falhar em alguma etapa, o mais eficaz é adicionar logging ao código, salvar os logs, testar e revisar os logs repetidamente para descobrir a causa. Se você fizer o modelo entender, a partir do design do código existente, quais partes precisam ser alteradas, dá para evitar que a IA enfie tudo em um único arquivo. Vi blogs de várias pessoas compartilhando esse tipo de dica e, embora ainda não seja perfeito, pelo menos minha experiência não chega a ter 95% de resultados inúteis.

    • Eu já tento tudo isso e, mesmo assim, na maioria das vezes sai código inútil; e, quando funciona mais ou menos, ainda preciso mexer manualmente para ficar utilizável. Às vezes realmente funciona muito bem e isso empolga, mas, pessoalmente, não sinto um ganho grande de eficiência.
    • Em trabalhos grandes e complexos, sinto que funciona bem instruir: "Não escreva código agora. Vou detalhar cada etapa." Por exemplo, apresentar um esboço por etapas como leitura de entrada, geração de candidatos, pontuação dos candidatos, priorização e ordenação, criação da estrutura de dados de saída, salvamento no banco etc. O Claude organiza essas etapas em uma lista de TODOs e em documentação, o que facilita retomar depois. Na prática, eu já trabalhei uma hora, parei e pedi: “gere o código do estágio concluído e deixe comentários para continuarmos depois”, e foi fácil seguir o trabalho depois.
    • Mesmo usando vários LLMs/agentes por bastante tempo, ainda é difícil obter resultados úteis de forma consistente. Para evitar saídas inúteis, preciso gastar mais energia escrevendo prompts do que gastaria fazendo o trabalho diretamente, e isso de me preocupar com formulação, tom e associações indesejadas acaba gerando uma ansiedade meio boba. Seria ótimo existir uma ferramenta, como se fosse um framework de frontend separado, para gerenciar prompts de LLM: organizar estruturas comuns de prompt ou aplicar boas práticas por padrão, reduzindo bastante a necessidade de pensar nisso ao procurar algo no código, desenhar uma nova funcionalidade ou escrever testes.
    • Se precisa de um procedimento tão elaborado assim, então acho melhor escrever o código você mesmo.
    • Testando AI e vibe coding em um projeto pessoal, percebi que desenvolvimento orientado a testes combina bastante com vibe coding. Recomendo quebrar o problema em unidades pequenas e testáveis, pedir primeiro para a IA escrever os testes unitários e só depois implementar o código real.

  • Acho que já passou da hora de esse tipo de artigo trazer exemplos concretos de tarefas em que "agentes trabalham de forma distribuída", em vez de só refatorações simples ou boilerplate de React. Dizem que a Sanity tem funcionalidades pedidas há muito tempo e que os agentes paralelizam uma parte significativa do trabalho. Mas é difícil acreditar em afirmações do tipo "80% do código foi escrito por um júnior que não aprende".

    • Na minha opinião, a expressão "júnior que não aprende" está errada. O Claude se parece mais com um sênior altamente instruído que só conhece as respostas dos livros, mas sem experiência prática. Tem um conhecimento enciclopédico excelente, mas pouco tato de mundo real. Tenho usado Claude para montar codebases comerciais recentemente, e a maior parte do meu input está focada no “sabor do código” e na definição de sucesso; o código em si é quase descartável.
    • Com tanto código gerado por IA surgindo, ainda assim o open source continua acumulando issues sem solução. Isso é bem irônico.
    • Se mostrassem exemplos reais das tarefas entregues à IA e seus resultados, haveria espaço para questionar expectativas exageradas. Mas, sem exemplos práticos, o que continua aparecendo são só histórias sobre como o Claude Code é incrível.
    • Quando vejo blog técnico de engenheiro já virando vendedor usando expressões como "learnings" em vez de "lessons", sinto que isso vai no sentido oposto da minha trajetória, em que, com mais experiência, passei a depender menos do Google e mais de simplesmente acompanhar a documentação.

  • O autor disse que houve ganho de produtividade, mas também repetiu as limitações normalmente apontadas, então no fim parece que não disse muita coisa de concreta. Tenho certeza de que ninguém vai delegar desenvolvimento de funcionalidades centrais ao Claude Code.

  • Evitar boilerplate é parte do trabalho do desenvolvedor e também uma abstração para facilitar a vida do seu eu do futuro. Se você gerar boilerplate com IA, quando precisar alterar todas as instâncias depois, o inconveniente pode ser ainda maior; e, se esse boilerplate espalhado ficar inconsistente em vários pontos, o problema só cresce.

    • Frameworks e ferramentas já incluem geradores automáticos de boilerplate na maioria dos casos, então fico em dúvida se vale tanto a pena gastar tokens e dinheiro com IA para isso.

  • O interessante é que essa pessoa tenta usar IA para a implementação básica, enquanto eu faço o contrário: sempre construo a base manualmente primeiro. Assim entendo com precisão a estrutura e o funcionamento, e depois deixo para a IA só o boilerplate repetitivo. A IA é boa em seguir padrões, mas é muito fraca em projetar arquitetura.

    • LLMs são muito fracos para planejar arquitetura sustentável e de fácil manutenção. Conforme o código evolui, eles não conseguem refatorar a estrutura adequadamente, e isso talvez seja um limite do entendimento de contexto.

  • O salário-base do desenvolvedor já é alto, então questiono essa ideia de ainda investir mais US$ 1 mil a 1,5 mil por mês em problemas marginais cujo ganho de produtividade talvez nem venha. Pelo menos meu chefe não gostaria disso.

    • Empresas de hardware compram anualmente várias licenças de ferramentas EDA que custam mais do que o salário de um desenvolvedor. Se a produtividade realmente melhorar de forma perceptível, então US$ 1 mil não seria nada.
    • Se o salário do desenvolvedor é tão caro assim, então deixar de investir é que seria irracional. Se US$ 1 mil a 1,5 mil por mês aumentarem a produtividade de forma clara, hesitar nisso é que seria ineficiente. Sob essa ótica, olhar apenas para o custo do investimento em IA é uma visão simplista demais. E, se a IA permitir reduzir o número de desenvolvedores, isso também é economia real.
    • Eu mesmo mal gasto US$ 20 por mês com o AI do IntelliJ Pro, então fui procurar se o Claude era realmente tão caro e aparentemente pode ser sim. De qualquer forma, é fato que a assinatura de IA está entrando no orçamento de alguém, e, assim como a empresa já paga por internet de alta capacidade, o custo com IA também está virando básico.
    • E também vale lembrar que esse preço ainda é, na prática, subsidiado.
    • Estou curioso para ver como as empresas vão mudar daqui para frente. O ponto central, no fim, é por quais critérios os desenvolvedores serão avaliados: se o uso de IA aumenta o risco de prejuízo em avaliação de desempenho/demissões e como provar que o principal responsável pelo resultado foi você, e não o LLM.

  • Não entendi muito bem o modo de uso de MCP (Multi-Channel Processor) citado no texto. O Claude code consegue chamar quase qualquer serviço de terceiros via shell usando curl, gh etc., então usar MCP pode até trazer problemas (por exemplo: o servidor MCP do Linear corta issues quando ficam longas demais, enquanto uma chamada direta à API não tem essa limitação). Fico pensando se deixei passar alguma coisa.

  • A Anthropic publicou uma entrevista com Boris Cherny (criador do Claude Code), compartilhando ideias sobre o futuro do agentic coding e formas de uso do Claude Code: https://youtu.be/iF9iV4xponk

  • Ao ver a menção a um "orçamento de US$ 1000-1500/mês", pensei se não seria um caso de usar apenas chave de API e não conhecer planos mensais como o claude MAX. Por US$ 100-200/mês, me parece suficiente, desde que não seja só para ficar repetindo consultas sem parar.

    • US$ 1 mil-1,5 mil me parece um valor alto demais. Mesmo o plano Max de 20x cobre bastante uso por US$ 200/mês, e o limite é resetado a cada 5 horas. Ainda assim, se mesmo com isso você estoura o limite todos os dias, talvez pagamento por token saia ainda mais caro.

  • Se você pretende usar Claude ou qualquer outro agente, recomendo fortemente fazer logging. Quando você coloca o arquivo de log inteiro na IA, aumenta a chance de conseguir organizar o problema, obter uma resposta ou avançar para a próxima etapa. Logging realmente é tudo.