Loop engineering é o nome que ficou pra uma ideia simples: em vez de você pedir uma coisa pro assistente e conferir o resultado, você deixa ele repetindo o ciclo sozinho. Ele faz, olha o que saiu, tenta de novo, e só para quando bate uma regra objetiva que você escreveu antes.

A conversa sobre isso nasceu no código, que é onde o padrão é mais fácil de aplicar. O Addy Osmani publicou sobre o tema essa semana e o time do Claude Code publicou a classificação de loops deles. As duas peças explicam bem como disparar o ciclo e como declarar a condição que encerra a execução. E código tem uma sorte que quase nenhum outro material tem: existe teste, existe build, existe uma nota de performance. O agente escreve e o mundo responde se está certo.

Eu apliquei o mesmo padrão num material que não tem nada disso.

o que eu deixei o agente cuidar

Eu mantenho um segundo cérebro, que é o nome bonito pra uma pasta de arquivos de texto onde entra tudo que eu aprendo trabalhando. Toda conversa longa com uma IA que produz alguma conclusão, toda decisão de produto, todo erro que me custou dinheiro, tudo isso vira nota, com a fonte anexada e a data em que aconteceu. Faz quatro meses que eu opero assim, e são quase mil arquivos hoje, entre as notas de assunto e as conversas que deram origem a elas. Tudo isso conectado em toda LLM que eu uso, seja GPT, Claude, desktop ou CLI.

Cada nota tem duas partes: em cima, o que eu sei sobre aquele assunto hoje; embaixo, a lista datada das evidências que sustentam isso. A parte de baixo só cresce e nunca é editada. A parte de cima é reescrita sempre que a de baixo muda.

Isso virou o ativo mais importante que eu tenho, e a razão é o efeito composto. Uma anotação solta serve uma vez. Aqui, quando eu vou decidir alguma coisa, eu não dependo de lembrar: eu pergunto, e o que volta é o que eu já concluí sobre aquilo, com as fontes e com a data. Essa semana me mandaram um artigo sobre um tema que eu achava novo, e em cinco minutos eu vi que o meu próprio sistema já sustentava aquilo com mais evidência do que o artigo trazia. Quatro meses disso é uma vantagem que eu não consigo reconstruir se sumir, porque a matéria-prima foi conversa e trabalho que já passaram.

E aí vem o trabalho chato. A evidência entra toda semana e o resumo lá em cima envelhece, e ninguém vai reler tudo isso pra descobrir quais notas estão desatualizadas. Então eu passei o trabalho pro agente, com acesso aos arquivos e permissão pra agir sozinho. Sempre que eu abro o terminal na pasta, ele escolhe uma nota que parece estar apodrecendo, reescreve o resumo e tenta gravar a mudança.

Foram 88 rodadas em três semanas. Vinte e uma delas eram outro tipo de decisão e oito não chegaram a produzir mudança nenhuma. Sobram 59 tentativas reais de reescrever uma nota, das quais 52 foram reprovadas e 7 passaram.

Uma taxa dessas parece um sistema quebrado. Eu também achei, até sentar pra ler o motivo de cada reprovação.

o que o agente faz quando erra

O primeiro susto foi o formato do erro. Eu esperava alucinação grosseira, do tipo citar um estudo que não existe, e isso é a minoria. Li as reprovações que vieram com o motivo escrito e elas caem em quatro famílias, em ordem de dificuldade de detecção.

Vale dizer antes: nada disso é má-fé. É um modelo otimizando pra deixar o texto bom, e algumas das maneiras de deixar um texto bom passam por afirmar mais do que você pode.

Afirmação sem lastro. O agente insere um fato que não estava em nenhuma evidência disponível. Uma nota minha sobre meios de pagamento ganhou uma explicação sobre Pix Automático e regras do Banco Central, bem escrita e sem uma linha embaixo que a sustentasse. É a família fácil de entender, porque o fato ou tem fonte ou não tem.

Elevação de certeza. Aqui nenhuma palavra é falsa e mesmo assim a nota ficou mentirosa. A evidência dizia que uma medição “reforça” uma hipótese e a nova versão passou a dizer que ela “confirma”. Uma decisão que estava marcada como proposta virou uma decisão concluída e aplicada. Outra nota ganhou um “é o pilar com a base empírica mais forte”, ranking que não existia em lugar nenhum. Cada rodada dessas apaga um qualificador, e vinte rodadas depois você tem um documento que afirma com certeza tudo que entrou como suspeita. É a família mais comum no meu log e a mais difícil de pegar lendo, porque relendo o texto fica melhor.

Fusão de categorias. O agente junta duas coisas que a evidência mantinha separadas. Numa nota sobre desempenho de carrossel eu tinha duas observações distintas: uma sobre o alcance travar num teto, outra sobre a profundidade do conteúdo. A reescrita empacotou as duas numa regra fechada só, que era mais fácil de ler e dizia algo que nenhuma das duas evidências dizia sozinha.

Perda de informação. Ele reescreve melhor e no caminho some com um dado. A versão anterior de uma nota dizia que um projeto “começou manual”, e a versão nova, mais bem escrita, simplesmente não tinha mais essa informação.

As duas primeiras qualquer um imagina. As duas últimas são as que degradam um sistema sem nunca disparar alarme, porque cada passo isolado parece uma melhoria de redação.

quem tem autoridade pra dizer não

Quando o agente termina de reescrever uma nota, ele não grava nada. A versão nova fica esperando, e precisa passar por três portas antes de virar a nota oficial. Cada porta custa mais caro que a anterior, e é por isso que elas vêm nessa ordem.

A primeira porta é um script que eu escrevi, e ele não entende nada do que está lendo. São duas regras burras, que rodam de graça em toda tentativa, antes de qualquer IA ser consultada.

A primeira compara a nota velha com a nova e vai atrás dos números e dos links que existiam antes. Se algum sumiu no caminho, reprovado. O agente tem liberdade total pra reescrever a frase em volta de um dado; o que ele não pode é fazer o dado desaparecer. Cinco tentativas morreram aí.

A segunda cuida das aspas. Toda vez que ele escreve uma frase entre aspas, atribuindo aquilo a alguém, o script vai na conversa original e procura a frase letra por letra. Se não achar do jeitinho que foi escrita, reprovado. Sete tentativas morreram nessa.

E aqui está o detalhe que eu não esperava. Nas primeiras vezes que essa regra reprovou, a frase entre aspas estava certa. O erro estava na frase em volta dela, que trocava quem tinha dito, ou apresentava um palpite do próprio agente como se fosse fala de outra pessoa.

A segunda porta é outro modelo de IA, e essa é a cara. Ele recebe pouca coisa de propósito: só o trecho que mudou e a versão antiga da nota, com uma pergunta única. Essa mudança se sustenta na evidência que já estava aqui? É esse modelo que pega as duas famílias que nenhuma regra burra pegaria, a certeza inflada e as categorias fundidas. Trinta e sete reprovações vieram daqui, incluindo o Pix Automático e o “começou manual”.

A terceira porta ignora o texto e olha o histórico. Duas reprovações seguidas encerram a rodada e o agente para por ali. Se a taxa de reprovação de uma janela maior explodir, ele desliga sozinho. A lógica é que uma reprovação é um erro comum, e várias seguidas significam que o problema saiu do texto e foi parar em quem está escrevendo.

A régua que decide o que vai pra qual porta é uma só: se dá pra responder comparando dois pedaços de texto, vira código. Código custa uma vez e roda pra sempre, então mesmo pegando pouco ele se paga. O modelo caro fica só com o que exige entender significado, que é onde ele é insubstituível e onde ele também erra.

o critério de parada responde outra pergunta

Aqui tem uma confusão que vale desfazer, e ela aparece na ferramenta que a maioria vai usar.

O Claude Code, que é o ambiente de programação por terminal da Anthropic, tem um comando chamado /goal. Você declara o objetivo e um modelo avaliador confere, toda vez que o agente tenta parar, se o critério que você escreveu foi atingido. É comum ler isso como revisão de qualidade. O que esse avaliador faz é comparar a transcrição da conversa com as regras duras que você declarou, sem abrir o resultado pra ver se ficou bom. O próprio Addy sublinha isso no texto dele.

Ou seja, são dois trabalhos. O critério de parada responde “já acabou?” e o verificador responde “o que saiu presta?”. Um loop com critério excelente e sem verificador roda até o fim e entrega lixo no prazo.

Isso também explica por que critério mensurável funciona melhor. “Nota de performance acima de 90 no Lighthouse”, que é a auditoria do Google que dá nota de zero a cem pra uma página, é uma coisa que o mundo responde. “Até a página ficar boa” devolve pro modelo uma decisão que ele vai tomar a favor dele mesmo.

o que isso custa

Taxa de aceite baixa é o preço de rodar sem supervisão, e ela deveria ser baixa mesmo. Eu li os motivos das 52 reprovações e não achei nenhuma que eu quisesse ter deixado passar.

O custo mais chato é outro: o detector também erra, e o meu errou feio. No fim de julho a fila de notas suspeitas não esvaziava nunca, e o motivo era circular. O sinal que marcava uma nota como “precisa de revisão” era disparado pela própria nota de revisão que eu tinha acabado de escrever nela. A checagem estava certa e quem estava errado era o protocolo em volta dela. Nove notas presas nesse laço, e uma noite pra achar.

Só achei porque cada rodada deixa registro em disco com o motivo por escrito. Se você montar um desses, guarde esse log desde o primeiro dia. Ele ensina mais que o resultado aprovado.

onde isso não serve

O padrão inteiro depende de existir alguma referência fora do modelo pra decidir se o resultado está certo: um teste, um número, um comando que roda, ou, no meu caso, a evidência que já estava embaixo da nota. Onde o “pronto” é questão de gosto, como direção visual ou escolha editorial, não tem verificador pra montar, e o loop vira uma máquina de gerar variação com aprovação automática.

E se a sua ideia de verificador é pedir pro mesmo agente reler o que ele escreveu, o resultado é conhecido desde 2023 e continua se replicando em pesquisa nova: ele corrige os outros com facilidade e passa a mão na própria cabeça. Por isso, no meu sistema, toda mudança aceita carrega junto o registro de quem aprovou e com base em qual evidência.

Esse motor vai virar um app de desktop, que eu estou terminando. Ele monta e mantém essa base a partir das suas conversas, conectado no assistente que você já usa. Estou fechando a primeira versão e não vou fazer barulho antes da hora. Se quiser o convite quando abrir, responde esse e-mail com a palavra “cérebro”.

Até a próxima,
Bruno

Nota de processo: o rascunho desse texto foi escrito por um agente lendo o log do sistema que ele descreve, e não pela minha memória do que aconteceu. Depois passou por um modelo de outra família, que achou dois erros meus: a conta dos ciclos não fechava, e eu tinha dado o crédito de duas capturas pra camada errada. Os dois estão corrigidos acima. A edição final é minha. É o mesmo desenho do artigo, aplicado nele mesmo.

