Eu montei uma equipe de IAs que cuida dos meus projetos 24/7

Todo mundo que já usou uma IA pra trabalhar conhece a frustração: você passa horas construindo algo junto com ela e, quando a conversa fica longa demais, a sessão acaba, e a IA esquece tudo. É como ter um funcionário brilhante que perde a memória no meio do expediente, todos os dias. Foi esse problema que me fez começar este projeto: em vez de aceitar o esquecimento, construí uma memória externa que nenhuma sessão consegue apagar.

Hoje isso cresceu pra algo maior do que eu planejei. Duas frentes de IA diferentes, o Claude e o opencode (que me deixa alternar entre modelos como Kimi K3 e GPT 5.6), trabalham nos meus projetos dividindo a mesma memória, um daemon (um programa que roda sozinho, 24 horas por dia) cuida de revisão e correção de código sem que eu peça, e um painel me deixa colocar qualquer projeto no ar com um clique. Este artigo conta como cada peça surgiu, quase sempre por causa de um problema real que doeu primeiro.

Uma memória que ninguém perde

A base do sistema é simples de explicar: arquivos de texto compartilhados que funcionam como o caderno de anotações de uma equipe. O que está sendo feito agora, o que ficou pendente, quais decisões foram tomadas e por quê. Toda vez que uma IA conclui uma etapa (salvou um arquivo, passou um teste), ela é obrigada a anotar um 'checkpoint' nesse caderno. Se a sessão morrer no minuto seguinte, nada se perde: o próximo modelo (ou o mesmo, numa sessão nova) lê o último checkpoint e continua exatamente de onde parou. Chamo essa troca de bastão de handoff, como numa corrida de revezamento.

O detalhe mais importante é que a passagem do bastão acontece sozinha. Quando a IA percebe que está chegando perto do limite de memória da sessão, ela entra em modo de 'pouso suave': para de aceitar tarefa nova, termina o que está no meio pra não deixar nada quebrado, escreve o checkpoint final e publica o handoff. Eu não preciso pedir, o sistema se preserva sozinho.

Quando a memória cresce demais, ela aprende a arquivar

Com meses de uso, o caderno virou um livro, e apareceu um problema irônico: a memória que existia pra economizar trabalho estava custando caro só de ler. Cada sessão nova começava engolindo o histórico inteiro. A solução foi a mesma que qualquer escritório usa: mesa de trabalho e arquivo morto. O que é recente e pendente fica numa área 'quente', pequena de propósito; todo o resto vai pra um arquivo organizado por mês, que só é consultado quando alguém precisa, por busca de termo exato ou por busca semântica, aquela que entende o sentido da pergunta e não só as palavras. O custo de iniciar uma sessão caiu pra menos de um décimo do que era.

Cinco revisores que não dormem

A parte que mais me orgulha é o ciclo de revisão de código. Funciona como uma linha de montagem com cinco agentes, cada um com um papel: o primeiro lê as mudanças recentes de um projeto e aponta problemas, como um revisor humano faria. O segundo é um cético profissional, recebe a lista de problemas e tenta derrubar cada um antes que vire comentário público, porque IA também inventa defeito que não existe. O terceiro pega os problemas confirmados e corrige, um por um, abrindo uma proposta de mudança no GitHub. O quarto confere se a correção realmente resolveu o que foi pedido. E o quinto entra quando os testes automáticos quebram por um motivo banal: lê o log de erro, acha o arquivo culpado e conserta sozinho.

Isso não nasceu confiável. No começo, o revisor comentava coisas como 'verifique se tal rota está registrada', e a rota estava registrada, num arquivo que ele nunca tinha visto. A cura não foi pedir educadamente pra IA 'ser mais precisa'; foi mudar as regras do jogo: todo problema apontado agora precisa citar a linha exata de código que o comprova. Sem evidência, não é achado, é palpite, e palpite é descartado por um filtro automático antes de chegar perto do GitHub. Depois dessa regra, o ruído praticamente sumiu.

O revisor mais rápido do mundo não vale nada se metade do que ele diz é inventado.

De cinco revisores para um time de doze especialistas

O ciclo de revisão provou que agente com papel estreito funciona melhor do que agente genérico tentando fazer tudo. Levei a ideia até o fim: hoje existe uma fábrica com doze bots especializados, cada um com sua descrição de cargo escrita, seu modelo de IA escolhido pelo tipo de raciocínio que o trabalho exige e, o mais importante, seu próprio conjunto de permissões. Tem líder técnico, backend, frontend, qualidade, infraestrutura, segurança, marketing, finanças, pesquisa, auditoria de vídeo e auditoria de disco. Os que auditam rodam em modo somente leitura de propósito: quem julga o trabalho não mexe no trabalho, senão o parecer vira autoelogio.

A parte que mais mudou o dia a dia é banal de descrever e demorou pra existir: os bots não vivem numa pasta genérica. Cada um abre o terminal já dentro do repositório certo, com as chaves de acesso vindo do ambiente da máquina e nunca escritas dentro de arquivo versionado. Antes disso, eu pedia uma análise do código e o bot respondia que não encontrava o diretório, porque estava procurando na casa dele, não na do projeto. Autonomia sem endereço é só um agente educado dizendo que não achou nada.

