Viabilizando o Desenvolvimento Evolutivo de Bancos de Dados: Ramificação de banco de dados com Lakebase, a conclusão

A metodologia descrita em Evolutionary Database Design e operacionalizada em Refactoring Databases: Evolutionary Database Design está clara há vinte anos. As sete práticas, o catálogo de mais de 70 refatorações nomeadas, a mecânica de transição – tudo isso documentado, revisado por pares e ensinado.

Essa metodologia chegou ao CI/CD em 2010 com Continuous Delivery (Capítulo 12: Managing Data). As migrações tornaram-se artefatos de primeira classe no pipeline de implantação. A disciplina de alterações de banco de dados como código alcançou o movimento mais amplo de CI/CD. O que o CD não resolveu foi o isolamento por pipeline: os pipelines podiam executar migrações, mas ainda precisavam de um banco de dados de destino, e esse destino era compartilhado. A Prática nº 4 – Todo mundo tem sua própria instância de banco de dados – continuou sendo um sonho para a maioria das equipes porque bancos de dados reais com formato de produção por desenvolvedor custam tempo, dinheiro e ciclos de DBA. A camada de compensação que surgiu para contornar essa lacuna (objetos mock, ambientes de staging compartilhados, substitutos de banco de dados em memória, filas de chamados para DBA) tornou-se a metodologia fundamental por padrão, não por design.

Em 2026, a ramificação de banco de dados copy-on-write chega ao Databricks Lakebase. Uma ramificação de um segundo e zero armazenamento na criação de um banco de dados de produção em escala de terabytes agora é uma operação O(1). A restrição que mantinha a Prática nº 4 apenas como um desejo foi eliminada.

Esta série descreve o que muda quando a restrição é eliminada: não a metodologia – que se mantém –, mas as práticas que surgem pela primeira vez, a governança em escala de equipe que se torna automática, a evolução do papel do DBA e o novo substrato que os agentes compartilham com seus colegas humanos.

Conheça Jen

Jen é a personagem desenvolvedora de Evolutionary Database Design. Nesse ensaio, ela implementou uma refatoração de banco de dados – dividindo um campo inventory_code em location_code, batch_number e serial_number – como uma história de usuário rotineira, ilustrando que DBAs e desenvolvedores podem colaborar, os esquemas podem evoluir em pequenos incrementos e as migrações levam a alteração adiante com segurança.

A série reencontra Jen vinte anos depois. A metodologia que ela segue é a mesma que seguia em 2003. A novidade é o substrato sob seu fluxo de trabalho: a ramificação de banco de dados copy-on-write, que torna as práticas sobre as quais ela lia operacionalmente reais em escala de produção. Ao longo das três partes desta série, ela é a mesma Jen em três escopos – seu dia (Parte 1), seu novo playbook (Parte 2) e sua equipe (Parte 3).

Parte 3: A equipe de Jen em escala

A Parte 1 guiou Jen por uma funcionalidade. A Parte 2 nomeou o playbook de onze práticas que seu trabalho segue em 2026. A Parte 3 leva o mesmo playbook para uma equipe de cinquenta desenvolvedores, com agentes criando ramificações ao lado de humanos, e pergunta: o que se torna estrutural nessa escala?

Três coisas tornam-se pilares estruturais.

Primeiro, a topologia de camadas, as ramificações de longa duração que representam cada ambiente no caminho de promoção. Com um desenvolvedor, você tinha uma ramificação de funcionalidade e a produção. Com cinquenta, você tem uma hierarquia estruturada com vias estáveis e vias efêmeras sobrepostas.

Segundo, o modelo de permissão, a estrutura que define quem pode fazer o quê em qual ramificação. Com um desenvolvedor, você podia confiar na convenção. Com cinquenta, com agentes envolvidos, a estrutura precisa ser projetada uma vez e aplicada automaticamente.

Terceiro, o papel do DBA. Com um desenvolvedor, o DBA era o parceiro de design de Jen no PR. Com cinquenta, o DBA é o engenheiro de plataforma que projetou a estrutura dentro da qual Jen e seus colegas de equipe estão operando.