P.S. A classificação das falhas e o desenho das três portas estão aqui de propósito, porque é o que eu queria ter lido antes de montar o meu. Montar de verdade, escolher o que vira código, escrever o prompt do verificador e calibrar os limites, é o que eu mostro passo a passo dentro do Protocolo AI, na Codar.me.

O ativo mais valioso que eu construí nos últimos anos é uma pasta de arquivos de texto: uma Wikipédia particular sobre o meu trabalho, que agentes de IA escrevem e mantêm. Se eu perder ela, perco meses de conhecimento, aprendizado e decisões, e praticamente tudo que eu produzo hoje nasce de lá (esse email, inclusive).

Pra você entender por que uma pasta de markdown vale tanto, deixa eu começar com uma pergunta: quanto do que você leu, decidiu e aprendeu nos últimos 6 meses você lembra hoje?

Se você é como eu era, quase nada. A leitura boa evapora em duas semanas, a decisão tomada vira dúvida de novo (”por que mesmo a gente descartou aquela ideia?”), e o app de notas vira um cemitério: você escreve, nunca mais abre, e no fim tá sempre recomeçando do zero.

Eu sei disso porque passei anos tentando resolver com um “segundo cérebro”, que é como se chama um sistema externo que lembra por você. Estudei Zettelkasten a fundo, apliquei, cheguei a dar palestra sobre o método, e não decolou. Caí nas evergreen notes e no site do Andy Matuschak (que continua sendo uma das coisas mais bonitas da internet), assisti uma quantidade embaraçosa de vídeo sobre métodos de nota e testei ferramenta atrás de ferramenta. O gargalo era sempre o mesmo: disciplina pra ingerir as coisas e manter tudo rastreado e atualizado, todo dia, pra sempre.

Quando conheci o blog do Tiago Forte e o método PARA, achei que tinha encontrado a saída. Comprei o livro no lançamento, devorei em 3 dias, apliquei, e dessa vez começou a funcionar. Automatizei um pedaço com o Readwise puxando meus highlights do Kindle direto pro Notion, mas era só um pedaço, o resto continuava dependendo de eu sentar e processar. Meu segundo cérebro nunca chegou nem no potencial mínimo que eu imaginava.

Até que a IA tirou da minha mão a parte que eu nunca sustentei: a disciplina.

Hoje o meu segundo cérebro é aquela Wikipédia particular do começo do texto, e o meu papel encolheu pra uma coisa só, entregar o material. Terminei uma conversa boa com um LLM, passo pro agente, e ele extrai o que importa, arquiva conectado ao que já existe e marca o quanto dá pra confiar em cada informação (hipótese fica marcada como hipótese até fontes independentes confirmarem). Artigo que muda algo no meu trabalho entra do mesmo jeito, decisão de produto fica registrada com o contexto do momento. E a parte que mais gera valor com o tempo são os meus nãos: toda vez que eu recuso uma proposta, o sistema guarda o que foi proposto, que eu recusei e principalmente o porquê, porque os sims a gente documenta fácil, mas são os nãos com o porquê que ensinam o agente a decidir como eu decidiria.

O efeito é que eu nunca mais comecei do zero. Antes de escrever, o agente consulta o que o sistema já sabe sobre o tema, antes de uma decisão ele checa se eu já vetei algo parecido, e quando eu vou construir qualquer coisa, a primeira consulta é sempre lá: dessa pasta saem projetos, features, aulas e conteúdos. Ele cresce enquanto eu trabalho, aprendo e decido. Ele vai se tornando um clone, pois começa a entender como eu penso e decido, automatizando decisões que eu tomaria, e ele acerta muito. Quanto mais informação é ingerida, mais certeiras e automatizadas ficam as próximas decisões.

O melhor de tudo é que eu não preciso mais copiar nada de um lado pro outro, ou depender de um app. Qualquer LLM, em qualquer lugar, Claude Desktop, Claude Code, Chatgpt, Gemini… todos eles enxergam meu segundo cérebro, sabem pesquisar, ingerir infos novas, e f

azem isso sozinhos muitas vezes.

Parece o setup perfeito, né? Eu também achava, até essa semana, quando descobri uma página com cara de fato que era hipótese bem escrita, promovida como se tivesse lastro. Peguei o meu próprio sistema mentindo pra mim com carimbo de verdade, e precisei de um segundo modelo de IA, de outra empresa, pra ver o tamanho real do problema. Essa história merece espaço, então ela fica pra próxima edição.

Até a próxima,

Bruno

P.S. E você, já tentou montar um segundo cérebro? Responde me contando como foi (ou por que desistiu), eu leio tudo.

P.P.S. Esse sistema virou meu laboratório de como agentes constroem e mantêm conhecimento confiável, e tem coisa saindo dele em breve. Se quiser ser avisado quando sair, uma palavra basta: cérebro.

Outro dia eu mandei um diff de webhook de pagamento pro meu pipeline de review. Os testes passaram, o lint passou, o build passou, e na maioria dos times isso bastaria pra mergear.

O meu pipeline não para aí. Depois desse gate, o diff cai num grupo de reviewers de IA que leem o código em paralelo, cada um caçando um tipo diferente de problema (bug, segurança, performance, observabilidade). Foi um desses reviewers que achou uma coisa que nenhum teste cobria. O código tratava bem os erros temporários do banco, mas uma classe de erro tinha ficado fora da lista, e quando ela acontecia o webhook respondia sucesso pro provedor de pagamento sem ter gravado nada. O provedor lia aquele sucesso e parava de reenviar o evento. Pagamento perdido, em silêncio, sem alarme.

Pouco depois o mesmo padrão apareceu disfarçado num segundo diff, e o reviewer pegou de novo. Duas vezes no mesmo mês um teste verde quase me custou dinheiro.

Agora o detalhe que muda a conversa. O modelo que escreveu esses bugs e o modelo que achou esses bugs eram o mesmo. O que mudou entre o erro e a captura foi a estrutura em volta dele.

Essa estrutura é o assunto desta edição, porque é ela que compra o direito de confiar em código que você não leu. Sem ela sobram duas opções ruins, reler tudo que a IA produz e ficar mais lento do que era sozinho, ou mergear no escuro e descobrir o custo em produção.

Essa estrutura tem nome

Harness engineering. O termo apareceu em abril de 2026 num artigo da Birgitta Böckeler, Distinguished Engineer na Thoughtworks e a mesma Birgitta da crítica ao Spec Kit que citei na edição de SDD. Ela deu nome pra algo que muita gente já montava sem vocabulário, que é tudo o que cerca o modelo no seu setup de IA. System prompt, rules, skills, hooks, testes, gates e aqueles reviewers do começo do texto, tudo isso é harness.

A palavra é mais literal do que parece. Harness é arreio, e um arreio existe pra transformar a força bruta do cavalo em trabalho direcionado. Ninguém ara um campo com cavalo solto.

O modelo é o cavalo dessa história. E enquanto o feed elege um cavalo novo por semana, o arreio é a parte do setup que ignora a rotação, o que pra mim define fundamento: algo que você implanta num time hoje e continua colhendo quando o modelo da moda mudar três vezes.

As duas metades

Por dentro, todo harness se divide em duas metades que trabalham em momentos diferentes. A primeira age antes de o agente tocar no código e existe pra orientar, e é onde vivem as rules, as skills, o CLAUDE.md e o linter que devolve erro antes do commit. A Böckeler chama essa metade de guides. A segunda age depois que o agente terminou e existe pra conferir, e é onde vivem os testes, o type check e os agentes de review. Essa metade são os sensors.

Eu demorei pra enxergar que as duas metades formam um fundamento só. Minha tentação era tratar verificação como coisa separada, do tipo valida o output da IA com testes e reviewers e pronto. Só que validar exige um critério, o critério vem das rules, e as rules viram decoração quando ninguém confere se foram seguidas. Cada metade pressupõe a outra, e a Böckeler descreve o que acontece quando falta uma delas: só guides gera agente seguindo manual sem feedback, só sensors gera agente que tropeça e aprende devagar.

Um harness funcional tem as duas metades populadas.

A regra de ouro: o barato roda primeiro

Dentro da metade dos sensors mora a regra mais prática desta edição. Sensors vêm em dois tipos, e a diferença entre eles é custo. O computacional é determinístico, roda em segundos e quase de graça, como lint, type check, build e testes. O inferencial pensa em vez de checar, e pensar custa caro, porque um agente de IA lendo seu diff leva minutos e consome tokens.

A regra que organiza os dois tipos, a Böckeler chama de keep quality left. O barato roda primeiro, e o caro só entra se o barato passou, porque gastar review de LLM num diff que nem compila é queimar dinheiro à toa.

Foi essa cascata que pegou o bug do pagamento lá do começo. O gate barato aprovou tudo o que sabia checar, e sobrou pra camada cara exatamente o tipo de pergunta que só leitura semântica responde. Teste verde garante que o código roda. Se ele faz a coisa certa, quem responde é a outra camada.

Quatro harnesses, as mesmas escolhas

Uma pesquisa da Arize foi olhar o código-fonte de quatro harnesses de mercado (Claude Code, Letta, Pi e OpenClaw) atrás do que eles tinham em comum, e a pesquisadora, Aparna Dhinakaran, documentou seis padrões presentes nos quatro, entre eles: 1) um teto fixo de leitura de arquivo, 2) isolamento de subagents, 3) compactação de contexto por threshold e 4) medição contínua de pressão de contexto. Quatro times, nenhuma coordenação, as mesmas escolhas.

A frase que fecha o estudo dela merece ficar inteira:

50 anos de computação ensinaram que a melhor memory management é a invisível pra camada acima. Agent harnesses estão indo na mesma direção.

O teste do fundamento

No fim sobra o teste que separa fundamento de ferramenta. Troca o modelo do seu setup amanhã e observa o que sobrevive. As rules continuam dizendo o que é correto, os testes continuam validando, os reviewers continuam lendo diff. O nome dos arquivos muda conforme a ferramenta, de CLAUDE.md pra .cursorrules pra AGENTS.md pra o que mais inventarem, mas externalizar comportamento em artefato versionado sobrevive a todas as trocas (pelo menos por enquanto).

Essa edição fecha um trio que começou lá atrás: a da atenção em U era sobre o que o modelo vê (context engineering), a do Spec Kit sobre a fonte de verdade (spec-driven development), e essa sobre o que cerca o modelo, a metade que orienta e a metade que valida.

Na próxima edição eu puxo o fio que essa deixou armado: por que eu não leio mais código, nem PR, e quando ainda faz sentido ler.

--

Bruno Bertolini

P.S. Se quiser começar um harness hoje, começa pequeno: um arquivo de rules com os 3 níveis da edição de SDD (Always, Ask First, Never) e um gate que roda lint e teste antes de qualquer review. O resto cresce a partir das falhas, porque toda vez que o agente erra a mesma coisa duas vezes, aquilo vira regra ou vira teste.

