Existe uma ideia antiga de que as ferramentas que usamos moldam o jeito como pensamos. Marshall McLuhan disse algo próximo disso sobre mídia. Marceneiros dizem sobre ferramentas manuais. Programadores dizem sobre as linguagens em que passam mais tempo — Lisp vai te dar um modelo de computação; Haskell vai te dar outro; o modelo que você carrega adiante é o modelo que mais usou.

Venho pensando numa versão dessa ideia nos últimos meses, observando o que acontece com meu próprio formato mental enquanto construo ferramental de IA ao redor do meu jeito de trabalhar. O efeito direto é o que todo mundo espera: as ferramentas economizam tempo, trabalho compõe, capacidades empilham. Isso tem sido verdade pra mim. O que eu não esperava era que, três meses depois, eu estaria abordando problemas desconhecidos com um formato mental diferente do que tinha antes. Não porque meu cérebro mudou. Porque o sistema ao redor do meu cérebro mudou, e o jeito como penso sobre problemas começou a refletir o sistema dentro do qual estou pensando.

O primeiro loop é familiar: construa uma ferramenta, reduza o atrito numa tarefa recorrente, faça essa tarefa com mais confiabilidade. É real. Vale fazer. Mas não é o loop interessante.

O segundo loop — trabalho mudado muda como você pensa sobre trabalho

O loop interessante é o que roda ao longo de semanas e meses, quase invisivelmente, depois que o primeiro loop já está operando há um tempo.

O formato dele, na minha experiência:

As ferramentas lidam bem com as tarefas recorrentes. Você para de gastar energia mental nelas. A energia mental liberada vai pra perceber padrões num nível mais alto. Esses padrões sugerem novas ferramentas. As novas ferramentas mudam as tarefas recorrentes de novo. A cada volta do loop, o nível de abstração no qual você opera sobe um degrau.

A primeira vez que percebi isso acontecendo, eu estava fazendo debug de um problema no projeto de agente de IA em que trabalho. Dois anos atrás, “fazer debug de um problema” significava: abrir o codebase, achar o ponto de entrada, rastrear o fluxo de dados à mão, olhar logs, reconstruir o que aconteceu. A abordagem razoável de um engenheiro pra debug. Funcionava.

Agora, “fazer debug de um problema” significa: pedir ao agente pra inspecionar o estado persistido, pedir ao agente pra replay de uma fatia do pipeline com inputs mockados, pedir ao agente pra resumir o trace. Ações diferentes. As ações em si não são o que mudou.

O que mudou é a pergunta que faço primeiro. Dois anos atrás, minha primeira pergunta era “o que o código está fazendo?”. Agora minha primeira pergunta é “em que estado o sistema está?”. A mudança de código pra sistema é pequena em palavras. É enorme na prática. Muda qual evidência eu olho primeiro, quais intuições confio, quais tipos de bugs espero encontrar.

Esse é o segundo loop em ação. As ferramentas tornaram barato inspecionar estado. Inspeção barata de estado virou meu movimento padrão. Esse default reformulou quais perguntas eu faço. As perguntas reformuladas agora operam num nível de abstração diferente do que costumavam.

Algumas mudanças específicas que percebi

Alguns exemplos concretos de como o formato mental mudado se parece.

Agora penso em pipelines primeiro, código depois. Antes de todo esse ferramental, meu modelo mental de qualquer projeto era um grafo de arquivos e funções. Eu navegava por nome. Agora meu modelo mental é um grafo de estágios — input, processamento, persistência, output, comunicação — e os arquivos são coisas que implementam os estágios. A visão pipeline-primeiro veio de passar meses trabalhando com sistemas explicitamente em formato de pipeline, onde a máquina de estados do agente tem estágios nomeados e as skills de debug os inspecionam. A visão pipeline-primeiro migrou pra como penso sobre outros sistemas também, inclusive os que não têm pipelines explícitos.

Percebo o custo de perguntar antes do custo de responder. Quando estou tentando descobrir algo, a primeira coisa que avalio agora não é “quão difícil é a resposta?” mas “quão barato é tornar essa pergunta perguntável?”. Se a pergunta não é expressável como input pra nenhuma ferramenta que tenho, eu percebo. Às vezes esse perceber é sinal de que deveria escrever uma ferramenta. Às vezes é sinal de que a pergunta ainda não está bem formulada. De qualquer forma, transformar a pergunta em input de ferramenta virou o primeiro movimento.

Trato meu eu-do-futuro como uma audiência que precisa de input estruturado. Esse é o efeito do journaling. Quando algo acontece que o eu-do-futuro vai precisar lembrar, escrevo numa forma que é estruturada, pesquisável e desacoplada do histórico de chat desta semana. A mudança é de armazenar memória em conversa pra armazenar memória em artefatos. Parece um pequeno hábito organizacional. Na verdade é um modelo diferente de como conhecimento se acumula ao longo do tempo.