Este post aborda cada um desses pontos e, em seguida, foca nos agentes. Agentes na mesma capacidade é a Prática nº 11. Os agentes são como desenvolvedores juniores: eles produzem código que funciona, testes que passam, migrações que se aplicam e, sem orientação, sistemas impossíveis de manter. Os testes são a forma como a equipe os mantém sob controle. O playbook de TDD que vem a seguir é como a equipe faz com que os testes venham primeiro.

Camadas como ramificações de longa duração, não instâncias separadas

No mundo antes da ramificação, um ambiente era uma instância: uma implantação dedicada do Postgres para staging, outra para UAT, outra para testes de desempenho, cada uma provisionada, corrigida, mascarada e sincronizada separadamente. A camada de compensação mencionada na Parte 2 também vivia aqui. A divergência entre os ambientes era estrutural.

Na escala de equipe, o modelo de camadas se consolida em ramificações de longa duração a partir do mesmo pai no Lakebase.

Uma ramificação é uma de duas coisas: uma camada (de longa duração, um pai na hierarquia de promoção) ou uma funcionalidade (efêmera, descende de uma camada e é limpa). Uma camada tem um pai. A cadeia "pai de" é a hierarquia de promoção.

Na Fig. 1: vemos uma hierarquia simples, com a linha principal (main) sendo a produção e as ramificações de funcionalidade (Feature branches) sendo criadas sempre que necessário. Essa configuração geralmente é útil para prototipagem inicial ou trabalho em estágio inicial com uma equipe muito pequena. Equipes maduras com mais desenvolvedores e/ou muitos ambientes precisam de uma configuração como a mostrada abaixo.

Em algumas empresas, há a necessidade de ter um release candidate (RC). Esse release candidate fica em desenvolvimento por algum tempo e, após testes bem-sucedidos, é promovido para a produção. A Fig. 3 mostra um layout que permite que os release candidates sejam desenvolvidos e posteriormente promovidos para a produção, com a ramificação do release candidate sendo limpa em seguida.

Os nomes das ramificações são arbitrários; o que importa são as convenções sobre como as relações "pai de" são configuradas. Uma política que não permita transições que contradigam a hierarquia da cadeia pai pode ser implementada para evitar uma mesclagem direta de funcionalidade.

As definições de política trazem muitos benefícios para o gerenciamento de pipelines:

• Uma única definição de pipeline, ciente de ramificações. O pr.yml introduzido na Parte 2 é executado para cada PR; o merge.yml é executado para cada promoção. O mesmo fluxo de trabalho abrange funcionalidades, camadas e as transições entre elas.
• A promoção é uma mesclagem (merge), não uma nova implantação. O envio de staging para a produção é um merge do git cujo efeito downstream é uma promoção de ramificação do Lakebase. A migração é aplicada uma vez em cada camada, validada primeiro na camada anterior, exatamente como o código é validado em estágios anteriores.
• Sem divergência entre "o ambiente de teste" e a produção. Cada camada descende do mesmo pai. A diferença de esquema (schema diff) entre duas camadas quaisquer é algo real e computável: o esquema é uma única cadeia de páginas com marcadores de divergência, não duas instalações de software de banco de dados. Isso permite que as equipes não precisem lidar com uma frota de servidores de banco de dados que precisam de patches e atualizações.

Rollback por novo apontamento. Uma promoção malsucedida é recuperada apontando a aplicação para o snapshot do tier anterior à promoção. O snapshot em si é outra branch, permitindo que as equipes se recuperem de implantações com falhas.

Atribuição de custos por project_id, branch_id, endpoint_id. O Unity Catalog captura metadados automaticamente. Uma consulta SQL nas tabelas de auditoria e faturamento responde quem criou qual branch, quando ela foi criada e quanto custa mantê-la em execução.

O grande número de instâncias de banco de dados também cai drasticamente. Um mundo de seis instâncias de ambiente (prod, staging, UAT, QA, perf, demo) se reduz a um Lakebase pai com uma hierarquia vinculada ao pai de branches de longa duração. A instância usada para provisionar, monitorar e aplicar patches agora é uma branch lógica com o mesmo formato de dados da produção, governada pelas mesmas políticas da produção, que é redefinida para o estado de produção em um segundo quando necessário.

