Nodar Daneliya, CEO og medstifter af Shuttle – Interviewserie

Nodar Daneliya, CEO og medstifter af Shuttle – Interviewserie: Nodar Daneliya har fungeret som medstifter og CEO af Shuttle siden grundlæggelsen af virksomheden i 2019, hvor han har ledet dens vækst fra en tidlig YC Summer 2020-startup til en udviklerfokuseret platformteknologivirksomhed; før Shuttle havde han roller som Chief Risk Officer i Provenance Technologies Ltd, hvor han arbejdede med kvantitative hedgefondstrategier, og tidligere tekniske og dataroller i London og hos Google.

Shuttle er en open-source cloud-infrastrukturplatform, der forenkler backend-udvikling og -installation ved at aflede infrastruktur fra kodeannoteringer, så udviklere kan fokusere på at skrive Rust eller anden kode uden at skulle håndtere separate konfigurationsfiler eller komplekse cloud-installationer; platformen muliggør hurtig installation, ud af boksen ressourceallokering og problemfri skalerbarhed og bruges af titusinder af ingeniører med over 130.000 installationer, med målet at udvide sin zero-config, AI-assisterede oplevelse til alle sprog og integrere med værktøjer som GitHub Copilot og Cursor.

Hvad var det øjeblik eller den frustration, der til sidst fik dig til at co-founder Shuttle, og hvilket problem forsøgte du at løse helt fra starten?

Vendepunktet kom under min tid som leder af handel i en kvantitativ hedgefond. Vi havde exceptionelle ingeniører – PhD’er, senior platformfolk, ML-forskere – men selv med den talent, var cloud-infrastruktur konstant flaskenhalen. At bygge en handelsmodel eller backend-tjeneste var ikke det svære. Problemet var installation: At få det live sikkert, skalerbart, og forbinder cloud-tjenester sammen. Det var der, hvor alt gik i stå. På et tidspunkt var mere end halvdelen af vores udviklingsteam beskæftiget med DevOps-arbejde bare for at holde systemerne kørende.

Det, der blev hos mig, var ikke sofistikationen af koden eller matematikken. Det var at se højt kvalificerede mennesker brænde det meste af deres tid på at kæmpe mod cloud’en i stedet for at bygge det, der virkelig betød noget. Ingen ville gøre det arbejde, men det var uundgåeligt. Den friktion – gapet mellem “Jeg byggede noget” og “det kører pålideligt” – er det, Shuttle blev skabt for at løse.

Shuttle blev grundlagt i 2019, før bølgen af AI-kodningsværktøjer i dag. Hvordan er din oprindelige vision ændret, da AI-assisteret udvikling er blevet mainstream?

Kerneproblemet forblev det samme, men AI forstærkede det dramatisk. Da vi startede, var infrastruktur allerede den begrænsende faktor for stærke udviklingsteams. Da værktøjer som Copilot, Cursor og Claude dukkede op, blev denne flaskenhalning umulig at ignorere.

Pludselig kunne udviklere generere fulde applikationer på få minutter, men disse applikationer ramte en mur med det samme. AI kan skrive kode, men kan ikke pålideligt konfigurere og styre cloud-resourcer. Gapet, vi løste for, blev meget bredere og mere presserende. Millioner af mennesker bygger nu prototyper, men kun en brøkdel når til produktion.

Visionen udviklede sig fra “gør infrastruktur lettere for udviklere” til “gør infrastruktur arbejde for en helt ny generation af byggere” – solo-stiftere, små teams og AI-agenter, der kan skabe backend-kode, men har ingen interesse i at kæmpe med cloud-konfiguration. Vi serverer ikke kun traditionelle ingeniører mere. Publikum er eksploderet.

AI-værktøjer som Cursor og GitHub Copilot har ændret, hvordan udviklere skriver kode. Fra din synsvinkel, hvilke dele af software-livscyklussen er forbedret mest, og hvor kæmper teams stadig?

Kode-generering har sprunget fremad. Den del er næsten løst. Du kan beskrive en funktion, og AI vil skabe en ramme. Frontend har især nydt godt af dette, fordi mønstrene er godt forstået – komponenter, stilarter, layouts.

Hvor teams kæmper er alt, der kommer efter: installation, infrastruktur, operationer. AI måske genererer en API-endpoint, men kan ikke automatisk oprette en database, lager, kø, netværk, tilladelser eller installation-rørledning, der gør det virkeligt. Backend-infrastruktur har ikke holdt trit med kode-generering.