O passo a passo de montar o harness inteiro (rules, skills, pipeline de reviewers) vai dentro do Protocolo AI, o curso que estou montando na Codar.me.

No começo deste ano, eu estava falido. Uma série de investimentos malsucedidos me deixaram com 3 meses de reserva de emergência.

Mas eu tinha dois planos, e compartilhei os dois no Instagram. O plano A era o óbvio: voltar pro mercado de trabalho. O plano B era construir um SaaS, mesmo sem saber ainda qual.

Nunca precisei buscar emprego, eles sempre vieram do meu networking ou de indicação, famoso QI. Pela primeira vez em 20 anos, fui atrás de emprego do jeito convencional. Dessa vez eu fui mandar currículo como todo mundo. Em parte por vergonha de ter quebrado. Em parte por teimosia de querer empreender de novo e “não querer" arrumar um emprego. Era uma sabotagem, eu sei.

Foi o plano A que fez o plano B brilhar. Correndo atrás de vaga, ficou claro o que valia a pena construir. Botei a IA pra trabalhar e em 3 dias o produto estava no ar.

No dia 03 de fevereiro, a Karvi (na época, DevProfile) faturava R$ 0. No dia 92, tinha somado R$ 100k. Bem mais rápido do que eu esperava. Sozinho, sem sócio, sem time, sem investidor.

Eu sei como isso soa: mais um print de “fiz um SaaS em 3 dias com IA”. Então deixa eu contar a parte que não cabe no print.

20 anos em 3 dias

Os “3 dias” são verdade. Mas eles montaram em cima de 20 anos que não aparecem no print.

Eu não comecei do zero. A base eu já tinha de outros produtos meus no ar: login, pagamento, o gateway de IA, tudo testado em produção. Os 3 dias foram pra construir o que era novo, não pra refazer o que eu já tinha resolvido dez vezes.

Eu sei dirigir a IA. Largada sozinha, ela te entrega um protótipo bonito que cai na primeira esquina. Quando ela me dava o caminho complicado, eu jogava fora e mandava simplificar. Quando ela queria sair arquitetando, eu parava e validava com dado real antes. Vinte anos viraram isso: saber o que pedir e farejar quando a resposta veio torta.

E sei o que não construir. Metade da velocidade é cortar. A feature que parece óbvia mas não move ponteiro, a integração que todo mundo colaria só porque dá, o atalho que cobra juros lá na frente: disse não pra todas. Isso não vem no tutorial, vem de ter errado por muito tempo.

E mesmo com 20 anos nas costas, os 3 dias foram só o pontapé. Vieram três meses de caverna, 18 horas por dia, olhando número e ajustando o produto. Sem fim de semana, sem muito descanso.

A ideia que eu não tive que procurar

Eu não achei a ideia, eu era o cliente.

Buscando emprego, esbarrei na minha própria dor: meu LinkedIn estava abandonado. Largado, sem graça, sem dizer nada do que eu sabia fazer, bem na hora em que era ele que ia me abrir ou fechar portas.

A maioria dos devs faz o contrário: passa meses caçando “a ideia genial”, um problema que nem vive. Eu não precisei de pesquisa de mercado pra saber que aquilo valia: eu mesmo pagaria pra alguém resolver se eu não soubesse. Eu ajudei, por anos, muitos alunos da Codar.me a resolver isso também.

E essa é a parte que a IA não faz por você. Ela escreve o código em horas. Mas qual problema vale a pena resolver, isso ela não sabe, quem sabe é quem tá vivendo ele.

Lançar feio no dia 3

Com a dor certa em mãos, o próximo erro seria sumir seis meses caprichando antes de mostrar pra alguém. Isso tem nome: Build Trap. Você se convence de que falta “só mais uma feature”, e o tempo evapora. No fim, o produto tá lindo e ninguém usa.

Lancei no dia 3. Feio, incompleto, com vergonha de mostrar, sem pagamento por pix, só cartão. No primeiro dia, entraram R$ 2.500.

E não estava nem perto de pronto. Mas feature não é progresso, progresso é alguém usando seu app e tirando dinheiro do bolso. Cada dia que você segura o lançamento é mais um dia de achismo não testado.

O mercado corrige o que você não vê

Tem uma frase que eu repito: nenhum projeto sobrevive ao primeiro contato com o usuário. Você acha que sabe o que as pessoas querem, até elas botarem a mão no produto.

Por isso instrumentei tudo desde os primeiros dias, antes de ter volume pra medir. Eu precisava ver o que as pessoas faziam de verdade no produto. O que eu imaginava sozinho quase nunca batia.

Foi assim que achei o vazamento. O faturamento total subia e parecia ótimo, mas a conversão por device contava outra história: no desktop a pessoa convertia bem (16-18%), no mobile bem menos, menos de 5%. Eu calculei que deixei de ganhar R$ 16k nos dois primeiros meses. Eu estava pagando pra trazer gente boa e travando ela na porta.

Então, arrumei o onboarding no mobile, só isso. A segunda metade dos R$ 100k entrou na metade do tempo da primeira.

O que eu levo dos primeiros 100k

Plano B virou plano A. De falido a R$ 100k em 92 dias, sozinho.

Se você é dev e tira uma coisa daqui, que seja essa: a IA não escolhe a sua dor, não lança no seu lugar, e não lê o que o mercado te responde.

Constrói o que você mesmo precisa. Lança antes de achar que está pronto, e deixa o mercado te corrigir, que o resto, a IA acelera.

Os R$ 100k já ficaram pra trás enquanto eu escrevia isto, e a régua já se moveu de novo.

Mas tem uma armadilha em deixar a IA preencher os espaços por você: sem os teus fatos, ela não trava. Inventa o que é mais provável (essa é a natureza dela) e escreve com a confiança de um especialista, mesmo errando feio. Foi isso que me fez construir a Karvi de um jeito bem específico. Mas essa história fica pra próxima.

Até a próxima, Bruno

P.S: Tá travado em qual problema resolver, ou com medo de lançar antes de estar pronto? Me responde esse e-mail ou comenta aqui a tua dúvida. Eu leio todas, e as melhores podem virar assunto de alguma edição.

No texto sobre a Teoria da convergência eu terminei com uma frase que ficou na minha cabeça por dias.

A convergência é inevitável. A paciência com quem ainda não convergiu é uma escolha.

Escrevi aquilo como fechamento. Ficou bonito, fazia sentido. E segui em frente.

Dias depois, a vida resolveu testar a frase.

Fiz uma pergunta pública no X sobre um assunto que eu não domino. Uma pergunta simples, sem pretensão. E a reação de alguém me lembrou que escrever sobre paciência é fácil. Praticar, no calor do momento, é outra coisa.

Não vou contar o caso. Não importa quem disse o quê. O que importa é o que eu senti e o que eu fiz com isso. Porque essa é a parte que ninguém te ensina.

Quando os mapas se encontram

Em A Construção da Conciência, primeiro texto desta série, falei sobre o fog of war. Sobre como o mapa de cada pessoa tem um tamanho diferente, e como a maioria dos conflitos nasce do fato de que cada um só enxerga o pedaço que já descobriu.

Na Teoria da Convergência Cognitiva, falei sobre a estrada em perspectiva. Sobre como no começo todo mundo parece distante, e como a convergência só acontece quando você acumula cicatrizes suficientes pra fechar portas suficientes.

Essa terceira parte é sobre o que acontece no meio. Quando um mapa expandido encontra um que ainda não expandiu. Quando a pessoa do outro lado não vê o que você vê. E quando, em vez de curiosidade, o que vem é hostilidade.

Isso acontece o tempo todo pra quem constrói em público. Você faz uma pergunta porque não sabe algo, e alguém usa isso como prova de que você não deveria estar onde está. Você mostra vulnerabilidade, e alguém interpreta como fraqueza. Você pede ajuda, e a resposta é ataque.

O impulso

O primeiro impulso é sempre o mesmo. Aquele calor no peito. A vontade de abrir o currículo, listar tudo que você já fez, e provar que a pessoa está errada.

Eu já cedi a esse impulso mais de uma vez. Nunca, nenhuma vez, terminou bem.

E agora eu sei por quê. Uma meta-análise recente com mais de 250 mil participantes analisou a relação entre regulação emocional e agressividade. A conclusão: estratégias adaptativas (pausar, reinterpretar, escolher a resposta) estão associadas a menos agressão. Estratégias disfuncionais (reagir de impulso, ruminar) estão associadas a mais agressão, e de forma mais intensa. O impulso de revidar não é só ineficaz, ele amplifica o conflito. A parte difícil é que no momento do conflito, o impulso vem primeiro, a estratégia vem depois, se você treinou.

Então ao longo dos anos eu fui desenvolvendo um reflexo. Não é natural, preciso praticar toda vez.

Texto não transmite emoção

Primeiro: releio tudo assumindo boa intenção. E aqui eu preciso ser honesto, porque essa é uma das partes mais mal compreendidas da comunicação digital.

A gente lê um texto e sente algo (raiva, deboche, arrogância), e assume que quem escreveu estava sentindo aquilo. Mas não tem como saber. Um texto escrito com raiva e um texto escrito com pressa podem ser idênticos. A emoção que você lê não é necessariamente a emoção que existia do outro lado.

Um estudo clássico de 2005 mostrou que a gente superestima a capacidade do texto de transmitir nosso tom. Estudos mais recentes mostraram que em ambientes de conflito, quem recebe tende a interpretar de forma mais negativa do que um observador externo faria.

Ou seja: texto não transmite emoção, texto transmite palavras. A emoção, quem coloca é você, na leitura.

E quando já existe tensão, a emoção que você coloca tende a ser a pior possível.

Mais um motivo pra pausar.

A gravidade emocional

Segundo: eu separo o que é do outro do que é meu. Na Teoria da Convergência, falei sobre a gravidade na engenharia de software. Aqui tem uma gravidade parecida: em todo conflito, a reação do outro puxa você pra baixo, e escolha de não descer é um ato contra a gravidade. E como todo ato contra a gravidade, exige energia.

Terceiro: eu lembro por que eu perguntei. Porque eu não sei. E não saber é o pré-requisito pra aprender.

O dado que me surpreendeu

E aqui tem um dado que me surpreendeu. Pesquisadores de Harvard e Wharton descobriram que pessoas que pedem conselho são percebidas como mais competentes, não menos. O medo de parecer incompetente ao pedir ajuda existe, mas é infundado, mas tem mais: o efeito é mais forte quando a tarefa é difícil e quando você pede diretamente a alguém. Perguntar no vazio da internet pode não gerar o mesmo efeito, ainda assim, pedir ajuda, na maioria dos contextos, é percebido como inteligência.

Isso se conecta com algo maior. O Project Aristotle do Google analisou 180 times e identificou segurança psicológica como o fator número um que separava equipes de alta performance. Não era talento, não era processo, não era experiência. Era a confiança de que você pode falar sem ser punido.