Diferentes convenções permitem criar muitos tipos diferentes de branches como pais. Uma convenção comum seria manter uma branch que contenha o esquema do banco de dados e quaisquer dados de referência para que qualquer pessoa possa criar uma branch a partir dela e preenchê-la com dados de teste ou executar testes automatizados que criem dados reais, evitando conflitos com staging ou outras branches.

O que fazer agora: o modelo de permissões

Prática nº 10 No playbook da Parte 2, discutimos a governança projetada uma única vez, herdada por branch. Vamos ver como isso é implementado.

O trabalho de design não bloqueia o tempo de execução. É um design estrutural que as tarefas comuns podem aplicar.

As decisões que devem ser tomadas agora, antes que a equipe cresça ou que agentes sejam adicionados:

• Criação de branches a partir de cada camada. Fazer um fork a partir da produção exige uma permissão diferente em comparação com fazer um fork a partir de staging ou de uma feature. O padrão deve ser: as features fazem fork a partir da camada de entrada (inferior), nunca da produção. Os forks de produção são reservados para fluxos de hotfix e recuperação.
• Promoção entre camadas. Uma promoção de “feature para staging” é uma questão de revisão de código. Uma promoção de “staging para produção” é uma questão de coordenação de release. As duas são etapas de aprovação distintas com revisores separados, permitindo independência para as equipes de negócios e desenvolvimento.
• Leitura vs. gravação. O acesso de leitura a dados com o formato de produção em uma branch não é a mesma permissão que o acesso de gravação a essa branch. Muitos cargos de engenharia precisam de leitura; poucos precisam de gravação.
• Políticas do Unity Catalog. Unity Catalog, como mascaramento, filtros de linha e permissões em nível de coluna, se aplicam à produção. Essas políticas são herdadas em cada branch descendente por padrão; exceções específicas de camada (por exemplo, uma camada de QA com PII sintetizados para testes de carga) são declaradas uma única vez.
• Capturas de trilha de auditoria. Cada criação de branch, cada promoção, cada aplicação de migração, cada padrão de acesso, em um único local consultável.

O princípio que faz isso funcionar em escala de equipe: as funções declaram; a política aplica. O engenheiro de plataforma declara a hierarquia de camadas, o modelo de permissões, os caminhos de promoção e a postura de política do Unity Catalog. A política recusa uma transição que contradiga o que foi declarado. Não há situação em que um humano ou um agente possa substituir um limite declarado tentando novamente a operação em um formato diferente.

Este é o trabalho a ser feito hoje, antes que a equipe tenha cinquenta desenvolvedores e os agentes estejam criando branches mais rápido do que qualquer humano poderia revisar. O framework é o que mantém a equipe unida com convenções e proteções compartilhadas. Todo o resto opera dentro dele.

A nova função: de DBA a engenheiro de plataforma

Vinte anos atrás, a conclusão do ensaio de 2003 Evolutionary Database Design ecoou o seguinte:

“Usar as técnicas que descrevemos aqui pode parecer muito trabalho, mas, na verdade, não exige uma quantidade enorme de pessoas. Em muitos projetos, tivemos cerca de trinta desenvolvedores e um tamanho de equipe (incluindo QA, analistas e gerência) de quase cem pessoas. Em um determinado dia, teríamos cerca de cem cópias de vários esquemas nas estações de trabalho das pessoas. No entanto, toda essa atividade exigia apenas um DBA em tempo integral, com alguns desenvolvedores que entendiam o funcionamento do processo e do fluxo de trabalho.”

Esse argumento se mantém para 2026 com cinco reforços.

1. A proporção se mantém, com mais margem por DBA. Um DBA em tempo integral para cada ~100 pessoas, com as mesmas mais de cem branches simultâneas em andamento, gera menos custo por branch porque a criação de branches agora é uma operação de metadados de um segundo. A proporção não é o mais importante. O que importa é o que o DBA está fazendo com essas horas.

