Escrever código ficou barato. O que continua difícil é entender o problema e conseguir defender a própria decisão depois. As seções abaixo mostram como eu transformo isso em rotina: um ciclo de sete etapas e sete princípios, cada um testado num projeto de verdade.
As palavras sublinhadas no texto do site têm uma explicação rápida. Toque nelas.
Tudo que eu leio, assisto ou estudo entra primeiro numa caixa de entrada, sem nenhum tratamento. Ainda não é conhecimento, é só matéria-prima na fila. Se for material de curso, ele só sai dessa caixa depois que eu escrevo um resumo com as minhas palavras. Ler o resumo pronto da máquina dá a sensação de ter aprendido sem ter aprendido.
Clique nos números para percorrer o ciclo.
A parte cara de trabalhar com IA não é o que ela escreve. É o que eu preciso reexplicar antes: o que já foi decidido, qual conceito se aplica, onde o projeto parou. Aqui isso é arquivo versionado, lido na mesma ordem toda sessão. No dia em que eu trocar de assistente, o que ele precisa saber já está escrito.
Um arquivo na raiz define o contrato de operação: que papel o assistente assume, em que ponto ele tem obrigação de me contestar, como traduzir decisão técnica em custo e risco, e onde ele não encosta sem aprovação. Nada disso é escrito para um assistente específico: trocar de ferramenta custa apontar para o mesmo texto, não reescrever o método.
Passado certo ponto, a máquina começa a perder o que foi dito no começo da conversa. Então o assistente abre um índice com uma linha por frente de trabalho, e só abre o arquivo da frente que eu escolher. Carregar tudo "para ter contexto" é o que faz a resposta piorar justamente no trabalho mais longo.
As regras de tratamento de dado não ficam num documento que alguém precisa lembrar de abrir. Elas entram sozinhas quando o assistente toca num arquivo de dados: não usar informação que só existiria depois da previsão, não preencher buraco sem justificar, não deixar dado pessoal vazar. Regra que depende de memória humana não chega ao terceiro mês.
O índice de conceitos não guarda a explicação, guarda quando usar cada um. Uma linha por conceito, no formato "se você está diante disto, leia aquilo". Antes de decidir arquitetura em projeto novo, essa é a primeira consulta: uma leitura curta em vez de abrir sessenta arquivos.
Cada frente aberta tem um arquivo com o próximo passo escrito de forma acionável, não um resumo do que já aconteceu. Encerrar o trabalho atualiza só a frente que foi tocada, então duas sessões em paralelo não se sobrescrevem. É assim que o trabalho passa de uma máquina para a outra sem eu reconstruir contexto de cabeça.
Decisão de arquitetura não óbvia vira registro versionado sem eu pedir. Trabalho não trivial gerado por máquina passa por especificação, revisão do que mudou e trilha de evidência antes de entrar. Antes de propor automação nova, a pergunta é qual sinal barato ela vai monitorar: sem sinal, não entra.
A base não audita só projeto. Ela audita a si mesma: protocolo que não produz nada é apagado, checagem barata roda sem gastar IA, e o agente que decide sobre crédito é conferido por uma função separada, não pelo próprio parecer.
Toda regra que eu escrevo pra mim mesmo entra numa lista. Passados trinta dias sem produzir nenhum artefato, ela vira automação de verdade ou sai da lista. Instrução que depende só de eu lembrar não sobrevive.
prova, na própria baseDos cinco rituais escritos no protocolo cognitivo da base, hoje só um é obrigatório em toda decisão técnica não óbvia: o quê, por quê, como. Os outros quatro ficaram como opcionais, não como obrigação esquecida.
Regra herdada sem revalidar o motivo, pasta redundante, revisão de conceito vencida: isso é sinal barato, que um script resolve sem gastar um token de modelo nenhum.
prova, na própria baseSeis checagens rodam sozinhas no início de cada sessão, todas sem IA. Uma delas trava o próprio commit: se o texto do commit denuncia que foi editado por IA, ele não entra no histórico.
Um agente que decide sobre crédito não pode ser avaliado só pelo parecer que ele escreve. Ele também precisa provar que usou as ferramentas certas antes de decidir.
prova, na própria baseNo projeto de crédito, uma função separada confere se o agente chamou cada ferramenta obrigatória antes do parecer. O próprio código documenta o ponto fraco: se uma ferramenta nova entrar e a lista não for atualizada, a checagem passa calada, sem alarme.
Escolho onde um modelo de linguagem entra no trabalho. Nenhuma resposta dele chega a uma decisão minha sem passar pelas três checagens da abertura, o mesmo diagrama de lá.
Delegar melhora a entrega e piora o aprendizado. O método existe por causa disso.
Então eu trato a parte de executar como commodity, e protejo o que é escasso: entender o problema a fundo, e conseguir auditar a minha própria decisão depois.
Por isso uma ou duas frentes por mês ficam marcadas como proibido usar IA. Não é economia, é o oposto: eu escrevo o código sozinho, de propósito, nas habilidades que quero manter, porque um assistente que sempre acerta é também um assistente que nunca me deixa errar a tempo de aprender com isso.
Antes de treinar qualquer modelo, eu escrevo a regra mais boba que resolve o mesmo problema, em série temporal geralmente "amanhã é igual a hoje". E depois de ver o resultado, não volto para ajustar o experimento até o número melhorar.
Quando eu sou muito rigoroso num ponto (a conta econômica, o método estatístico), fica a sensação de que revisei tudo, e eu paro de olhar a qualidade do dado ou se aquilo é viável. Resposta rápida e bem arrumada sobre um trabalho que devia ser demorado é o sinal para eu insistir: "me diga o que ficou de fora", não "está tudo coberto?".
Antes de construir qualquer coisa que decide sobre um grupo difícil (a zona de dúvida de um modelo, uma fila de casos para revisão manual), eu meço primeiro o acerto máximo possível naquele grupo com o dado que já tenho. Quando você separa os casos difíceis pela incerteza do modelo, está tirando de lado justamente os casos onde as variáveis fortes funcionam. Sobra o quase imprevisível.
Toda premissa com número eu confiro contra o dado que tenho. Se o dado mede uma população diferente da que interessa, eu desfaço a substituição e deixo a função no código marcada como experimento que não deu certo. O que não dá para medir vira premissa declarada, com o aviso à vista.
Erro que eu cometo durante o trabalho eu anoto em uma linha, na hora. Quando fecho um projeto, cada dívida técnica passa por uma triagem: ou é problema só daquele projeto, ou é uma falha de método que vira regra para todos os próximos.
Antes de rodar uma medição ou soltar um agente, eu escrevo o número que espero e o caminho que imagino. Se o resultado vem diferente, eu paro e descubro se o erro foi meu ou da máquina, em vez de engolir a resposta.
Antes de cada pedaço de lógica que importa, o comentário no código diz duas coisas: o que aquilo faz tecnicamente, e qual número, dor ou custo de negócio justifica aquela linha. A meta é um gestor conseguir auditar as regras de negócio lendo só os comentários, sem saber ler o código.