# Um sistema que a IA lê, a IA conserta · Diário da fábrica URL: https://www.edugalbs.com/fabrica-24x7/capitulos/um-sistema-que-a-ia-le > Todo o estado em arquivos legíveis: quando duas cópias do app bagunçaram o roadmap, a IA leu, entendeu e consertou em dois minutos. Capítulo 08 · 2 de novembro de 2026 ## Um sistema que a IA lê, a IA conserta Todo o estado em arquivos legíveis: quando duas cópias do app bagunçaram o roadmap, a IA leu, entendeu e consertou em dois minutos. ⏱️ 7 min de leitura **TL;DR** O capítulo conta a noite em que uma segunda cópia do aplicativo bagunçou o roadmap e a IA o consertou em dois minutos, lendo os arquivos de estado. Fala da decisão de não usar banco de dados, das três travas que o motor ganhou na manhã seguinte, do nome que essa ideia tem lá fora, agent-native, e do preço que ela cobra. No capítulo anterior, [**Refinar antes ou reagir depois?**](https://www.edugalbs.com/fabrica-24x7/capitulos/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**](https://www.edugalbs.com/fabrica-24x7/capitulos/escala-24x7) (capítulo 1) e em [**Dormi e acordei com o trabalho pronto**](https://www.edugalbs.com/fabrica-24x7/capitulos/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**](https://www.edugalbs.com/fabrica-24x7/capitulos/o-gargalo-e-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. ![Tabela em três colunas ligadas por setas. Em vermelho, o que deu errado às 22h23: duas cópias do app na mesma pasta, execuções vivas tratadas como mortas e três duplicatas, o roadmap pausado em execuções canceladas. Em laranja, o conserto à mão do agente: ler o código, cancelar as duplicatas e retomar as duas execuções, fazer backup e reapontar. Em verde-azulado, a trava que o motor ganhou na manhã seguinte para cada um: uma cópia por pasta, o roadmap só mexendo em execução morta, o estado calculado dos eventos com escrita completa ou nenhuma](https://www.edugalbs.com/fabrica-24x7/media/capitulo-08-tres-travas.png) 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. ![Mapa com a fábrica no centro, ligada a oito textos. Encaixam: Every, de Dan Shipper, 12-Factor Agents e dois textos da Anthropic. Encaixam e tensionam: local-first, Karpathy e o Ralph loop, a IA em loop a noite toda. Contradiz em parte: Builder.io, as mesmas ações, mas em um banco SQL](https://www.edugalbs.com/fabrica-24x7/media/capitulo-08-fontes.png) 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](https://every.to/guides/agent-native), Every, Dan Shipper - [Agent-Native: The Next Architecture for Software](https://www.builder.io/blog/agent-native-architecture), Builder.io, Vishwas Gopinath - [12-Factor Agents](https://github.com/humanlayer/12-factor-agents), HumanLayer, Dex Horthy - [Effective harnesses for long-running agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents), Anthropic - [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents), Anthropic - [Ralph Wiggum loop](https://paddo.dev/blog/ralph-wiggum-autonomous-loops/), sobre a ideia de Geoffrey Huntley - [Software 3.0](https://www.latent.space/p/s3), Andrej Karpathy - [Local-first software](https://www.inkandswitch.com/local-first/static/local-first.pdf), Ink & Switch, Kleppmann e outros Próximo capítulo**O barco de Teseu: quando o software reescreve a si mesmo**Sai em breve. Assine para receber quando sair. [← Todos os capítulos](https://www.edugalbs.com/fabrica-24x7) Newsletter ### Receba os próximos capítulos. Um e-mail quando sair um capítulo novo. Sem spam, e você sai quando quiser.