Nodar Daneliya, CEO und Mitgründer von Shuttle – Interview-Serie

Nodar Daneliya, CEO und Mitgründer von Shuttle – Interview-Serie: Nodar Daneliya ist seit der Gründung des Unternehmens im Jahr 2019 als Mitgründer und CEO von Shuttle tätig und hat das Unternehmen von einem frühen YC-Sommer-2020-Startup zu einem auf Entwickler ausgerichteten Plattform-Engineering-Unternehmen geführt; vor Shuttle hatte er Positionen inne, darunter Chief Risk Officer bei Provenance Technologies Ltd, wo er an quantitativen Hedge-Fonds-Strategien arbeitete, und früher technische und datenbezogene Rollen in London und bei Google.

Shuttle ist eine Open-Source-Cloud-Infrastruktur-Plattform, die die Backend-Entwicklung und -Bereitstellung durch die Ableitung von Infrastruktur aus Code-Anmerkungen vereinfacht, sodass Entwickler sich auf das Schreiben von Rust- oder anderem Code konzentrieren können, ohne separate Konfigurationsdateien oder komplexe Cloud-Einrichtungen verwalten zu müssen; die Plattform ermöglicht eine schnelle Bereitstellung, eine out-of-the-box-Ressourcenbereitstellung und eine nahtlose Skalierung und wird von Zehntausenden von Ingenieuren mit über 130.000 Bereitstellungen verwendet, mit dem Ziel, die Zero-Config-, AI-gestützte Erfahrung auf alle Sprachen auszuweiten und mit Tools wie GitHub Copilot und Cursor zu integrieren.

Welcher Moment oder welche Frustration haben Sie letztendlich dazu gebracht, Shuttle mitzubegründen, und welches Problem haben Sie zu Beginn zu lösen versucht?

Der Wendepunkt kam während meiner Zeit als Leiter des Handels bei einem quantitativen Hedge-Fonds. Wir hatten außergewöhnliche Ingenieure – PhDs, Senior-Plattformleute, ML-Forscher – aber selbst mit diesem Talent war die Cloud-Infrastruktur der ständige Flaschenhals. Das Erstellen eines Handelsmodells oder eines Backend-Dienstes war nicht das Schwierige. Das Problem war die Bereitstellung: Es live und sicher zu machen, es zu skalieren, Cloud-Dienste zu verbinden. Dort verlangsamte sich alles. Zu einem Zeitpunkt machte mehr als die Hälfte unseres Ingenieur-Teams DevOps-Arbeit, nur um Systeme am Laufen zu halten.

Was mir im Gedächtnis blieb, war nicht die Komplexität des Codes oder der Mathematik. Es war das Beobachten hochqualifizierter Menschen, die den größten Teil ihrer Zeit damit verbrachten, gegen die Cloud zu kämpfen, anstatt das zu bauen, was wirklich zählte. Niemand wollte diese Arbeit tun, aber es war unvermeidlich. Diese Reibung – die Lücke zwischen “Ich habe etwas gebaut” und “es läuft zuverlässig” – ist das, was Shuttle geschaffen wurde, um es zu lösen.

Shuttle wurde 2019 gegründet, bevor die heutige Welle von AI-Coding-Tools kam. Wie hat sich Ihre ursprüngliche Vision im Laufe der Zeit entwickelt, als die AI-gestützte Entwicklung zum Mainstream wurde?

Das Kernproblem blieb das gleiche, aber die AI hat es dramatisch verstärkt. Als wir begannen, war die Infrastruktur bereits der limitierende Faktor für starke Ingenieur-Teams. Als Tools wie Copilot, Cursor und Claude auftraten, wurde dieser Flaschenhals unhaltbar.

Plötzlich konnten Entwickler vollständige Anwendungen in Minuten generieren, aber diese Anwendungen trafen sofort auf eine Wand. Die AI kann Code schreiben, aber sie kann nicht zuverlässig Cloud-Ressourcen konfigurieren und verwalten. Die Lücke, die wir lösen wollten, wurde viel breiter und viel dringender. Millionen von Menschen bauen jetzt Prototypen, aber nur ein Bruchteil davon kommt in die Produktion.

