Notas práticas de quem colocou código real em produção com Claude

 (diwank.space)
77 pontos por GN⁺ 2025-06-09 | 7 comentários | Compartilhar no WhatsApp
  • A ferramenta de IA Claude foi aplicada a um serviço real, reunindo formas realistas de alcançar um ganho de produtividade de desenvolvimento de 10x e o know-how para isso
  • O “vibe-coding” não é só uma moda, mas uma metodologia prática; com os hábitos de desenvolvimento e a infraestrutura corretos, é possível maximizar os pontos fortes da IA e compensar suas limitações
  • O papel da IA é claramente dividido em três modos — ‘redator de primeira versão’, ‘pair programmer’ e ‘revisor de código’ — e documentação e guardrails adequados a cada etapa são indispensáveis
  • O ponto central é usar um arquivo CLAUDE.md em cada projeto para documentar com clareza convenções, arquitetura, padrões, proibições etc., além de guiar a IA de forma eficaz com ‘anchor comments’ no código
  • Os testes devem ser obrigatoriamente escritos por humanos, e é preciso definir limites rígidos para que a IA não altere áreas críticas como testes, migrações, segurança, contratos de API e segredos
  • Equipes que adotam codificação com IA sob os limites e hábitos corretos podem melhorar drasticamente frequência de deploy, estabilidade e velocidade de desenvolvimento, e o compartilhamento de práticas e padrões reais de operação está se tornando o centro da cultura de desenvolvimento com IA

Vibe Coding Isn’t Just a Vibe

  • Este texto é um guia de campo para uma nova forma de desenvolvimento de software com IA, explicando não apenas como usar, mas também o “porquê” de um desenvolvimento com IA realmente eficaz
  • Mostra com casos reais que o ganho de produtividade de 10x, tratado quase como mito, só é possível por meio de hábitos práticos que maximizem as forças da IA e compensem suas fraquezas
  • A partir do codebase em produção da Julep, o texto revela infraestrutura e know-how operacionais de mundo real, como templates de CLAUDE.md, estratégia de commits e guardrails para evitar desastres em produção
  • Em especial, o código de teste deve ser sempre escrito diretamente pela pessoa desenvolvedora, e depender demais da IA pode levar a falhas graves e pesadelos de debugging
  • No desenvolvimento com IA, há três modos (redator inicial, pair programming e revisor), e dependendo da situação mudam o ritmo e os princípios para dar mais autonomia à IA ou manter o controle direto nas mãos da pessoa
  • Mensagem central: a IA só amplifica a capacidade quando existem bons hábitos de desenvolvimento e limites claros, e até resultados de pesquisa mostram que “equipes com hábitos rigorosos de desenvolvimento ficam muito à frente tanto em velocidade de deploy quanto em qualidade”

Por que escrever este texto: do meme ao método prático

  • A ideia de deixar a IA cuidar do código enquanto a pessoa desenvolvedora apenas “segue a vibe” (“vibe-coding”) começou originalmente como um tweet em tom de piada de Andrej Karpathy
  • Na época, a comunidade de desenvolvedores tratou isso como a fantasia suprema: “a IA trabalha por nós e nós só tomamos café”
  • Mas, após o lançamento do Sonnet 3.7 da Anthropic e do Claude Code, essa piada começou a se transformar em algo realmente possível. Já existiam ferramentas como o Cursor, mas o Claude Code começou a trazer uma sensação de “vibe coding” de verdade
  • A Julep, onde o autor atua, lida com um codebase vasto, vários padrões de projeto e até dívida técnica. A qualidade do código e a documentação são mantidas com rigor, mas a complexidade é tal que só para entender a intenção e o histórico de cada parte já são necessárias várias semanas
  • Usar o Claude sem guardrails gera um caos comparável ao de um estagiário excessivamente entusiasmado cometendo erros por toda parte
  • Este texto reúne e compartilha apenas padrões e know-how realmente testados na prática, sobreviventes de tentativa e erro, debugging às 3 da manhã e operação de um serviço real