Quando eu li “Os 5 Desafios das Equipes” do Patrick Lencioni, entendi por quê. Ele coloca a ausência de confiança como a base de toda disfunção de time. Mas não qualquer confiança. Ele fala de confiança baseada em vulnerabilidade. A confiança que permite dizer “eu não sei”, “errei”, “preciso de ajuda”, sem medo de que isso seja usado contra você. Sem essa base, a pirâmide inteira desmorona: o time evita conflito, não se compromete, não cobra, não entrega.

Dizer “eu não sei” não diminui ninguém. Cria espaço pra todo mundo ao redor fazer o mesmo.

O começo da estrada

Lembra da estrada em perspectiva? Quem está no começo vê todo mundo longe, vê cada diferença, vê cada discordância como pessoal. Quem já caminhou o suficiente sabe que lá na frente, os pontos se encontram.

Quando alguém te ataca por uma pergunta que você fez, aquela pessoa está no começo da estrada, onde pedir ajuda parece fraqueza, onde experiência deveria significar onisciência, e onde vulnerabilidade é algo a ser explorado, não respeitado.

Eu sei disso porque eu já estive ali.

Inteligência emocional não é o que parece

Inteligência emocional não é ficar zen. Não é engolir e sorrir. É perceber o que tá acontecendo dentro de você e escolher o que fazer com isso antes de reagir.

Às vezes eu escolho bem, às vezes não. Mas a direção importa mais que a perfeição.

A convergência é inevitável, a paciência com quem ainda não convergiu é uma escolha, e inteligência emocional é o que torna essa escolha possível no calor do momento, quando tudo dentro de você tá gritando pra reagir.

Se você tá procurando a verdade, buscando melhoria contínua, tentando se livrar do ego, vai encontrar gente no começo da estrada, gente que confunde humildade com incompetência, gente que transforma pergunta em arma.

A pergunta não é se isso vai acontecer.

É quem você vai ser quando acontecer.

Eu vou continuar pedindo ajuda, vou continuar não sabendo, e vou continuar construindo em público.

Porque a pergunta mais perigosa não é a que te expõe.

É a que você deixou de fazer por medo do que iam pensar.

Abraço, Bruno

Referências citadas nessa edição:

• Kruger, Epley, Parker & Ng (2005). Egocentrism over e-mail. Journal of Personality and Social Psychology.

• Sillars & Zorn (2021). Hypernegative Interpretation of Negatively Perceived Email at Work. Management Communication Quarterly.

• Brooks, Gino & Schweitzer (2015). Smart People Ask for (My) Advice: Seeking Advice Boosts Perceptions of Competence. Management Science.

• Meta-análise: Emotion Regulation and Aggression. PMC, 2024. N = 252.605.

• Google Project Aristotle (2015). Re:Work — Guide: Understand team effectiveness.

  ---

A Meta pagou 2 bilhões de dólares pelo Manus em dezembro. Um agente de IA que em menos de um ano chegou a $100 milhões de receita recorrente.

Mas o que me interessa não é o valuation. É o que eles publicaram sobre como fazem o agente funcionar. Porque as técnicas que eles usam em escala são as mesmas que eu aplico todo dia no Claude Code pra construir meus projetos.

Uma tarefa média no Manus executa cerca de 50 tool calls. Ratio input/output de 100:1. Sem gerenciamento ativo, isso quebra qualquer modelo.

E no entanto, funciona.

Mantenha os erros visíveis

Quando um agente falha, o instinto é limpar e tentar de novo. Manus faz o oposto: mantém stack traces e ações falhadas no contexto.

O modelo usa essas evidências pra ajustar decisões. Ao ver que tentativa X falhou com erro Y, ele evita abordagens similares. Remover o trace remove a evidência.

Eu faço o mesmo no Claude Code. Quando ele erra, não limpo o chat. Mando tentar de novo com o erro ali. A taxa de acerto na segunda tentativa é muito maior do que se eu apagasse tudo e pedisse do zero.

Filesystem como memória

LLMs têm contexto finito, disco não.

Manus salva informações grandes em arquivos e mantém só o path no contexto. A compressão é restaurável: se o path tá lá, o agente recupera o conteúdo quando precisar. Diferente de sumarizar, que perde informação sem volta.

É exatamente o que CLAUDE.md e skill files fazem. Você não enfia tudo no prompt. Coloca num arquivo, o modelo lê quando precisa. Quem usa Claude Code com skills já tá fazendo context engineering sem saber.

O TODO.md e o custo escondido

O Manus criava um TODO.md e ia atualizando conforme avançava, e isso parecia organização. Na real, era manipulação de atenção: empurrava os objetivos pro final do contexto, onde o modelo presta mais atenção.

Mas custava caro: 30% das ações eram gastas só atualizando a lista. Trocaram por um sub-agente Planner que injeta o plano só quando necessário.

A lição pra quem usa AI no dia a dia: se você tá repetindo instruções toda hora pro modelo não esquecer, o problema não é o modelo. É onde a instrução tá no contexto. Coloca no final, não no meio. Expliquei a ciência por trás disso aqui:

Bruno Bertolini

Por que a IA ignora metade do que você escreve

Você já montou um prompt caprichado, colocou contexto, explicou o tom, disse o que não queria, deu exemplos... e o modelo ignorou exatamente o detalhe que você mais se preocupou em especificar…

Read more

6 months ago · 4 likes · Bruno Bertolini

Context Rot

Um modelo pode ter janela de 1 milhão de tokens. A performance começa a cair muito antes de encher. O mercado chama isso de ‘Context Rot’. A regra prática que o Manus adotou: comprima o contexto proativamente, não espere o modelo começar a errar.

Eu vivi isso na prática. Recentemente criei um sistema de ‘auto context’ no meu workflow: a cada 30 tool calls, ou quando chega em 75% do contexto usado, ele gera um checkpoint file com o contexto comprimido. O modelo continua trabalhando com contexto limpo sem perder o histórico do que já fez. Mesma lógica do Manus, escala menor.

Remover, não adicionar

O Manus foi refatorado cinco vezes em menos de um ano. Os maiores ganhos não vieram de adicionar coisas. Vieram de tirar.

Tiraram definições complexas de ferramentas. Tiraram “management agents”. Tiraram camadas de orquestração que pareciam necessárias mas limitavam o modelo.

Boris Cherny, criador do Claude Code, cita a mesma filosofia: construiu a ferramenta pra ser flexível, não otimizada pro modelo de hoje. Conforme os modelos melhoram, o scaffolding deveria diminuir, não aumentar.

Isso vale pra qualquer pessoa usando AI pra codar. Se seu CLAUDE.md tá ficando mais complexo a cada semana, pare e pergunte: isso tá ajudando ou tá atrapalhando? Faça melhoria continua, remova arquivos, comprima rules, sintetize…

Esses dias compartilhei isso no X:

Algumas pessoas pensaram ser engenharia de foguete, mas, é um simples skill file, menos de 30 linhas. É o mesmo pensamento que eu sempre tive com relação à programação: simples que funciona. Um bom senior é quem consegue resolver problemas complexos com soluções simples.

KV-cache: onde o dinheiro mora

Quando o modelo processa tokens que já viu antes, o custo cai 10x. No Claude Sonnet: $0.30 por milhão cacheados versus $3.00 não cacheados.

A regra: mantenha o prefixo do prompt estável. Um token diferente invalida o cache dali pra frente. Por isso o Manus não adiciona nem remove ferramentas dinamicamente, ele mascara as indisponíveis sem mudar a estrutura.

Na prática: se você muda seu system prompt toda hora, tá pagando mais e recebendo menos. Estabilize o que puder.

Context engineering não é otimização. É a arquitetura que define se a coisa vai funcionar ou não.

A equipe do Manus resume: o agente é tão bom quanto o contexto que recebeu.

A mesma coisa vale pro seu Claude Code, pro seu Cursor, pro qualquer AI que você usa. O que entra e sai do contexto é a decisão mais importante que você toma. Todo dia.

Até a próxima, Bruno

Eu passei anos estudando, lendo, quebrando sistemas e reconstruindo. Em algum momento, cheguei numa arquitetura que fazia sentido pra mim. Separação clara de responsabilidades. Regras de negócio isoladas. Dependências apontando pra dentro, nunca pra fora. Não era nada revolucionário. Era o que sobrou depois de eliminar tudo que dava problema.

Aí eu descobri um cara chamado Robert C. Martin. E a Clean Architecture dele.

Quando eu fui estudar, levei um susto. A estrutura era assustadoramente parecida com o que eu já usava. Obviamente, a dele era muito mais robusta, mais evoluída, formalmente documentada. A minha ainda era embrionária. Mas o esqueleto era o mesmo.

Eu não copiei. Eu não tinha lido. Eu cheguei ali sozinho.

E isso me intrigou por anos. Até eu entender que não era coincidência.

Convergência cognitiva

Isso tem nome. Convergência cognitiva. É o fenômeno onde indivíduos com trajetórias distintas, expostos a desafios parecidos, chegam em padrões parecidos. Não porque combinaram. Porque as restrições do problema empurram todo mundo na mesma direção.

Quando você enfrenta os mesmos problemas por tempo suficiente, o espaço de soluções viáveis vai encolhendo. E o que sobra se parece muito com o que sobra pra qualquer outra pessoa que tenha enfrentado os mesmos problemas pelo mesmo tempo.

Eu vejo isso acontecer o tempo todo. Coloca dois desenvolvedores seniores na mesma sala. Experiências diferentes. Empresas diferentes. Stacks diferentes. Um veio do Java enterprise, o outro do mundo startup com Node. Um passou por banco, o outro por e-commerce.

Faz uma pergunta sobre arquitetura. Sobre como organizar código. Sobre quando usar um monolito e quando partir pra microsserviços.

Eles vão discordar nos detalhes. Vão usar vocabulários diferentes. Mas a essência da resposta vai ser assustadoramente parecida.

A estrada em perspectiva

A melhor forma que eu encontrei de explicar isso é com uma imagem.

Imagina uma estrada longa em perspectiva. Aquelas que vão afunilando no horizonte. Se você olhar perto de você, duas pessoas caminhando, cada uma em um lado da estrada, parecem distantes uma da outra. Mas lá na frente, elas estão juntas. Quase no mesmo ponto.

É exatamente isso que acontece com experiência.

Quando você é júnior, o espaço de possibilidades parece infinito. Frameworks, padrões, arquiteturas. Tudo parece viável. Tudo parece questão de preferência. Você e o dev do lado podem discordar sobre absolutamente tudo.

Mas conforme vocês avançam, as restrições vão aparecendo. Não as restrições que alguém te conta. As que você sente. Sistemas que quebraram às 3 da manhã. Abstrações elegantes que ninguém conseguia manter. Decisões que pareciam simples e custaram meses de refatoração.

Cada cicatriz dessas elimina possibilidades. Cada fracasso fecha uma porta.

E o que sobra, quando você fecha portas suficientes, é surpreendentemente parecido com o que sobra pra qualquer outro dev que tenha fechado portas suficientes.