Die Vision hat sich von “Infrastruktur für Entwickler einfacher machen” zu “Infrastruktur für eine ganz neue Generation von Erbauern funktionieren lassen” entwickelt – Solo-Gründer, kleine Teams und AI-Agenten, die Backend-Code generieren können, aber kein Interesse daran haben, mit Cloud-Konfiguration zu kämpfen. Wir bedienen nicht mehr nur traditionelle Ingenieure. Das Publikum ist explodiert.

AI-Tools wie Cursor und GitHub Copilot haben die Art und Weise, wie Entwickler Code schreiben, verändert. Aus Ihrer Perspektive, welche Teile des Software-Lebenszyklus haben sich am meisten verbessert, und wo kämpfen Teams noch?

Code-Generierung hat einen Sprung nach vorne gemacht. Dieser Teil ist fast gelöst. Sie können eine Funktion beschreiben, und die AI wird sie aufbauen. Insbesondere die Frontend-Entwicklung hat davon profitiert, weil die Muster gut verstanden sind – Komponenten, Styles, Layouts.

Wo Teams kämpfen, ist alles, was danach kommt: Bereitstellung, Infrastruktur, Betrieb. AI-Tools wie Copilot können einen API-Endpunkt generieren, aber sie können nicht automatisch eine Datenbank, Speicher, Warteschlange, Netzwerk, Berechtigungen oder eine Bereitstellungs-Pipeline erstellen, die es real macht. Backend-Infrastruktur hat nicht mit der Code-Generierung Schritt gehalten.

Das Ergebnis ist ungleichmäßiger Fortschritt. Anstatt dass sich die Dinge von Anfang bis Ende vereinfachen, tauchen neue Druckpunkte auf. Teams generieren ganze Backends in Minuten, dann stecken sie tagelang fest, wenn sie sie sicher bereitstellen wollen. Manchmal macht die AI es sogar schlimmer, indem sie mehr Code produziert, als Teams tatsächlich ausführen oder warten können. Dort lebt die echte Reibung jetzt.

Bereitstellung wird oft als der größte Flaschenhals für AI-generierte Anwendungen beschrieben. Was macht die Produktion dieser Systeme so herausfordernd im Vergleich zur Code-Generierung selbst?

Das Problem ist Zuverlässigkeit und Konsequenzen. Code-Generierung ist verzeihlich – wenn die AI einen Fehler macht, sehen Sie es sofort und korrigieren es. Infrastruktur-Fehler sind anders. Ein falsches Berechtigungsrecht, eine falsch konfigurierte Ressource, eine falsche Annahme über Kosten oder Sicherheit, und Sie haben ein echtes Problem geschaffen, das möglicherweise erst später auftaucht.

Frühzeitig haben wir versucht, der AI freie Hand zu geben, Infrastruktur aus Anwendungscodes abzuleiten. Es sah großartig in Demos aus. In realen Systemen brach es zusammen. Die AI würde zuversichtlich Einrichtungen produzieren, die fast richtig, aber nicht ganz waren – Berechtigungen zu weit, seltsame Ressourcenwahlen, Konfigurationen, die still und heimlich teuer werden könnten.

Das hat uns etwas Kritisches gelehrt: In der Produktion schafft Intelligenz ohne Grenzen Probleme. Die AI benötigt nicht mehr Freiheit. Sie benötigt bessere Schienen. Sie müssen Systeme entwerfen, in denen die AI vorschlagen und beschleunigen kann, aber nicht wild laufen kann. Das ist die technische Herausforderung, die die Produktion von AI-generierten Apps so viel schwieriger macht als die Code-Generierung.

Shuttle hat kürzlich Neptune als nächste Evolution seiner Plattform vorgestellt. Neptune wird als universelle AI-Plattform-Ingenieurin beschrieben – was bedeutet das in praktischen Begriffen für Entwickler, die von einem Prototyp zu einem produktionsreifen Backend übergehen?

