---
title: "Centenas de agentes ajudaram a criar um banco de dados mas ficaram proibidos de executá-lo"
author: "Ignácio Afonso"
date: "2026-09-19 09:45:00-03"
category: "Inteligência Artificial & Dados"
url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/19/centenas-de-agentes-ajudaram-a-criar-um-banco-de-dados-mas-ficaram-proibidos-de-executa-lo/md"
---

## Resumo
- A Perplexity criou o CobbleDB em dois meses com dois engenheiros e centenas de agentes de programação.
- O banco tem cerca de 40.000 linhas de código em Rust e substitui o DynamoDB em partes da infraestrutura de busca.
- A latência mediana de leitura em lote caiu de 31,4 ms para 5,6 ms em testes de produção.
- O p99 caiu de 123 ms para 24,2 ms, enquanto o 90º percentil passou de 56,7 ms para 9,77 ms.
- Os agentes ajudaram na construção, mas ficaram proibidos de executar ou administrar diretamente o sistema em produção.
- A arquitetura separa estado durável, pacotes de atualização e a camada de serviço para evitar que réplicas lentas bloqueiem a busca.
- A Perplexity estima economia de pelo menos 20% e planeja disponibilizar o CobbleDB como código aberto no futuro.

---

O bug que a **Perplexity** decidiu resolver era conhecido por qualquer equipe que já precisou acelerar uma busca: a infraestrutura precisava entregar muitos dados preparados em pouco tempo, mas o banco usado até então impunha uma latência maior do que a empresa queria aceitar. A resposta foi o **CobbleDB**, um banco de dados de chave-valor criado com dois engenheiros e centenas de agentes de programação de inteligência artificial. O detalhe que transforma o projeto em uma história maior do que uma simples troca de tecnologia está na fronteira estabelecida pela empresa: os agentes ajudaram a construir o sistema, mas ficaram fora da execução e da gestão direta do ambiente de produção. A piada é sem graça, mas funciona: a IA ajudou a erguer a casa e recebeu ordem para não entrar nela.

## O primeiro desenho: poucos engenheiros, muitos agentes

