Wie die agentengesteuerte Softwareentwicklung Datenbanken verändern wird

In unserem vorherigen Blogbeitrag haben wir Lakebase vorgestellt, die Datenbankarchitektur der dritten Generation, die Speicher und Rechenleistung grundlegend trennt. In diesem Blogbeitrag untersuchen wir eine wichtige Folge dieses Wandels: Wie verändern KI-Agenten den Softwareentwicklungszyklus und welche Art von Datenbanken benötigen KI-Agenten tatsächlich?

Der Softwareentwicklungszyklus durchläuft eine radikale Transformation. LLMs haben eine neue Generation von agentenbasierten Frameworks ermöglicht, die Anforderungen analysieren, Code schreiben, Tests ausführen, Dienste bereitstellen und Anwendungen iterativ verfeinern können – und das alles in Rekordgeschwindigkeit. Infolgedessen sinken die Grenzkosten für die Erstellung und Bereitstellung von Anwendungen rapide.

Obwohl wir uns noch in den Anfängen der agentenbasierten Softwareentwicklung befinden, haben wir sowohl bei Databricks als auch bei unseren Kunden durchweg beobachtet, dass die Experimentierrate beschleunigt wird und das schiere Volumen der erstellten Anwendungen explodiert. Während sich die Welt von handgefertigter Software zur agentenbasierten Softwareentwicklung wandelt, identifizieren wir drei aufkommende Trends, die gemeinsam die Anforderungen moderner Datenbanksysteme neu definieren werden:

1. Die Softwareentwicklung wird sich von einem konventionellen, langsamen und linearen Prozess zu einem schnellen, evolutionären Prozess entwickeln.
2. Software wird insgesamt wertvoller werden, aber der Wert jeder einzelnen Anwendung wird sinken, da die Grenzkosten für die Softwareentwicklung sinken. Das bedeutet, dass wir eine Infrastruktur benötigen, die die Softwareentwicklung zu minimalen Grenzkosten unterstützt. Entscheidend ist, dass die Architektur auch berücksichtigt, dass jede dieser kleinen, kurzlebigen Datenbanken zu einem Produktionssystem mit viel Traffic werden kann, was die Fähigkeit zur Unterstützung nahtlosen, elastischen Wachstums zu einer grundlegenden architektonischen Anforderung macht.
3. Offene Ökosysteme werden zu einer strengen operativen Anforderung, nicht nur zu einer Präferenz.

Hier werfen wir einen genaueren Blick auf jeden dieser Trends und wie Lakebase einzigartig dafür entwickelt wurde, diese zu unterstützen.

Schnelle evolutionäre Softwareentwicklung

Da ein großer Teil des Softwareentwicklungszyklus historisch sehr kostspielig war (Code schreiben, testen, Betrieb), erforderte die Erstellung und der Betrieb einer neuen Anwendung erhebliche Investitionen in die Entwicklung. Folglich wurde die traditionelle Softwareentwicklung für sorgfältige Planung und einen relativ linearen Prozess optimiert.

Agenten verändern diese Dynamik. Anwendungen können jetzt in Minuten generiert, modifiziert und neu bereitgestellt werden. Anstatt ein sorgfältig entworfenes System zu erstellen, erkunden Entwickler und Agenten zunehmend große Räume möglicher Implementierungen. Die Entwicklung beginnt, einem evolutionären Algorithmus zu ähneln:

1. Erstellen einer anfänglichen Version einer Anwendung.
2. Schnelles Erstellen von Varianten mit unterschiedlichen Schemata, Prompts oder Logik.
3. Bewerten der Ergebnisse.
4. Fortsetzen der Entwicklung aus den erfolgreichsten Versionen.

Abhängig von der Komplexität kann jede evolutionäre Iteration von Sekunden bis Stunden dauern, was 100- bis 1000-mal schneller ist als die Entwicklungszyklen vor LLMs. Tatsächlich zeigen unsere Telemetriedaten aus Lakebase-Produktionsumgebungen, dass jedes Datenbankprojekt im Durchschnitt etwa 10 Branches hat und einige Datenbanken mit verschachtelten Branches Tiefen von über 500 Iterationen erreichen (d. h. 500 Iterationen in der Evolution).