A gravidade da engenharia de software

A estrada afunila. Mas por quê?

Porque o problema tem forma. E a forma tem menos soluções do que parece.

Humanos precisam ler código. Sistemas precisam escalar de forma previsível. Complexidade tem custo composto. Times mudam. Requisitos mudam. Essas forças são constantes.

São a gravidade da engenharia de software. E a gravidade não negocia.

Martin Fowler, Kent Beck, Uncle Bob. Backgrounds diferentes, épocas diferentes, contextos diferentes. Mas quando falam sobre design de software, as ideias se sobrepõem de um jeito que não pode ser coincidência. Separação de responsabilidades. Favorecer composição. Código que comunica intenção. Testes como rede de segurança.

Ninguém combinou. O problema combinou.

Não é que seniores são iguais. É que a gravidade é a mesma. E quem respeita a gravidade por tempo suficiente acaba construindo estruturas parecidas.

A meta-teoria

Mas tem uma segunda camada aqui que me fascina ainda mais.

Não é só que profissionais experientes convergem nas mesmas soluções. É que pessoas chegam em ideias que já foram pensadas, documentadas e nomeadas por outras, sem nunca ter tido contato com elas.

Foi o que aconteceu comigo e a Clean Architecture. E acontece o tempo todo na história.

Newton e Leibniz inventaram o cálculo diferencial de forma independente, quase ao mesmo tempo. Darwin e Wallace chegaram na teoria da evolução por seleção natural sem um saber do trabalho do outro. O sociólogo Robert K. Merton estudou esse fenômeno e deu um nome: multiple independent discovery. Ele mostrou que quando o ambiente está maduro o suficiente, quando o conhecimento acumulado chega num certo ponto, as mesmas ideias emergem em lugares diferentes, de pessoas diferentes, quase simultaneamente.

Não é mágica. É que o problema estava maduro. E pessoas imersas no mesmo problema, com ferramentas parecidas, chegam nas mesmas respostas.

E isso leva a uma pergunta que eu fiz pra mim mesmo, e que talvez seja a mais desconfortável desse texto: quantas vezes eu pensei em algo que já tem nome, já tem teoria, já tem documentação formal, e eu simplesmente não sabia?

Provavelmente mais vezes do que eu imagino. Provavelmente mais vezes do que qualquer um de nós imagina.

Quando os mapas se sobrepõem

Na última edição dessa série, falei sobre a construção da consciência. Sobre como avançar na carreira expande o mapa do que você sabe que não sabe. Sobre o fog of war que vai recuando conforme você ganha experiência.

A convergência cognitiva é o que acontece depois.

Quando duas pessoas limpam fog of war suficiente, elas começam a ver a mesma paisagem. Não porque estão no mesmo lugar, mas porque o terreno debaixo da névoa sempre foi o mesmo.

É por isso que um dev sênior brasileiro e um dev sênior finlandês, que nunca se falaram, vão concordar sobre princípios de software. Os dois navegaram terrenos diferentes. Mas o território que descobriram é, em grande parte, compartilhado.

Júniores divergem muito. Porque cada um tem um pedaço diferente do mapa. Seniores convergem. Porque, quando o mapa é grande o suficiente, a geografia começa a se repetir.

Convergência não é conformidade

Tem uma diferença importante aqui. E eu quero fechar com ela.

Convergir nos princípios não significa concordar em tudo. Dois seniores podem concordar que acoplamento é o inimigo. E discordar violentamente sobre como reduzir acoplamento naquele sistema específico. Podem concordar que testes são essenciais. E ter filosofias opostas sobre o que testar e como.

A convergência está nos princípios. A divergência criativa está na aplicação.

E é justamente essa tensão que produz boas soluções. Não a concordância cega. Mas a concordância sobre os fundamentos, combinada com a disputa honesta sobre a implementação.

Se você está em início de carreira, isso é bom. Significa que você não precisa inventar tudo do zero. Os princípios já existem. Foram descobertos e redescobertos por milhares de pessoas antes de você, em contextos que você nem imagina. Seu trabalho não é ser original nos fundamentos. É aplicar esses fundamentos no seu contexto, com as restrições do seu problema.

E se você é sênior e se sente frustrado quando um júnior sugere algo que “obviamente” não funciona, lembre: ele ainda está no começo da estrada. Onde tudo parece distante. Onde tudo parece possível. Dê tempo. As restrições vão fazer o trabalho.

A convergência é inevitável. A paciência com quem ainda não convergiu é uma escolha.

Até a próxima, Bruno

P.S. Se você curtiu essa reflexão, responde esse email com uma palavra: “convergiu”. Eu leio todas as respostas. E se tiver uma história parecida com a minha da Clean Architecture, onde você chegou numa conclusão que já existia, quero ouvir.

Umas semanas atrás eu vi um post no Reddit de um dev descrevendo o que aconteceu depois de 3 meses de vibe coding num projeto real. Começou bem. Ele descrevia features em linguagem natural, a IA gerava o código, ele aceitava, seguia em frente. O ritmo era incrível.

Até que uma mudança pequena quebrou 4 features. Ele pediu pra IA consertar, e o conserto quebrou outras 3. O cara descreveu isso como “whack-a-mole com meu próprio código.”

Eu li aquilo e pensei: conheço esse filme.

Eu já passei por exatamente isso uns meses atrás. Fiz o sistema de pagamentos inteiro com IA, aceitando código sem questionar muito. Funcionou por semanas. Quando precisei mudar a lógica de créditos, foi um efeito dominó. Três dias pra desfazer o que a IA tinha criado em duas horas.

A diferença é que eu tinha 20 anos de base pra diagnosticar o problema. Se eu não tivesse, estaria até hoje tentando consertar.

E isso me levou a uma pergunta: se vibe coding claramente não escala, o que vem depois?

O que vem depois já tem nome

Nos últimos meses, aconteceu algo que pouca gente no Brasil percebeu: GitHub, Google e Anthropic convergiram pro mesmo padrão. Independentemente.

O GitHub lançou o Spec Kit, um toolkit open source com um workflow de 4 fases: Specify, Plan, Tasks, Implement. A ideia: antes de pedir pra IA codar qualquer coisa, você escreve uma spec clara do que precisa ser feito. Essa spec vira a “fonte de verdade” do projeto. O código é gerado a partir dela, não a partir de vibes.

O Addy Osmani (engenheiro do Google, autor de livros da O’Reilly) publicou um framework de 5 princípios pra escrever specs que agentes de IA conseguem executar. “Waterfall em 15 minutos”, ele chama. Planejamento estruturado rápido, não burocracia.

A Anthropic publicou o “Building Effective Agents”, dizendo que os sistemas mais bem-sucedidos usam padrões simples e composáveis, não frameworks complexos.

Até a Amazon lançou uma IDE com essa estrutura interna, o Kiro (que eu testei na época do lançamento e fiz review constante no instagram da Codar.me).

O nome que grudou: Spec-Driven Development (SDD).

Como funciona na prática

O workflow do Spec Kit tem 4 fases com checkpoints claros:

1. Specify - Você descreve user journeys, experiencias do usuário, e critérios de sucesso. Sem mencionar tecnologia. O foco é no “o que” e no “por que”.

2. Plan - Agora sim: stack, arquitetura, constraints técnicas. Isso vira um documento que o agente vai seguir.

3. Tasks - O plano é decomposto em unidades atômicas. Cada tarefa é independente, testavel, e inclui os arquivos exatos que precisa tocar.

4. Implement - A IA executa tarefa por tarefa. Cada uma é verificável antes de seguir pra próxima.

A sacada é que o checkpoint entre cada fase é um portão de qualidade. Você revisa a spec antes de planejar. Revisa o plano antes de decompor. Revisa as tarefas antes de implementar. A IA nunca sai correndo sem aprovação.

Isso resolve o problema central do vibe coding: você perdia o controle porque não existia controle. Não tinha spec, não tinha plano, não tinha checkpoint. Só vibes.

Por que specs funcionam (a ciência por trás)

Se você leu a edição anterior sobre por que a IA ignora metade do que você escreve, já sabe que modelos têm atenção em formato de U, prestam atenção no início e no fim do contexto, e tendem a ignorar o meio. E que existe um orçamento real de ~150-200 instruções que o modelo consegue seguir com consistência.

SDD é a resposta prática a esses dois problemas.

Quando você vibecoda, a cada prompt novo o contexto fica mais longo e mais confuso. Instruções antigas se perdem no meio. O modelo começa a “esquecer” o que deveria fazer. É exatamente o efeito “Lost in the Middle” que a pesquisa do MIT documentou.

Quando você trabalha com specs, cada tarefa tem um contexto limpo e focado. O agente recebe exatamente o que precisa pra executar aquela unidade de trabalho, nada mais, nada menos. Isso mantém o modelo dentro do seu orçamento de atenção.

A spec não é burocracia. A spec é gerenciamento de contexto.

O dado que me convenceu

O GitHub analisou 2.500 repositórios com arquivos de configuração de agentes de IA. O padrão mais eficaz que encontraram usa um sistema de 3 níveis de autonomia:

• Sempre: ações que o agente faz sem pedir. “Sempre rode testes antes de commitar.”

• Pergunte primeiro: ações de alto impacto. “Pergunte antes de alterar schemas do banco.”

• Nunca: stops absolutos. “Nunca comite secrets ou API keys.”

É simples. E funciona porque elimina ambiguidade. O agente sabe exatamente onde tem autonomia e onde precisa parar.

Sabe qual foi a instrução de “Never” mais comum nos 2.500 repos? “Never commit secrets.” A coisa mais básica de segurança. E mesmo assim precisava ser escrita explicitamente pro agente não fazer.

Isso diz tudo sobre o nível de confiança que você pode ter em código gerado sem supervisão.

O que a equipe do Martin Fowler pensa (e por que importa)

Nem todo mundo é entusiasta. Birgitta Böckeler, Distinguished Engineer na Thoughtworks e colaboradora direta do Martin Fowler, testou o Spec Kit e o Kiro na prática e publicou uma análise honesta.

A critica central dela não é contra a ideia de spec-first. Ela mesma diz que frequentemente gasta tempo escrevendo uma spec cuidadosa antes de pedir algo pra IA. O que ela questiona é a cerimônia excessiva das ferramentas.

Quando usou o Spec Kit numa feature de tamanho médio, a quantidade de arquivos markdown gerados pra revisar era enorme. Repetitivos entre si, redundantes com código que já existia. Ela estimou que no mesmo tempo que gastou revisando specs, teria implementado a feature inteira com coding assistido por IA normal, sem todo o aparato formal.

O outro ponto forte: mesmo com todas as specs, templates, workflows e checklists, o agente frequentemente não seguiu todas as instruções. Em um caso, o agente ignorou notas sobre código existente e recriou classes duplicadas. Em outro, seguiu uma regra da “constitution” de forma tão entusiasmada que fez mais do que deveria.

