Nodar Daneliya, VD och medgrundare av Shuttle – Intervjuserie

Nodar Daneliya, VD och medgrundare av Shuttle – Intervjuserie: Nodar Daneliya har varit medgrundare och VD för Shuttle sedan företaget grundades 2019, och har lett dess tillväxt från en tidig YC Summer 2020-startup till ett utvecklarfokuserat plattformsföretag; innan Shuttle hade han roller som inkluderade Chief Risk Officer på Provenance Technologies Ltd, där han arbetade med kvantitativa hedgefondstrategier, och tidigare tekniska och datarelaterade roller i London och på Google.

Shuttle är en öppen källkodsplattform för molninfrastruktur som förenklar backend-utveckling och distribution genom att hämta infrastruktur från kodannoteringar, så att utvecklare kan fokusera på att skriva Rust- eller annan kod utan att hantera separata konfigurationsfiler eller komplex molnkonfiguration; plattformen möjliggör snabb distribution, ut-ur-lådan-resursallokering och smidig skalning, och används av tiotusentals ingenjörer med över 130 000 distributioner, i syfte att utöka sin zero-config, AI-assisterade upplevelse till alla språk och integrera med verktyg som GitHub Copilot och Cursor.

Vilken ögonblick eller frustration fick dig att medgrundade Shuttle, och vilket problem försökte du lösa från början?

Vändpunkten kom under min tid som ledare för handel på en kvantitativ hedgefond. Vi hade exceptionella ingenjörer – doktorer, seniora plattformsanställda, maskinläringsforskare – men även med den talangen var molninfrastruktur den konstanta flaskhalsen. Att bygga en handelsmodell eller backend-tjänst var inte det svåra. Problemet var distribution: att få det live säkert, skala det, ansluta molntjänster. Där var allt långsammare. Vid en tidpunkt gjorde mer än hälften av vårt ingenjörsteam DevOps-arbete bara för att hålla systemen igång.

Det som fastnade hos mig var inte den sofistikerade koden eller matematiken. Det var att se högkvalificerade människor bränna större delen av sin tid på att kämpa mot molnet istället för att bygga det som verkligen betydde något. Ingen ville göra det arbetet, men det var oundvikligt. Den friktionen – gapet mellan “Jag byggde något” och “det körs tillförlitligt” – är vad Shuttle skapades för att lösa.

Shuttle grundades 2019, innan dagens våg av AI-kodverktyg. Hur har din ursprungliga vision utvecklats när AI-assisterad utveckling har blivit mainstream?

Kärnproblemet förblev detsamma, men AI förstärkte det dramatiskt. När vi började var infrastruktur redan den begränsande faktorn för starka utvecklingsteam. När verktyg som Copilot, Cursor och Claude uppträdde, blev flaskhalsen omöjlig att ignorera.

Plötsligt kunde utvecklare generera fullständiga applikationer på några minuter, men dessa applikationer stötte omedelbart på ett vägg. AI kan skriva kod, men den kan inte konfigurera och hantera molnresurser tillförlitligt. Gapet vi löste för blev mycket bredare och mycket mer brådskande. Miljontals människor bygger nu prototyper, men bara en bråkdel når produktion.

Visionen utvecklades från “göra infrastruktur lättare för utvecklare” till “göra infrastruktur fungera för en helt ny generation byggare” – solo-grundare, små team och AI-agenter som kan skapa backend-kod men inte vill kämpa med molnkonfiguration. Vi tjänar inte bara traditionella ingenjörer längre. Publiken har exploderat.

AI-verktyg som Cursor och GitHub Copilot har förändrat hur utvecklare skriver kod. Från din synvinkel, vilka delar av programvarans livscykel har förbättrats mest, och var kämpar team fortfarande?

Kodgenerering har tagit ett stort steg framåt. Den delen är nästan löst. Du kan beskriva en funktion, och AI kommer att skapa en ram för den. Framför allt har frontend fått nytta av detta, eftersom mönstren är väl förstådda – komponenter, stilar, layouter.

