Git worktrees isolam os arquivos dos seus agentes. O padrão Lakebase da Databricks isola os bancos de dados.

Rode três agentes de código em paralelo e eles não vão colidir no Git. Cada um tem seu próprio worktree, seu próprio branch, seus próprios arquivos. Eles vão colidir no banco de dados. A migração de um agente renomeia uma coluna da qual os testes de outro agente dependem, os fixtures de um terceiro agente sobrescrevem as linhas que os dois estavam usando, e as falhas parecem bugs em um código que na verdade está certo.

Um post da Databricks publicado em 8 de outubro descreve uma saída. Escrito por Thibaut Gourdel, é um workflow de referência, não o lançamento de um produto, construído sobre o Lakebase, o Postgres gerenciado da Databricks, e seu branching com copy-on-write. A Databricks diz que o Lakebase consegue criar o branch de “um banco de dados inteiro em menos de um segundo, independentemente do tamanho”. Os branches compartilham os dados do branch pai e consomem armazenamento extra apenas quando divergem, e branches ociosos podem escalar até zero, e por isso não geram custo de computação enquanto não são usados.

O workflow

O padrão dá um branch de banco de dados a cada unidade de trabalho paralelo, em dois níveis.

Por agente. Quando um agente de código recebe um worktree do Git, um hook de post-checkout do Claude Code cria um branch de banco de dados correspondente. O agente desenvolve contra sua própria cópia, escreve suas mudanças de schema como migrações e, quando o pull request está aberto, o worktree e seu branch de banco de dados podem ser encerrados.

Por pull request. Na CI, o GitHub Actions cria um branch como pr-123 como filho da produção, roda as migrações (Drizzle no exemplo), faz o deploy de um app de preview no Databricks Apps e publica um diff de schema no pull request. O branch é excluído quando o pull request é fechado ou mesclado.

1. O agente recebe um worktree
2. O hook cria seu branch de banco de dados
3. O agente escreve código e uma migração
4. A CI cria um branch a partir da produção e roda a migração
5. Diff de schema e preview revisados
6. O merge aplica a migração à produção

• Por agente: O agente recebe um worktree · O hook cria seu branch de banco de dados · O agente escreve código e uma migração
• Por pull request: A CI cria um branch a partir da produção e roda a migração · Diff de schema e preview revisados

Espaço de trabalho do agenteValidação na CI

Por que a regra de migração importa mais

A frase mais importante do post é uma limitação: “branches do Lakebase não são mesclados de volta ao branch principal”. As mudanças de schema são rastreadas em código junto com a aplicação e promovidas por meio de migrações.

Isso transforma uma restrição em um controle. Faça o que o agente fizer com seu branch de banco de dados, a única coisa que chega à produção é um arquivo de migração em um pull request, revisado como qualquer outra mudança. É o princípio que descrevemos em agentes como autores de mudanças em produção: a mudança de um agente só conta quando passa pelo processo de mudança, como um artefato que uma pessoa consegue ler e rejeitar.

Onde o padrão precisa de regras

Quais dados o agente vê. O branch de PR no exemplo parte da produção, que é o que torna o teste de migração realista. Mas um agente trabalhando em um branch da produção está trabalhando com dados de produção. O post observa que criar um branch a partir de um banco de dados populado “também é comum” para evitar expor dados sensíveis, e que branches derivados da produção podem usar o mascaramento do Unity Catalog. Nós faríamos da escolha segura o padrão: branches de agente a partir de dados populados ou mascarados, e branches de produção apenas dentro da CI, sob uma identidade que roda migrações sem entregar linhas ao agente.

Quais credenciais alcançam qual branch. Isolamento de dados significa pouco se todo agente tem credenciais para todo branch. A identidade de banco de dados de cada agente deve alcançar apenas seu próprio branch, o mesmo princípio que se aplica ao seu role na nuvem.

Limpeza. Centenas de branches de vida curta são baratos só se forem de fato excluídos. O ciclo de vida dos branches pertence à automação, não à memória de um desenvolvedor, e alguém deveria verificar periodicamente branches que sobreviveram ao seu worktree.

Status. O post não informa o status de lançamento dos recursos de branching que usa, nem quaisquer limites. Confira isso antes de planejar um rollout.

Agentes em paralelo expõem todo recurso mutável compartilhado que um time tem: bancos de dados primeiro, depois filas, caches, feature flags e contas externas de teste. Os worktrees resolveram o mais fácil. O branching de banco de dados é uma resposta forte para o próximo, e a disciplina que ele impõe, migrações como o único caminho para a produção, vale a pena adotar mesmo onde o ferramental é diferente.