Ela resume a preocupação com uma palavra alemã que não tem tradução: “Verschlimmbesserung”, quando você tenta melhorar algo e acaba piorando.

E ela tem razão. A ferramenta não é o conceito. Spec Kit pode ser overkill pra muita coisa. Kiro gerou 4 user stories e 16 critérios de aceite pra um bug simples.

Mas o princípio por trás do SDD, pensar antes de codar, documentar a intenção, dar contexto estruturado pro agente, isso ela mesma pratica. A questão não é “SDD sim ou não”. É “quanto de cerimônia faz sentido pra cada tamanho de problema?”

E essa é a pergunta certa.

O que eu mudei no meu workflow

Depois dessa pesquisa, mudei 3 coisas:

1. Spec antes de código. Qualquer feature nova começa com uma spec de 1 parágrafo: o que, por que, e critérios de aceite verificáveis. Se eu não consigo escrever uma spec clara, a feature não está pronta pra ser construída.

2. Boundaries explícitas. Cada projeto tem um arquivo com os 3 níveis: Always, Ask First, Never. O agente sabe o que pode fazer sozinho e onde precisa parar.

3. Tarefas atômicas. Em vez de pedir “implementa o sistema de pagamentos”, eu decomponho em tarefas de 1-3 arquivos com uma definição de “pronto” verificável. “Quando o endpoint /payment receber um request com créditos insuficientes, deve retornar 402 com a mensagem X.”

O resultado: menos surpresas, menos retrabalho, menos whack-a-mole.

Não é perfeito. A IA ainda erra. Mas quando ela erra, eu sei exatamente o que ela deveria ter feito, porque a spec existe. Isso cria um novo portão de qualidade automatizado. E isso muda tudo.

O ponto que ninguém fala

Vibe coding não vai morrer. Pra protótipos, MVPs, side projects, experimentação rapida, funciona. Eu uso até hoje quando quero testar uma ideia em 30 minutos.

Mas pra qualquer coisa que vai pra produção, que vai ter usuários reais, que vai precisar de manutenção, vibe coding é dívida técnica no cartão de crédito. Parece barato agora. Os juros chegam depois.

SDD é a alternativa: mantém a velocidade da IA, mas adiciona a estrutura que impede o código de virar um castelo de cartas.

A frase que resume: deixamos de tratar código como a fonte de verdade. A intenção é a fonte de verdade agora. O código é só o output.

Na próxima edição, vou falar sobre o Manus AI , o agente que faz ~50 tool calls por tarefa e descobriu que a forma como você estrutura o contexto importa mais do que o modelo que você usa. Os números que eles publicaram sobre overhead de tarefas mal escritas são surpreendentes.

--

Bruno Bertolini

P.S. Se você quiser testar SDD no seu próximo projeto, o Spec Kit do GitHub é open source e funciona com Claude Code, Copilot, Cursor e Gemini. Link: github.com/github/spec-kit

“Meu conselho pra dev júnior: aprenda a mentir no currículo. Coloque experiências que vc nunca viveu, aumente projetos que você fez e até cite empresas que já fecharam. Ninguém vai conferir isso mesmo. O difícil é entrar. Depois vc aprende no trabalho. Só seja bom tecnicamente.”

Eu respondi. Virou uma thread. E o que aconteceu nessa thread é mais interessante do que o tweet em si, porque a pessoa que me respondeu demonstrou, ao vivo, cada mecanismo psicológico que a ciência descreve sobre como a desonestidade funciona.

Vou te mostrar o que aconteceu. E por que importa muito além de currículo.

O ponto de partida

Minha resposta ao tweet foi direta:

Curioso como ninguém que dá esse conselho quer trabalhar com alguém que seguiu ele.

Porque é verdade. Nenhum tech lead quer descobrir que o dev mentiu sobre experiência. Nenhum founder quer um sócio que aprendeu cedo que trapacear funciona.

Mas o problema real não é ser pego. É o que isso faz com você por dentro.

A primeira racionalização

A resposta veio rápido:

“Desce do cavalo branco e olha o mercado real: vaga júnior pedindo 3/4/5 anos de experiência, teste técnico de 8 horas sem retorno, empresa que some após a entrevista. O dev júnior não tá corroendo caráter, tá tentando entrar num jogo que foi viciado antes dele chegar.”

O mercado tá quebrado? Tá. Tenho 20 anos de mercado. A gente já discutia requisitos irreais quando eu era júnior. Isso nunca foi diferente. E nunca foi motivo pra mentir.

Mas repara no que aconteceu nessa resposta: a pessoa pegou um sistema injusto e usou como justificativa para uma resposta desonesta. Re-rotulou mentira como estratégia de sobrevivência.

Isso tem nome na ciência.

Ethical Fading

Max Bazerman e Ann Tenbrunsel, pesquisadores de Harvard e Notre Dame, chamam isso de “ethical fading”: quando a dimensão ética simplesmente desaparece da decisão e vira “só uma questão de mercado.”

Organizações fazem isso o tempo todo: re-rotulam dilemas éticos como “decisões de negócios.” O resultado é o que eles chamam de “bounded ethicality” (eticidade limitada): pessoas boas se comportando de forma antiética sem perceber que estão fazendo isso.

A pessoa não escolhe ser desonesta. A ética nem entra na equação.

A segunda racionalização

Aí veio o segundo argumento:

“Caráter também é construído com oportunidade. Quem nunca teve chance de provar nada não teve caráter testado, teve caráter bloqueado.”

Lê de novo essa frase.

A pessoa disse que caráter é construído com oportunidade. E aí, quando a oportunidade de construir caráter aparece, o conselho é... mentir?

Isso não é caráter bloqueado. É caráter sendo testado. E falhando no teste.

O mercado difícil é a oportunidade. Não de trapacear. De provar quem você é quando seria mais fácil não ser.

O Fudge Factor

Dan Ariely, pesquisador de economia comportamental da Duke University, estudou por anos como pessoas comuns lidam com a desonestidade. Ele descobriu o que chamou de “fudge factor” (fator de ajuste): as pessoas trapaceiam o suficiente pra tirar vantagem, mas não tanto que destrua a imagem que têm de si mesmas.

A lógica interna funciona assim: “eu sou uma pessoa honesta que, neste caso específico, tem uma boa razão pra flexibilizar.”

É exatamente o que aconteceu na thread. A pessoa não se vê como desonesta. Ela se vê como alguém que está sobrevivendo num sistema injusto. A mentira no currículo não é desonestidade, é estratégia. O fudge factor em ação.

O modelo econômico clássico dizia que desonestidade é puro cálculo de risco vs. recompensa. Ariely mostrou que não: em experimentos, as pessoas não trapaceavam mais quando a chance de serem pegas diminuía. O que realmente opera é essa negociação interna entre vantagem e autoimagem.

Outro achado importante: pessoas mais criativas são melhores em racionalizar comportamento desonesto. Não porque são mais desonestas, mas porque têm mais facilidade em construir narrativas que justificam desvios.

A terceira racionalização

Veio mais um argumento:

“Às vezes a primeira pedrada no sistema é entrar nele.”

Entrar por fraude não te dá autoridade pra mudar nada. Te dá um segredo pra esconder. Toda sua posição dentro do sistema passa a depender de ninguém descobrir como você chegou lá. Isso não é liberdade. É refém.

Não conheço ninguém que entrou por atalho ético pra “mudar por dentro” e conseguiu. Ninguém volta de lá. O sistema absorve. Sempre. É só olhar pra politica, quantos entraram como paladinos da justiça e no final, se tornaram tão sujos como aqueles a quem acusavam.

O Slippery Slope Neural

E aqui entra o estudo que muda tudo.

Em 2016, pesquisadores da University College London (Neil Garrett e Tali Sharot) publicaram “The Brain Adapts to Dishonesty” na Nature Neuroscience. Eles colocaram voluntários numa máquina de ressonância magnética e deram oportunidades repetidas para mentir em benefício próprio.

A amígdala, região do cérebro ligada a respostas emocionais, reagia com força na primeira mentira. Aquele desconforto que a gente sente quando faz algo errado. Mas a cada mentira seguinte, a resposta diminuía. E conforme a resposta emocional caía, as mentiras ficavam maiores.

A explicação de Tali Sharot: quando mentimos para ganho pessoal, a amígdala produz um sentimento negativo que limita o quanto estamos dispostos a mentir. Mas essa resposta enfraquece com a repetição. Quanto mais ela cai, maiores ficam as mentiras.

A pessoa que defendeu “entrar no sistema” como primeira pedrada não entende que não existe “só essa vez.” O cérebro se adapta. O freio enfraquece. O que começa como currículo inflado se torna o padrão de operação.

“Só dessa vez” não é exceção ao mecanismo. É o início dele.

A escalada completa

Quando olhei pra thread inteira, percebi que a própria conversa era uma demonstração perfeita:

Primeiro argumento: “O mercado é injusto.” Segundo argumento: “Caráter precisa de oportunidade.” Terceiro argumento: “A primeira pedrada é entrar no sistema.”

Cada resposta foi uma camada nova de racionalização. Mais sofisticada que a anterior. Exatamente o que a ciência descreve: o custo da verdade sobe, a narrativa se ajusta, e a pessoa se convence de que não é desonestidade, é sobrevivência.

Sabe quem mais usa essa lógica?

Político corrupto.

“O sistema é assim mesmo.” “Todo mundo faz.” “Preciso estar lá dentro pra mudar.” “Os fins justificam os meios.”

A diferença entre o dev que mente no currículo e o político que desvia verba não é de caráter. É de escala. O mecanismo é o mesmo. Começa no “ninguém vai conferir” e vai até onde o acesso permitir.

Isso é o jeitinho brasileiro. E é por isso que a gente não sai do lugar.

Mas por que o desconforto existe?

Até aqui, tudo que descrevi são mecanismos. Como a honestidade oscila, por que o cérebro se adapta, como nos damos permissão.

Mas tem uma pergunta que esses estudos não respondem: por que sentimos o desconforto em primeiro lugar?

Se a desonestidade fosse simplesmente “natural”, o cérebro não precisaria produzir um sinal negativo na amígdala quando mentimos. Se fosse puro cálculo racional, não existiria o fudge factor. As pessoas simplesmente trapaceariam o máximo possível.

Mas não é o que acontece. Todo ser humano, em toda cultura, começa com um freio moral ativo. A amígdala dispara. O desconforto aparece.

C.S. Lewis, em “Cristianismo Puro e Simples”, faz uma observação que se encaixa aqui. Ele argumenta que existe uma Lei Moral universal, que ele chama de “Lei da Natureza Humana”, diferente das leis da natureza como a gravidade.

A diferença: a gravidade descreve o que acontece. A Lei Moral descreve o que deveria acontecer. E diferente da gravidade, o ser humano pode escolher desobedecer essa lei.

O argumento de Lewis é simples: observe duas pessoas discutindo. O que elas fazem? Apelam a um padrão de comportamento que ambas reconhecem. “Isso não é justo.” “Você prometeu.” Ninguém nessas discussões nega que o padrão existe. A pessoa que está errada tenta explicar por que, no caso dela, existe uma exceção.

