A ideia de dar um cérebro persistente a agentes de código, como Claude Code e OpenCode, parecia ambiciosa. Há cerca de três semanas, nascia o projeto ai-memory, um sistema de memória de longo prazo que prometia uma wiki versionada em Git, busca FTS, handoff entre agentes e consolidação opcional via LLM — tudo rodando localmente, sem nuvens ou terceiros. O que ninguém esperava é que, em menos de um mês, esse projeto se tornaria um exemplo vivo de como o software, de verdade, é cultivado, e não apenas montado.
O criador do projeto, que já havia compartilhado os detalhes do ai-memory em um post anterior, decidiu agora revelar os bastidores do seu processo de desenvolvimento. Segundo ele, a evolução do ai-memory é uma prova de que a ideia de “montar software bom peça por peça, como quem monta um Lego” é, na prática, uma falácia. Os números contam uma história de crescimento orgânico e adaptação contínua, que contraria a forma como muitos desenvolvedores imaginam a construção de grandes sistemas.
O que os números dizem hoje?
Em apenas 24 dias — do primeiro commit em 21 de maio até agora — o ai-memory alcançou marcas impressionantes:
482 commits no
main, uma média de 20 por dia.26 pessoas contribuíram com commits para o repositório.
10 crates Rust compõem o workspace.
A base de código em Rust de produção soma aproximadamente 62,7 mil linhas, além de 11 mil linhas de teste em
tests/, com mais de 1.000 funções de teste e 90 módulos#[cfg(test)].A documentação em Markdown (
docs/) já possui cerca de 19,7 mil linhas.Foram abertos 70 pull requests, dos quais 59 foram mesclados (84% de aceitação).
As 27 issues abertas foram 100% fechadas.
O projeto, que começou na versão
v1.0.0em 12 de junho, já está nav1.0.6.
Esses 24 dias são cruciais, não pelo tamanho final do projeto, mas pela maneira como ele chegou a esse ponto.
Como o ai-memory começou?
O ai-memory foi concebido para ser intencionalmente pequeno e simples em seu início. Nos dois primeiros dias, o esqueleto completo foi estabelecido: o bootstrap do workspace, o servidor MCP, a captura por hooks, o handoff entre agentes, o versionamento da wiki em Git, a trait de provedor de LLM e os embeddings. Tudo isso, porém, funcionava para apenas um cenário: para um usuário, uma máquina, um workspace, uma arquitetura (Linux, principalmente).
Não havia suporte a múltiplos usuários, permissões, escopo ou compatibilidade com Windows ou macOS. Era, nas palavras do criador, o meu cérebro de agente, na minha máquina, pra mim. No terceiro dia, quando a primeira contribuição externa chegou — um fix do Lucas Oliveira para URLs de provedores compatíveis com OpenAI (o PR #6) — o projeto já contava com 102 commits e cerca de 22,9 mil linhas de código-fonte. Já possuía os mesmos 10 crates de hoje, mas com uma fração de funcionalidade. Era um MVP (Produto Mínimo Viável) que servia apenas ao seu criador.
É nesse estágio que muitos projetos sucumbem, ou onde desenvolvedores menos experientes frequentemente cometem erros.
A ilusão do Lego no desenvolvimento de software
Há uma crença disseminada, especialmente entre iniciantes, de que é possível planejar tudo que um software será antes mesmo de escrever a primeira linha de código. A ideia é sentar, desenhar a arquitetura completa, dividi-la em partes organizadas, com pastas, camadas e interfaces todas previstas, e então construir peça por peça. Quando a última peça de Lego se encaixa, o software está pronto. Um cenário que parece perfeito no papel.
Na prática, essa abordagem é o caminho mais rápido para a deterioração do código. Quanto mais cedo uma estrutura é cristalizada, mais rapidamente ela se torna uma limitação. Criar um sistema de permissões complexo antes de ter usuários reais, por exemplo, leva a manter uma abstração que ninguém utiliza e que, na maioria das vezes, está incorreta porque foi projetada com base em adivinhações do futuro, e não em necessidades concretas. O desenvolvedor inexperiente acaba fazendo um excesso de engenharia no início, e não importa o quão detalhado seja o planejamento, o resultado começa a falhar rapidamente, pois ele está resolvendo problemas inexistentes e errando nos que de fato existem.
O autor do projeto não acredita em software que tem um fim. Ele já abordou o tema em seu texto Software nunca está pronto, que se conecta diretamente a essa filosofia de desenvolvimento iterativo e orgânico.