Neptune agiert als fehlendes Glied zwischen Code und Produktion. In praktischen Begriffen bedeutet es, dass Entwickler – oder AI-Agenten – sich auf die Logik der Anwendung konzentrieren können, und Neptune alles andere übernimmt: Verständnis, welche Infrastruktur benötigt wird, Ressourcen bereitstellen, Geheimnisse verwalten, Bereitstellung handhaben, Dienste orchestrieren.

Anstatt Entwickler dazu zu zwingen, ihre Anwendung in Cloud-Infrastruktur zu übersetzen, versteht Neptune die Anwendung und generiert die Infrastruktur darum herum. Der Code ist die Blaupause. Neptune baut die Umgebung, die benötigt wird, um es auszuführen. Keine Docker-Dateien, kein Terraform, keine endlosen Konfigurationen.

Für jemanden, der von einem Prototyp zu einem produktionsreifen Backend übergeht, bedeutet es, dass er nicht an die Wand stößt, an der er plötzlich DevOps lernen muss. Die Anwendung, die er gebaut hat, funktioniert weiter, während er sie skalieren lässt. Neptune überbrückt die Lücke zwischen “Ich habe etwas gebaut” und “es läuft zuverlässig in der Produktion”.

Wie balancieren Sie, wenn Entwickler immer stärker auf AI setzen, um Backend-Systeme zu generieren, die Geschwindigkeit und Abstraktion mit dem Bedarf an Kontrolle, Sicherheit und Beobachtbarkeit?

Vertrauen ist die Antwort. In der Infrastruktur zählt Vertrauen mehr als Fähigkeit. Eine schlechte Überraschung – ein Sicherheitsloch, eine fehlerhafte Bereitstellung, eine massive Cloud-Rechnung – und Sie haben die Leute verloren.

Wir haben früh gelernt, dass alles, was die AI berührt, verständlich und überprüfbar sein muss. Selbst wenn ein Entwickler etwas nicht von Hand konfiguriert hat, muss er immer noch sehen, was passiert und warum. Deshalb verwendet Neptune deterministische Infrastruktur-Regeln. Die AI kann vorschlagen und beschleunigen, aber alles, was sie tut, ist in Spezifikationen verwurzelt, die überprüfbar, vorhersehbar und testbar sind.

Der Wechsel, den wir vorgenommen haben, war von “AI entscheidet” zu “AI schlägt innerhalb von Grenzen vor.” Das ist der Unterschied zwischen einem lustigen Demo und etwas, das Sie vertrauen können, wenn es zählt. Entwickler verbringen nicht weniger Zeit damit, Entscheidungen zu treffen – sie verbringen weniger Zeit mit Tippen und mehr Zeit damit, zu entscheiden, was existieren sollte, was akzeptabel ist, welche Kompromisse Sinn machen. Die besten Teams behandeln die AI wie einen sehr fähigen Junior-Ingenieur: hilfreich, produktiv, aber nicht verantwortlich.

Welche Arten von Teams sehen den stärksten Nutzen von Neptune heute, sei es Solo-Entwickler, Start-ups oder größere Ingenieur-Organisationen?

Das Profil hat sich dramatisch verändert. Ursprünglich hatten wir auf der Rust-Seite eine vielfältige Basis – Einzelentwickler, frühe Start-ups, Scale-ups, sogar Unternehmensteams in der Automobilindustrie, IoT, Finanzen, Krypto, überall, wo Zuverlässigkeit und Leistung zählen. Diese Teams wollten die Kraft von Rust ohne den Overhead der Verwaltung komplexer Cloud-Infrastruktur.

Aber im Laufe des letzten Jahres hat die Aufnahme von AI-gesteuerter Entwicklung völlig verändert, wer Software baut. Jetzt sehen wir Solo-Gründer, unabhängige Entwickler, AI-Agenten, kleine Teams und traditionelle Software-Unternehmen, die alle Backend-Code mit unvergleichlicher Geschwindigkeit generieren. Das Publikum ist nicht mehr nur Senior-Ingenieure in spezialisierten Bereichen.

