Minha esposa queria Dior. Gastei US$ 600 no Claude Code para programar por vibe um banco de dados de 2 milhões de linhas em vez disso.
Minha esposa e eu estamos casados há dez anos, e ela queria uma bolsa Dior para o nosso aniversário.
Em vez de comprar qualquer coisa — porque eu estava completamente absorvido em um experimento de IA — passei o feriado inteiro trancado no meu escritório, gerenciando três assinaturas do Claude Code de US$ 200/mês, tentando convencer um LLM a fazer cross-compile de um banco de dados distribuído em C++ com 2 milhões de linhas.
E você provavelmente consegue imaginar o que aconteceu comigo depois. 😂
Olhando em retrospectiva, essa não foi uma alocação ideal de recursos.
Então aprendi duas lições naquele fim de semana.
Primeiro: escute sua esposa. “Happy wife, happy life” não é apenas um slogan. É um princípio de estabilidade de sistemas.
Segundo: a IA parece mágica em tarefas pequenas e bem delimitadas. Ela se comporta de maneira muito diferente quando você a direciona para uma infraestrutura distribuída real.
Este post é sobre a segunda lição.
Contexto
Sou o mantenedor e um dos principais contribuidores do Milvus, o banco de dados vetorial open-source mais popular, com mais de 42 mil estrelas no GitHub no momento em que escrevo (~2 milhões de linhas de C++, Go e Python). O sistema é totalmente distribuído: nós proxy, nós de consulta, nós de dados e nós de índice, todos coordenados por meio de filas de mensagens. Minha área é a camada de armazenamento e indexação.
Eu vinha usando o Claude Code havia alguns meses e estava genuinamente impressionado. Ele preencheu todos os recursos ausentes de uma CLI inteira por US$ 20 em tokens. Ele melhorou em 5x um caminho crítico de desempenho de consultas em um dia, o tipo de otimização que levaria uma semana só para eu entender o código bem o suficiente para mexer nele. Parecia ter um engenheiro júnior competente que nunca dormia e não cobrava por hora.
Decidi dar a ele um problema real: compilação multiplataforma.
A lição de US$ 600 aprendida
Durante anos, ninguém na equipe do Milvus queria tocar em compilação multiplataforma. O sistema de build é uma mistura de Go, C++ e Rust, mantida de pé por anos acumulados de patches de Conan e CMake que ninguém queria revisitar. Fazer isso rodar no Linux já é sofrível. Windows e macOS moderno eram um pesadelo tão grande de compilar que a equipe os tratava como problema de outra pessoa.
Achei que agora eu tinha o Claude Code. Eu poderia lidar com isso.
No começo, parecia que eu estava certo. O Windows compilou, e eu enviei o patch, pensando que a parte difícil tinha acabado.
Então o Linux falhou. Corrigi o Linux e o Mac falhou. Corrigi o Mac, e o ambiente de GPU falhou. Cada correção introduzia dois novos problemas em uma plataforma diferente, e os patches começaram a se acumular. No fim, eu tinha um patch de 1000 arquivos, ~100 mil linhas, mexendo em configurações do Conan, scripts CMake, shims de compatibilidade em C++ e coisas que eu nem reconhecia.
A parte enlouquecedora não eram os bugs; era o ciclo. Eu continuava dizendo ao Claude: "Nada de correções gambiarra", "me dê a solução limpa." Ele obedecia todas as vezes, gerando patches que pareciam mais limpos. Então cada patch limpo quebrava três outras plataformas, e o ciclo recomeçava. Se você olhasse meu .claude/settings.local.json, encontraria 147 regras de permissão aprovadas manualmente. Cada uma é um carimbo de data e hora de eu pensando: "Desta vez vai funcionar."
Gastei US$ 600 no plano Max e queimei umas férias inteiras, e tudo o que eu tinha era uma pilha de comandos git reset --hard.
Fiquei ali encarando meu terminal, me perguntando se tudo aquilo não era apenas hype bem embalado. Então percebi que o problema não era o Claude. Era como dizer a um estudante de pós-graduação para publicar um artigo na Nature sem especificar a pergunta de pesquisa. Eu tinha entregado a ele um problema sem nunca definir o que "resolvido" realmente significava.
O que realmente funciona
A falha não foi a inteligência do Claude. Foi uma falha de processo. Então recomecei com um processo diferente.
Restrições antes do código. Não "fazer compilar no Windows." As restrições reais, escritas explicitamente: todas as plataformas passam em seus testes unitários, o CI fica verde em todos os lugares, sem hacks de plataforma com #ifdef, sem contornar dependências quebradas com shims. Esta é a parte difícil — exige saber como é "pronto", o que exige pensar cuidadosamente antes de tocar em qualquer coisa. Com infraestrutura complexa, a maior parte do trabalho está em pensar.
Revise testes, não código. Eu escrevo casos de teste (ou peço ao Claude para gerá-los), mas reviso os testes, não a implementação. Este teste verifica se a receita Conan resolve corretamente no ARM? Ele cobre a configuração CMake no Docker? Consigo avaliar isso em minutos. Não consigo revisar 10.000 linhas de patches C++ multiplataforma com qualquer confiança, em qualquer quantidade de tempo.
De baixo para cima, uma camada por vez. Não deixe o Claude alterar 1000 arquivos. Trave primeiro as versões das dependências. Depois que essas restrições forem verificadas, suba para a configuração CMake. Quando isso estiver estável, código específico de plataforma. Cada camada é pequena o suficiente para ser verificada completamente antes de subir.
Refiz do zero a build multiplataforma usando esta abordagem. Dois dias. Algumas dezenas de commits. Cada um pequeno, cada um com um teste correspondente. Sem hacks com #ifdef — a correção subjacente foi atualizar receitas Conan e incrementar versões de bibliotecas de terceiros, corrigindo a cadeia real de dependências em vez de encobri-la.
Mesma tarefa. Resultado completamente diferente.
O insight sobre testes merece um ponto próprio: em um sistema distribuído com uma suíte de testes madura, os testes são a especificação. Se esses testes de integração passam — todos os 47 que ficaram vermelhos na minha primeira tentativa — então os contratos de seal/flush estão intactos, o replay do WAL está correto, e os nós de consulta ainda conseguem carregar segmentos com mmap sem corrupção. Não preciso ler o C++ para saber disso.
Parei de revisar código. Comecei a revisar testes. O código virou um detalhe de implementação.
Jogando hardware no problema
Depois que o fluxo de trabalho estava certo, apareceu um novo gargalo: eu estava sentado ali esperando.
Uma sessão do Claude Code mastigando uma base de código de 2M de linhas não é rápida. Cada tarefa leva 20-30 minutos de tempo real. O gargalo não era inteligência. Era vazão.
Então eu disse à minha esposa que precisava de um servidor com GPU para meus “agentes de IA.” Essa conversa foi tão bem quanto você imaginaria. Comprei mesmo assim — mais um Mac Mini para acompanhar meu MacBook. No fim, eu tinha três máquinas e seis terminais, cada um rodando uma sessão independente do Claude Code.
O que faz isso funcionar é git worktree. Cada sessão recebe sua própria tarefa, branch e diretório de trabalho, completamente isolados dos outros. E como a abordagem de restrições primeiro significa que cada branch tem seus próprios critérios de aceitação, o paralelismo é trivialmente seguro: se os testes de cada branch passam independentemente, o merge é de baixo risco.
Para a build multiplataforma, isso significou uma sessão resolvendo dependências Conan do Linux ARM, uma corrigindo a configuração CMake do macOS e uma lidando com compatibilidade Windows MSVC, todas rodando simultaneamente sem interferência. O que costumava ser troca de contexto serial entre plataformas virou execução paralela entre máquinas.
O padrão se generaliza para o trabalho diário. Em qualquer dia, uma sessão está refatorando o escalonador de compaction, outra está otimizando o caminho de busca HNSW, e uma terceira está escrevendo testes de integração para um caso de borda de inserção por streaming. Eu alterno entre terminais como um gerente verificando subordinados diretos, exceto que esses subordinados diretos nunca precisam de pausas para café e não têm opiniões sobre planejamento de sprint.
A verdadeira lição é que infraestrutura com vibe coding é limitada por computação, não por talento. O fator limitante não é quão inteligente a IA é; é quantas instâncias você consegue rodar em paralelo. A Anthropic usou 16 instâncias paralelas do Claude para construir um compilador C inteiro, o que fez meus seis terminais parecerem modestos.
A coisa à qual eu sempre volto
A IA resolve exatamente o problema que você coloca diante dela, nada mais. Se você enquadrar o problema errado, obtém uma solução perfeita para a coisa errada.
"Compila no macOS 15" — resolvido em uma hora. Mas isso é um ótimo local. O objetivo real era "compila em todos os lugares sem gambiarras." Esses são problemas diferentes. A IA não tinha como saber disso. Isso é inteiramente responsabilidade do engenheiro.
Construir para si mesmo com IA é surpreendentemente fácil — você conhece sua máquina, seus casos extremos, e "funciona para mim" é um alvo de otimização alcançável. Construir infraestrutura que funcione para todos os usuários, em todas as plataformas, em todos os ambientes é fundamentalmente diferente. Essa lacuna é onde a engenharia ainda vive. Para software de infraestrutura, essa lacuna é enorme.
Os bugs mais difíceis no nosso sistema de produção — aqueles que exigiram reverter após o merge — não foram detectados por nenhuma abordagem de revisão de código com IA que tentamos. Os bugs estavam sintaticamente corretos. O problema estava nas suposições implícitas do desenvolvedor, invisíveis no diff e ausentes no código ao redor. O comportamento do sistema só fazia sentido se você tivesse um modelo mental de como três componentes diferentes deveriam se coordenar — um modelo que existia apenas na cabeça de um desenvolvedor, nunca documentado.
Esses ainda exigem um humano que entenda o sistema bem o suficiente para saber quais perguntas fazer.
Os três planos de $200 e umas férias perdidas foram o melhor investimento que já fiz. Não porque me ensinaram a usar IA. Porque me ensinaram como não usá-la.
As ferramentas são genuinamente boas. A peça que faltava sempre foi o workflow ao redor delas. Testes antes do código, restrições antes dos testes, e hardware suficiente para rodar tudo em paralelo. É isso.
Os problemas que continuam sem solução
Depois de tudo — o patch fracassado, os comandos de reset, os seis terminais em paralelo — o problema mais difícil de resolver ainda é o humano.
Por enquanto, tenho duas dores de cabeça, e nenhuma delas tem uma solução simples.
A primeira: minha esposa. Ela entrou nas férias com expectativas razoáveis. Saiu me vendo dar git reset --hard na minha vida. O orçamento da bolsa Dior virou conta de servidor. Ela, compreensivelmente, não está impressionada com minhas conquistas de build multiplataforma. Ainda não encontrei um workflow para "como pedir desculpas por passar seu aniversário de casamento fazendo trabalho de sistemas distribuídos." Claude Code não ajuda aqui. Eu tentei perguntar. Ele sugeriu flores e uma carta escrita à mão. Eu disse para ser mais específico. Ele gerou doze variações de uma carta emotiva na voz de um desenvolvedor C++. Nenhuma funcionou.
Se alguém resolveu o problema de manter um relacionamento enquanto faz vibe-coding durante as férias, estou muito aberto a sugestões de workflow. 😂
A segunda: como escalar isso para além de mim. Tudo acima — a abordagem com restrições primeiro, o paralelismo com git worktree, a disciplina de revisão com testes primeiro — está atualmente na minha cabeça e na minha configuração local. Colocar isso no workflow diário de uma equipe é mais difícil do que qualquer build multiplataforma.
Isso é em parte um problema de tooling. Mas, acima de tudo, é um problema de pessoas. Esse tipo de workflow exige engenheiros que genuinamente gostam de descobrir como as coisas funcionam — pessoas que realmente vão escrever o teste primeiro, que encontram satisfação em uma restrição limpa e bem definida, e que não vão pegar o atalho de "só faz passar." Essa combinação é mais rara do que deveria ser.
Então sim — estamos contratando.
Se você é o tipo de engenheiro que lê um artigo sobre vibe coding de infraestrutura e imediatamente começa a formar opiniões fortes sobre o que eu fiz errado, você é exatamente a pessoa com quem quero falar.
Milvus é um problema de sistemas distribuídos genuinamente difícil: storage engines, pipelines de indexação, compactação, replicação, recuperação de falhas — tudo sob carga de produção do mundo real. Não estamos construindo demos. Estamos construindo infraestrutura da qual as pessoas dependem.
Se resolver problemas nesse nível parece interessante, venha construir conosco.
E eu cuido do plano de recuperação do aniversário de casamento.
Você pode conferir nossas vagas abertas ou entrar em contato comigo diretamente no LinkedIn.
E se você discordar de algo neste post, melhor ainda — fico feliz em discutir isso com você.
Participe da nossa comunidade no Slack ou agende uma sessão de Milvus Office Hours — estamos sempre felizes em conversar sobre sistemas distribuídos, infraestrutura de IA ou onde você acha que estamos errados.
Continue lendo
We spent 8 years making vector databases faster. Then we stopped.
Rarely queried embeddings still need to stay searchable. See how Vector Lakebase enables on-demand vector search without always-on compute costs.
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
Building RAG Pipelines for Real-Time Data with Cloudera and Milvus
explore how Cloudera can be integrated with Milvus to effectively implement some of the key functionalities of RAG pipelines.