2. O trabalho sobe na stack. As horas que eram dedicadas ao provisionamento de infraestrutura, provisionamento de esquemas, controle de acesso e intervenções manuais ocasionais em 2003 agora são direcionadas para o design de políticas de ramificação, políticas de mascaramento, fluxos de trabalho de promoção e observabilidade de trilhas de auditoria. Os artefatos concretos: bots de schema-diff que publicam em cada PR, tarefas agendadas que redefinem branches de desenvolvimento todas as noites, painéis de observabilidade que rastreiam o ciclo de vida das branches e a conformidade com o TTL, definições de CI que controlam merges com base na validação de esquemas. Este é um trabalho de design de plataforma; um trabalho de nível muito mais alto do que antes.

3. Os agentes entram na equação. Algo com que o ensaio de 2003 não precisou lidar foi com agentes escrevendo código. A Neon relata cerca de meio milhão de branches por dia, com mais de 80% delas criadas por agentes. Um único DBA não consegue controlar esse volume por meio de chamados. A evolução da função para arquiteto de plataforma é a única que funciona na escala de agentes.

4. Os números se tornam concretos. Uma equipe de seis desenvolvedores normalmente gera mais de 30 chamados operacionais por sprint no modelo antigo (provisionamento, revisões de esquema, atualizações de dados, concessões de acesso). No modelo nativo de branch: menos de 5 revisões de política de alto valor por sprint. O trabalho repetitivo do DBA cai de mais de 20 horas por semana para menos de 5, e o MTTR cai de mais de 4 horas para menos de 30 minutos. Essa redução no trabalho repetitivo pode ajudar o DBA a trabalhar em conjunto com os desenvolvedores para chegar a soluções ideais para as features que estão sendo desenvolvidas.

5. A trilha de auditoria se torna um painel estratégico. O que antes exigia o cruzamento de referências de três serviços e três linguagens de consulta agora é uma única consulta SQL nas tabelas do sistema da plataforma. Cada branch, cada ação, cada custo, cada evento de governança em um só lugar. O DBA não está criando essa visualização manualmente; é a plataforma que faz isso.

No prefácio de Refactoring Databases (2006), Martin Fowler esperava que o livro representasse "apenas um primeiro passo" em direção a ferramentas que automatizassem a refatoração de bancos de dados da mesma forma que as IDEs automatizam a refatoração de código. O branching é esse próximo passo. O que Fowler esperava em 2006, uma alteração disciplinada de banco de dados na velocidade do código, é o que a plataforma oferece agora. O DBA projeta a disciplina; a plataforma a aplica.

O título da nova função varia (engenheiro de plataforma, proprietário de plataforma de banco de dados, ou ainda DBA apenas no nome). A essência é a mesma: a pessoa que projeta o framework dentro do qual todos os outros operam.

Agentes com a mesma capacidade

Prática nº 11 na Parte 2, descrevemos o agente de codificação como profissional com a mesma capacidade de branching. Vamos discutir isso.

Os agentes têm acesso a branches, não à produção. As mesmas regras de fluxo de trabalho que se aplicam a Jen se aplicam ao agente. Os testes são executados em um banco de dados real em uma branch, e não em mocks que um agente poderia modificar ou excluir. As diferenças de esquema (schema diffs) aparecem em cada PR, independentemente de quem criou a migração. As políticas que protegem Jen protegem o agente.

Agentes, se deixados sem direcionamento, são como desenvolvedores juniores.

Um desenvolvedor júnior, ao receber um ticket de funcionalidade sem nenhuma orientação adicional, consegue produzir um código que compila, testes que passam e um script de migração que é aplicado sem problemas. O código também pode duplicar uma lógica que já existia em outro lugar da base de código, introduzindo redundância. A migração pode adicionar uma coluna com o nome certo e o tipo errado. O teste pode passar porque exercita apenas o caminho feliz (happy path). Nenhuma dessas falhas aparece na execução bem-sucedida do CI; elas aparecem seis semanas depois, quando outra pessoa precisa estender o trabalho.

Os agentes fazem a mesma coisa, mas muito mais rápido e em maior volume.

Sem orientação explícita, um agente vai:

