Como o desenvolvimento de software agêntico mudará os bancos de dados

Em nosso artigo anterior, apresentamos o Lakebase, a arquitetura de banco de dados de terceira geração que separa fundamentalmente armazenamento e computação. Neste artigo, exploramos uma consequência crítica dessa mudança: como os agentes de IA estão mudando o ciclo de vida de desenvolvimento de software e que tipo de bancos de dados os agentes de IA realmente precisam?

O ciclo de vida de desenvolvimento de software está passando por uma transformação radical. Os LLMs possibilitaram uma nova geração de frameworks agênticos que podem analisar requisitos, escrever código, executar testes, implantar serviços e refinar aplicações iterativamente, tudo em velocidade recorde. Como resultado, o custo marginal de construir e implantar aplicações está despencando.

Mesmo estando ainda nos estágios iniciais do desenvolvimento de software agêntico, observamos consistentemente, tanto dentro da Databricks quanto entre nossa base de clientes, que a taxa de experimentação está acelerando e o volume de aplicações sendo criadas está explodindo. À medida que o mundo transita do software feito à mão para o desenvolvimento de software agêntico, identificamos três tendências emergentes que redefinirão conjuntamente os requisitos dos sistemas de banco de dados modernos:

1. O desenvolvimento de software mudará de um processo convencional lento e linear para um processo evolutivo rápido.
2. O software se tornará mais valioso no geral, mas o valor de cada aplicação individual despencará à medida que o custo marginal para desenvolver software diminui. Isso significa que precisamos de infraestrutura que possa suportar o desenvolvimento de software com custo marginal mínimo. Crucialmente, a arquitetura também deve levar em conta o fato de que qualquer um desses bancos de dados pequenos e efêmeros pode se tornar um sistema de produção com muito tráfego, tornando a capacidade de suportar crescimento contínuo e elástico um requisito arquitetural fundamental.
3. Ecossistemas abertos se tornarão um requisito operacional rigoroso, não apenas uma preferência.

Aqui está uma análise mais aprofundada de cada uma dessas tendências e como o Lakebase é arquitetado de forma exclusiva para suportá-las.

Desenvolvimento de Software Evolutivo Rápido

Como grande parte do ciclo de vida de desenvolvimento de software era historicamente muito custosa (escrever código, testar, operações), construir e operar uma nova aplicação exigia um investimento significativo de engenharia. Consequentemente, o desenvolvimento de software tradicional foi otimizado para planejamento cuidadoso e um processo relativamente linear.

Os agentes mudam essa dinâmica. As aplicações agora podem ser geradas, modificadas e reimplantadas em minutos. Em vez de construir um sistema cuidadosamente projetado, desenvolvedores e agentes exploram cada vez mais grandes espaços de implementações possíveis. O desenvolvimento começa a se assemelhar a um algoritmo evolutivo:

1. Gerar uma versão inicial de uma aplicação.
2. Criar rapidamente variantes com esquemas, prompts ou lógica diferentes.
3. Avaliar os resultados.
4. Continuar o desenvolvimento a partir das versões mais bem-sucedidas.

Dependendo da complexidade, cada iteração evolutiva pode durar de segundos a horas, o que é 100x a 1000x mais rápido do que os ciclos de desenvolvimento pré-LLM. De fato, nossa telemetria de ambientes de produção do Lakebase mostra que, em média, cada projeto de banco de dados tem ~10 branches e alguns bancos de dados com branches aninhados atingindo profundidades de mais de 500 iterações (ou seja, 500 iterações na evolução).

Infraestrutura de código como o Git já suporta muito bem esse fluxo de trabalho. Desenvolvedores ou agentes podem criar um branch da base de código com git checkout -b instantaneamente. No entanto, a infraestrutura de banco de dados legada não oferece uma maneira rápida e econômica de criar um branch do estado do banco de dados.

O Lakebase foi projetado para suportar nativamente esse fluxo de trabalho evolutivo agêntico. Agentes podem criar um branch de um banco de dados de produção ou teste instantaneamente e a um custo quase zero. Como o Lakebase usa um mecanismo de branching copy-on-write O(1) na camada de armazenamento, nenhuma cópia física cara de dados é necessária. Você simplesmente cria um branch dos dados junto com o código e paga apenas pela computação do banco de dados durante o experimento.

Sensibilidade ao Custo

Como mencionado anteriormente, embora o software se torne mais valioso no geral, o valor de cada aplicação individual despencará à medida que o custo marginal para desenvolver software diminui. Muitos serviços gerados por agentes são pequenas ferramentas internas, protótipos ou fluxos de trabalho restritos. Eles podem ser executados ocasionalmente ou atender a cargas de trabalho altamente intermitentes e orientadas por eventos.