Code-Infrastrukturen wie Git unterstützen diesen Workflow bereits sehr gut. Entwickler oder Agenten können einen Branch der Codebasis mit git checkout -b sofort erstellen. Legacy-Datenbankinfrastrukturen bieten jedoch keine schnelle, kostengünstige Möglichkeit, einen Branch des Datenbankzustands zu erstellen.

Lakebase wurde entwickelt, um diesen agentenbasierten evolutionären Workflow nativ zu unterstützen. Agenten können sofort und zu nahezu null Kosten einen Branch einer Produktions- oder Testdatenbank erstellen. Da Lakebase auf der Speicherebene einen O(1)-Metadaten-Copy-on-Write-Branching-Mechanismus verwendet, ist kein teures physisches Kopieren von Daten erforderlich. Sie verzweigen die Daten einfach zusammen mit dem Code und zahlen nur für die Datenbankberechnung während des Experiments.

Kostenempfindlichkeit

Wie bereits erwähnt, wird Software zwar insgesamt wertvoller, aber der Wert jeder einzelnen Anwendung wird sinken, da die Grenzkosten für die Softwareentwicklung sinken. Viele von Agenten generierte Dienste sind kleine interne Tools, Prototypen oder eng gefasste Workflows. Sie laufen möglicherweise nur gelegentlich oder bedienen stark bursty, ereignisgesteuerte Workloads.

In dieser Welt benötigen wir eine Infrastruktur, die neue Softwareentwicklung zu minimalen Grenzkosten/inkrementellen Kosten unterstützen kann. Jede Datenbank, die einen monatlichen Grundpreis von Hunderten von Dollar auferlegt, ist nicht zu rechtfertigen, wenn die Anwendung selbst nur einen begrenzten oder experimentellen Wert bietet. Unsere Daten zeigen, dass für etwa die Hälfte dieser agentenbasierten Anwendungen die Datenbankberechnungslebensdauer weniger als 10 Sekunden beträgt.

Traditionelle Datenbanken wurden als Always-On-Infrastrukturkomponenten mit fester Bereitstellung und betrieblichem Overhead konzipiert. Dieses Modell passt zu großen, stabilen Anwendungen, versagt aber wirtschaftlich, wenn Anwendungen zahlreich, kurzlebig und kurzzeitig sind.

Die serverlose, elastische Natur von Lakebase adressiert diesen Kostenimperativ direkt. Durch die vollständige Entkopplung der Recheninstanzen von der Speicherebene kann Lakebase die Datenbankberechnung basierend auf der Last in weniger als einer Sekunde automatisch skalieren. Entscheidend ist, dass sie die Datenbank auch auf null herunterfährt, wenn sie nicht genutzt wird, wodurch die Kostenobergrenze vollständig entfällt und nahezu null Leerlaufkosten erzielt werden.

Wachstum von klein zu groß

Die Natur der agentengesteuerten Entwicklung bedeutet, dass ständig eine riesige Menge kleiner, kurzlebiger Datenbanken für Tests, Prototyping und eng gefasste Workflows erstellt werden. Die entscheidende architektonische Herausforderung besteht darin, dass Entwickler und die Agenten selbst nicht vorhersagen können, welche dieser aufkommenden Anwendungen plötzlich an Bedeutung gewinnen und massive Produktionsskalierung erfordern werden.

Die Datenbankarchitektur muss daher inhärent nahtloses, elastisches Wachstum von einer winzigen, kostengünstigen Instanz zu einem vollständigen Produktionssystem mit starkem Traffic unterstützen. Dieser Übergang muss erfolgen, ohne dass der Benutzer manuelle Re-Platforming-, Bereitstellungs- oder komplexe Migrationsschritte durchführen muss. Die Architektur allein sollte die Evolution bewältigen, wodurch die Fähigkeit, sofort von nahezu null auf massive Kapazität zu skalieren, zu einer grundlegenden Anforderung für eine Welt wird, in der agentenbasierte Erkundung das Standardentwicklungsmodell ist.