• Reinventar um padrão que a base de código já possui.
• Criar uma alteração de esquema que parece correta, mas ignora a mecânica de transição de refatoração nomeada (por exemplo, exclui uma coluna sem antes mover os dados ou adiciona uma coluna NOT NULL sem atualizar as linhas existentes).
• Escrever testes que passam com base no formato de dados que ele imaginou, e não no formato de dados que existe em produção.
• Criar migrações que são aplicadas, mas produzem um estado inconsistente em caso de rollback.
• Empilhar abstrações sobre abstrações para acomodar uma pequena alteração.

O substrato torna a barra verde honesta (sem mocks; banco de dados real em uma branch). O que ele não faz é tornar o código fácil de manter.

A equipe torna o código fácil de manter por meio de quatro reforços:

• Guardrails: o modelo de permissão. Os agentes não podem criar branches a partir da produção, não podem promover alterações entre camadas e não podem aplicar migrações a uma camada que não possuem. O substrato recusa.
• Padrões: as refatorações nomeadas. O catálogo de 2006 em databaserefactoring.com nomeia mais de 70 refatorações com mecânicas de transição explícitas. Um agente orientado a "aplicar a refatoração Split Column" produz uma migração diferente de um agente orientado a "dividir esta coluna".
• Fluxo de trabalho: a máquina de estados de SCM. Os agentes seguem uma sequência de estados com etapas de bloqueio entre eles. O substrato recusa transições que não atendem ao contrato declarado.
• Revisão: humanos no ciclo de PR. A diferença de esquema (schema-diff) fica visível em cada PR, com o DBA no caminho de revisão. A Prática nº 1 reformulada na Parte 2 tornou isso assíncrono; em escala de equipe, com agentes integrados, essa revisão assíncrona é o que detecta os desvios que os testes não pegaram.

O fluxo de trabalho de SCM é o pilar principal. No Lakebase App Dev Kit, o controle de versão (SCM) abrange mais do que a branch de código: ele cobre a ramificação pareada (a branch de código e a branch do Lakebase gerenciadas como uma única unidade, conforme apresentado na Parte 1). Essa ramificação pareada, fornecida como um recurso no substrato comum do Lakebase App Dev Kit, impõe guardrails comuns, como merges que contradizem a hierarquia, a migração que acompanha a branch, as etapas de validação do CI e o merge que aplica a migração à camada pai. O kit de desenvolvimento fornece esse fluxo de trabalho de SCM como uma máquina de estados executável.

A Fig. 4 acima descreve os cinco estados durante o desenvolvimento: scaffold-complete, feature-claimed, pr-ready, ci-green, merged. Cada transição entre estados diferentes é impulsionada por um comando CLI (lakebase-scm-claim-feature-branch, lakebase-scm-prepare-pr, lakebase-scm-wait-ci, lakebase-scm-merge). Cada comando CLI valida as pré-condições antes de realizar o trabalho, executa a transição e grava o novo estado em .lakebase/workflow-state.json (uma superfície de validação com esquema verificado). Uma falha na validação deixa a máquina recuperável no estado anterior. As etapas de validação são de bloqueio, não apenas informativas.

Os agentes chamam essas CLIs; eles não podem inventar um caminho paralelo. O substrato se recusa a avançar a máquina de estados em caso de falha de pré-condição: uma branch de funcionalidade originada na camada errada é rejeitada; uma tentativa de merge antes que o CI esteja verde é recusada; um arquivo de estado inconsistente bloqueia a próxima etapa de validação. Os contratos de entrega são de responsabilidade do papel de scrum master; o substrato os impõe. Decisões estruturais (a hierarquia de camadas, a camada de origem para uma funcionalidade, o caminho de promoção) pertencem ao arquiteto ou scrum master, são registradas e depois respeitadas pelo substrato. O substrato nunca inventa uma camada ou um elemento pai; ele respeita o que foi declarado e recusa transições que o contradigam.

Este é o framework que muda a forma como as equipes vêm usando agentes até agora. A integração ingênua trata um agente como um engenheiro sênior em uma janela de chat: envie o contexto, peça o resultado, intere. Isso funciona na escala de um único desenvolvedor, mas falha na escala de equipe, porque o "contexto" do agente não pode ser revisado, governado ou reproduzido. Em vez disso, trate o agente como um desenvolvedor júnior: dê a ele uma tarefa específica e documentada dentro de uma máquina de estados executável, valide sua saída em relação a um esquema, avance a etapa de validação e repita. O substrato impõe as regras; o arquivo de estado do fluxo de trabalho é a API.

