Nodar Daneliya, CEO og medgrunnlegger av Shuttle – Intervju-serie

Nodar Daneliya, CEO og medgrunnlegger av Shuttle – Intervju-serie: Nodar Daneliya har vært medgrunnlegger og CEO av Shuttle siden selskapet ble etablert i 2019, og har ledet veksten fra et tidlig YC Summer 2020-startup til en utviklerfokusert plattformingeniørsselskap; før Shuttle hadde han roller som inkluderte Chief Risk Officer i Provenance Technologies Ltd, der han arbeidet med kvantitative hedgefondstrategier, og tidligere tekniske og datarelaterte roller i London og i Google.

Shuttle er en åpen kildekode-basert skyinfrastrukturplattform som forenkler backend-utvikling og -utvikling ved å avlede infrastruktur fra kodeannoteringer, slik at utviklere kan fokusere på å skrive Rust- eller annen kode uten å måtte håndtere separate konfigurasjonsfiler eller komplekse skyoppsett; plattformen muliggjør rask utvikling, ut-av-boksen ressursallokering og sammenhengende skalerbarhet, og brukes av titusener av ingeniører med over 130 000 utviklinger, med mål om å utvide sin null-konfigurasjons-, AI-assisterte erfaring til alle språk og integrere med verktøy som GitHub Copilot og Cursor.

Hva var det som til slutt førte til at du grunnla Shuttle, og hva var problemet du forsøkte å løse fra begynnelsen av?

Vendepunktet kom under min tid som leder for handel i et kvantitativt hedgefond. Vi hadde usedvanlige ingeniører – PhD-er, seniorplattformfolk, ML-forskere – men selv med den talenten, var skyinfrastruktur alltid flaskenhalen. Å bygge en handelsmodell eller backend-tjeneste var ikke det vanskelige. Problemet var utviklingen: å få det live sikkert, å skalerer det, å koble skytjenester sammen. Det var der alt gikk sakte. På et tidspunkt, var mer enn halvparten av vårt ingeniørteam opptatt med DevOps-arbeid bare for å holde systemene i gang.

Det som ble hos meg, var ikke sofistikasjonen i koden eller matematikken. Det var å se på høyt kvalifiserte mennesker brenne mesteparten av sin tid med å kjempe mot skyen i stedet for å bygge det som virkelig betydde noe. Ingen ønsket å gjøre det arbeidet, men det var uunngåelig. Den friksjonen – gapet mellom “Jeg bygde noe” og “det kjører pålitelig” – er det som Shuttle ble skapt for å løse.

Shuttle ble grunnlagt i 2019, før dagens bølge av AI-kodingverktøy. Hvordan har din opprinnelige visjon utviklet seg nå som AI-assistert utvikling har blitt mainstream?

Kjerneproblemet forble det samme, men AI forsterket det dramatisk. Da vi startet, var infrastruktur allerede begrensningen for sterke ingeniørteam. Da verktøy som Copilot, Cursor og Claude dukket opp, ble flaskenhalen umulig å ignorere.

Plutselig kunne utviklere generere fullstendige applikasjoner på minutter, men disse applikasjonene traff en vegg umiddelbart. AI kan skrive kode, men den kan ikke konfigurere og håndtere skyressurser pålitelig. Gapet vi løste for, ble mye bredere og mye mer presserende. Millioner av mennesker bygger nå backend-kode, men bare en brøkdel kommer til produksjon.

Visjonen utviklet seg fra “gjør infrastruktur enklere for utviklere” til “gjør infrastruktur arbeide for en helt ny generasjon av byggere” – solo-grunnleggere, små team og AI-agenter som kan skape backend-kode, men som ikke ønsker å kjempe mot skykonfigurasjon. Vi serverer ikke bare tradisjonelle ingeniører lenger. Publikum har eksplodert.

AI-verktøy som Cursor og GitHub Copilot har endret hvordan utviklere skriver kode. Fra din perspektiv, hvilke deler av programvarelivssyklusen har forbedret seg mest, og hvor kjemper teamene fortsatt?

Kodegenerering har sprunget fremover. Den delen er nesten løst. Du kan beskrive en funksjon, og AI vil skaffe rammen. Frontend har spesielt nytt av det, fordi mønsterene er godt forstått – komponenter, stiler, layout.