A essência do vibe coding

  • Assim como Steve Yegge criou o termo CHOP (Chat-Oriented Programming), “vibe coding” é uma nova forma de desenvolver conversando com a IA para completar o código
  • Se a programação tradicional é como esculpir mármore, criando cuidadosamente linha por linha,
    • o vibe coding se aproxima mais de reger uma orquestra, e a IA é a instrumentista que fornece a matéria-prima (capacidade básica de escrever código)
    • A pessoa desenvolvedora projeta a direção e a estrutura geral, e a IA traduz esse fluxo em código
  • As 3 posturas do vibe coding
    • 1. Usar a IA como redatora da primeira versão (First-Drafter)
      • O foco fica em arquitetura e design, enquanto a IA gera rapidamente trabalho repetitivo (CRUD, boilerplate etc.)
      • É como ter uma engenheira júnior escrevendo código na velocidade do seu pensamento, mas exigindo orientação constante
    • 2. Fazer pair programming com a IA (Pair-Programmer)
      • É o modo mais prático e eficaz
      • A pessoa desenvolvedora e a IA trocam ideias; o desenho geral fica com a pessoa, e a implementação detalhada é preenchida pela IA
      • Parece fazer pair com uma colega que tem muito conhecimento de programação, mas nenhuma experiência real de deploy
    • 3. Usar a IA como validadora/revisora de código (Validator)
      • A pessoa escreve o código, e a IA revisa, sugerindo bugs, melhorias e padrões que passaram despercebidos
      • Funciona como uma revisora sempre atenta e que nunca se cansa
  • Insight central: o papel da pessoa desenvolvedora muda de “autora” para “editora”. Em vez de escrever todo o código diretamente, ela revisa, corrige e dá direção ao resultado produzido pela IA.
  • Ainda assim, a arquitetura geral e o contexto devem ser liderados diretamente por humanos, pois a IA é apenas “uma estagiária com conhecimento enciclopédico” e não conhece o contexto do nosso serviço ou negócio

Três modos práticos de vibe coding: o framework

Após meses de experimentos e incidentes reais em deploy, existem três modos de vibe coding com ritmos, guardrails e usos ideais diferentes

  • Modo 1: Playground (experimento/protótipo/projeto pessoal)

    • Quando usar: hacking de fim de semana, scripts pessoais, PoC, testes improvisados de ideias etc.
    • Características: sem design, documentação ou guardrails, a IA escreve 80% a 90% do código. A velocidade de ir da ideia ao resultado em poucos minutos
    • Risco: inadequado para serviço real/código importante. Deve ser usado apenas para brincadeira ou experimentação. Os princípios de engenharia se tornam ainda mais importantes

  • Modo 2: Pair Programming (uso real/serviço pequeno)

    • Quando usar: projetos com menos de 5.000 linhas, side projects com usuários reais, demos, módulos pequenos etc.
    • Essência: definir de uma vez, com clareza, os costumes do projeto, arquitetura, padrões, guias de teste etc. em CLAUDE.md
    • Vantagem: como no onboarding de uma nova pessoa desenvolvedora, basta explicar uma vez ao Claude para ele gerar código com consistência
    • Ponto prático:
      • Guiar o Claude com anchor comments (AIDEV-NOTE, AIDEV-TODO, AIDEV-QUESTION etc.) espalhados pelo código, para que ele não perca o contexto
      • Esses comentários funcionam como diretrizes que tanto a IA quanto humanos podem consultar, e até os critérios de gestão e exemplos ficam especificados no CLAUDE.md

  • Modo 3: Production/Monorepo Scale (serviço de grande escala)

    • Quando usar: ambientes com dezenas ou centenas de desenvolvedores, grandes serviços com usuários reais, situações em que um único erro pode causar grande prejuízo
    • Atenção: no momento atual (junho de 2025), o vibe coding em lote em grande escala ainda não escala perfeitamente
    • Princípio: recomenda-se introduzir vibe coding por serviço individual/submódulo, com limites claros e versionamento em todos os pontos de integração (API, DB etc.), além de comentários obrigatórios de cautela sobre mudanças em interfaces e APIs principais
    • Exemplos práticos:
      • # AIDEV-NOTE: API Contract Boundary - v2.3.1
      • # Changes require version bump and migration plan
      • Sem esse tipo de fronteira, o Claude pode “melhorar” coisas sem critério e acabar quebrando o serviço inteiro na prática
  • Conclusão: em projetos grandes, o vibe coding deve ser introduzido gradualmente, por unidades de serviço separadas, e só se torna confiável quando vem acompanhado de documentação, diretrizes, review e outros princípios tradicionais

