Quando falam de escala 6x1, eu penso em outra conta. Aqui a escala é 24x7. E não sou eu que trabalho 24 horas por dia: é a fábrica de software agêntica que eu construí, por hobby, em pouco mais de uma semana.
Este é o primeiro capítulo de um diário. Vou contar o que estou construindo, como cheguei até aqui, o que deu errado no caminho e o que aprendi com isso. Nos próximos capítulos, cada aprendizado ganha um texto próprio, com os dados e com os erros. Por exemplo, por que o gargalo não é o código (capítulo 4) e por que o git foi feito para humanos (capítulo 6).
Como começou
Num sábado à noite, eu tive uma ideia simples: e se eu conseguisse abrir várias sessões de IA ao mesmo tempo, cada uma cuidando de uma parte do trabalho? Uma escreve o código, outra escreve os testes, outra revisa. Talvez dê para fazer com alguns terminais e um script.
Não ficou nos terminais. Na mesma noite a ideia virou um aplicativo de desktop com um motor que segue um fluxo de trabalho definido em um arquivo de configuração. Cada etapa do fluxo é executada por um agente de IA (Claude, Codex ou Grok), e o motor só decide qual é a próxima etapa. Ele não improvisa.
Essa foi a primeira decisão importante, e eu só entendi o tamanho dela depois. A parte que decide "o que vem agora" é código comum, previsível, que faz sempre a mesma coisa. A IA só entra onde precisa de inteligência: escrever, testar, revisar. Isso deixa o processo auditável. Quando algo dá errado, eu sei exatamente em que etapa foi e por quê.
O fluxo é o mesmo que um time de desenvolvimento seguiria:
- Desenvolver: um agente implementa a tarefa numa cópia isolada do projeto, sem mexer no que já está funcionando.
- Testar: outro agente, que não escreveu o código, escreve os testes.
- Revisar: um terceiro revisa, de preferência usando um modelo diferente do que escreveu. Uma IA revisando o trabalho de outra pega coisas que a primeira não veria.
- Aprovar: o código só entra se passar pelos testes e pela revisão. Nos pontos em que eu quero decidir, o fluxo para e espera por mim. Nenhuma automação passa por cima dessa aprovação.
Ainda naquela noite entraram as etapas de build, de integração contínua e de um ambiente de teste para cada mudança. Fui dormir com um esqueleto que já parecia uma esteira de produção. Foi o começo do que hoje se chama de fábrica de software agêntica: uma fábrica de software em que cada etapa é executada por agentes de IA, e as pessoas decidem o que construir e aprovam o que entra.
O domingo: a primeira execução real, e o primeiro erro
No domingo eu fiz o que todo mundo faz com um brinquedo novo: coloquei para rodar de verdade.
A primeira execução real falhou. Um detalhe na forma como a resposta de um agente era validada derrubou o fluxo no final. A segunda, já com o fluxo completo de desenvolvimento, funcionou, mas levou quase 40 minutos, e a etapa de integração contínua rodou quatro vezes seguidas até passar. Ali eu tive a primeira pista de que o problema não seria escrever código. Essa pista virou o capítulo 4, O gargalo não é o código, é o teste.
Foi no domingo também que nasceu o supervisor: uma IA que só entra em cena quando alguma etapa falha. Ele investiga o que aconteceu e propõe como destravar.
Na primeira vez que ele trabalhou, sugeriu corrigir o código direto. Parecia útil, mas eu percebi o risco: um supervisor que conserta código por fora do fluxo pula exatamente as etapas que dão segurança, como teste, revisão e aprovação. Redefini o papel dele ali mesmo. O supervisor cuida do fluxo, não do código. Quando o problema está no código, ele devolve a tarefa para os agentes do fluxo, com as evidências e as hipóteses, e o código passa por todas as etapas de novo.
Essa regra virou um princípio do projeto: a automação nunca atravessa uma aprovação humana, nem o supervisor.
Segunda-feira, o dia calmo
A segunda-feira foi o dia mais tranquilo da semana. Nenhuma execução, poucos pedidos. Foi dia de arquitetura: separar o motor da interface, endurecer a segurança do aplicativo e escrever um documento de contexto que todo agente lê antes de começar. Esse documento nasceu de uma emergência: a conversa com a IA ficou tão longa que estava chegando no limite de memória, e eu pedi um resumo de tudo. O resumo virou o manual da casa.
Olhando para trás, foi esse dia calmo que tornou possível o que veio depois.
O dia em que a ferramenta começou a se desenvolver
Na terça, eu abri várias sessões em paralelo, cada uma numa cópia isolada do projeto, e quase todas começavam do mesmo jeito: "roda a aplicação para eu ver".
No meio da tarde, abri uma sessão só para anotar ideias num arquivo de texto. Quinze minutos depois, as ideias já eram tarefas registradas, e o aplicativo ganhou uma tela de backlog, onde cada tarefa pode ser entregue a um fluxo. Até a meia-noite foram mais de 50 tarefas registradas, quase todas nascidas de uma conversa.
E então eu passei a mandar a própria ferramenta resolver as tarefas.
Por volta das 16h40, a primeira tarefa foi entregue pela própria ferramenta. Quase no mesmo minuto, eu escrevi uma frase para o Claude que hoje parece uma previsão: que eu não ia abandonar ele, ia continuar usando, só que, dali a pouco, dentro da minha ferramenta.
Uma hora depois, por volta das 17h, aconteceu a virada: a ferramenta passou a gerar mais trabalho de IA do que eu, usando a IA diretamente. A partir daí, a curva não voltou mais. Em poucos dias, mais de 90% do trabalho de IA no projeto estava saindo da ferramenta. As minhas sessões mudaram de função: em vez de escrever código, eu acompanhava, diagnosticava e decidia. Essa virada tem um capítulo só dela: O dia em que a IA saiu do meu volante (capítulo 2).
Cinco agentes, um arquivo
Na terça à noite, empolgado, coloquei cinco tarefas para rodar ao mesmo tempo.
Cada agente trabalhava na sua própria cópia do projeto, sem atrapalhar os outros. Funcionou muito bem até o final, quando chegou a hora de juntar tudo. Quatro das cinco falharam no último passo, por conflito: dois agentes tinham mexido no mesmo trecho de um arquivo. Todo o trabalho já tinha sido feito e pago, e travou na porta de saída.
Essa noite me ensinou uma lição: paralelismo é barato para começar e caro para terminar. Conto essa história no capítulo 6, O git foi feito para humanos. As respostas vieram em camadas:
- Agrupar tarefas relacionadas numa mesma execução, para trocar vários conflitos por um único caminho.
- Juntar o trabalho localmente, no meu próprio computador, em vez de depender de um serviço externo a cada mudança. Isso tirou do ciclo curto as filas e os minutos de integração contínua que eu não controlava. A taxa de sucesso das execuções saltou de cerca de metade para mais de nove em cada dez.
- Planejar antes, em vez de resolver o conflito depois.
E foi essa última camada que abriu caminho para a primeira noite.
A primeira noite
Para deixar o computador trabalhando sozinho, faltava alguém para organizar o trabalho. Então criei um Product Owner de IA.
Ele lê o backlog e monta um roteiro em etapas. Para cada grupo de tarefas, ele prevê quais arquivos vão ser mexidos, aponta onde pode haver conflito e separa em etapas diferentes as tarefas que iriam brigar pelo mesmo arquivo. A resolução de conflito saiu do momento de juntar o código e foi para o momento do plano. Durante o dia, eu escrevo as ideias. À noite, o roteiro roda.
Lembro da última mensagem que mandei naquela noite: "cancela o monitor, vou dormir e deixar o PC rodando".
O roteiro rodou em duas frentes paralelas. Às 23h30, as duas primeiras tarefas. Quase à uma da manhã, as duas seguintes. Depois às 01h30, às 02h30 e às 03h. A última execução terminou às quatro da manhã.
Acordei com 10 tarefas entregues, testadas e integradas. Nenhuma falhou. Nenhuma mensagem minha entre meia-noite e sete da manhã. E entre as tarefas daquela noite estava uma que deixava o próprio supervisor de plantão. A ferramenta estava, literalmente, melhorando a si mesma enquanto eu dormia.
A máquina só parou às quatro porque o roteiro acabou. Não tinha mais trabalho planejado. Esse detalhe mudou a forma como eu penso o projeto: para 24x7, o que mais importa talvez seja quantas horas de trabalho bem definido estão prontas quando eu vou dormir. Os bastidores dessa noite, hora a hora, estão no capítulo 3, Dormi e acordei com o trabalho pronto.
A noite em que tudo quase deu errado
Nem tudo foi tranquilo. Uma hora antes de a primeira noite começar, eu abri sem querer uma segunda cópia do aplicativo, apontando para a mesma pasta de trabalho. As duas começaram a escrever no mesmo estado ao mesmo tempo. Execuções que estavam vivas foram marcadas como interrompidas, apareceram execuções duplicadas e o roteiro parou, apontando para tarefas canceladas.
Eu perguntei para a IA: "não consegue consertar para mim?".
E ela conseguiu. Como todo o estado do aplicativo fica em arquivos legíveis, e não num banco de dados fechado, a IA leu o código que grava o roteiro, entendeu o formato, fez um backup, apontou cada item para a execução certa e tirou a pausa. Em dois minutos o roteiro voltou a rodar, sem perder trabalho. Naquela hora, eu senti que tinha superpoderes.
O defeito e o superpoder tinham a mesma origem: arquivos não têm trava. Dois processos escreveram no mesmo lugar. A correção definitiva virou tarefa no mesmo dia, e hoje o aplicativo garante uma única instância por pasta de trabalho. Mas a lição ficou: um sistema que a IA consegue ler é um sistema que a IA consegue consertar. Essa ideia, de guardar tudo em arquivos que a IA consegue ler, tem um capítulo próprio: Um sistema que a IA lê, a IA conserta (capítulo 8).
A segunda noite: sem parar
Antes da segunda noite, a ferramenta passou o fim de tarde reorganizando o próprio código para que vários agentes pudessem trabalhar ao mesmo tempo sem esbarrar uns nos outros. Telas separadas em arquivos próprios, listas com uma entrada por linha, tabelas geradas automaticamente. Nenhuma mudança de comportamento, só de formato. Parece pouco, mas é o que permitiu escalar.
E escalou. Na segunda noite a máquina não parou. Foram cerca de 25 tarefas, mais que o dobro da primeira, com até 5 agentes trabalhando ao mesmo tempo. Houve quatro conflitos, e os quatro foram resolvidos sem mim. Às sete da manhã ainda tinha execução rodando.
Teve uma única trava, e eu gosto dela. De madrugada, uma tarefa chegou num ponto em que o fluxo exige a minha aprovação. Ela ficou parada mais de duas horas, esperando eu acordar. É exatamente o comportamento certo: a máquina trabalha a noite inteira, mas não decide no meu lugar o que é decisão minha.
Na mesma noite, os créditos de um dos provedores de IA acabaram, e o revisor passou a usar outro modelo. Até então, eu achava que crédito de IA nunca seria o limite. Com cinco agentes em paralelo, o consumo por hora mais que dobra.
O gargalo que anda
No dia seguinte, coloquei quatro execuções pesadas em paralelo, e o meu computador travou. Tive que cancelar tudo.
Foi aí que eu percebi um padrão. O gargalo nunca some, ele muda de lugar. Primeiro era o serviço externo de integração contínua. Depois, os conflitos na hora de juntar o código. Depois, a forma como o código estava organizado. Depois, o planejamento. Agora era a própria máquina: processador e memória. A resposta foi parecida com a de um time humano: deixar os testes mais pesados para o fechamento de uma versão, e não para cada tarefa.
Na noite seguinte, o custo dos testes por execução caiu para uma fração do que era. E o gargalo andou de novo: agora é o tempo que a suíte de testes leva para rodar. Essa história continua no capítulo 4.
Duas horas minhas, 22 horas da IA
Quando a ficha caiu, foi chocante. Eu não tinha noção do que é ter agentes trabalhando 24 por 7.
Se eu organizar bem os fluxos, os agentes e o backlog, posso interagir com o sistema por duas horas por dia. Na primeira hora, reviso o que foi feito durante a noite e aprovo ou peço correções. Na segunda, preparo o trabalho das próximas 24 horas. O resto é a IA trabalhando.
Este projeto é o que eu faço nas horas que sobram. E foi justamente isso que mudou minha cabeça: duas horas por dia de uma pessoa podem virar 24 horas de trabalho, desde que exista trabalho bem definido para fazer.
E trabalho nunca falta. Pergunte em qualquer empresa se tem coisa para fazer em tecnologia, e a resposta é sempre a mesma: tem um milhão de coisas. O que falta é definir, organizar num backlog e ter uma esteira que execute com qualidade. O backlog é o combustível da fábrica agêntica.
Ainda não cheguei nas duas horas. Na segunda noite, eu ainda mandei mais de cem mensagens ao longo do dia, boa parte delas para planejar a noite. Mas o caminho ficou claro: o limite deixou de ser o meu tempo.
O que aprendi até aqui
Os números chamam atenção, mas o que mais valeu foram as surpresas. Quase todas vão virar um capítulo.
O gargalo não é escrever código, é testar (capítulo 4). Somando o tempo das etapas, os testes levaram mais tempo do que o desenvolvimento. Boa parte desse tempo era um agente esperando um comando terminar, com condições que nunca se cumpriam. Ajustar os testes reduziu o custo dessa etapa para uma fração do que era.
O token mais caro é o de uma IA esperando (capítulo 5). A execução mais cara do projeto não entregou nada. Um agente passou o tempo consultando, de novo e de novo, se um processo tinha terminado, bloqueado por uma permissão que ele não tinha. Esperar, consultar status e comparar resultados é trabalho para código comum. A IA entra quando existe uma decisão a tomar.
O git foi feito para humanos (capítulo 6). Pessoas mexem em poucas linhas por vez. Agentes em paralelo, não. Dois agentes que acrescentam uma linha no fim da mesma lista entram em conflito, mesmo sem nenhuma contradição real entre eles. Com vários agentes, até o formato dos arquivos passa a ser uma decisão de arquitetura.
Refinar antes ou reagir depois? (capítulo 7) O jeito tradicional investe pesado no começo: refinamento, protótipo, tentar prever cada detalhe. Quando gerar fica barato, acordar com uma proposta pronta e dizer "não é isso, é assim" sai mais barato do que tentar descrever tudo no vazio. O incremento funcionando vira a especificação mais barata que existe.
O que eu peço três vezes vira automação. "Roda a aplicação para eu ver" virou uma etapa que gera evidências de cada entrega, com capturas de tela e registros. "Registra isso como tarefa" virou um fluxo próprio. Até o ditado por voz que eu usava virou funcionalidade. Os meus pedidos repetidos foram, quase sempre, a próxima peça do produto.
Uma semana em números
- Mais de 200 commits desde o primeiro, num sábado à noite.
- Mais de uma centena de tarefas registradas, quase todas nascidas de uma conversa.
- 10 tarefas na primeira noite e cerca de 25 na segunda, com até 5 agentes ao mesmo tempo.
- Mais de 90% do trabalho de IA no projeto saindo da própria ferramenta.
- Nenhuma aprovação humana atravessada pela automação.
Por que estou escrevendo isto
Não estou vendendo nada. É um projeto de hobby, e escrever é a forma que encontrei de organizar o que estou aprendendo. Tenho a impressão de que a forma de construir software está mudando rápido, e quero registrar isso de dentro, com dados reais, enquanto acontece. Inclusive os erros.
No próximo capítulo, conto o dia em que a IA saiu do meu volante: como foi a virada em que a ferramenta passou a fazer mais do que eu, e o que muda quando você deixa de ser quem programa e passa a ser quem decide.
E, no último capítulo, uma conversa com a IA sobre o barco de Teseu, que eu não esperava ter.