Entradas do playbook para as práticas em escala de equipe

Parte 2 introduziu as práticas nº 10 e nº 11 em Práticas emergentes para 2026

Prática nº 10: Governança projetada uma única vez, herdada por branch

Regra. O modelo de permissão, as políticas do Unity Catalog para gerenciar o controle de acesso e a captura de trilhas de auditoria são projetados uma única vez na branch principal (trunk) e herdados automaticamente por cada branch descendente.

Por que este é um hábito duradouro agora? Em escala de equipe, a governança deve ser uma função do DBA ou do engenheiro de plataforma, não uma disciplina de que o desenvolvedor precise se lembrar. As branches são criadas e destruídas em segundos; a configuração manual de governança por branch consumiria a economia de tempo gerada pela ramificação.

Funcionamento:

• Declarar a hierarquia de camadas: quais branches de longa duração existem, quais são seus links pais e qual postura de governança cada camada carrega.
• Declarar os limites de permissão: quem pode criar branches a partir de cada camada, quem pode promover alterações entre camadas e quem tem permissão de leitura versus gravação.
• Declarar a herança de políticas do Unity Catalog: mascaramento, filtros de linha e quais permissões em nível de coluna são herdadas do pai por padrão; exceções específicas de camada são declaradas uma única vez. A autopropagação em todos os tipos de política do Unity Catalog está terminando de ser implementada; projete o framework para o estado de destino.
• Declarar a captura de trilha de auditoria: cada criação de branch, cada promoção, cada aplicação de migração e cada padrão de acesso são inseridos automaticamente em tabelas de sistema consultáveis.
• O DBA ou engenheiro de plataforma impõe as regras por meio de políticas. Qualquer transição que contradiga o modelo declarado é recusada.

Antipadrão. Configurar a governança por branch em tempo de execução. O objetivo de declarar uma única vez é garantir que o framework se sustente mesmo quando as branches são criadas mais rapidamente do que um humano consegue revisar. A configuração manual por branch recria o gargalo que a ramificação acabou de eliminar.

Onde a equipe de Jen vai além. O engenheiro de plataforma ou DBA de Jen declarou a hierarquia de camadas na criação do projeto. Cada branch que Jen, seus colegas de equipe ou os agentes da equipe criam herda as configurações declaradas de mascaramento, permissões e auditoria. Quando a equipe adiciona uma nova camada, o framework registra o novo link pai; recursos em andamento mantêm seu pai original (sem reassociação retroativa); novos recursos fazem fork a partir da nova camada de entrada.

Prática nº 11: Agente como profissional com a mesma capacidade de branching

Regra. Os agentes operam dentro da máquina de estados executável do fluxo de trabalho do SCM: cinco estados, gates de bloqueio entre eles, arquivos de estado validados por esquema. As mesmas regras de fluxo de trabalho regem Jen e o agente; um substrato comum as impõe, independentemente de quem esteja agindo.

Por que esse é um hábito duradouro agora? A criação de branches é uma operação de metadados, portanto, o volume gerado por agentes é viável. O substrato desenvolvido para que os agentes aproveitem pode recusar transições que contradigam a hierarquia de camadas declarada ou o estado do gate registrado. Não há contexto de janela de chat para recorrer; apenas o artefato no disco (workflow-state.json) cruza a fronteira entre as transições de gate.

Mecânica:

• A máquina de estados do SCM tem cinco estados: scaffold-complete, feature-claimed, pr-ready, ci-green, merged. Cada transição é orientada por uma CLI; cada CLI valida as pré-condições antes de realizar o trabalho.
• A superfície do gate é .lakebase/workflow-state.json, validada em relação a scm-workflow-state.schema.json. Cada transição grava o novo estado e as invariantes que o próximo gate precisa.
• Decisões estruturais (hierarquia de camadas, camada de origem por recurso, caminho de promoção, contratos de entrega) pertencem a funções (arquiteto ou scrum-master), são registradas e, em seguida, aplicadas pelo substrato.
• Os agentes chamam as CLIs. O substrato as impõe; os agentes não podem contorná-las. Um gate com falha deixa a máquina de estados recuperável no estado anterior; o agente não "tenta novamente de uma forma diferente".
• Os gates de CI que são executados dentro de pr-ready para ci-green exercitam o Postgres real em um branch, com a diferença de esquema (schema diff) publicada no PR. O estado real do banco de dados é aquilo contra o qual o trabalho do agente é medido.

