Nodar Daneliya, CEO en mede-oprichter van Shuttle – Interviewreeks

Nodar Daneliya, CEO en mede-oprichter van Shuttle – Interviewreeks: Nodar Daneliya is sinds de oprichting van het bedrijf in 2019 Co-Founder en CEO van Shuttle, en leidt de groei van het bedrijf van een vroeg YC Summer 2020-startup tot een developer-georiënteerde platform engineering company; voordat hij bij Shuttle kwam, had hij functies zoals Chief Risk Officer bij Provenance Technologies Ltd, waar hij werkte aan kwantitatieve hedgefondstrategieën, en eerder technische en datafuncties in Londen en bij Google.

Shuttle is een open-source cloud-infrastructuurplatform dat backend-ontwikkeling en -implementatie vereenvoudigt door infrastructuur af te leiden uit code-annotaties, zodat ontwikkelaars zich kunnen concentreren op het schrijven van Rust- of andere code zonder separate configuratiebestanden of complexe cloud-configuratie te hoeven beheren; het platform biedt snelle implementatie, out-of-the-box resource-toewijzing en naadloze schaling, en wordt gebruikt door tienduizenden ingenieurs met meer dan 130.000 implementaties, met als doel de zero-config, AI-geassisteerde ervaring uit te breiden naar alle talen en te integreren met tools zoals GitHub Copilot en Cursor.

Wat was het moment of de frustratie die u uiteindelijk ertoe bracht Shuttle mede op te richten, en welk probleem probeerde u aanvankelijk op te lossen?

Het keerpunt kwam tijdens mijn tijd als leider van de handel bij een kwantitatief hedgefonds. We hadden uitzonderlijke ingenieurs – PhD’s, senior platformmensen, ML-onderzoekers – maar zelfs met dat talent was cloud-infrastructuur de constante bottleneck. Het bouwen van een handelsmodel of backend-service was niet het moeilijke deel. Het probleem was implementatie: het live krijgen op een veilige manier, schalen, cloudservices met elkaar verbinden. Dat is waar alles vertraagde. Op een gegeven moment deed meer dan de helft van ons ingenieursteam DevOps-werk om systemen draaiende te houden.

Wat bij me bleef hangen, was niet de complexiteit van de code of de wiskunde. Het was zien hoe hooggekwalificeerde mensen de meeste tijd verloren met vechten tegen de cloud in plaats van te bouwen aan wat er echt toe deed. Niemand wilde dat werk doen, maar het was onvermijdelijk. Die wrijving – de kloof tussen “ik heb iets gebouwd” en “het draait betrouwbaar” – is wat Shuttle is ontworpen om op te lossen.

Shuttle werd in 2019 opgericht, voordat de huidige golf van AI-codingtools ontstond. Hoe is uw oorspronkelijke visie geëvolueerd nu AI-geassisteerde ontwikkeling mainstream is geworden?

Het kernprobleem bleef hetzelfde, maar AI versterkte het dramatisch. Toen we begonnen, was infrastructuur al de beperkende factor voor sterke engineersteams. Toen tools zoals Copilot, Cursor en Claude verschenen, werd die bottleneck onmogelijk te negeren.

Plotseling konden ontwikkelaars complete applicaties in enkele minuten genereren, maar die applicaties botsten meteen tegen een muur. AI kan code schrijven, maar kan geen infrastructuur configureren en beheren. De kloof die we probeerden op te lossen, werd veel groter en veel urgenter. Miljoenen mensen bouwen nu prototypes, maar slechts een fractie komt tot productie.

De visie evolueerde van “maak infrastructuur gemakkelijker voor ontwikkelaars” naar “maak infrastructuur werken voor een geheel nieuwe generatie bouwers” – solo-oprichters, kleine teams en AI-agents die backend-code kunnen genereren maar geen interesse hebben in worstelen met cloud-configuratie. We serveren niet langer alleen traditionele ingenieurs. Het publiek is geëxplodeerd.

AI-tools zoals Cursor en GitHub Copilot hebben de manier waarop ontwikkelaars code schrijven veranderd. Vanuit uw perspectief, welke delen van de software-levenscyclus zijn het meest verbeterd, en waar worstelen teams nog?

Codegeneratie heeft een sprong voorwaarts gemaakt. Dat deel is bijna opgelost. U kunt een functie beschrijven, en AI zal het scaffolden. Vooral frontend heeft gebaat bij dit proces, omdat de patronen goed begrepen worden – componenten, stijlen, lay-outs.