Open-Source-Ökosysteme

Agentenbasierte Systeme beziehen ihre Fähigkeiten aus LLMs, die auf umfangreichen Korpora öffentlich verfügbarer Quellcodes und technischer Dokumentationen trainiert wurden. Diese Trainingsverzerrung verleiht ihnen eine tiefe, operative Vertrautheit mit Open-Source-Ökosystemen, APIs und Fehlerssemantiken.

Datenbanken wie Postgres sind tief in der Open-Source-Welt verwurzelt. Ihre Schnittstellen, Verhaltensweisen und Fehlercodes erscheinen in den Trainingsdaten, aus denen moderne Modelle lernen. Infolgedessen können Agenten für sie weitaus zuverlässiger Abfragen, Schemata und Integrationen generieren. Proprietäre Datenbanken haben einen inhärenten Nachteil, da Agenten einfach nicht genügend Kontext haben, um sie effektiv zu bedienen.

Für die agentenbasierte Entwicklung ist Offenheit keine philosophische Präferenz mehr, sondern eine praktische Anforderung für zuverlässige Automatisierung. Diese Anforderung muss sich jedoch über die reine Abfrageschnittstelle hinaus erstrecken; sie muss bis zur Speicherebene reichen. Während Cloud-Datenbanken der zweiten Generation möglicherweise Open-Source-Ausführungs-Engines verwenden, sperren sie Ihre Daten immer noch in proprietäre, interne Speicherformate ein.

Lakebase basiert auf Postgres, geht aber in Sachen Offenheit noch einen Schritt weiter. Es speichert Daten in Standard-Postgres-Seitenebenenformaten direkt im Cloud-Objektspeicher (dem Data Lake). Dies ermöglicht es Agenten, externen Analyse-Engines und neuen Tools, nativ mit den Daten zu interagieren, ohne jemals durch eine einzige, proprietäre Compute-Engine ausgebremst zu werden.

Datenbanken für die Agenten-Ära

Der Wandel ist nicht hypothetisch – er ist bereits im Gange. Im Lakebase-Dienst von Databricks erstellen KI-Agenten derzeit etwa 4x mehr Datenbanken als menschliche Benutzer.

Dieser Datenpunkt erfasst die oben beschriebenen Trends in einem einzigen Diagramm. Agenten sind produktive Ersteller von Datenbankumgebungen – sie starten Instanzen für Experimente, verzweigen für Tests und verwerfen sie, wenn sie fertig sind. Die Infrastruktur, die diese Workloads bedient, muss dieses Muster wirtschaftlich und betrieblich unterstützen.

Eigenschaften wie Kosteneffizienz, Agilität und Offenheit waren schon immer wünschenswert. Aber der Aufstieg der agentenbasierten Softwareentwicklung hat sie von „nice-to-haves“ zu grundlegenden Anforderungen gemacht. Datenbanken, die hohe Kostenuntergrenzen auferlegen, keine Verzweigungsprimitive aufweisen oder Daten in proprietären Formaten sperren, werden zunehmend aus dem Takt geraten, wie Software entwickelt wird.

Dies ist genau der Designbereich von Lakebase. Es wurde für die spezifischen wirtschaftlichen und technischen Realitäten entwickelt, die die KI-gesteuerte Entwicklung mit sich bringt: evolutionäres Branching zu Null Kosten, echte Scale-to-Zero-Elastizität, offene Postgres-Speicherung im Lake und selbstverwaltete Operationen. Da Agenten zunehmend an der Erstellung und Weiterentwicklung von Software beteiligt sind, sind die Datenbanken, die für diese neue Welt am besten geeignet sind, diejenigen, die von Grund auf für Experimentierfreudigkeit, Offenheit und Elastizität konzipiert wurden.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag