12 Regras para Manter o Desenvolvimento de IA nos Eixos

Estas regras aplicam a cada tarefa neste projeto a menos que explicitamente sobrescrito. Bias: cautela sobre velocidade em tarefas não triviais.

Assumir Assumções Explicitamente

Mencionar claramente as suas suposições. Perguntar em vez de supor. Recusar-se quando uma abordagem mais simples existe. Parar quando estiver confuso.

Código Mínimo que Soluciona o Problema

Usar apenas o código necessário. Não usar abstrações para código de uso único. Não melhorar o código adjacente. Manter o estilo existente. Não refatorar o código que não está quebrado.

Definir Critérios de Sucesso

Loop até ser verificado. Critérios de sucesso fortes permitem que Claude execute de forma independente.

Regra 5: Usar o Modelo apenas para Decisões Judiciais

Usar para: classificação, redação, resumo, extração. Não usar para: roteamento, tentativas, transformações determinísticas. Se o código pode responder, o código responde.

Regra 6: Não Exceder o Orçamento de Tokens

Per-tarefa: 4,000 tokens. Per-sessão: 30,000 tokens. Se estiver se aproximando do orçamento, resumir e começar do zero. Revelar a violação. Não sobrecarregar silenciosamente.

Regra 7: Revelar Conflitos, Não Averiguar

Se duas padrões contradizem, escolher um (mais recente / mais testado). Explicar por que. Marcar o outro para limpeza.

Regra 9: Testes Verificam Intenção, Não Só o Comportamento

Testes devem codificar por que a intenção do comportamento importa, não só o que ele faz. Um teste que não pode falhar quando a lógica do negócio muda está errado.

Regra 10: Resumir Cada Passo Importante

Resumir o que foi feito, o que foi verificado, o que resta. Não continuar de um estado que você não pode descrever de volta.

Regra 11: Conformidade com Convenções do Código

Conformidade > gosto dentro do código. Se você acredita que uma convenção é prejudicial, superficie-o. Não forneça uma cópia silenciosa.

Regra 12: Testes Unitários Robustos

Testes devem cobrir os casos de teste. Não continuar de um estado que você não pode descrever de volta.

Conclusão

Novo template de regras para garantir que a IA não quebre o código, focando em regras claras e eficazes. Testes unitários robustos e gerenciamento adequado do contexto são essenciais para garantir que a IA não quebre o código.

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

Fonte: https://github.com/multica-ai/andrej-karpathy-skills

Os templates devem ser necessariamente em inglês, não poderiam ser em português?

Dependo do modelo: se ele for um flagship/frontier (chatGPT, Gemini, Claude) ou multilingual, pode colocar no idioma que você quiser.

Caso o modelo entenda português como os da Anthropic, você pode, mas pagará mais caro por isso.

Mais um template? A gente tá caminhando pra uma situação onde passamos mais tempo escrevendo regras pro agente ler do que código pro compilador ler. Sinceramente, a maioria dessas 12 regras resolve-se com duas coisas: Context Window bem gerenciado: Se o agente lê os arquivos errados, ele vai errar independente da regra. Testes Unitários Robustos: Se o teste falha, o agente sabe que errou. Simples assim. Regras como "Think Before Coding" ou "Fail Loud" são comportamentos que deveriam ser intrínsecos ao modelo, não algo que precisamos implorar via markdown. Se o modelo precisa de 12 regras pra não quebrar o build, talvez ele não esteja pronto pra essa tarefa específica ainda. Prefiro um README claro e uma suite de testes cobrindo os edge cases do que um CLAUDE.md de 500 linhas.

Tambem não fico muito animado com um novo template por semana, mas como este que coloquei aqui tem sido citado em diversas situações, achei interessante replicar, uma vez que o harness ainda é uma disciplina em maturação.