Waar teams worstelen, is alles wat daarna komt: implementatie, infrastructuur, operaties. AI kan een API-eindpunt genereren, maar kan geen database, opslag, wachtrij, netwerken, machtigingen of implementatiepijplijn automatisch creëren die het werkbaar maakt. Backend-infrastructuur heeft geen gelijke tred gehouden met codegeneratie.

Het resultaat is onevenwichtige vooruitgang. In plaats van dat dingen eind-tot-eind eenvoudiger worden, verschijnen er nieuwe drukpunten. Teams genereren complete backends in enkele minuten, maar komen dan vast te zitten voor dagen bij het proberen om ze veilig te implementeren. Soms maakt AI het erger door meer code te produceren dan teams daadwerkelijk kunnen uitvoeren of onderhouden. Dat is waar de echte wrijving nu leeft.

Implementatie wordt vaak beschreven als de grootste bottleneck voor AI-gegenereerde applicaties. Wat maakt het zo moeilijk om deze systemen in productie te brengen in vergelijking met het genereren van de code zelf?

Het probleem is betrouwbaarheid en gevolgen. Codegeneratie is vergevingsgezind – als de AI een fout maakt, ziet u het meteen en corrigeert u het. Infrastructuurfouten zijn anders. Één verkeerde machtiging, één verkeerd geconfigureerde resource, één verkeerde aanname over kosten of beveiliging, en u heeft een echt probleem gecreëerd dat mogelijk pas later aan het licht komt.

In het begin probeerden we AI vrij te laten om infrastructuur af te leiden uit applicatiecode. Het zag er goed uit in demonstraties. In echte systemen viel het uit elkaar. De AI produceerde configuraties die bijna goed waren, maar niet helemaal – machtigingen te breed, vreemde resourcekeuzes, configuraties die stil worden duur.

Dat leerde ons iets kritisch: in productie creëert intelligentie zonder grenzen problemen. AI heeft geen meer vrijheid nodig. Het heeft betere rails nodig. U moet systemen ontwerpen waarin AI kan suggereren en versnellen, maar niet los kan gaan. Dat is de technische uitdaging die het in productie brengen van AI-gegenereerde apps zo veel moeilijker maakt dan het genereren van de code.

Shuttle introduceerde onlangs Neptune als de volgende evolutie van zijn platform. Neptune wordt beschreven als een universele AI-platformengineer – wat betekent dit in praktische zin voor ontwikkelaars die van een prototype naar een productieklare backend gaan?

Neptune fungeert als de ontbrekende laag tussen code en productie. In praktische zin betekent dit dat ontwikkelaars – of AI-agents – zich kunnen concentreren op het schrijven van applicatielogica, en Neptune alles anders afhandelt: begrijpen welke infrastructuur nodig is, resources toewijzen, geheimen beheren, implementatie afhandelen, services orkestreren.

In plaats van ontwikkelaars te laten vertalen hun applicatie naar cloud-infrastructuur, begrijpt Neptune de applicatie en genereert de infrastructuur eromheen. Uw code is het blauwdruk. Neptune bouwt de omgeving die nodig is om het uit te voeren. Geen Dockerfiles, geen Terraform, geen eindeloze configuratie.

Voor iemand die van een prototype naar productie gaat, betekent dit dat u niet tegen de muur aan loopt waar u plotseling DevOps moet leren. De applicatie die u hebt gebouwd, blijft werken terwijl u deze schaalt. Neptune overbrugt de kloof tussen “ik heb iets gebouwd” en “het draait betrouwbaar in productie”.

Terwijl ontwikkelaars steeds meer vertrouwen op AI om backend-systemen te genereren, hoe balanseert u snelheid en abstractie met de behoefte aan controle, beveiliging en observatie?

Vertrouwen is het antwoord. In infrastructuur gaat vertrouwen boven capaciteit. Één slechte verrassing – een beveiligingsgat, een kapotte implementatie, een enorme cloudrekening – en u bent mensen kwijt.

We leerden vroeg dat alles wat AI aanraakt, begrijpelijk en herzienbaar moet zijn. Zelfs als een ontwikkelaar iets niet handmatig configureerde, moet hij nog steeds zien wat er gebeurt en waarom. Dat is waarom Neptune deterministische infrastructuurregels gebruikt. AI kan suggereren en versnellen, maar alles wat het doet, is gebaseerd op specificaties die herzienbaar, voorspelbaar en testbaar zijn.

De verschuiving die we maakten, was van “AI beslist” naar “AI stelt voor binnen grenzen”. Dat is het verschil tussen een leuk demo en iets waarop u kunt vertrouwen als het ertoe doet. Ontwikkelaars besteden niet minder tijd aan beslissingen nemen – ze besteden minder tijd aan typen en meer tijd aan beslissen wat moet bestaan, wat acceptabel is, welke compromissen zin hebben. De beste teams behandelen AI als een zeer capabele junior-engineer: behulpzaam, productief, maar niet in charge.