Antipadrão. Tratar um agente como um engenheiro sênior em uma janela de chat usando "despejar contexto e pedir saída" funciona na escala de um único desenvolvedor, mas falha na escala de equipe porque o "contexto" não pode ser revisado, governado ou reproduzido. Em vez disso, use o modelo de artefato como API: os agentes LÊEM workflow-state.json e as entradas documentadas para sua fase; eles GRAVAM as saídas documentadas; os validadores verificam; o próximo gate só é acionado quando o contrato é cumprido.

Onde a equipe de Jen vai além. Cada agente na equipe de Jen opera dentro da mesma máquina de cinco estados que Jen e seus colegas de equipe. A função de scrum-master é proprietária dos contratos de entrega; o substrato recusa transições que não os satisfaçam. Um agente não pode implantar um recurso que tenha feito fork da camada errada; um agente não pode fazer merge antes que o CI esteja verde; um agente não pode ignorar o artefato de schema-diff. O framework se mantém firme, independentemente de quem ou do que iniciou a ação.

TDD como uma camada opcional tecida por cima

A Prática nº 11 estabelece o fluxo de trabalho do SCM como a linha de base: cada consumidor do kit o segue, tanto agentes quanto humanos. O TDD é uma consideração separada que se sobrepõe a essa linha de base para equipes que desejam a disciplina de testar primeiro (test-first). Ele é opcional; os gates do SCM são obrigatórios, independentemente do caminho.

Por que os testes importam, mesmo antes do TDD: quando os agentes criam código, os testes são a única imposição que escala. Kent Beck, em sua entrevista de 2026 para o Pragmatic Engineer, nomeou publicamente o modo de falha: ele está tendo problemas para impedir que os agentes de IA excluam testes para fazê-los passar. A barra verde é fácil de satisfazer quando nada no loop força o agente a confrontar a forma real do sistema. Mocks tornam isso trivial. Substitutos em memória também.

O branching torna a barra verde honesta na camada de dados. Um banco de dados real em um branch real é aquilo contra o qual o agente está testando; as restrições de esquema rejeitam inserções de linhas que não correspondem, as chaves estrangeiras rejeitam órfãos, o formato real dos dados expõe suposições que o mock teria absorvido silenciosamente, o agente não pode excluir tabelas. O custo de simular a conformidade aumenta com essas proteções (guardrails).

Mas o substrato é necessário, não suficiente. Os testes têm que vir de algum lugar. Se o agente os escreve, o agente também pode excluí-los. Essa é a lacuna que o TDD preenche.

O fluxo de trabalho do TDD se sobrepõe ao fluxo de trabalho do SCM. Ele é acionado entre os estados do SCM feature-claimed e pr-ready; ele faz chamadas para o SCM para operações de branch (branches de experimentos de ciclo usam a primitiva do SCM por baixo); ele não faz chamadas para cima no SCM. A dependência é unidirecional. Equipes que não desejam a camada de TDD podem entregar recursos por meio de edição direta no branch de recursos e ainda assim satisfazer todos os gates do SCM.

O Lakebase App Dev Kit fornece o fluxo de trabalho do TDD como uma segunda máquina de estados com seus próprios agentes por função e validadores de gate:

• Spec-author transforma a narrativa de um solicitante em um artefato de recurso estruturado, validado por esquema.
• Architect-reviewer mapeia os requisitos não funcionais e os princípios de arquitetura do recurso para decisões arquitetônicas, gerando como saída architecture.json mais texto explicativo.
• Test-strategist produz a lista de testes e os cenários por critério de aceitação, gerando como saída test-list.json mais markdown renderizado. Cada NFR tem pelo menos um critério de aceitação (AC); cada AC tem um cenário.
• Scrum-master orquestra os ciclos de build. Cada ciclo faz fork de um branch de experimento (usando o substrato do SCM por baixo), executa um agente driver para implementar o próximo AC e executa um agente navigator para revisar e validar o resultado.
• Driver e navigator são o escritor de testes e o escritor de código do loop interno, pareados, RED-GREEN-REFACTOR.