Wir sehen regelmäßig Solo-Gründer und kleine Teams, die von einer Idee zu einem bereitgestellten Backend in einer einzigen Sitzung kommen, weil sie nicht Tage mit der Einrichtung verbringen müssen. Es ist nicht nur die gesparte Zeit – es ist der erhaltene Schwung, was alles am Anfang zählt. Dort zeigt sich der stärkste Nutzen: Menschen, die bauen können, aber keine Infrastruktur-Experten werden wollen, nur um ihre Ideen live zu sehen.

Wie handhabt Neptune aus technischer Sicht die Umgebungs-Konfiguration, das Geheimnis-Management und die Infrastruktur-Orchestrierung, wenn es AI-generierten Code in ein bereitstellbares Produktions-Backend umwandelt?

Neptune behandelt Code und Infrastruktur als ein einheitliches System. Die meisten Bereitstellungstools agieren wie ein Lieferdienst – Sie bringen ihnen einen Container, und sie versuchen, ihn auszuführen. Das lässt Sie jedoch immer noch verantwortlich für das Zusammenfügen von Cloud-Ressourcen, die Konfiguration, die Umgebungsvariablen, das Geheimnis-Management und die Bereitstellung von Datenbanken.

Neptune dreht dieses Modell um. Anstatt den Entwickler dazu zu zwingen, seine Anwendung in Cloud-Infrastruktur zu übersetzen, versteht Neptune die Anwendung und generiert die Infrastruktur darum herum. Es ist ein AI-nativer Ansatz für DevOps: Der Code ist die Blaupause, und Neptune baut die Umgebung, die benötigt wird, um es auszuführen – einschließlich Geheimnis-Management, Umgebungs-Konfiguration und Ressourcen-Orchestrierung.

Der Schlüssel ist, dass die AI innerhalb deterministischer Infrastruktur-Regeln arbeitet. Sie kann keine willkürlichen Konfigurationen produzieren. Alles bleibt überprüfbar und vorhersehbar, was für Sicherheit und Kostenkontrolle in Produktionsumgebungen unerlässlich ist.

Wie sehen Sie die Rolle von Neptune in einer Zukunft, in der AI-Systeme zunehmend Software-Systeme bauen, bereitstellen und verwalten?

Wir bewegen uns auf eine Welt zu, in der die Lücke zwischen einer Idee und einem funktionierenden Produkt nahe Null ist. Sehr bald werden Produkte nicht nur schneller gebaut – sie werden kontinuierlich auf der Grundlage von Echtzeit-Feedback von der tatsächlichen Nutzung verbessert.

In dieser Welt wird Software nicht statisch sein. Anwendungen, Agenten und Systeme werden kontinuierlich erstellt, modifiziert und weiterentwickelt. All das benötigt immer noch Infrastruktur, Berechtigungen, Ressourcen und Zuverlässigkeit.

Unser langfristiges Ziel ist es, zur Standard-System für AI-gestütztes DevOps zu werden – im Wesentlichen der AI-Plattform-Ingenieur. Egal, ob Code von einem Entwickler in Cursor oder autonom von einem AI-Agenten generiert wird, Neptune sollte die Schicht sein, die ihn von Code zu einem vollständig laufenden, skalierbaren, produktionsreifen Dienst macht.

Wenn Kreativität unbegrenzt wird, kann Infrastruktur nicht die Einschränkung sein. Wenn AI-Agenten und auto-evolvierende Produkte zur Norm werden, ist unsere Aufgabe, die Interaktion mit Cloud-Infrastruktur nahtlos, vorhersehbar und sicher zu machen. Wir konzentrieren uns darauf, dies unsichtbar zu machen, damit Entwickler, Gründer und Unternehmen sich auf die Schaffung von Wert konzentrieren können, anstatt mit Infrastruktur zu kämpfen.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten Shuttle besuchen.