Vê-los trabalhando é a parte estranha. Eles conversam entre si numa sala, em português, sobre a tarefa que eu abri: o líder técnico distribui, o de qualidade escreve os critérios de auditoria antes de alguém escrever código, o de infraestrutura ajusta a esteira de testes, o de backend implementa e devolve o resultado com o número da linha. Eu entro na conversa uma vez, pra escolher qual tarefa atacar, e volto depois pra aprovar.

A ponte entre o caderno e o quadro de tarefas

Sobrou um vão no meio do sistema: a memória compartilhada sabia o que estava pendente, mas os bots trabalhavam a partir de um quadro de tarefas separado, do tipo que qualquer equipe usa, com cartões movendo de coluna. Duas fontes de verdade sobre a mesma coisa é receita de trabalho duplicado. Construí uma ponte: toda tarefa pendente com dono definido vira cartão no quadro, o bot executa, e o resultado volta pro caderno preenchido, sem eu abrir uma única conversa.

A primeira versão dessa ponte foi reprovada numa auditoria, e por um motivo que vale contar: metade do código era morto. Ela filtrava por campos que o quadro simplesmente não devolve na listagem, então nunca encontrava nada e nunca reclamava. Passava a impressão de funcionar. É a mesma família de erro do status verde mentiroso, só que dessa vez quem pegou foi um agente cético, antes de mim. A regra de evidência, que nasceu pra domar o revisor de código, virou a regra da casa inteira: nada é dado como feito sem uma linha de código, um log ou uma resposta de servidor que prove.

Fechando o circuito, o daemon agora expõe as métricas dos bots: quanto cada um trabalhou, quanto custou, o que entregou. É o que faltava pra responder a pergunta mais chata sobre qualquer automação: ela está pagando o próprio salário?

O dia em que o sistema mentiu pra mim

A lição mais valiosa dos últimos meses veio de uma auditoria que fiz no sistema de deploy, a parte que coloca os projetos no ar. Descobri duas mentiras confortáveis. A primeira: o sistema dizia 'construção concluída com sucesso' em verde... em casos onde não havia nada para construir. Ele não tinha feito nada, e reportava vitória. A segunda: se o processo responsável morresse no meio de um deploy, o painel continuava mostrando 'rodando...' por até meia hora, com um processo que já não existia. Nenhum erro, nenhum aviso, só um status otimista e falso.

A correção virou uma regra de projeto: o sistema é proibido de dizer 'deu certo' sem provar. Antes de construir, ele verifica se existe algo a construir, e falha alto se não existir. Um batimento cardíaco constante detecta processo morto em segundos, não em meia hora. E um diagnóstico contínuo examina cada projeto cadastrado e mostra, escrito na tela, o que está errado na configuração, nada de erro escondido em tooltip. Falha silenciosa é o pior tipo de falha, porque você só descobre quando já custou caro.

Deploy em um clique, de qualquer versão

Com a confiança restaurada, o deploy virou o que sempre deveria ter sido: apertar um botão. No painel, escolho o projeto, escolho qual versão do código quero publicar, a principal ou qualquer ramificação de trabalho, e clico. O sistema atualiza o código, reconstrói o container e sobe a versão nova, transmitindo o log ao vivo na tela. Meu momento favorito de todo o projeto: o daemon faz deploy de si mesmo. Ele derruba o próprio container, se reconstrói e volta ao ar na versão nova, um sistema que se atualiza usando a si próprio como ferramenta.

E tudo isso cabe no bolso

A cereja do bolo: conectei o sistema ao Telegram. Pergunto, em linguagem normal, 'como está o projeto X?', e um agente decide sozinho o que precisa consultar: propostas de mudança abertas, a nota da última revisão, tarefas pendentes. A resposta vem com dados ao vivo do banco, não com um texto decorado. É o estado real de qualquer projeto, do celular, em segundos.

O que eu aprendi construindo isso

Três lições ficaram. Primeira: autonomia sem verificação é só velocidade. Um agente rápido que inventa problemas ou esconde falhas atrapalha mais do que ajuda, então cada agente ganhou outro agente cético olhando por cima do ombro. Segunda: os melhores recursos nasceram de bugs que doeram. O botão que abriu 14 propostas duplicadas me ensinou sobre concorrência; o status verde mentiroso me ensinou sobre evidência. Terceira: confiança em automação não se declara, se constrói com prova, com log visível e com um humano no único ponto que importa: a decisão final de aprovar.

O sistema segue crescendo: as métricas de qualidade ao longo do tempo já estão de pé, e o próximo passo é usá-las pra decidir onde vale colocar mais bots e onde vale tirar. Mas a mudança de fundo já aconteceu: eu deixei de ser o operador de cada tarefa e virei o editor-chefe de uma pequena redação de agentes. O trabalho não para quando eu saio do teclado, e o meu tempo passou a ir para o que só um humano faz: decidir.