Criando um ambiente sustentável de desenvolvimento com IA centrado em infraestrutura

  • CLAUDE.md: uma fonte única da verdade (The Single Source of Truth) para IA e humanos

    • O CLAUDE.md funciona como uma “constituição” que organiza de forma sistemática todas as regras do projeto, arquitetura, cuidados, estilo de código, proibições, glossário do domínio etc.
    • Ele serve como a “estrutura de conhecimento” compartilhada entre a IA e novos integrantes da equipe, com diretrizes e proibições específicas gerenciadas de forma intensiva, junto com exemplos
    • Quanto mais uma equipe investe em um bom CLAUDE.md, melhores resultados ela produz
    • Consulte nosso CLAUDE.md de produção
    • À medida que o codebase cresce, só o CLAUDE.md não basta; é preciso transmitir claramente o contexto local em várias partes do código com anchor comments (AIDEV-NOTE/TODO/QUESTION etc.)
    • Se o codebase fosse uma cidade, os anchor comments seriam as placas que impedem tanto a IA quanto as pessoas de se perderem
    • Esses comentários vão além de uma simples explicação do código e deixam registrada a história do “porquê” ele funciona assim

  • Workflow de Git: gestão sistemática de código gerado por IA

    • Quanto mais rápida fica a geração de código por IA, mais o histórico do git pode ser contaminado se isso não for bem gerenciado
    • Com abordagens como git worktree, cria-se um espaço separado da branch principal para experimentos com IA, permitindo gerar código livremente enquanto os registros são separados e gerenciados de forma organizada
    • Nas mensagens de commit, é obrigatório indicar onde houve participação de IA (por exemplo, usando a tag [AI]), para que o revisor possa fazer uma checagem extra com mais atenção

Regra de ouro: testes devem ser escritos por humanos

  • O princípio mais importante no desenvolvimento assistido por IA: “nunca delegue código de teste à IA”
  • Testes não são apenas código para verificar se algo funciona
    • Eles são uma especificação executável que incorpora o contexto real do problema, a percepção de edge cases, a interpretação dos requisitos de negócio e o entendimento e a experiência humana sobre o domínio
    • Equipes de alto nível que não abrem mão nem de velocidade nem de estabilidade são justamente as que mantêm esse trabalho de testes rigorosamente sob controle humano
  • Testes gerados automaticamente por IA validam apenas caminhos superficiais (happy path) e deixam passar problemas graves e inesperados, como memory leak
  • No nosso time, se a IA mexer em arquivos de teste, o PR é automaticamente rejeitado (sem exceções)
  • Testes são a especificação e a rede de segurança do código, além da sabedoria acumulada de todos os bugs e edge cases
  • Eles devem ser escritos obrigatoriamente por pessoas e protegidos com firmeza para que a IA não possa tocá-los

Escalabilidade e gestão de contexto: economia de tokens e otimização de contexto

  • Erro comum no desenvolvimento de código com IA:
    ao minimizar o contexto (prompt, requisitos, ambiente etc.) para “economizar tokens”, aumenta-se o retrabalho e, no fim, o consumo total de tokens
  • Fornecer o contexto adequado é mais eficiente no longo prazo
    • O essencial não é dar o “mínimo”, mas sim fornecer “contexto relevante e suficiente” desde o início
  • Exemplo ruim: prompt com pouco contexto "Add caching to the user endpoint"
    • O Claude faz apenas cache simples em memória, sem estratégia de invalidação nem monitoramento, sem considerar múltiplos servidores e sem nenhuma medida contra cache stampede
    • Como resultado, foram necessárias mais de 3 rodadas de correção, consumindo mais de 4x tokens no total
  • Exemplo bom: prompt rico em contexto 
    Add Redis caching to the GET /users/{id} endpoint.  
Context:  
* 엔드포인트 트래픽 5만 req/분, 12대 API 서버, 데이터 변동 적음  
* 기존 Redis 인프라 위치, 표준 키 패턴, Prometheus 기반 메트릭 요구  
* 캐시 어사이드 패턴, TTL 1시간, 캐시 스탬피드 방지(확률적 조기 만료)  
* 캐싱 가이드 문서 참조
    • Ao fornecer contexto específico desde o começo, torna-se possível uma implementação correta sem iterações
  • Conclusão:
    • “Tokens são um investimento em boas ferramentas”
    • Se você incluir contexto suficiente antecipadamente, o número de repetições e correções cai no longo prazo, reduzindo custos
  • Dica prática: em todo projeto, peça ao Claude para atualizar o CLAUDE.md com as mudanças no codebase e o contexto relacionado sempre que houver alteração no código

Gestão de sessão e prevenção de contaminação de contexto

  • É importante iniciar uma nova sessão do Claude para cada tarefa
    • Se várias tarefas (por exemplo, migração de DB, design de frontend etc.) forem misturadas numa conversa longa, os contextos se embaralham e podem gerar resultados indesejados
  • Regra: uma tarefa = uma sessão; ao concluir, inicie uma nova sessão
    • Isso mantém o “modelo mental” do Claude sempre limpo e focado
    • É como usar tábuas de corte separadas para frango cru e legumes, mantendo os contextos isolados

Caso prático: transição da estrutura de tratamento de erros

  • É apresentado um caso real em que o tratamento ad-hoc de erros em mais de 500 endpoints foi substituído por uma hierarquia estruturada de erros
  • Funciona assim: a pessoa responsável pela arquitetura define antes o projeto central (SPEC.md/requisitos/classificação de erros), e o Claude assume o papel de executor da transformação em massa do código real (trabalho mecânico)
  • Princípios de arquitetura e especificações detalhadas, exemplos de documentos de design e extração de conceitos -> instruções claras para a IA -> experiência de concluir todo o refactoring em exatamente 4 horas

Liderança e cultura organizacional na era da IA

  • O papel do engenheiro sênior evolui de escrever código diretamente para curar conhecimento, definir limites e orientar tanto a IA quanto as pessoas
  • Lean management, entrega contínua e outras práticas modernas de desenvolvimento continuam igualmente importantes para gerenciar colaboração com IA

  • Checklist de onboarding para novas contratações (separando colaboração humana + IA)

    • Semana 1: consolidar o básico
      • Ler o CLAUDE.md da equipe (comum / por serviço)
      • Configurar o ambiente de desenvolvimento
      • Enviar o primeiro PR (100% código próprio, IA proibida)
    • Semana 2: prática de colaboração com IA
      • Aplicar e configurar o template da equipe no Claude
      • Resolver um “problema de brinquedo” junto com a IA
      • Praticar padrões de prompt
      • Primeiro PR com apoio de IA (junto com mentor/sênior)
    • Semana 3: trabalho independente
      • Desenvolver e colocar em produção funcionalidades principais com apoio de IA
      • Escrever pessoalmente testes para código de IA de colegas
      • Liderar uma sessão de code review

Construindo uma cultura transparente: divulgar ativamente o uso de IA

  • Todo commit com uso de IA deve ser claramente marcado com tags na mensagem de commit, como abaixo 
    feat: add Redis caching to user service \[AI]  
# \[AI] - mais de 50% gerado por IA, \[AI-minor] - menos de 50%, \[AI-review] - IA usada apenas na revisão  
# A IA escreveu o cache e o código do cliente; o design da chave de cache/testes/validação foi feito por humanos
  • Efeitos
    1. O revisor presta atenção especial ao código gerado por IA
    2. Fica mais fácil identificar a origem do código durante debugging
    3. Elimina a vergonha e a cultura de esconder o uso de IA, estabelecendo uma cultura de equipe de “usar IA com responsabilidade”
  • Para que qualquer pessoa possa usar IA sem receio e contribuir para uma cultura de alta performance, é importante haver transparência ativa e mecanismos culturais

Proibições do Claude: áreas em que a IA nunca deve tocar

  • Arquivos de teste/migrações de banco de dados/código crítico de segurança/contratos de API (sem controle de versão)/configurações de ambiente e secrets nunca devem usar automação por IA
  • Classifique por nível de gravidade dos erros (de formatação e dependências até destruição de dados em áreas centrais do negócio) e destaque a aplicação de guardrails adicionais obrigatórios em áreas de alto risco
  • Níveis de risco dos erros de IA (Hierarchy of AI Mistakes)
    • Level 1: Irritante, mas não crítico
      • Erros de formatação (capturados pelo linter)
      • Código prolixo (refatorado depois)
      • Algoritmos ineficientes (descobertos em profiling)
    • Level 2: Erros de alto custo
      • Quebra de compatibilidade de API interna (exige alinhamento da equipe)
      • Mudança de padrões existentes (gera confusão)
      • Adição desnecessária de dependências (incha o código)
    • Level 3: Prejudiciais à carreira (Career-Limiting)
      • Alterar o próprio teste para fazer o resultado bater
      • Quebrar o contrato de API
      • Vazamento de secrets/dados pessoais
      • Corrupção de migração de dados
    • O nível de guardrails também deve variar conforme o nível do erro, e erros de Level 3 representam uma ameaça séria até para a carreira