Peço ao agente pra empurrar de volta antes de me comprometer com um plano. O post de guardrails comportamentais é a fonte desse. A rule “Think Before Coding” pede ao agente pra levantar premissas, propor alternativas, e empurrar de volta quando justificado. Uma vez que esse padrão virou real, comecei a pré-aplicá-lo no meu próprio pensamento. Antes de me comprometer com um plano, agora rodo a mesma checagem em mim mesmo: o que estou pressupondo? quais alternativas não considerei? qual é a versão mais simples disso? A disciplina do agente virou minha disciplina.

Meu default é mudanças cirúrgicas. Mesma fonte. A rule “Surgical Changes” codifica o teste de que cada linha alterada deve se ligar diretamente ao pedido do usuário. Uma vez que operei com essa rule por um tempo, comecei a aplicá-la ao meu próprio trabalho, incluindo trabalho em que o agente não está envolvido. “Por que estou mexendo nisso?” é agora uma pergunta que me faço reflexivamente ao revisar meus próprios diffs.

Em cada caso, uma constraint ou padrão que codifiquei no ferramental de IA migrou pra cima, pro meu próprio pensamento. O agente não me ensinou essas coisas — a maioria delas já era higiene de engenharia com a qual eu teoricamente concordava. O que mudou é que operar um agente que aplicava consistentemente esses padrões fez eles parecerem menos aspirações e mais o formato real do trabalho.

O que realmente está acontecendo, num nível um pouco mais profundo

Quando você passa muito tempo operando num sistema com certas formas — pipelines explícitos, artefatos estruturados, rules escritas, revisões auditadas — essas formas ficam disponíveis pro seu pensamento mesmo fora do sistema. Cientistas cognitivos têm um nome pra algo assim; a prática de modelos mentais serem moldados pelo uso repetido de ferramentas não é nova. A coisa nova, pra mim, é observar isso acontecer com ferramental de IA especificamente, onde as formas que você está internalizando não são a forma de uma calculadora ou uma linguagem de programação, mas a forma de um jeito estruturado de decompor problemas e atribuir sub-problemas a handlers especializados.

Cada ferramenta é uma instância concreta de um hábito mais amplo: codifique as convenções, guarde os procedimentos, especialize os papéis, persista os registros, desacople do runtime. Esses hábitos não são novos. O que é novo é ter um sistema que exige que eu os pratique todo dia, porque o sistema fica pior quando eu não faço isso.

Essa exigência é a disciplina. A disciplina reformula como eu penso.

Por que isso importa além de mim

Se o segundo loop é real — se trabalhar dentro de sistemas de IA bem moldados reformula silenciosamente os hábitos cognitivos do engenheiro — então a pergunta de quais sistemas de IA nós construímos, hoje é muito maior do que a pergunta de quais features entregam na próxima release. Os sistemas são formativos. Os hábitos que instalam nos seus usuários vão sobreviver a qualquer ferramenta específica.

Sistemas ruins instalam hábitos ruins. Um sistema que encoraja aceitação rápida de output que parece plausível instala um hábito de baixo escrutínio. Um sistema que esconde seu raciocínio instala um hábito de confiança sem curiosidade. Um sistema que recompensa verbosidade instala um hábito de inflação. Essas não são preocupações hipotéticas; são padrões que vi em workflows ao meu redor, e já me peguei escorregando neles em dias ruins.

Sistemas bons instalam hábitos bons. Um sistema que empurra de volta, levanta premissas, pede critérios de sucesso explícitos, audita seu próprio output, e persiste suas decisões em artefatos legíveis instala hábitos de rigor, estrutura e humildade. Esses também não são hipotéticos; são os hábitos que vi desenvolver em mim mesmo nos projetos onde o sistema foi moldado corretamente.

A escolha de qual tipo de sistema construir pra si mesmo, e qual tipo encorajar no seu time, é mais consequente do que parece no início. O sistema não está apenas ajudando com tarefas. O sistema está te ensinando, devagar, como pensar.

O fechamento honesto

Três meses é uma janela curta pra afirmações sobre formato mental. Eu gostaria de voltar a isso em um ano e ver se os padrões se estabilizaram ou se foram a novidade temporária de uma ferramenta nova.

O que eu tenho certeza é do perceber. Algo tem sido silenciosamente diferente em como abordo problemas, e senti isso sem procurar. O primeiro loop — ferramentas economizam tempo — é o que todo mundo fala. O segundo loop — trabalho mudado muda como pensamos sobre trabalho — é o que acho que vai se mostrar mais importante, no longo prazo, pras pessoas que se inclinarem nele deliberadamente.

Esse é o post inteiro. As ferramentas que construímos moldam como pensamos. Sabíamos disso sobre martelos e canetas. Também é verdade sobre agentes de IA, e a moldagem acontece quer a gente perceba ou não. Melhor perceber e moldar a moldagem, enquanto ainda podemos.