Där team kämpar är allt som kommer efter: distribution, infrastruktur, drift. AI kan generera en API-slutpunkt, men den kan inte automatiskt skapa databasen, lagringen, kön, nätverket, behörigheterna eller distributionspipelinen som gör den verklig. Backend-infrastruktur har inte hållit jämna steg med kodgenerering.

Resultatet är ojämn framgång. Istället för att allt blir enklare från början till slut, dyker nya tryckpunkter upp. Team genererar hela backends på några minuter, men sedan fastnar de i dagar med att försöka distribuera dem säkert. Ibland gör AI det värre genom att producera mer kod än team kan faktiskt köra eller underhålla. Där bor den verkliga friktionen nu.

Distribution beskrivs ofta som den största flaskhalsen för AI-genererade applikationer. Vad är det specifikt som gör att dessa system är så svåra att producera jämfört med att generera koden själv?

Problemet är tillförlitlighet och konsekvenser. Kodgenerering är förlåtande – om AI gör ett misstag, ser du det omedelbart och åtgärdar det. Infrastrukturmisstag är annorlunda. Ett felaktigt tillstånd, en felkonfigurerad resurs, ett dåligt antagande om kostnad eller säkerhet, och du har skapat ett riktigt problem som kanske inte visar sig förrän senare.

Tidigt försökte vi låta AI fritt dra slutsatser om infrastruktur från applikationskod. Det såg bra ut i demonstrationer. I riktiga system gick det sönder. AI producerade konfigurationer som var nästan rätt men inte riktigt – behörigheter som var för breda, konstiga resursval, konfigurationer som skulle bli dyra.

Det lärde oss något kritiskt: i produktion, skapar intelligens utan gränser problem. AI behöver inte mer frihet. Den behöver bättre räls. Du måste designa system där AI kan föreslå och accelerera, men inte kan springa amok. Det är den tekniska utmaningen som gör att producera AI-genererade appar så mycket svårare än att generera koden.

Shuttle introducerade nyligen Neptune som den nästa utvecklingen av sin plattform. Neptune beskrivs som en universell AI-plattformsingenjör – vad betyder det i praktiska termer för utvecklare som går från en prototyp till en produktionssäker backend?

Neptune fungerar som den saknade länken mellan kod och produktion. I praktiska termer betyder det att utvecklare – eller AI-agenter – kan fokusera på att skriva applikationslogik, och Neptune hanterar allt annat: förstå vilken infrastruktur som behövs, allokera resurser, hantera hemligheter, hantera distribution, orkestrera tjänster.

Istället för att tvinga utvecklare att översätta sin applikation till molninfrastruktur, förstår Neptune applikationen och genererar infrastrukturen runt den. Din kod är ritningen. Neptune bygger miljön som behövs för att köra den. Inga Dockerfiler, inga Terraform, ingen ändlös konfiguration.

För någon som går från prototyp till produktion betyder det att du inte möter väggen där du plötsligt behöver lära dig DevOps. Applikationen du byggde fortsätter att fungera medan du skalar den. Neptune broar gapet mellan “Jag byggde något” och “det körs tillförlitligt i produktion”.

När utvecklare alltmer förlitar sig på AI för att generera backend-system, hur balanserar du hastighet och abstraktion med behovet av kontroll, säkerhet och observerbarhet?

Förtroende är svaret. I infrastruktur är förtroende viktigare än förmåga. En enda dålig överraskning – en säkerhetslucka, en trasig distribution, en enorm molnräkning – och du har förlorat människor.

Vi lärde oss tidigt att allt som AI berör måste vara förståeligt och granskningsbart. Även om en utvecklare inte konfigurerade något för hand, behöver de fortfarande se vad som händer och varför. Därför använder Neptune deterministiska infrastrukturregler. AI kan föreslå och accelerera, men allt den gör är grundat i specifikationer som är granskningsbara, förutsägbara och testbara.

Skiftet vi gjorde var från “AI bestämmer” till “AI föreslår inom begränsningar”. Det är skillnaden mellan en rolig demo och något du kan lita på när det betyder något. Utvecklare spenderar inte mindre tid på att fatta beslut – de spenderar mindre tid på att skriva och mer tid på att bestämma vad som borde finnas, vad som är acceptabelt, vilka kompromisser som har mening. De bästa teamen behandlar AI som en mycket kapabel junioringenjör: hjälpsam, produktiv, men inte i kommandot.

