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 virksomheden blev grundlagt i 2019, og 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 backendudvikling 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 om 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, der til sidst fik dig til at co-founder Shuttle, og hvilket problem forsøgte du at løse fra starten?

Vendepunktet kom under min tid som leder af handel på 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 blev langsommere. På et tidspunkt var mere end halvdelen af vores ingeniørteam beskæftiget med DevOps-arbejde bare for at holde systemerne kørende.

Det, der blev fast i min erindring, var ikke kompleksiteten 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. 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 ingeniørteam. Da værktøjer som Copilot, Cursor og Claude dukkede op, blev flaskenhalen 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 den kan ikke pålideligt konfigurere og administrere cloud-resourcer. Gapet, vi løste for, blev meget bredere og meget 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å team, og AI-agenter, der kan skabe backend-kode, men har ingen interesse i at kæmpe med cloud-konfiguration. Vi betjener ikke længere kun traditionelle ingeniører. Publikum er eksploderet.

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

Kodegenerering 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 det, fordi mønstrene er godt forstået – komponenter, stile, layouts.

Hvor teamene kæmper, er alt, der kommer efter: installation, infrastruktur, operation. AI må generere en API-endpoint, men den kan ikke automatisk oprette databasen, lagring, kø, netværk, tilladelser eller installationspipeline, der gør det virkeligt. Backend-infrastruktur har ikke holdt trit med kodegenerering.

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

Installation beskrives ofte som den største flaskenhal for AI-genererede applikationer. Hvad gør specifikt, at produktion af disse systemer er så udfordrende i forhold til at generere koden selv?

Problemet er pålidelighed og konsekvenser. Kodegenerering er tilgivende – hvis AI committer en fejl, ser du det med det samme og fikser det. Infrastrukturfejl 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 antage infrastruktur fra applikationskode. Det så godt ud i demos. I virkelige systemer gik det i stykker. AI ville producere konfigurationer, 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 er intelligens uden grænser problemtæsk. AI har ikke brug for mere frihed. Den 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-platformtekniker—hvad betyder det i praktisk forstand for udviklere, der går fra en prototype til en produktionssikker backend?

Neptune fungerer som den 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, og 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 blåkopien. Neptune bygger miljøet, der er nødvendigt for at køre det. Ingen Dockerfiler, ingen Terraform, ingen endeløse konfigurationer.

For en, der går fra prototype til produktion, betyder det, at du ikke rammer væggen, hvor du pludselig skal lære DevOps. Applikationen, du byggede, fungerer stadig, mens du skalerer den. Neptune bropper gapet mellem “Jeg byggede noget” og “det kører pålideligt i produktion”.

Som udviklere stoler mere og 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 evne. Én dårlig overraskelse – en sikkerhedsfejl, en fejlende installation, en enorm cloud-regning – og du har tabt folk.

Vi lærte tidligt, at alt, AI rører, skal være forståeligt og gennemgåeligt. Selv om en udvikler ikke konfigurerer noget manuelt, skal de stadig se, hvad der sker, og hvorfor. Det er derfor, Neptune bruger deterministiske infrastrukturregler. AI kan foreslå og accelerere, men alt, den gør, er baseret på specifikationer, der er gennemgåelige, forudsigelige og testbare.

Ændringen, 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, og hvilke kompromiser giver mening. De bedste team behandler AI som en meget kapabel junior-ingeniør: hjælpsom, produktiv, men ikke ansvarlig.

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

Profilen er ændret dramatisk. Oprindeligt havde vi på Rust-siden en diversificeret base – enkeltudviklere, tidlige startups, scaleups, selv større virksomheder i brancher som bilindustri, IoT, finans, krypto, hvor pålidelighed og ydeevne betyder noget. Disse team ønskede kraften fra Rust uden omkostningerne ved at administrere kompleks cloud-infrastruktur.

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å team og traditionelle softwarefirmaer generere backend-kode i en hidtil uset hastighed. Publikum er ikke længere kun senior-ingeniører i specialiserede felter.

Vi ser ofte solo-stiftere og små team gå fra idé til installeret backend på en enkelt sæde, 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 der, 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.

Set fra et teknisk synspunkt, hvordan håndterer Neptune miljøkonfiguration, hemmelighedshåndtering og infrastruktur-koordinering, når det drejer sig om at omdanne AI-genereret kode til en installerbar produktionssikker 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øvariable, håndtere hemmeligheder, provisionere databaser.

Neptune vendrer 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 blåkopien, og Neptune bygger miljøet, der er nødvendigt for at køre det – herunder hemmelighedshåndtering, miljøkonfiguration og ressource-koordinering.

Nøglen er, at AI arbejder inden for deterministiske infrastrukturregler. Den kan ikke producere arbitrære konfigurationer. Alt forbliver gennemgåeligt og forudsigeligt, hvilket er afgørende for sikkerhed og omkostningskontrol i produktionsmiljøer.

Set fremad, hvordan ser du Neptunes rol udvikle sig i et økosystem, hvor AI-systemer i stigende grad bygger, installerer og administrerer 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 blot blive bygget hurtigere – de vil også 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 skal stadig køre et sted. Det skal stadig have infrastruktur, tilladelser, resourcer og pålidelighed.

Vores langsigtede mål er at blive standard-systemet for AI-assisteret DevOps – essentieligt den AI-platformtekniker. Uanset om koden 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 en fuldt fungerende, skalerbar, produktionssikker tjeneste.

Hvis kreativitet bliver ubegrænset, kan infrastruktur ikke være begrænsningen. Da AI-agenter og selv-udviklende produkter bliver normale, er vores job at gøre interaktionen med cloud-infrastruktur seamless, 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.

Tak for det gode interview. Læsere, der ønsker at lære mere, skal besøge Shuttle.