Wenn jeder Software bauen kann, verändert sich die Datenbank

Die Folge What Happens When Everyone Can Build Software aus Y Combinators Podcast Lightcone stellt eine Frage, die schon heute auch kleine Unternehmen betrifft: Was passiert, wenn jeder Software bauen kann, und zwar selbst? Zu Gast ist Paul Copplestone, Gründer und CEO von Supabase.

Supabase durchlief den Sommer-Batch 2020 von Y Combinator. Laut YCs Folgenbeschreibung zählt der Dienst inzwischen 13 Millionen Nutzer und verwaltet mehr als 50 Millionen Datenbanken. Das Unternehmen bereitet sich auf eine Zukunft vor, in der jeder seine eigene Software schreiben kann, Milliarden Menschen eine persönliche Datenbank haben und KI-Agenten einen großen Teil der Nachfrage erzeugen.

Bauen ist nicht mehr nur Sache von Programmierern

Im Zentrum der Folge steht der Unterschied zwischen klassischen Entwicklern und einer neuen Generation von Buildern. Diesem Vergleich ist ein eigener Abschnitt gewidmet, ebenso den drei Phasen von Supabase und der Vervierfachung des Umsatzes. Für Kleinunternehmer klingt der Gedanke vertraut: Eine Steuerberaterin, ein Friseur oder ein Onlinehändler kann sich heute ein funktionierendes Werkzeug zusammenstellen, ohne eine Softwarefirma zu beauftragen.

Der Wandel macht Fachwissen nicht überflüssig, er verlagert es. Wer ein Werkzeug selbst bauen kann, muss sich stärker fragen, welche Daten es verarbeitet, wer es pflegt und wie es sicher bleibt. Dasselbe Thema haben wir im Beitrag über eine funktionierende Arbeitsumgebung für KI-Agenten behandelt.

Persönliche Apps und eigene Daten

Der Kapitelübersicht zufolge geht es anschließend um persönliche Apps, persönliche Datenbanken und Datenhoheit. Die Idee: Immer mehr Anwendungen entstehen für einen einzelnen Nutzer oder ein einzelnes Team statt für Millionen. Dann gibt es auch ungleich mehr Datenbanken, und die Frage, wem die Daten gehören, wird ganz praktisch.

Für Unternehmer bedeutet das zweierlei. Erstens lassen sich eigene Kunden- und Vertriebsdaten strukturiert vorhalten, ohne ein schwerfälliges System anzuschaffen. Zweitens wandert die Verantwortung zu ihnen selbst: Backups, Zugriffsrechte und Datenschutz erledigen sich nicht dadurch, dass die App schnell gebaut war.

Agenten als Datenbanknutzer

Gegen Ende der Folge geht es darum, für persönliche Agenten zu bauen und das eigene Produkt im eigenen Arbeitsalltag einzusetzen (Dogfooding), außerdem um agentenzentriertes Design und Evaluierungen. Zur Sprache kommt auch, wie Supabase KI in der eigenen Organisation eingeführt hat und was das Team dabei gelernt hat.

Wenn ein Agent und nicht ein Mensch der wichtigste Nutzer eines Dienstes ist, muss das Produkt berechenbar, gut dokumentiert und testbar sein. Das gilt genauso für die eigenen Automatisierungen eines kleinen Unternehmens. Warum Offenheit und Austauschbarkeit wichtig sind, haben wir auch im Artikel über offene KI-Modelle erörtert.

Wer ein Werkzeug selbst bauen kann, muss vor allem klären, welche Daten es verarbeitet und wer dafür verantwortlich ist.

Was Gründer jetzt tun sollten

• Wählen Sie eine wiederkehrende Aufgabe, etwa die Nachverfolgung von Angeboten oder Buchungen, und bauen Sie probeweise ein kleines eigenes Werkzeug dafür.
• Legen Sie vor dem Bauen fest, wo die Daten liegen, wer darauf zugreifen darf und wie sie gesichert werden.
• Dokumentieren Sie, was das Werkzeug tut, damit auch jemand anderes es pflegen kann.
• Wenn Sie einen Agenten mit Ihren Daten arbeiten lassen, beschränken Sie seine Rechte und testen Sie Situationen, in denen Informationen fehlen.

Zum Schluss geht es um die Zukunft des Programmierens und darum, wie einfachere Softwareentwicklung neuem Unternehmertum Türen öffnet. Einen breiteren Blick auf die Start-up-Szene bietet unser Beitrag über Kundenverständnis als Wettbewerbsvorteil von KI-Start-ups.

▶

Die Originalfolge auf YouTube ansehen: Y Combinator.

Quellen

• Y Combinator: What Happens When Everyone Can Build Software (Lightcone, YouTube) — Grundlage sind die von YC veröffentlichte Folgenbeschreibung und die Kapitelübersicht mit Zeitmarken, kein geprüftes Transkript. Themen sind unter anderem Builder vs. klassische Entwickler (4:34), persönliche Datenbanken (12:12) und agentenzentriertes Design (30:01). Die praktischen Empfehlungen sind eigene Überlegungen der Redaktion.