Vilka typer av team ser den starkaste värdet från Neptune idag, antingen solo-utvecklare, startups eller större ingenjörsorganisationer?

Profilen har förändrats dramatiskt. Ursprungligen, på Rust-sidan, hade vi en diversifierad bas – enskilda utvecklare, tidiga startups, scaleups, till och med företagsgrupper inom fordonsindustri, IoT, finans, krypto, varhelst tillförlitlighet och prestanda betyder något. Dessa team ville ha kraften i Rust utan den överbelastning som hantering av komplex molninfrastruktur medförde.

Men under det senaste året har uppkomsten av AI-driven utveckling helt förändrat vem som bygger programvara. Nu ser vi solo-grundare, indie-utvecklare, AI-agenter, små team och traditionella programvaruföretag alla generera backend-kod i en aldrig tidigare skådad takt. Publiken är inte längre bara seniora ingenjörer inom specialiserade områden.

Vi ser regelbundet solo-grundare och små team gå från en idé till en distribuerad backend på en enda sittning, eftersom de inte behöver spendera dagar på inställningar. Det är inte bara tid som sparas – det är momentum som bevaras, vilket är allt på början. Där visas det starkaste värdet: människor som kan bygga men inte vill bli infrastruktur-experter bara för att få sina idéer live.

Från ett tekniskt perspektiv, hur hanterar Neptune miljökonfiguration, hemlighetsshantering och infrastrukturorkestrering när det gäller att omvandla AI-genererad kod till en distribuerbar produktionssäker backend?

Neptune behandlar kod och infrastruktur som ett enda, enhetligt system. De flesta distributionsverktyg fungerar som en leveransservice – du bringar dem en container, och de försöker köra den. Det lämnar fortfarande utvecklaren ansvarig för att sy ihop molnresurser, skriva konfiguration, hantera miljövariabler, hantera hemligheter, allokera databaser.

Neptune vänder på den modellen. Istället för att tvinga utvecklaren att översätta sin applikation till molninfrastruktur, förstår Neptune applikationen och genererar infrastrukturen runt den. Det är ett AI-nativt tillvägagångssätt för DevOps: koden är ritningen, och Neptune bygger miljön som behövs för att köra den – inklusive hemlighetsshantering, miljökonfiguration och resursorkestrering.

Nyckeln är att AI fungerar inom deterministiska infrastrukturregler. Den kan inte producera godtyckliga konfigurationer. Allt förblir granskningsbart och förutsägbart, vilket är avgörande för säkerhet och kostnadskontroll i produktionsmiljöer.

Om man ser framåt, hur ser du på Neptunes roll i ett ekosystem där AI-system alltmer bygger, distribuerar och hanterar annan programvara?

Vi rör oss mot en värld där gapet mellan en idé och en fungerande produkt är nästan noll. Mycket snart kommer produkter inte bara att byggas snabbare – de kommer att kontinuerligt förbättras av sig själva baserat på realtidsfeedback från hur människor faktiskt använder dem.

I den världen kommer programvara inte att vara statisk. Applikationer, agenter och system kommer att skapas, modifieras och utvecklas konstant. Allt detta behöver fortfarande köras någonstans. Det behöver fortfarande infrastruktur, behörigheter, resurser och tillförlitlighet.

Vårt långsiktiga mål är att bli standard-systemet för AI-assisterad DevOps – i princip AI-plattformsingenjören. Oavsett om koden skrivs av en utvecklare i Cursor eller genereras autonomt av en AI-agent, bör Neptune vara lagret som tar det från kod till en fullt fungerande, skalbar, produktionssäker tjänst.

Om kreativitet blir obegränsad, kan infrastruktur inte vara begränsningen. När AI-agenter och självutvecklande produkter blir normala, är vår uppgift att göra interaktionen med molninfrastruktur smidig, förutsägbar och säker. Vi fokuserar på att göra det osynligt, så att utvecklare, grundare och företag kan fokusera på att skapa värde istället för att kämpa med infrastruktur.

Tack för den underbara intervjun, läsare som vill lära sig mer bör besöka Shuttle.