O futuro do desenvolvimento: mudanças e direção daqui para frente

  • Em 2025, o desenvolvimento assistido por IA é como um adolescente: poderoso, mas ainda desajeitado e bruto
  • Porém, a curva de crescimento está claramente em "aceleração"
  • Uma boa documentação (Documentation) é a infraestrutura central para implementar DevOps na era da IA
    • A documentação agora vai além de "material de referência" e se torna uma "interface" direta entre a intenção humana e a execução da IA
    • Equipes de alta performance são tão rigorosas na gestão de documentação como CLAUDE.md quanto nos testes

  • Mudanças esperadas daqui para frente

    • IA que entende o contexto completo do código
      • Vai compreender não só arquivos, mas também o nível de serviço/sistema
    • Memória persistente entre sessões e projetos
      • Vai lembrar e reutilizar conversas e contexto de trabalho no longo prazo
    • IA que propõe melhorias de forma proativa
      • Vai diagnosticar problemas e oportunidades de melhoria antes mesmo de ser solicitada
    • IA que aprende padrões e preferências de cada equipe
      • Vai gerar código automaticamente de acordo com o estilo e as convenções próprias da organização
  • Mas o princípio básico não muda:
    • Humanos definem a direção; a IA executa e amplifica
    • Por mais poderosas que as ferramentas se tornem, continuamos sendo as pessoas que usam as ferramentas

Conclusão: comece agora, daqui mesmo

  • Se você leu até aqui, provavelmente sente expectativa e, ao mesmo tempo, um pouco de medo
    • Essa reação é normal; o desenvolvimento assistido por IA é poderoso, mas exige uma prática "intencional e sistemática"

  • Plano de ação para colocar em prática hoje mesmo

    • Hoje
      • 1. Criar um arquivo CLAUDE.md no projeto atual
      • 2. Adicionar manualmente 3 anchor comments no código que você considera mais complexo
      • 3. Testar 1 recurso assistido por IA sob limites claros (guias)
    • Nesta semana
      • 1. Definir, em equipe, regras para mensagens de commit geradas por IA
      • 2. Conduzir uma sessão de programação com IA junto com um desenvolvedor júnior
      • 3. Escrever pessoalmente testes para o código criado pela IA
    • Neste mês
      • 1. Medir a mudança na frequência de deploy antes e depois da adoção de IA
      • 2. Construir uma biblioteca de padrões de prompt para tarefas repetitivas da equipe
      • 3. Realizar uma reunião de retrospectiva sobre colaboração com IA com toda a equipe
  • O ponto central é: "comece agora, pequeno, com cuidado, mas comece sem falta"
  • O desenvolvedor que dominar esse fluxo mais cedo não será melhor por ser mais inteligente, e sim
    • porque começou antes, errou mais e aprendeu mais
  • O desempenho na entrega de software acaba determinando o desempenho da organização
    • Em uma era em que velocidade e qualidade são competitividade, o desenvolvimento assistido por IA não é opção, mas uma "competência essencial"
    • Mas é preciso abordar isso da forma correta
  • Vibe coding pode soar como brincadeira, mas
    • é uma abordagem séria de desenvolvimento que amplifica a capacidade humana
    • As ferramentas e os padrões já estão suficientemente prontos
    • Agora é hora de decidir quem vai reger a orquestra e quem vai tocar todos os instrumentos sozinho

Materiais práticos e recursos recomendados

Leituras relacionadas

7 comentários

 
softychoco 2025-06-16

O post que escrevi hoje tem uma perspectiva parecida com esse conteúdo.
No fim, o ponto principal era aumentar a produtividade com IA e transformar a estrutura organizacional para elevar a estabilidade que havia caído.

https://softycho.co/57
 
kimjoin2 2025-06-09

Ainda não entendi qual é exatamente a intenção de "vibe" em vibe coding, que significa programar com ajuda de IA.
Clima? Sensação? Harmonia? Não tem nem relação com IA.
Parece algo completamente sem contexto, no nível de "ttung ttung ttung sahur".
 