Welke soort teams zien de sterkste waarde in Neptune vandaag, of het nu solo-ontwikkelaars, startups of grotere engineeringsorganisaties zijn?

Het profiel is dramatisch veranderd. Oorspronkelijk, aan de Rust-kant, hadden we een diverse basis – individuele ontwikkelaars, vroege startups, scaleups, zelfs enterprise-teams in automotive, IoT, financiën, crypto, overal waar betrouwbaarheid en prestaties ertoe doen. Deze teams wilden de kracht van Rust zonder de overhead van het beheren van complexe cloud-infrastructuur.

Maar in het afgelopen jaar veranderde de opkomst van AI-gedreven ontwikkeling volledig wie software bouwt. Nu zien we solo-oprichters, indie-ontwikkelaars, AI-agents, kleine teams en traditionele softwarebedrijven allemaal backend-code genereren met een ongekende snelheid. Het publiek is niet langer alleen senior-ingenieurs in gespecialiseerde velden.

We zien regelmatig solo-oprichters en kleine teams die van een idee naar een geïmplementeerde backend gaan in één zitting, omdat ze niet dagen hoeven te besteden aan setup. Het is niet alleen tijd besparen – het is momentum behouden, wat alles is in het begin. Dat is waar de sterkste waarde naar voren komt: mensen die kunnen bouwen, maar geen infrastructuurexperts willen worden om hun ideeën live te krijgen.

Vanuit een technisch oogpunt, hoe handelt Neptune omgevingsconfiguratie, geheimenbeheer en infrastructuurorkestratie aan bij het omzetten van AI-gegenereerde code in een implementeerbare productiebackend?

Neptune behandelt code en infrastructuur als één geïntegreerd systeem. De meeste implementatietools handelen als een bezorgdienst – u brengt ze een container, en ze proberen het uit te voeren. Dat laat u nog steeds verantwoordelijk voor het in elkaar zetten van cloudresources, configuratie schrijven, omgevingsvariabelen afhandelen, geheimen beheren, databases inrichten.

Neptune keert dat model om. In plaats van ontwikkelaars te laten vertalen hun applicatie naar cloud-infrastructuur, begrijpt Neptune de applicatie en genereert de infrastructuur eromheen. Het is een AI-natieve aanpak voor DevOps: de code is het blauwdruk, en Neptune bouwt de omgeving die nodig is om het uit te voeren – inclusief geheimenbeheer, omgevingsconfiguratie en resource-orkestratie.

De sleutel is dat AI werkt binnen deterministische infrastructuurregels. Het kan geen willekeurige configuraties produceren. Alles blijft herzienbaar en voorspelbaar, wat essentieel is voor beveiliging en kostencontrole in productieomgevingen.

Terwijl we vooruitkijken, hoe ziet u de rol van Neptune evolueren in een ecosysteem waarin AI-systemen steeds vaker andere software-systemen bouwen, implementeren en beheren?

We bewegen ons naar een wereld waar de kloof tussen een idee en een werkend product bijna nul is. Binnenkort worden producten niet alleen sneller gebouwd – ze zullen zichzelf voortdurend verbeteren op basis van real-time feedback van hoe mensen ze daadwerkelijk gebruiken.

In die wereld is software niet statisch. Apps, agents en systemen worden voortdurend gecreëerd, gewijzigd en geëvolueerd. Alles heeft nog steeds infrastructuur, machtigingen, resources en betrouwbaarheid nodig.

Ons langetermijndoel is om de standaard te worden voor AI-geassisteerde DevOps – in wezen de AI-platformengineer. Of code nu wordt geschreven door een ontwikkelaar in Cursor of gegenereerd door een AI-agent, Neptune moet de laag zijn die het van code naar een volledig uitgevoerd, schaalbaar, productieklare service brengt.

Als creativiteit onbeperkt wordt, kan infrastructuur geen beperking zijn. Terwijl AI-agents en auto-evoluerende producten normaal worden, is onze taak om de interactie met cloud-infrastructuur naadloos, voorspelbaar en veilig te maken. We zijn gericht op het maken van die interactie onzichtbaar, zodat ontwikkelaars, oprichters en bedrijven zich kunnen concentreren op waarde creëren in plaats van te worstelen met infrastructuur. We’re focused on making that invisible, so developers, founders, and companies can focus on creating value instead of wrestling with infrastructure. Thank you for the great interview, readers who wish to learn more should visit Shuttle.