Neste mundo, precisamos de infraestrutura que possa suportar o desenvolvimento de novo software com custo marginal/incremental mínimo. Qualquer banco de dados que imponha centenas de dólares por mês como preço mínimo de base é impossível de justificar se a aplicação em si fornecer valor limitado ou experimental. Nossos dados mostram que para cerca de metade dessas aplicações agênticas, o tempo de computação do banco de dados é inferior a 10 segundos.

Bancos de dados tradicionais foram projetados como componentes de infraestrutura sempre ativos com sobrecarga fixa de provisionamento e operação. Esse modelo se adapta a aplicações grandes e estáveis, mas falha economicamente quando as aplicações são numerosas, efêmeras e de curta duração.

A natureza serverless e elástica do Lakebase aborda diretamente essa necessidade de custo. Ao desacoplar completamente as instâncias de computação da camada de armazenamento, o Lakebase pode dimensionar automaticamente a computação do banco de dados com base na carga em tempo inferior a um segundo. Crucialmente, ele também reduz a computação do banco de dados a zero quando não está em uso, eliminando completamente o piso de custo e alcançando custos ociosos próximos de zero.

Crescendo de Pequeno para Grande

A natureza do desenvolvimento impulsionado por agentes significa que um grande volume de bancos de dados pequenos e efêmeros está sendo constantemente criado para testes, prototipagem e fluxos de trabalho restritos. O desafio arquitetural crucial é que os desenvolvedores, e os próprios agentes, não conseguem prever quais dessas aplicações nascentes de repente decolarão e exigirão escala massiva de produção.

A arquitetura do banco de dados deve, portanto, suportar inerentemente crescimento contínuo e elástico de uma instância minúscula e de baixo custo para um sistema de produção em larga escala com tráfego intenso. Essa transição deve ocorrer sem exigir nenhum replanejamento manual, provisionamento ou etapas complexas de migração do usuário. A arquitetura sozinha deve lidar com a evolução, tornando a capacidade de escalar instantaneamente de quase zero para capacidade massiva um requisito fundamental para um mundo onde a exploração agêntica é o modelo de desenvolvimento padrão.

Ecossistemas de Código Aberto

Sistemas agênticos derivam suas capacidades de LLMs treinados em extensos corpora de código-fonte publicamente disponível e documentação técnica. Esse viés de treinamento lhes confere familiaridade operacional profunda com ecossistemas de código aberto, APIs e semântica de erros.

Bancos de dados como o Postgres estão profundamente integrados ao mundo do código aberto. Suas interfaces, comportamentos e códigos de erro aparecem nos dados de treinamento que os modelos modernos aprendem. Como resultado, os agentes podem gerar consultas, esquemas e integrações para eles de forma muito mais confiável. Bancos de dados proprietários enfrentam uma desvantagem inerente porque os agentes simplesmente não têm contexto suficiente para operá-los efetivamente.

Para o desenvolvimento impulsionado por agentes, a abertura não é mais apenas uma preferência filosófica — é um requisito prático para automação confiável. Mas esse requisito deve ir além apenas da interface de consulta; ele deve alcançar a própria camada de armazenamento. Embora bancos de dados em nuvem de segunda geração possam usar motores de execução de código aberto, eles ainda bloqueiam seus dados em formatos de armazenamento proprietários e internos.

O Lakebase é construído sobre o Postgres, mas leva a abertura um passo adiante. Ele armazena dados em formatos de página Postgres padrão e abertos diretamente no armazenamento de objetos da nuvem (o data lake). Isso permite que agentes, motores analíticos externos e novas ferramentas interajam com os dados nativamente, sem nunca serem gargalados por um único motor de computação proprietário.

Bancos de Dados para a Era Agêntica

A mudança não é hipotética — já está em andamento. No serviço Lakebase da Databricks, os agentes de IA agora criam aproximadamente 4x mais bancos de dados do que usuários humanos.

Este ponto de dados captura as tendências descritas acima em um único gráfico. Agentes são criadores prolíficos de ambientes de banco de dados — criando instâncias para experimentos, ramificando para testes e descartando-as quando terminam. A infraestrutura que atende a essas cargas de trabalho deve suportar esse padrão de forma econômica e operacional.

Propriedades como eficiência de custo, agilidade e abertura sempre foram desejáveis. Mas o surgimento do desenvolvimento de software agentivo as transformou de algo bom de se ter em requisitos fundamentais. Bancos de dados que impõem altos custos iniciais, carecem de primitivas de ramificação ou bloqueiam dados em formatos proprietários ficarão cada vez mais fora de sintonia com a forma como o software está sendo construído.

Este é precisamente o espaço de design do Lakebase. Ele foi construído para as realidades econômicas e técnicas específicas que o desenvolvimento impulsionado por IA cria: ramificação evolutiva a custo zero, elasticidade real de escala para zero, armazenamento Postgres aberto no lake e operações de autogerenciamento. À medida que os agentes participam cada vez mais da construção e evolução de software, os bancos de dados mais adequados para este novo mundo são aqueles projetados para experimentação, abertura e elasticidade desde o início.

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