Cada função tem entradas e saídas documentadas, validadas em relação a um esquema. Cada agente recebe apenas suas entradas documentadas; as saídas são validadas antes que a próxima função seja executada. O artefato é a API entre as funções; o esquema é a verificação de tipo. Um artefato ausente é tratado como um gate com falha. Um artefato malformado é tratado como um artefato ausente. A camada de TDD empresta o mesmo modelo de artefato como API que a Prática nº 11 estabeleceu para o SCM.

O manual completo para a camada de TDD está no Companion: Lakebase App Dev Kit (de código aberto, com um e-book complementar para profissionais humanos). As máquinas de estado do SCM e do TDD, os contratos de agentes por função, as verificações de conformidade de artefatos e os validadores de gate são todos fornecidos como CLIs que qualquer orquestrador (o kit, a extensão do IDE, um job de CI, uma sessão de shell humana) pode chamar.

A versão resumida: o SCM é a linha de base (Prática nº 11). O TDD é uma camada por cima. O branching torna os testes honestos; o TDD faz com que os testes venham primeiro; o kit torna ambos os fluxos de trabalho executáveis.

O que a equipe de Jen mostra

A Parte 1 guiou Jen por um recurso: ela pareou um branch de código com um branch do Lakebase, executou uma migração real em relação a dados com o formato de produção em segundos, testou sem mocks, abriu um PR com a diferença de esquema (schema diff) publicada inline para revisão e fez o merge com a migração aplicada e os branches efêmeros limpos. A alteração no banco de dados tornou-se parte do desenvolvimento normal.

A Parte 2 nomeou o playbook: as sete práticas de 2003, as limitações que mantiveram cinco delas como aspiração até 2026, as mesmas sete reformuladas assim que a ramificação chegou, além de duas novas práticas que a tecnologia possibilita para o desenvolvedor individual. Nove práticas no dia a dia, mais duas surgindo em escala de equipe.

A Parte 3 levou o playbook para a equipe. Definiu a topologia de camadas, descrevendo como ramificações de longa duração residem dentro de um pai Lakebase, como o modelo de permissão se torna o artefato de design do engenheiro de plataforma, declarado uma vez e imposto pelo substrato (Prática nº 10). Como o papel do DBA conclui sua evolução para arquiteto de plataforma, com essa confirmação do argumento de contratação de 2003. Os agentes entram no fluxo de trabalho com a mesma capacidade, dentro da máquina de estados executável do fluxo de trabalho de SCM, com o substrato impondo os gates independentemente de quem ou do que está agindo (Prática nº 11). O TDD é uma camada opcional tecida por cima: disciplina de testes primeiro com funções dedicadas, gates e contratos de artefatos, para equipes que desejam isso.

O Companion: Plugin Walkthrough cobre a Lakebase SCM Extension para VS Code e Cursor de ponta a ponta.

O Companion: Lakebase App Dev Kit, com um e-book complementar para profissionais humanos, cobre o fluxo de trabalho de TDD acima: as máquinas de estado de SCM e TDD, os agentes por função, os validadores de gate e os contratos de artefato que tornam os agentes seguros para serem incluídos na equipe.

A metodologia estava clara há vinte anos. A capacidade técnica chegou em 2026. O playbook para profissionais humanos e agentes agora está operacional. A equipe de Jen tem cinquenta desenvolvedores e uma frota de agentes; o fluxo de trabalho é o mesmo.

Conclusão: A capacidade de ramificar um banco de dados agora oferece imensa flexibilidade para a equipe de desenvolvimento provisionar bancos de dados, criar testes em esquemas reais, executar CI para cada criação de PR em seu próprio banco de dados e permitir que os agentes trabalhem dessa maneira, tudo com a estrutura de governança do Unity Catalog aplicando as políticas.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original