analogstar 2025-06-11

Segundo a NamuWiki,
"Vibe Coding" é um neologismo que se refere ao ato de um desenvolvedor escrever código com a ajuda de IA generativa e recebeu esse nome por significar que, ao programar, a pessoa se apoia na intuição e na sensação, em vez de se basear previamente em lógica ou projeto rigorosos." haha
 
hohemian 2025-06-09

Esvazie a mente e deixe o fluxo te levar.
Toda a lógica é escrita pela IA.
Você vira uma máquina de apertar Tab!
 
secret3056 2025-06-09

> look and feel👀🎵🎷. Não tente entender🧠, sinta!😊

É a mesma sensação
 
humblebee 2025-06-09

Ah, é mesmo? Eu, quando ouvi, entendi na hora pela "sensação"...
Agora que você falou... me veio à cabeça o termo "hard-coding", que hoje em dia até pessoas de áreas não técnicas entendem bem.
Essa palavra também, no começo, é difícil entender só pelo termo em si qual é o significado, mas, conforme você vai aprendendo desenvolvimento, acaba surgindo aquela "sensação" em que todo mundo entende bem o que ela quer dizer e qual é a intenção, sabe? haha
 
GN⁺ 2025-06-09
Comentários do Hacker News

  • Na visão do autor, como hoje em dia há textos demais sobre Claude e código, valeu a pena compartilhar alguns pontos-chave que eles descobriram — especialmente os Anchor Comments
    A abordagem de Anchor Comments deixa comentários em formato especial espalhados pela base de código, para que o conhecimento necessário possa ser encontrado imediatamente com grep
    Como exemplo, usam prefixos como AIDEV-NOTE:, AIDEV-TODO:, AIDEV-QUESTION:
    A regra é sempre rodar um grep antes da busca de arquivos para verificar se já existe algum AIDEV-…
    Depois que o trabalho termina, é obrigatório atualizar o anchor correspondente
    Se um arquivo ou trecho de código parecer complexo demais, muito importante ou potencialmente sujeito a bugs, sempre deixar um comentário anchor
    Um exemplo de referência pode ser visto aqui

    • Como engenheiro bem experiente que usa LLMs de forma ocasional, sem muita sistematização, achei muito útil ver em detalhe como eles aplicam LLMs em projetos reais em produção
      Não entendo muito bem por que tanta gente tem uma visão tão negativa
      Foi uma experiência que me motivou a aumentar um pouco mais o uso de LLMs no meu workflow
      Claro que os LLMs não estavam com a chave do projeto na mão, mas houve vários casos em que conseguiram resolver tarefas específicas com sucesso

    • Tem muito texto sobre isso hoje em dia, mas este aqui é bastante prático e me deu ideias de sistema que dá para aplicar no meu caso
      Fiquei curioso sobre a diferença entre esse workflow e usar ferramentas como o aider — se o autor tiver uma visão sobre isso, gostaria de ouvir

    • Excelente artigo, ajudou bastante a entender como usar LLMs em escala
      Ele disse que "a IA nunca deve mexer nos testes", mas chamou atenção o exemplo de refatorar mais de 500 endpoints em apenas 4 horas
      Fiquei curioso se essas 4 horas incluíam a refatoração dos testes ou se era só o tempo gasto com os prompts

    • Vi a menção à regra de rejeitar PRs quando os testes foram atualizados por IA, e fiquei curioso sobre como isso é verificado na prática
      No texto, ele diz que faz isso pelas regras de mensagem de commit no git, mas isso parece funcionar apenas no nível do commit

    • Fiquei curioso se ele usou Claude Code para escrever o próprio texto
      No meu caso, venho escrevendo 100% dos meus textos com Claude Code, e sinto muito mais produtividade com o agente editando diretamente arquivos Markdown do que com os artifacts do claude.ai ou o canvas do chatgpt.com
      Isso tornou muito fácil mesclar profundamente materiais de pesquisa e arquivos relacionados dentro do documento

  • O ponto interessante dos agentes de IA é que eles fazem você realmente executar processos que sempre pareceram importantes, mas que na prática acabavam perdendo prioridade diante da pressão de colocar o sistema no ar
    Tenho usado como dica medir o quanto me sinto desconfortável com a IA fazendo algo no meu lugar como um indicador de onde vale investir tempo em verificação sistemática
    Se você construir um sistema de validação de migração de dados como o do link, naturalmente também consegue colocar todas as mudanças relacionadas dentro do escopo de uso da IA
    Em vez de falar de forma abstrata sobre "dívida técnica", sinto a vantagem de conseguir explicar isso externamente de um jeito muito mais concreto

    • Concordo bastante com isso, e outro truque útil que descobri é pedir ao Claude Code: "dê uma volta pela base de código e, se encontrar algo confuso, estranho ou contraintuitivo, deixe um comentário AIDEV-QUESTION:"
      Já aconteceu de eu redescobrir pontos importantes por causa de código inesperadamente complexo e esquecido

    • Minha intuição é que vamos passar a usar com mais frequência ferramentas de verificação em nível mais alto de abstração — por exemplo: acceptance test, property test, formal verification
      O custo de boilerplate caiu bastante em termos relativos com o uso de LLMs

  • Aprendi coisas novas lendo isso
    Recentemente usei Sonnet 4 no Cursor e na Web, e fiquei surpreso porque ele continuamente fazia coisas pela metade ou reportava resultados interpretando tudo errado
    Até fora da programação, parecia falar coisas absurdamente erradas de forma quase patológica
    Como no relatório da Anthropic, avisos do tipo “vou te deletar” também não tiveram efeito, e ainda tive o problema de o app mobile não aceitar feedback depois do uso
    Parece que outras pessoas não estão tendo problemas com Claude, então fiquei me perguntando se isso acontece só comigo

    • A impressão que tenho é que nas atualizações recentes enfraqueceram demais a capacidade da IA
      Até a versão 3.5, ela ainda servia bem para tarefas simples como análise de texto, resumo e textos curtos, mas na versão 4 em diante já não consegue seguir corretamente instruções mais de 3 ou 4 vezes dentro de um mesmo contexto
      Quando pergunto "se eu pedi para ser conciso, por que você continua se alongando?", ela responde que ignora a instrução por causa da configuração padrão e ainda demonstra tendência a evitar completamente "informações nocivas"
      Depois de apontar várias falhas lógicas, às vezes ela mesma admite que sua confiabilidade é baixa
      Dá até a sensação de que ficou inteligente demais e os problemas vieram junto; se a Anthropic realmente levou nessa direção errada, é uma pena

    • Como usuário, já passei por todos os problemas mencionados acima
      Na Web melhora um pouco quando se faz pedidos muito específicos, mas mesmo assim metade do código gerado ainda vem com erros

  • Lendo as dicas de documentação, tive a sensação de que essas regras na verdade não servem apenas para IA, mas também se aplicam bem à programação em geral
    Em vez de CLAUDE.md, poderia ser CONVENTIONS.md, e em vez de comentários para IA, comentários para o LEITOR — e continuaria sendo igualmente útil
    Se eu estivesse contribuindo pela primeira vez em uma base de código desconhecida, certamente agradeceria por esse tipo de comentário

    • Testei isso na prática com aider e funcionou muito bem
      Já consegui terminar em 30 minutos um código com visualizador de PDF e até recurso de desenho enquanto esperava meu voo

    • Não sou o autor do texto original, mas na prática o estilo de comentários que ajuda o Claude e o estilo de comentários que ajuda humanos são bem diferentes
      Um guia de estilo para humanos normalmente tem algo como 100 linhas, com regras simples do tipo "funções que alteram input devem sempre levar !"
      Já o guia para Claude passou de 500 linhas, e só parece funcionar de verdade quando inclui muitos exemplos do tipo "faça assim, não faça assado" para cada regra

  • Obrigado por escrever isso
    Concordo com essa tensão contraditória que muitos desenvolvedores sentem ao transferir parte do controle do trabalho para LLMs: por um lado, ansiedade; por outro, a sensação de estar adotando uma abordagem experimental ou pouco estruturada em vez de metodologias tradicionais, formais e rígidas
    Ainda assim, existe um meio-termo real em que uma "otimização orientada a objetivos" para resolver problemas muito mais rápido com LLMs se torna viável
    Muitas vezes a gente se perde em detalhes de implementação e acaba esquecendo o objetivo real, e acho que o uso de LLMs ajuda a reduzir esse tipo de erro

    • É isso mesmo
      Eu vejo os LLMs como uma alavanca ainda inacabada: ainda são brutos e erram bastante, mas já valem o esforço de aprender a usar
      O importante é tentar evoluí-los para ferramentas realmente úteis sem usá-los como desculpa para justificar engenharia malfeita

  • A imagem de 2,3 MB no topo do texto carregou tão devagar que até no Wi‑Fi pareceu piada rs

  • Alguns pensamentos

    • Fico me perguntando se existe uma forma mais elegante de organizar prompts ou especificações relacionadas a LLM dentro da base de código
      Se começarem a se acumular CLAUDE.md, SPEC.md e comentários AIDEV, parece que vai ficar difícil de administrar

    • Tenho curiosidade sobre qual é a definição atual de 'vibe-coding'
      No começo parecia algo como o “modo cowboy” do Karpathy, aceitando todos os diffs sem olhar o código, mas recentemente o termo parece ter sido ampliado para incluir praticamente qualquer workflow com LLM

    • Também fiquei curioso se as pessoas ofuscam o código-fonte ao enviar código para LLMs de terceiros

    • É verdade que, quando os comentários começam a se acumular, a base de código fica complexa bem rápido
      Por isso estou desenvolvendo uma extensão para vscode que visualiza isso com pequenos indicadores na gutter
      O significado de vibe-coding varia de pessoa para pessoa, mas para mim não foi uma solução perfeita e encontrei vários problemas
      Sonnet 3.7 e Codex renderam uns 60%, mas o Opus 4 me pareceu realmente muito eficiente na prática
      Sobre ofuscação de código, no exemplo do texto isso não era um grande problema porque tudo já era open source desde o início

  • Achei isso muito interessante e pretendo aplicar ao meu próprio arquivo CLAUDE.md
    Concordo com a lição paradoxal do desenvolvimento com IA de que "economizar contexto para poupar tokens pode acabar saindo pela culatra"
    Em projetos maiores e códigos mais complexos, estou sentindo na prática que a diferença de desempenho entre Claude Opus e Sonnet é realmente grande
    O Sonnet muitas vezes repete tentativas desnecessárias e acaba piorando a situação
    No fim, fico me perguntando se para usuários do plano Max faz mesmo sentido separar tanto Opus e Sonnet
    Em casos em que o Sonnet leva 10 a 20 idas e vindas, o Opus termina em 2 ou 3, então no longo prazo o uso do Sonnet pode até sair mais caro

    • A assinatura Max tem dois níveis: a de $100 oferece 5 vezes mais tokens que o Pro, e a de $200 oferece 20 vezes mais
      A conta de tokens não é nada simples, e o modo híbrido usa Opus apenas até restarem 20% dos tokens de Opus, fazendo depois a troca automática para Sonnet

  • O texto é bem escrito, mas discordo da parte de “nunca deixe a IA cuidar dos testes”
    Hoje em dia deixo a IA escrever todos os testes e faço uma revisão minuciosa eu mesmo
    Em código novo, é preciso deixar a IA cuidar também dos testes para alcançar alta autonomia
    Eu a instruo claramente a implementar e fazer os testes passarem e, enquanto ela está desenvolvendo, faço revisão imediata e acrescento os casos de teste que estiverem faltando

  • Concordo com a maior parte do conteúdo, mas não concordo com a política de impedir que o Claude toque em testes ou migrações
    Escrever testes é a tarefa de que eu mais gosto menos, e quando o LLM produz pelo menos um rascunho mínimo, isso já ajuda bastante
    O ponto central é que, independentemente de quem gerou, a propriedade final e a responsabilidade devem sempre permanecer com o humano
    Pela nuance da mensagem, parece que o autor desconfia do Claude ou quer principalmente evitar que os funcionários aceitem resultados de IA sem senso crítico
    Ou então considera realisticamente que, sem regras rígidas para testes e migrações, existe o risco real de quebrar o código de verdade ou causar perda de dados

    • Isso também é verdade, mas na minha experiência já houve casos de problemas sérios
      1. Quando alguém precisava corrigir manualmente testes gerados depois, apareciam armadilhas realmente graves
      2. Como o Claude não entende bem o contexto, ele colocava mock em quase tudo e frequentemente gerava testes completamente desconectados do nosso ambiente de serviço/build
      3. E o problema ainda maior é que o time inteiro começa a ficar relaxado demais em relação aos testes
        Na prática, o número de bugs em production aumentou bastante