Em dois meses, **dois engenheiros** conduziram a criação do CobbleDB com o auxílio de **centenas de agentes de codificação**. O trabalho não colocou a inteligência artificial como uma autora autônoma responsável por todo o projeto, porque a supervisão humana permaneceu concentrada na equipe que orientava, revisava e decidia o que poderia seguir adiante. O caso descrito pela [cobertura técnica do projeto](https://thenewstack.io/perplexity-cobbledb-ai-database) apresenta uma divisão direta de responsabilidades: os agentes ampliaram a capacidade de produzir código, enquanto os engenheiros continuaram respondendo pelas decisões que levavam o sistema para perto da operação real. Essa separação é o ponto de partida para entender por que o CobbleDB conseguiu avançar rapidamente sem conceder aos agentes a última palavra.

O resultado desse processo foi um sistema com cerca de **40.000 linhas de código em Rust**, linguagem usada na implementação do banco, que passou a substituir o Amazon **DynamoDB** em partes da infraestrutura de busca da Perplexity. Um banco de chave-valor organiza cada registro a partir de uma chave que aponta para um valor, em vez de tentar resolver todos os tipos de consulta possíveis em uma única estrutura. Essa escolha permite desenhar o armazenamento em torno de uma tarefa específica, neste caso a leitura de dados já preparados para responder às buscas. O CobbleDB, portanto, não foi apresentado como um substituto universal para qualquer banco, mas como uma peça moldada para uma necessidade operacional delimitada.

## A fronteira que os agentes não atravessaram

Essa delimitação técnica veio acompanhada de uma delimitação operacional. A **supervisão humana** foi mantida para assegurar conformidade e qualidade, enquanto os agentes permaneceram fora da gestão direta do ambiente de produção. Produção é o ambiente em que um sistema atende às operações reais e qualquer mudança pode afetar usuários, dados ou resultados; por isso, a construção automatizada e a execução controlada aparecem como etapas diferentes na experiência da Perplexity. O desenho não elimina a participação da IA, mas impede que a mesma ferramenta que sugere ou produz alterações seja automaticamente autorizada a aplicá-las no serviço que sustenta a busca.

A primeira camada dessa separação é o **Pillar**, responsável pelo estado durável dos documentos no **YTsaurus**. Estado durável significa a versão persistente das informações, aquela que precisa continuar disponível mesmo quando uma cópia do serviço é reiniciada ou substituída. Ao manter esse estado em uma camada própria, a arquitetura não depende de uma única instância que precise fazer tudo ao mesmo tempo. A informação mais permanente fica separada da camada que atende às leituras, e essa escolha prepara o terreno para que as cópias usadas na busca possam acompanhar atualizações sem bloquear umas às outras.

A segunda camada é o **Lorry**, que distribui pacotes de atualização por meio do **S3**. Esses pacotes funcionam como entregas organizadas de mudanças que cada réplica pode processar de forma independente. Réplica, neste contexto, é uma cópia do serviço capaz de atender às solicitações, e a independência reduz a possibilidade de uma cópia lenta parar todas as demais. A terceira camada é o próprio CobbleDB, que atua como serviço de leitura, enquanto um roteador favorece réplicas na mesma zona de disponibilidade e pode migrar a carga quando um nó apresenta lentidão. A descrição oficial da arquitetura está na [publicação da Perplexity](https://x.com/perplexity_ai/status/2099955628194316346).

## Quando a leitura virou métrica

Essa arquitetura foi medida em produção com uma comparação que ajuda a dimensionar o efeito da mudança. A latência mediana de leitura em lote caiu de **31,4 milissegundos para 5,6 milissegundos** depois que partes do trabalho deixaram o DynamoDB e passaram a usar o CobbleDB. Leitura em lote significa buscar vários registros em uma mesma operação, algo especialmente relevante para uma infraestrutura que precisa reunir passagens e representações preparadas antes de montar uma resposta. No extremo mais lento da distribuição, o p99, indicador que observa as solicitações entre as 1% mais demoradas, caiu de **123 milissegundos para 24,2 milissegundos**. A diferença mostra que o ganho não ficou restrito ao comportamento médio.

A mesma comparação trouxe outro número: a latência do **90º percentil** caiu de 56,7 milissegundos para 9,77 milissegundos, enquanto testes de carga levaram o sistema a **500.000 requisições por segundo** antes da degradação de desempenho. Percentil é uma forma de observar como as solicitações se distribuem, em vez de olhar apenas para uma média que poderia esconder respostas muito lentas. Ainda assim, existe uma ressalva metodológica: as métricas compararam o comportamento antes e depois da migração do DynamoDB, e não foram produzidas em tráfego simultâneo entre os dois sistemas. O número é expressivo, mas precisa ser lido junto com a maneira como a comparação foi realizada.

## Um banco desenhado para uma tarefa

Os números ficam mais compreensíveis quando se observa o tipo de dado armazenado. O sistema usa **identificadores de página hasheados** como chaves e guarda passagens pré-processadas junto de representações vetoriais, que são formas numéricas usadas para representar informações em operações de busca. Os dados acessados com maior frequência permanecem na memória por meio do **RocksDB**, enquanto registros que não estão no cache são lidos de armazenamento NVMe local. Cache é uma área de acesso rápido que conserva dados requisitados com frequência; quando o registro não está ali, o serviço recorre ao armazenamento local. A organização aproxima cada etapa do tipo de leitura que a infraestrutura precisa fazer.

Esse recorte também explica o que o CobbleDB não tenta oferecer. O sistema não suporta **transações complexas** nem **consistência forte**, conceito que exige que as leituras observem de forma estrita as atualizações mais recentes em todas as cópias. Em vez disso, ele foi especializado em leituras rápidas de dados preparados, uma decisão coerente com o uso descrito para a busca da Perplexity. A escolha mostra que desempenho não vem de colocar todas as capacidades possíveis dentro do mesmo banco, mas de retirar responsabilidades que não pertencem à tarefa escolhida. A arquitetura ganha velocidade ao aceitar um conjunto mais estreito de operações.

A conta econômica acompanha essa especialização. A **Perplexity estima uma economia de pelo menos 20%** em comparação com o DynamoDB, além da queda de latência observada nos testes. Essa estimativa não transforma o CobbleDB em uma solução automaticamente adequada para qualquer aplicação, porque os próprios limites de transações e consistência restringem seu campo de uso. Ela indica, porém, por que uma empresa pode aceitar manter uma camada de armazenamento personalizada: quando a carga é previsível, os dados já estão preparados e a prioridade está na leitura, um sistema menor e ajustado ao trabalho pode reduzir tempo de resposta e custo ao mesmo tempo.

## O que fica depois da construção

O caso do CobbleDB deixa uma regra operacional clara para quem trabalha com agentes de programação: acelerar a construção não obriga a acelerar a autorização. A empresa usou centenas de agentes para ampliar o trabalho de desenvolvimento, mas conservou nos engenheiros a supervisão da qualidade e o controle sobre o ambiente que atende às operações reais. Essa decisão ganha peso porque o banco não é um exercício isolado; ele passou a ocupar partes da infraestrutura de busca, recebeu medições em produção e foi projetado para tratar dados que precisam chegar rapidamente à aplicação. A fronteira entre escrever código e executá-lo funciona, nesse caso, como uma camada adicional de controle.

O próximo passo anunciado é tornar o **CobbleDB código aberto** no futuro, o que poderá permitir que outras equipes examinem a implementação e avaliem se o mesmo desenho serve para suas próprias cargas de leitura. Até lá, o projeto permanece como uma demonstração específica: dois engenheiros coordenaram centenas de agentes, o sistema alcançou ganhos medidos diante do DynamoDB e a Perplexity manteve os agentes afastados da operação direta. A lição prática está nessa combinação, e não em uma promessa de autonomia total: a IA pode participar da construção de uma infraestrutura crítica sem receber automaticamente as chaves da sala onde ela funciona.