Resultatet er urent fremgang. I stedet for at tingene bliver enklere fra ende til anden, viser nye trykpunkter sig. Teams genererer hele backends på få minutter, derefter bliver de fast i dage med at installere dem sikkert. Nogle gange gør AI det værre ved at producere mere kode, end teams kan faktisk køre eller vedligeholde. Det er, hvor den virkelige friktion bor nu.

Installation er ofte beskrevet som den største flaskenhalning for AI-genererede applikationer. Hvad er det specifikt, der gør det så udfordrende at producere disse systemer sammenlignet med at generere koden selv?

Problemet er pålidelighed og konsekvenser. Kode-generering er tilgivende – hvis AI laver en fejl, ser du det med det samme og retter det. Infrastruktur-fejl er anderledes. En forkert tilladelse, en miskonfigureret ressource, en dårlig antagelse om omkostninger eller sikkerhed, og du har skabt et rigtigt problem, der måske ikke viser sig før senere.

Tidligt forsøgte vi at lade AI frit aflede infrastruktur fra applikationskode. Det så godt ud i demoer. I virkelige systemer brød det sammen. AI ville selvbevidst producere installationer, der var næsten rigtige, men ikke helt – tilladelser for brede, underlige ressourcevalg, konfigurationer, der ville blive dyre.

Det lærte os noget kritisk: I produktion, skaber intelligens uden grænser problemer. AI har ikke brug for mere frihed. Det har brug for bedre skinner. Du skal designe systemer, hvor AI kan foreslå og accelerere, men ikke løbe vildt. Det er den tekniske udfordring, der gør produktion af AI-genererede applikationer så meget sværere end at generere koden.

Shuttle introducerede nyligt Neptune som den næste udvikling af sin platform. Neptune beskrives som en universel AI-platformteknolog – hvad betyder det i praktisk forstand for udviklere, der bevæger sig fra en prototype til en produktionssikker backend?

Neptune fungerer som det manglende lag mellem kode og produktion. I praktisk forstand betyder det, at udviklere – eller AI-agenter – kan fokusere på at skrive applikationslogik, og Neptune håndterer alt andet: forstå, hvilken infrastruktur der er nødvendig, ressourceallokering, hemmelighedshåndtering, installation, tjeneste-koordinering.

I stedet for at få udviklere til at oversætte deres applikation til cloud-infrastruktur, forstår Neptune applikationen og genererer infrastrukturen omkring den. Din kode er skitsebogen. Neptune bygger miljøet, der er nødvendigt for at køre den. Ingen Dockerfiler, ingen Terraform, ingen endeløs konfiguration.

For nogen, der bevæger sig fra prototype til produktion, betyder det, at du ikke rammer væggen, hvor du pludselig skal lære DevOps. Applikationen, du byggede, fortsætter med at fungere, mens du skalerer den. Neptune brobygger gapet mellem “Jeg byggede noget” og “det kører pålideligt i produktion”.

Som udviklere kommer til at stole mere på AI for at generere backend-systemer, hvordan balancerer du hastighed og abstraktion med behovet for kontrol, sikkerhed og overvågning?

Tillid er svaret. I infrastruktur betyder tillid mere end kapacitet. Én dårlig overraskelse – en sikkerhedsfejl, en fejlende installation, en kæmpe cloud-regning – og du har tabt folk.

Vi lærte tidligt, at alt, hvad AI rører, skal være forståeligt og gennemgåeligt. Selv hvis en udvikler ikke konfigurerede noget manuelt, har de stadig brug for at se, hvad der sker, og hvorfor. Det er derfor, Neptune bruger deterministiske infrastruktur-regler. AI kan foreslå og accelerere, men alt, det gør, er grundet i specifikationer, der er gennemgåelige, forudsigelige og testbare.

Skiftet vi gjorde var fra “AI bestemmer” til “AI foreslår inden for rammer”. Det er forskellen mellem en sjov demo og noget, du kan stole på, når det betyder noget. Udviklere bruger ikke mindre tid på at træffe beslutninger – de bruger mindre tid på at taste og mere tid på at beslutte, hvad der skal eksistere, hvad der er acceptabelt, hvilke kompromiser giver mening. De bedste teams behandler AI som en meget dygtig junior-ingeniør: hjælpsom, produktiv, men ikke ansvarlig.

