⏱️ 7 min de leitura
No capítulo anterior, Refinar antes ou reagir depois? (capítulo 7), a fábrica terminou com regras novas no código. Este capítulo é sobre um conserto que nenhuma regra previu, e que veio antes de todas elas: na primeira noite, às 22h23.
Já contei esse susto em poucas linhas em Escala 6x1? Aqui é 24x7 (capítulo 1) e em Dormi e acordei com o trabalho pronto (capítulo 3). Aqui conto os 24 minutos inteiros, e por que uma decisão que eu tinha tomado sem dar muita importância virou uma decisão de arquitetura: guardar todo o estado do aplicativo em arquivos que uma pessoa, ou uma IA, consegue ler.
Uma decisão quase sem querer
Desde o começo, o aplicativo não tem banco de dados. Tudo o que ele sabe fica em arquivos de texto em uma pasta de trabalho: o backlog, o roadmap e cada execução, com um registro do que aconteceu passo a passo. Esse registro só recebe linhas novas no fim. Nunca apaga nem reescreve nada.
Eu não escolhi isso pensando em IA. Era só o jeito mais rápido de começar. Naquela noite, descobri um efeito que eu não tinha planejado.
22h23: duas cópias, um roadmap
A primeira etapa do primeiro roadmap do PO tinha começado às 21h25. Às 22h23, eu abri sem querer uma segunda cópia do aplicativo e ela apontava para a mesma pasta de trabalho.
A cópia nova bagunçou o que estava rodando:
- Marcou como interrompidas execuções que estavam vivas na outra cópia.
- Criou três duplicatas, para refazer o trabalho que achou perdido.
- Pausou o roadmap, apontando para execuções canceladas.
No pico, o painel mostrava seis execuções ao mesmo tempo, contando as duplicatas. A primeira noite inteira da fábrica estava parada antes de começar.
"Não consegue consertar para mim?"
Passei um bom tempo tentando entender o que tinha acontecido, até fazer a pergunta que deveria ter feito antes:
"Não consegue consertar para mim?"
Uso aqui a legenda de O gargalo não é o código, é o teste (capítulo 4): ⚙️ o motor é o orquestrador, um programa comum, sem IA; 🤖 o agente é uma IA fazendo o trabalho. Aquele conserto foi todo do agente, o Claude, na sessão em que eu conversava com ele, fora do aplicativo:
- 🤖 Ler antes de mexer: ele leu o código que grava o roadmap e confirmou que o aplicativo relê o arquivo a cada operação. Uma mudança no arquivo valeria na hora, sem fechar nada.
- 🤖 Backup: copiou o arquivo do roadmap antes de tocar nele.
- 🤖 Reapontar e soltar: cancelou as três duplicatas, apontou cada item para a execução real, retomou as duas que tinham sido marcadas como interrompidas e tirou a pausa.
Em dois minutos, o roadmap voltou a rodar, sem perder trabalho. Às 22h47, a noite estava de pé. Naquela mesma noite, escrevi no diário do projeto:
"Ter os arquivos locais permite que eu tenha uma IA que ajusta problemas em tempo real. [...] Eu ajustei via IA, é como se eu tivesse super poderes."
E se fosse um banco de dados?
O problema seria o mesmo: duas cópias escrevendo no mesmo lugar. O conserto, não. A IA teria que descobrir como o banco está organizado, conseguir acesso a ele e escrever uma migração ou um script para corrigir os registros. Tudo isso com o roadmap parado, às dez da noite.
Um banco de dados é feito para um programa ler e escrever. Um arquivo de texto é feito para qualquer um ler, e esse qualquer um, hoje, inclui uma IA. Ela leu o roadmap como eu leria, só que em segundos.
Um sistema que a IA consegue ler é um sistema que a IA consegue consertar.
O defeito e o superpoder
O capítulo 1 já tinha avisado: o defeito e o superpoder têm a mesma origem. Um banco de dados tem trava: quando um programa escreve, o outro espera. Arquivo não tem. A mesma abertura que deixou a IA consertar o estado deixou a segunda cópia estragá-lo. E o conserto só aconteceu porque eu estava acordado. Às três da manhã, eu teria acordado com uma noite perdida.
Para o superpoder ficar seguro, faltavam três travas. A primeira etapa do dia seguinte, que abri às 08h47, foi sobre elas, e às 09h11 as três estavam no código:
- ⚙️ Um escritor por vez: só uma cópia do aplicativo abre cada pasta de trabalho. Cada execução sabe qual cópia é a dona dela, e o roadmap só mexe em execução que está de fato morta.
- ⚙️ Escrita completa ou nenhuma: o arquivo de estado nunca fica pela metade. Ou a versão nova entra inteira, ou fica a antiga.
- ⚙️ Estado tirado dos eventos: a situação de cada item do roadmap passou a ser calculada a partir do registro das execuções, o que só recebe linhas novas. Se o roadmap ficar errado de novo, consertar vira recalcular.
O conserto daquela noite foi trabalho de agente, porque ninguém sabia o que tinha dado errado e era preciso julgar. As travas são trabalho de motor, porque agora a gente sabe, e o que já se sabe não precisa de uma IA para ser feito toda vez.
AI first
Dois dias depois, na noite de 2 de outubro, olhando a fábrica rodar, escrevi:
"Acho que entendi o que é criar aplicações AI first. Como tudo está integrado com a IA (o sistema de arquivos e as permissões), eu posso ir dormir, e o Claude consegue dar sequência ao fluxo de desenvolvimento e também à execução do app. Isso é incrível."
A IA não só escreve o código do aplicativo. Ela também o opera: lê o roadmap, entende em que pé está cada execução e, quando algo trava, mexe no estado.
Perguntei se alguém já tinha escrito sobre isso. Já. O nome que pegou lá fora é agent-native: um aplicativo pensado para ser operado por agentes de IA, e não só por pessoas. O Claude achou um grupo pequeno de textos de 2025 e 2026, e eles concordam no essencial:
- Estado legível: o agente precisa ler o que o sistema sabe, em arquivos ou em um registro de eventos.
- As mesmas ações: tudo o que a tela faz, o agente também consegue fazer.
- Permissão na medida do risco: o agente faz sozinho o que dá para desfazer e pede licença para o resto.
Os textos que mais conversam com a fábrica:
- Every, no guia de Dan Shipper: os arquivos são a interface universal, e o agente faz tudo o que a tela faz.
- HumanLayer, no 12-Factor Agents: o registro de eventos é a fonte única da verdade, e o resto é uma visão calculada a partir dele. É a terceira trava, que eu aprendi do jeito difícil.
- Builder.io: também põe pessoas e agentes operando o mesmo produto, mas coordena tudo em um banco de dados.
- Ink & Switch, com o local-first, de 2019: os dados são seus, em arquivos no seu computador. A minha decisão de não ter banco é, no fundo, isso. Eu só acrescentaria um ideal à lista deles: ser operável por uma IA.
O que não achei em nenhum desses textos foi as duas coisas juntas: a mesma IA desenvolvendo o aplicativo à noite e consertando o estado dele quando ele trava.
O preço dos arquivos
Arquivo legível não sai de graça. Alguns dias depois do susto, escrevi:
"Tem também o outro lado da decisão de não ter banco de dados. A quantidade de arquivos está crescendo, e algumas telas estão ficando carregadas."
Na noite do susto, a pasta de trabalho já tinha cerca de 4,4 GB, com 67 execuções. Quase 4 GB eram as cópias isoladas do projeto, cada uma com a própria cópia das bibliotecas do aplicativo. E as telas ficavam lentas porque, para montar uma lista, o aplicativo lia o registro de muitas execuções. As saídas não abrem mão dos arquivos:
- Um índice ao lado: uma tabela pequena, gerada a partir dos arquivos, só para as consultas das telas. Entrou na própria primeira noite, às 01h33. Se estragar, é só gerar de novo.
- Paginação: as telas já carregam um pedaço da lista por vez.
- Arquivo morto: o próximo passo, levar os registros antigos para um armazenamento fora do computador.
O custo que mais pesa não é o disco. Um estado que a IA lê também pode ser manipulado por um texto malicioso: uma instrução escondida em uma tarefa ou na saída de uma execução. Quanto mais autonomia a IA tem à noite, mais isso importa. Por isso o vigia noturno do capítulo 3 trata o que lê como informação, nunca como ordem, e só faz sozinho o que dá para desfazer. Responder a uma aprovação continua sendo só comigo.
O próximo passo
O conserto daquela noite foi feito pelo Claude de fora do aplicativo, a meu pedido. O passo natural seguinte era o próprio aplicativo fazer isso de dentro, sem eu pedir. Poucos dias depois, ele estava indo além: lendo os próprios registros, achando os próprios defeitos e escrevendo o código que os corrige.
No próximo capítulo, capítulo 9, O barco de Teseu: quando o software reescreve a si mesmo, conto o que acontece quando a ferramenta passa a trocar as próprias peças, uma a uma, e a pergunta que isso me fez: ainda é o mesmo software, e o que sobra para mim?
Referências
- Agent-native Architectures, Every, Dan Shipper
- Agent-Native: The Next Architecture for Software, Builder.io, Vishwas Gopinath
- 12-Factor Agents, HumanLayer, Dex Horthy
- Effective harnesses for long-running agents, Anthropic
- Effective context engineering for AI agents, Anthropic
- Ralph Wiggum loop, sobre a ideia de Geoffrey Huntley
- Software 3.0, Andrej Karpathy
- Local-first software, Ink & Switch, Kleppmann e outros