Exatamente o que aconteceu na thread.

Lewis nota que embora existam diferenças entre códigos morais de culturas diferentes, elas nunca são totais. Não existe civilização que celebre covardia, traição ou mentira para quem confia em você. As variações são de superfície. O núcleo é impressionantemente consistente.

Ele compara com a matemática: aprendemos a tabuada na escola, mas 2+2=4 não é uma invenção da escola. É uma verdade que existe independentemente de ser ensinada. Da mesma forma, aprendemos moral com pais e cultura, mas a moral em si não é invenção deles.

E aqui Lewis conecta com o que a neurociência encontrou décadas depois: nós não precisamos ser ensinados a sentir que mentir é errado. A amígdala já vem com essa resposta. O que precisamos ser ensinados é a racionalizar exceções.

O que separa integridade do resto

Se juntarmos todas as peças:

Todo ser humano tem uma Lei Moral interna que produz desconforto quando é violada. Mas todos nós ajustamos essa lei um pouquinho, o tempo todo, pra equilibrar identidade e conveniência. Cada ajuste enfraquece o freio, facilitando ajustes maiores. Em muitas situações, a dimensão ética simplesmente desaparece antes da decisão.

Então o que separa pessoas verdadeiramente íntegras?

Não é que elas não sentem a tentação. É que elas tomaram uma decisão antes da situação aparecer.

Peter Gollwitzer, pesquisador da NYU, estuda o que chama de “implementation intentions”: quando alguém define de antemão “SE esta situação acontecer, ENTÃO eu farei X”, o comportamento se torna quase automático. O cérebro não precisa negociar no momento. A decisão já foi tomada.

Em seus estudos, objetivos difíceis foram completados cerca de três vezes mais quando as pessoas tinham formado esse tipo de plano antecipado.

Aplicado à integridade: a pessoa que já decidiu “eu não faço isso” não precisa deliberar quando a tentação aparece. O ethical fading não tem espaço. O fudge factor não tem margem.

Mas como isso funciona na prática?

Você não precisa ter pensado em cada situação específica de antemão.

Eu nunca parei pra pensar “e se alguém me sugerir mentir no currículo?” Nunca planejei essa situação. Mas quando li o tweet, a resposta foi automática. Não precisei deliberar. Não pesei prós e contras. A reação foi imediata: não, isso não é quem eu sou.

Isso acontece porque a pré-decisão não precisa ser sobre cenários específicos. Ela pode ser sobre identidade. Em vez de planejar “se me pedirem pra mentir no currículo, eu recuso”, você decide algo mais fundamental: “eu sou uma pessoa que não mente pra obter vantagem.”

Quando a identidade está definida, ela funciona como um filtro automático. Qualquer situação que bata nesse filtro, mesmo uma que você nunca imaginou, ativa a mesma resposta. Você não precisa negociar com cada tentação individualmente. A decisão já foi tomada num nível mais profundo.

É a diferença entre ter uma lista de regras e ter um princípio. A lista precisa cobrir cada caso. O princípio cobre todos, inclusive os que você nunca previu.

Gollwitzer chamaria isso de uma “implementation intention” de nível superior: não é “SE me pedirem pra mentir, ENTÃO eu recuso.” É “EU SOU alguém que não faz isso.” O gatilho não é a situação. É qualquer coisa que colida com quem você decidiu ser.

Pra quem ficou até aqui

Uma última coisa sobre a thread.

A pessoa que me respondeu não é desonesta. Esse é justamente o ponto.

Ela não defende mentir no currículo porque é má pessoa. Defende porque o mecanismo já fez o trabalho dele: normalizou, racionalizou, e agora parece razoável. É exatamente assim que funciona. Com todo mundo.

A boa notícia é que o momento que você percebe o mecanismo é o momento que ele perde força.

Integridade não é nunca ter errado. É decidir parar quando percebe.

A maioria das pessoas não escolhe entre ser honesta ou desonesta. Escolhe entre quem quer ser e o que é conveniente agora. O que separa pessoas íntegras das demais não é que elas não sintam a tentação. É que elas decidiram antes que a própria identidade vale mais que a conveniência.

Integridade é uma decisão tomada antes da tentação.

Estudos citados nesta edição:

• Garrett, Lazzaro, Ariely & Sharot — “The Brain Adapts to Dishonesty” (Nature Neuroscience, 2016)

• Mazar, Amir & Ariely — “The Dishonesty of Honest People” (Journal of Marketing Research, 2008)

• Bazerman & Tenbrunsel — “Blind Spots: Why We Fail to Do What’s Right” (Princeton University Press, 2011)

• Gollwitzer & Brandstätter — “Implementation Intentions and Effective Goal Pursuit” (Journal of Personality and Social Psychology, 1997)

• C.S. Lewis — “Mere Christianity” (1952)

A reação natural é achar que precisa de um prompt ainda mais detalhado. Passei um tempo achando isso também.

Mas não é isso. É o contrário.

Fui pesquisar de verdade. Li 22 fontes (não eu exatamente, a AI, claro): papers acadêmicos do Stanford e MIT, publicações da Anthropic, Google e GitHub, dados de engenheiros que trabalham com IA em produção. O que encontrei mudou como eu uso IA no dia a dia.

A atenção do modelo tem formato de U

O paper mais importante foi publicado no MIT Press em 2024. “Lost in the Middle” (Liu et al.), pesquisa do Stanford com a Meta.

O experimento é simples: eles variaram a posição da informação relevante dentro de um prompt longo e mediram a performance dos modelos. O resultado foi consistente em todos os modelos testados.

LLMs prestam muito mais atenção no início e no fim do que você escreve. O meio é ignorado.

Os números: acurácia de 70-75% para informações nas extremidades. Cai para 55-60% para informações no meio. Em alguns casos, ter a informação relevante no meio gerou performance pior do que não ter informação nenhuma. O GPT-3.5-Turbo chegou a 56.1% de acurácia com informação no meio, abaixo do baseline sem contexto nenhum.

A curva de atenção tem literalmente o formato de um U.

Se você monta prompt longo e coloca a instrução mais importante no terceiro parágrafo, depois de duas seções de contexto, é ali que ela vai morrer. Não importa quão bem escrita ela está.

Existe um orçamento real de atenção

O HumanLayer, uma empresa que trabalha com agentes de IA em produção, chegou a um número concreto depois de testar com múltiplos modelos: LLMs de ponta conseguem seguir cerca de 150-200 instruções com consistência razoável.

Parece muito. Mas o comportamento de degradação é o que pega.

Quando você passa do limite, não são só as últimas instruções que perdem força. Todas perdem força uniformemente. Cada instrução nova que você adiciona dilui todas as anteriores.

Sabe quando você tem um arquivo CLAUDE.md ou system prompt com 50 regras e o modelo segue umas 30? Não é que as 20 de baixo são piores. É que 50 é demais. Se você cortar pra 15 bem escolhidas, as 15 funcionam melhor do que as 30 que funcionavam antes.

Isso inverte a lógica de “quanto mais detalhado, melhor”. Você não está sendo mais preciso. Está diluindo o que já funcionava.

Contexto irrelevante não é neutro

Esse foi o dado que mais me surpreendeu.

O Chroma Research publicou em 2025 um estudo chamado “Context Rot” testando o que acontece com a performance quando você adiciona conteúdo irrelevante ao contexto. A conclusão: performance degrada consistentemente, em todos os modelos testados, mesmo quando o conteúdo adicional não tem nada a ver com a tarefa.

E a degradação não é uniforme. Conteúdo complexo e irrelevante causa mais dano do que ruído simples.

Aquele contexto elaborado que você adicionou “só pra garantir que o modelo entenda”? Tá atrapalhando. Cada linha que não contribui diretamente pro resultado não ocupa só espaço, compete ativamente com o que importa.

É tipo poluição sonora. Você não precisa de silêncio absoluto pra trabalhar, mas se tem uma TV ligada, alguém falando no telefone e um cachorro latindo, sua produtividade cai mesmo que nenhum desses sons tenha a ver com sua tarefa.

O que mudou na prática

Três coisas que faço diferente hoje.

O mais importante vai no começo, sempre. Se tem uma instrução de tom, formato ou restrição que não pode ser ignorada, ela está na primeira linha. Não depois do contexto. Antes. Parece óbvio, mas vai olhar seus últimos prompts, aposto que a instrução principal tá enterrada no meio.

Corto contexto até doer. Pra cada bloco de um prompt longo, pergunto: se eu tirar isso, o resultado piora? Se a resposta for “talvez não”, tiro. Menos contexto com mais relevância tende a gerar resultado melhor do que mais contexto com mais completude.

Paro de repetir o que já está implícito. Se estou pedindo pra escrever um e-mail profissional, não preciso escrever “use tom profissional”. O modelo já infere. Instrução redundante consome orçamento de atenção sem retorno.

Se a palavra não tá ajudando, ela tá atrapalhando. Isso vale pra prompts simples, vale pra system prompts, e vale especialmente pra quem tá construindo agentes com contexto persistente, porque aí o lixo acumula e só piora com o tempo.

Na próxima edição falo sobre o outro lado do problema: como estruturar tarefas pra IA de forma que ela execute sem retrabalho. Um pesquisador do Manus AI publicou dados concretos sobre o overhead que tarefas mal escritas geram. O resultado é contraintuitivo e quero mostrar os números.

Bruno Bertolini

A maioria das pessoas tem um mapa errado do próprio conhecimento. Inclusive você.

Não porque são burras. Mas porque o mapa parece certo. Parece completo. Cada peça no lugar, nenhum espaço em branco, nenhuma lacuna visível. E é exatamente isso que o torna perigoso.

Entender como isso funciona pode mudar a forma como você enxerga sua própria vida. Mas antes, preciso te contar sobre um quebra-cabeça.

Existe uma empresa chamada Magic Puzzle Company que vende quebra-cabeças de 1000 peças. Você monta o puzzle normalmente. Encaixa todas as peças, completa a imagem, e ela faz sentido. Ilhas paradisíacas, florestas encantadas, cidades mágicas. Está tudo lá. Não falta nada. Você olha pro resultado, satisfeito, e já pode ir dormir. O quebra-cabeça está pronto.

Aí vem a instrução: abra o envelope lacrado.

Dentro tem dezenas de peças que não estavam no jogo original. E as instruções pedem que você separe seções inteiras do quebra-cabeça que já estava montado, reorganize tudo, e encaixe as novas peças no espaço que se abriu no meio. Quando você termina, a imagem mudou completamente. Onde antes havia ilhas tranquilas, agora aparece algo completamente inesperado que muda a narrativa inteira. Uma história que estava escondida se revela.

E o pior: depois que você vê a versão expandida, percebe que já havia pistas na versão “completa” que você tinha ignorado. Elas sempre estiveram lá. Você só não sabia que precisava procurá-las.