Hvor teamene kjemper, er alt som kommer etter: utvikling, infrastruktur, drift. AI kan generere en API-endepunkt, men den kan ikke automatisk skape databasen, lagringen, køen, nettverket, tillatelsene eller utviklingspipelinen som gjør det reelt. Backend-infrastruktur har ikke holdt tritt med kodegenerering.

Resultatet er urent fremgang. I stedet for at ting blir enklere fra ende til ende, dukker nye presseringspunkter opp. Teamene genererer hele backend på minutter, så blir de fast i dager med å deployere dem trygt. Av og til gjør AI det verre ved å produsere mer kode enn teamene kan faktisk kjøre eller vedlikeholde. Det er der den virkelige friksjonen bor nå.

Utvikling er ofte beskrevet som den største flaskenhalen for AI-genererte applikasjoner. Hva er det spesifikke som gjør produksjonen av disse systemene så utfordrende sammenlignet med å generere koden selv?

Problemet er pålitelighet og konsekvenser. Kodegenerering er tilgivende – hvis AI gjør en feil, ser du det umiddelbart og fikser det. Infrastrukturfeil er forskjellige. En feil tillatelse, en feil konfigurert ressurs, en dårlig antagelse om kostnad eller sikkerhet, og du har skapt et virkelig problem som kanskje ikke dukker opp før senere.

Tidlig ble vi forsøkt å la AI fritt slutte infrastruktur fra applikasjonskode. Det så bra ut i demonstrasjoner. I virkelige systemer, falt det fra hverandre. AI ville confidentt produsere oppsett som var nesten riktige, men ikke helt – tillatelser for brede, merkelige ressursvalg, konfigurasjoner som ville bli dyre.

Det lærte oss noe kritisk: i produksjon, skaper intelligens uten grenser problemer. AI trenger ikke mer frihet. Den trenger bedre skinner. Du må designe systemer hvor AI kan foreslå og akselerere, men ikke kan løpe vill. Det er den tekniske utfordringen som gjør produksjonen av AI-genererte applikasjoner så mye harder enn å generere koden.

Shuttle introduserte nylig Neptune som den neste utviklingen av sin plattform. Neptune beskrives som en universell AI-plattformingeniør—hva betyr det i praktiske termer for utviklere som går fra en prototype til en produksjonsklar backend?

Neptune fungerer som det manglende laget mellom kode og produksjon. I praktiske termer betyr det at utviklere – eller AI-agenter – kan fokusere på å skrive applikasjonslogikk, og Neptune håndterer alt annet: å forstå hva infrastruktur som trengs, å allokere ressurser, å håndtere hemmeligheter, å håndtere utvikling, å orchestrere tjenester.

I stedet for å få utviklere til å oversette sin applikasjon til skyinfrastruktur, forstår Neptune applikasjonen og genererer infrastrukturen rundt den. Din kode er blåkopien. Neptune bygger miljøet som trengs for å kjøre den. Ingen Dockerfiler, ingen Terraform, ingen endeløse konfigurasjoner.

For noen som går fra en prototype til en produksjonsklar backend, betyr det at du ikke trenger å lære DevOps. Applikasjonen du bygde, fortsetter å fungere mens du skalerer den. Neptune broer gapet mellom “Jeg bygde noe” og “det kjører pålitelig i produksjon”.

Som utviklere blir mer og mer avhengige av AI for å generere backend-systemer, hvordan balanserer du hastighet og abstraksjon med behovet for kontroll, sikkerhet og overvåkning?

Tillit er svaret. I infrastruktur, betyr tillit mer enn evne. En dårlig overraskelse – en sikkerhetshull, en feil utvikling, en enorm skyregning – og du har tapt mennesker.

Vi lærte tidlig at alt AI berører, må være forståelig og gjennomgåelig. Selv om en utvikler ikke konfigurerte noe manuelt, må de fortsatt se hva som skjer og hvorfor. Det er derfor Neptune bruker deterministiske infrastrukturregler. AI kan foreslå og akselerere, men alt den gjør, er grunnlagt i spesifikasjoner som er gjennomgåelige, forutsigbare og testbare.

Skiftet vi gjorde, var fra “AI bestemmer” til “AI foreslår innenfor begrensninger”. Det er forskjellen mellom en morsom demo og noe du kan stole på når det betyr noe. Utviklere bruker ikke mindre tid på å fatte beslutninger – de bruker mindre tid på å skrive og mer tid på å bestemme hva som skal eksistere, hva som er akseptabelt, hva slags kompromisser som gjør mening. De beste teamene behandler AI som en svært kapabel junioringeniør: nyttig, produktiv, men ikke ansvarlig.

Hvilke typer team ser den sterkeste verdien fra Neptune i dag, enten det er solo-utviklere, startup eller større ingeniørorganisasjoner?

Profilen har endret seg dramatisk. Opprinnelig, på Rust-siden, hadde vi en diversifisert base – enkeltutviklere, tidlige startup, skalaop, selv større ingeniørteam i bil, IoT, finanse, krypto, hvor som helst pålitelighet og ytelse betyr noe. Disse teamene ønsket kraften til Rust uten den komplekse skyinfrastrukturhåndteringen.

Men over det siste året, har oppblomstringen av AI-drevet utvikling fullstendig endret hvem som bygger programvare. Nå ser vi solo-grunnleggere, uavhengige utviklere, AI-agenter, små team og tradisjonelle programvareselskaper alle generere backend-kode i en uhørt hastighet. Publikum er ikke bare senioringeniører i spesialiserte felt lenger.

Vi ser jevnt solo-grunnleggere og små team gå fra en idé til en deployet backend på en enkelt sitting, fordi de ikke trenger å bruke dager på oppsett. Det er ikke bare tid spart – det er momentum bevart, som er alt på et tidlig stadium. Det er der den sterkeste verdien viser seg: mennesker som kan bygge, men som ikke ønsker å bli infrastruktur-eksperter bare for å få ideene sine live.

Fra et teknisk ståsted, hvordan håndterer Neptune miljøkonfigurasjon, hemmelighetsbehandling og infrastruktur-orchestrering når det gjelder å omdanne AI-generert kode til en deploybar produksjonsklar backend?

Neptune behandler kode og infrastruktur som ett forent system. De fleste utviklingsverktøy fungerer som en leveringservice – du bringer dem en container, og de prøver å kjøre den. Det etterlater deg fortsatt ansvarlig for å sy sammen skyressurser, skrive konfigurasjon, håndtere miljøvariabler, håndtere hemmeligheter, allokere databaser.

Neptune snur modellen på hodet. I stedet for å få utvikleren til å oversette sin applikasjon til skyinfrastruktur, forstår Neptune applikasjonen og genererer infrastrukturen rundt den. Det er en AI-nativ tilnærming til DevOps: koden er blåkopien, og Neptune bygger miljøet som trengs for å kjøre den – inkludert hemmelighetsbehandling, miljøkonfigurasjon og ressurs-orchestrering.

Nøkkelen er at AI arbeider innenfor deterministiske infrastrukturregler. Den kan ikke produsere vilkårlige konfigurasjoner. Alt blir gjennomgåelig og forutsigbar, hvilket er essensielt for sikkerhet og kostkontroll i produksjonsmiljøer.

Ser fremover, hvordan ser du på Neptunes rolle i et økosystem hvor AI-systemer stadig bygger, deployer og håndterer andre programvaresystemer?

Vi beveger oss mot en verden hvor gapet mellom en idé og en fungerende produkt er nær null. Svært snart, vil produkter ikke bare bygges raskere – de vil kontinuerlig forbedre seg selv basert på sanntidsfeedback fra hvordan folk faktisk bruker dem.

I den verden, vil programvare ikke være statisk. Applikasjoner, agenter og systemer vil bli skapt, modifisert og utviklet kontinuerlig. Alt det trenger fortsatt å kjøre et sted. Det trenger fortsatt infrastruktur, tillatelser, ressurser og pålitelighet.

Vårt langtidsmål er å bli standard-systemet for AI-assistert DevOps – essensielt AI-plattformingeniør. Uansett om koden er skrevet av en utvikler i Cursor eller generert autonomt av en AI-agent, skal Neptune være laget som tar det fra kode til en fullt fungerende, skalerbar, produksjonsklar tjeneste.

Hvis kreativiteten blir ubegrenset, kan ikke infrastruktur være begrensningen. Når AI-agenter og selv-utviklende produkter blir normale, er vår jobb å gjøre interaksjonen med skyinfrastruktur sammenhengende, forutsigbar og trygg. Vi fokuserer på å gjøre det usynlig, så utviklere, grunnleggere og selskaper kan fokusere på å skape verdi i stedet for å kjempe mot infrastruktur. Takk for det flotte intervjuet, lesere som ønsker å lære mer, kan besøke Shuttle.