Hvilke typer teams ser den stærkeste værdi fra Neptune i dag, enten solo-udviklere, startups eller større ingeniør-organisationer?

Profilen er ændret dramatisk. Oprindeligt havde vi på Rust-siden en diversificeret base – enkeltudviklere, tidlige startups, scaleups, selv større virksomheds teams i brancher som bilindustri, IoT, finans, krypto, hvor pålidelighed og ydeevne betyder noget. Disse teams ville have kraften fra Rust uden den ekstra belastning af at håndtere komplekse cloud-infrastrukturer.

Men over det sidste år har opblomstringen af AI-drevet udvikling ændret helt, hvem der bygger software. Nu ser vi solo-stiftere, indie-udviklere, AI-agenter, små teams og traditionelle software-virksomheder, der alle genererer backend-kode i en uhørt hastighed. Publikum er ikke kun senior-ingeniører i specialiserede felter mere.

Vi ser ofte solo-stiftere og små teams gå fra en idé til en installeret backend på én gang, fordi de ikke behøver at bruge dage på installation. Det er ikke kun tid sparet – det er momentum bevaret, hvilket er alt i begyndelsen. Det er, hvor den stærkeste værdi viser sig: mennesker, der kan bygge, men ikke vil blive infrastruktur-eksperter bare for at få deres idéer live.

Fra et teknisk synspunkt, hvordan håndterer Neptune miljøkonfiguration, hemmelighedshåndtering og infrastruktur-koordinering, når det omgør AI-genereret kode til en deploybar produktion-backend?

Neptune behandler kode og infrastruktur som ét samlet system. De fleste installationsværktøjer fungerer som en leveringservice – du bringer dem en container, og de prøver at køre den. Det efterlader dig stadig ansvarlig for at sy sammen cloud-resourcer, skrive konfiguration, håndtere miljøvariabler, håndtere hemmeligheder, allokerer databases.

Neptune vender denne model om. I stedet for at få udviklere til at oversætte deres applikation til cloud-infrastruktur, forstår Neptune applikationen og genererer infrastrukturen omkring den. Det er en AI-naturlig tilgang til DevOps: koden er skitsebogen, og Neptune bygger miljøet, der er nødvendigt for at køre den – herunder hemmelighedshåndtering, miljøkonfiguration og ressource-koordinering.

Nøglen er, at AI arbejder inden for deterministiske infrastruktur-regler. Det kan ikke producere vilkårlige konfigurationer. Alt forbliver gennemgåeligt og forudsigeligt, hvilket er afgørende for sikkerhed og omkostningskontrol i produktionsmiljøer.

Med henblik på fremtiden, hvordan ser du Neptunes rolle udvikle sig i et økosystem, hvor AI-systemer i stigende grad bygger, installerer og håndterer andre software-systemer?

Vi bevæger os mod en verden, hvor gapet mellem en idé og et fungerende produkt er tæt på nul. Meget snart vil produkter ikke kun blive bygget hurtigere – de vil kontinuerligt forbedre sig selv baseret på realtidsfeedback fra, hvordan folk faktisk bruger dem.

I den verden vil software ikke være statisk. Applikationer, agenter og systemer vil blive skabt, ændret og udviklet konstant. Alt dette har stadig brug for at køre et sted. Det har stadig brug for infrastruktur, tilladelser, resourcer og pålidelighed.

Vores langsigtede mål er at blive det standard-system for AI-assisteret DevOps – essentielt AI-Platform-Ingeniør. Uanset om kode er skrevet af en udvikler i Cursor eller genereret autonomt af en AI-agent, skal Neptune være laget, der tager det fra kode til et fuldt fungerende, skalerbart, produktionsklar service.

Hvis kreativitet bliver ubegrænset, kan infrastruktur ikke være begrænsningen. Når AI-agenter og selv-udviklende produkter bliver normale, er vores opgave at gøre interaktionen med cloud-infrastruktur ubesværet, forudsigelig og sikker. Vi fokuserer på at gøre det usynligt, så udviklere, stiftere og virksomheder kan fokusere på at skabe værdi i stedet for at kæmpe med infrastruktur. Thank you for the great interview, readers who wish to learn more should visit Shuttle.