Guarda essa imagem. O quebra-cabeça completo que descobre que não estava completo. Vamos voltar nela.

Em 2002, o secretário de defesa americano Donald Rumsfeld deu uma coletiva de imprensa que ficou famosa. Não pelo conteúdo político, mas por uma frase que virou framework. Ele dividiu o conhecimento humano em quatro quadrantes. A ideia é mais antiga que ele, mas foi Rumsfeld quem a colocou no mapa (sem trocadilho):

O que você sabe que sabe. Sua área de domínio. As coisas que, se alguém perguntar, você responde com segurança. O médico que sabe diagnosticar uma pneumonia. O engenheiro que sabe calcular uma estrutura. Aqui mora a competência consciente. Você tem conhecimento e tem consciência dele.

O que você sabe que não sabe. Igualmente importante. Eu sei que não sei tocar piano. Sei que não entendo de astrofísica. Existe um buraco no meu mapa e eu consigo apontar pra ele. Ter consciência das próprias lacunas é, paradoxalmente, uma forma sofisticada de conhecimento. Você não tem o conhecimento, mas tem consciência da ausência.

O que você não sabe que sabe. Esse é mais sutil. É o conhecimento empírico que vive no corpo, na intuição, nos padrões que você reconhece sem conseguir articular por quê. O profissional experiente que “sente” que algo vai dar errado antes de ter qualquer dado concreto. Você tem o conhecimento, mas não tem consciência dele. Ele opera em silêncio. E só descobre que existia quando precisa externalizar, quando alguém pergunta “como você sabia?” e a resposta honesta é “eu não sabia que sabia.”

O que você não sabe que não sabe. E aqui está o quadrante que muda tudo. Você não tem conhecimento e não tem consciência. Não existe buraco visível no seu mapa. Não existe espaço em branco. Na sua cabeça, no seu modelo mental, tudo está finalizado. Está pronto. Faz sentido. O quebra-cabeça parece completo. Até que alguém te entrega o envelope.

Os navegadores do século XV viviam exatamente nesse quadrante.

Eles olhavam pro mapa do mundo e viam algo completo. A Europa estava lá. A Ásia, mais ou menos. A África, parcialmente. O mapa tinha bordas, tinha forma, tinha fim. Não existia um espaço em branco com uma placa dizendo “atenção: aqui tem um continente inteiro que vocês ainda não descobriram.” O mapa simplesmente parecia pronto. Não faltava peças. Não havia lacunas visíveis. O modelo mental daqueles navegadores era internamente consistente. O que é muito diferente de estar correto.

Até que alguém cruzou o oceano.

E de repente, o mundo era incompreensivelmente maior do que qualquer mapa sugeria. Não era que eles estivessem errados sobre o que sabiam. É que existiam dimensões inteiras de realidade que sequer cabiam no modelo que tinham. O envelope foi aberto. E como em todo bom plot twist, ele não adicionou informação nova. Ele recontextualizou tudo que já estava lá.

Esse é o quadrante dos unknown unknowns. Não é ignorância comum. É uma ignorância invisível até pra quem a carrega. E é o quadrante mais importante dos quatro, porque é o único que, por definição, você não consegue acessar por esforço próprio. Você não pode estudar o que nem sabe que existe. Você não pode buscar respostas pra perguntas que ainda não aprendeu a fazer.

É aqui que fica interessante.

Existe um fenômeno documentado em psicologia cognitiva, o efeito Dunning-Kruger, que mostra algo contraintuitivo: a relação entre competência e confiança não é linear. No início de qualquer jornada de aprendizado, a confiança tende a ser desproporcionalmente alta. Não por arrogância, mas por uma razão estrutural: quando seu quebra-cabeça é pequeno, ele parece completo. Você não sabe o que não sabe, então não tem motivo pra duvidar de si. O envelope ainda está lacrado. Você nem sabe que ele existe.

O empreendedor de primeira viagem que acha que só precisa de uma boa ideia. O estagiário que acha que o trabalho é basicamente o que ele fez na faculdade. O investidor iniciante que acha que entende risco porque leu três livros. Nenhum deles está sendo arrogante. O quebra-cabeça deles simplesmente ainda é pequeno. E num quebra-cabeça pequeno, quase tudo está preenchido. Dentro do modelo que eles têm, a confiança faz sentido.

O problema começa quando o envelope é aberto.

Conforme a competência real cresce, uma coisa curiosa acontece: a pessoa começa a descobrir camadas que não sabia que existiam. Cada coisa nova que aprende revela dez que não sabia. O quebra-cabeça fica maior, mas os espaços vazios crescem muito mais rápido do que as peças encaixadas.

É aqui que a confiança desaba. E é aqui que nasce o que chamam de Síndrome do Impostor.

Mas repara na mecânica: a pessoa não ficou menos competente. Ela ficou mais consciente. O que mudou não foi o conhecimento real, foi a percepção da imensidão do que falta.

Imagina um mapa onde a maior parte do território está coberta por uma névoa escura. Você só enxerga o que já explorou. O resto é território desconhecido. Em jogos de estratégia chamam isso de fog of war. A pessoa que abriu o envelope é a que descobriu o fog of war do próprio conhecimento. Antes, ela achava que o mapa era tudo que existia. Agora ela vê a névoa. E sabe que além do que já explorou, tem uma zona vasta e escura onde qualquer coisa pode surgir. Ela não sabe o que tem lá. Mas sabe que tem algo. E só isso já muda tudo.

A síndrome do impostor, vista por essa lente, nada mais é que o gap entre a confiança e o conhecimento real. Quando sua confiança está abaixo da sua competência real, você se sente uma fraude. Não porque é uma. Mas porque sua capacidade de enxergar o que não sabe evoluiu mais rápido do que sua capacidade de se dar crédito pelo que já sabe.

Quem nunca abriu nenhum envelope dificilmente sente isso. Quanto menor o mapa, mais completo ele parece. Quanto mais completo parece, menos motivo pra duvidar. Bertrand Russell resumiu isso numa frase: os tolos estão cheios de certezas e os sábios cheios de dúvidas.

A síndrome do impostor não é um defeito. É um efeito colateral de ter expandido o mapa.

Existe outro problema nessa equação, e ele é mais silencioso.

Quando alguém sente que é uma fraude, a reação instintiva é se comparar. Olhar pro colega, pro líder, pro referência do mercado. E a comparação é quase sempre feita em uma única dimensão: conhecimento bruto. “Fulano sabe mais que eu sobre X, logo eu sou inferior.”

Mas conhecimento bruto é uma variável entre muitas. Experiência, contexto, história de vida, os problemas específicos que cada pessoa enfrentou, as decisões que tomou sob pressão, os fracassos que internalizou. Tudo isso molda não apenas o que alguém sabe, mas como sabe. Duas pessoas podem ter o mesmo “nível” e pensar de formas completamente diferentes, porque o caminho que percorreram até ali foi diferente.

David Epstein escreveu um livro inteiro sobre isso. Em “Range: Why Generalists Triumph in a Specialized World”, ele mostra como pessoas com experiências diversas resolvem problemas que especialistas profundos não conseguem, justamente porque trazem analogias de territórios que o especialista nunca explorou. O generalista carrega peças de quebra-cabeças diferentes. E às vezes é exatamente a peça que faltava no seu.

Comparar conhecimento como se fosse um número em uma escala linear é ignorar toda a complexidade que torna cada trajetória única. É como comparar dois quebra-cabeças baseado apenas no número total de peças encaixadas, ignorando que um montou paisagens e o outro montou retratos. São imagens diferentes. A comparação é estruturalmente injusta.

Tudo isso leva a um lugar.

Se o mapa nunca está completo, e se a comparação entre mapas é distorcida, a única postura intelectualmente honesta é uma que poucas pessoas praticam de verdade: humildade intelectual.

Não a humildade performática de quem diz “ah, eu não sei nada”. A humildade real de quem internaliza que qualquer informação nova pode redesenhar o quebra-cabeça inteiro. Que aquilo que você tem certeza hoje pode se mostrar incompleto amanhã, não porque estava errado, mas porque existiam peças que seu jogo ainda não incluía.

Isso tem consequências práticas profundas.

Significa aceitar que pessoas com contextos radicalmente diferentes dos seus, independente do nível de senioridade, da idade, da formação, carregam peças que o seu quebra-cabeça não tem. Aquele estagiário que entrou semana passada pode não saber o que você sabe. Mas ele viveu coisas que você não viveu, e isso lhe deu perspectivas que você não tem. Se você fecha o canal por uma hierarquia de conhecimento, perde acesso a peças que nunca vai encontrar sozinho.

Significa entender que buscar a verdade é mais importante que estar certo. São coisas diferentes. Estar certo é estático, é defender uma posição. Buscar a verdade é dinâmico, é estar disposto a abandonar uma posição quando a evidência aponta pra outro lugar. Richard Feynman construiu uma carreira inteira sobre esse princípio. Pra ele, a pergunta sempre foi mais valiosa que a resposta. Porque a resposta encaixa uma peça. A pergunta revela que existem mais peças do que você imaginava.

Significa, no fim, aceitar que o quebra-cabeça nunca vai estar completo. E que isso não é um problema a ser resolvido. É a condição fundamental de qualquer pessoa que está genuinamente crescendo. O momento em que seu quebra-cabeça parece pronto é o momento em que você parou de procurar envelopes.

A maioria das pessoas nunca questiona o próprio mapa. Algumas descobrem que ele é maior do que imaginavam e entram em pânico. Poucas entendem que o mapa vai se expandir pra sempre, e fazem as pazes com isso.

A pergunta que resta é simples: o que você faz quando descobre que existem mais peças do que a caixa prometia?

Mas esse espaço não é (só) sobre isso. É sobre o que acontece na cabeça de alguém que está sempre em busca de melhoria contínua e genuína, de ser alguém melhor pro mundo.

As decisões, as dúvidas, os erros. O que leio, o que penso, o que questiono. O que a fé me ensina sobre construir. O que ser pai mudou na forma como eu priorizo.

Eu não acredito na vida perfeita que vendem nas redes sociais. A vida é difícil e todo mundo tem problemas, inclusive eu. A diferença é que eu gosto de resolver. Seja um bug em produção, uma decisão de negócio, uma conversa difícil em casa ou um mês apertado. Aqui eu vou compartilhar esses problemas e como eu lido com eles.

Eu precisava de um lugar pra juntar tudo isso. Essa newsletter é esse lugar.

Meu nome é Bruno Bertolini. Marido, pai, cristão, engenheiro de software com 20 anos de experiência, ex-CTO, e fundador de uma escola que impactou mais de 70 mil devs. Hoje construo sozinho o que antes precisava de equipe.

Aqui não tem nicho. Não tem cronograma. Tem só alguém que constrói, aprende, lê, questiona tudo e não para quieto. Sempre em busca de melhoria contínua, minha e de quem me acompanha.

Se isso te interessa, fica por aqui.

Bruno Bertolini