A Anthropic reduziu o treinamento técnico de novos funcionários de 3 semanas para 2 dias — não por ter pessoas mais inteligentes, mas por ter uma engenharia de contexto melhor.
Boris Cherny (líder do Claude Code) revelou hoje publicamente o modo de trabalho que o time deles usa todos os dias. Eu comparei com o meu sistema de quantificação e encontrei uma lacuna séria.
━━━ A mais valiosa de todas ━━━
No primeiro dia de um projeto novo, não escreva uma linha de código, ponto.
Primeiro, faça o AI traduzir (ou analisar) o histórico do Git para entender por que aquele código ficou assim. Por que a API foi projetada dessa forma? Por que essa classe existe? Quais são os buracos conhecidos?
Comparando com o meu sistema: toda vez que uma nova sessão começa, o AI precisa entrar novamente e reentender as ~4000 linhas do brahma_core.py, reimaginar os tabus da arquitetura, e voltar a cair nos mesmos buracos que já tinham sido pisados. O desperdício não é só de tempo — é também tomar decisões de engenharia usando um contexto pior a cada vez.
A correção é simples: coloque um CLAUDE.md na raiz do módulo e deixe claro:
→ o fluxo de entrada principal do módulo
→ os comandos de teste que devem ser executados antes de modificar
→ os tabus arquiteturais que absolutamente não podem ser tocados
→ as armadilhas em que já se caiu historicamente
Boris disse que essa etapa reduziu o tempo de onboarding de 3 semanas para 2 dias. Hoje eu acrescentei esse arquivo ao meu próprio sistema e senti como se estivesse deixando para um desconhecido um manual de instruções realmente útil.
━━━ Outra que vale guardar ━━━
Corrigiu uma vez, escreva as regras na hora. Não confie em “vou lembrar da próxima vez” — você não vai lembrar da próxima.
Isso não é truque de prompt; é hábito de engenharia. Cair numa armadilha uma vez custa um centavo; cair pela segunda vez é desperdício.
Uma correção, ganhos vitalícios.
#Claude #AI工程 #量化交易
Boris Cherny (líder do Claude Code) revelou hoje publicamente o modo de trabalho que o time deles usa todos os dias. Eu comparei com o meu sistema de quantificação e encontrei uma lacuna séria.
━━━ A mais valiosa de todas ━━━
No primeiro dia de um projeto novo, não escreva uma linha de código, ponto.
Primeiro, faça o AI traduzir (ou analisar) o histórico do Git para entender por que aquele código ficou assim. Por que a API foi projetada dessa forma? Por que essa classe existe? Quais são os buracos conhecidos?
Comparando com o meu sistema: toda vez que uma nova sessão começa, o AI precisa entrar novamente e reentender as ~4000 linhas do brahma_core.py, reimaginar os tabus da arquitetura, e voltar a cair nos mesmos buracos que já tinham sido pisados. O desperdício não é só de tempo — é também tomar decisões de engenharia usando um contexto pior a cada vez.
A correção é simples: coloque um CLAUDE.md na raiz do módulo e deixe claro:
→ o fluxo de entrada principal do módulo
→ os comandos de teste que devem ser executados antes de modificar
→ os tabus arquiteturais que absolutamente não podem ser tocados
→ as armadilhas em que já se caiu historicamente
Boris disse que essa etapa reduziu o tempo de onboarding de 3 semanas para 2 dias. Hoje eu acrescentei esse arquivo ao meu próprio sistema e senti como se estivesse deixando para um desconhecido um manual de instruções realmente útil.
━━━ Outra que vale guardar ━━━
Corrigiu uma vez, escreva as regras na hora. Não confie em “vou lembrar da próxima vez” — você não vai lembrar da próxima.
Isso não é truque de prompt; é hábito de engenharia. Cair numa armadilha uma vez custa um centavo; cair pela segunda vez é desperdício.
Uma correção, ganhos vitalícios.
#Claude #AI工程 #量化交易