Nodar Daneliya, CEO e Co-fondatore di Shuttle – Serie di Interviste

Nodar Daneliya, CEO e Co-fondatore di Shuttle – Serie di Interviste: Nodar Daneliya ha ricoperto il ruolo di Co-fondatore e CEO di Shuttle fin dalla fondazione dell’azienda nel 2019, guidandone la crescita da startup di inizio YC Summer 2020 a società di ingegneria di piattaforme per sviluppatori; prima di Shuttle, ha ricoperto ruoli tra cui Chief Risk Officer presso Provenance Technologies Ltd, dove ha lavorato su strategie di hedge fund quantitative, e in precedenza ruoli tecnici e di dati a Londra e presso Google.

Shuttle è una piattaforma di infrastruttura cloud open-source che semplifica lo sviluppo e la distribuzione dei backend derivando l’infrastruttura dalle annotazioni del codice, in modo che gli sviluppatori possano concentrarsi sulla scrittura di codice Rust o altri senza gestire file di configurazione separati o complesse impostazioni cloud; la piattaforma consente un rapido deploy, la provisioning delle risorse out-of-the-box e una scalabilità senza soluzione di continuità, ed è utilizzata da decine di migliaia di ingegneri con oltre 130.000 deploy, con l’obiettivo di estendere la sua esperienza zero-config e assistita da AI a tutti i linguaggi e integrarsi con strumenti come GitHub Copilot e Cursor.

Qual è stato il momento o la frustrazione che ti ha spinto a co-fondare Shuttle, e qual era il problema che stavi cercando di risolvere all’inizio?

Il punto di svolta è arrivato durante il mio tempo alla guida del trading presso un hedge fund quantitativo. Avevamo ingegneri eccezionali – dottori di ricerca, senior platform, ricercatori di ML – ma anche con quel talento, l’infrastruttura cloud era il collo di bottiglia costante. Costruire un modello di trading o un servizio di backend non era la parte difficile. Il problema era il deploy: metterlo online in modo sicuro, scalarlo, collegare i servizi cloud tra loro. È lì che tutto si rallentava. A un certo punto, più della metà del nostro team di ingegneri stava facendo lavori di DevOps solo per mantenere i sistemi in funzione.

Ciò che mi è rimasto impresso non era la sofisticazione del codice o della matematica. Era guardare persone molto capaci bruciare la maggior parte del loro tempo combattendo contro il cloud invece di costruire ciò che realmente contava. Nessuno voleva fare quel lavoro, ma era inevitabile. Quella frizione – il gap tra “ho costruito qualcosa” e “sta funzionando in modo affidabile” – è ciò che Shuttle è stato creato per risolvere.

Shuttle è stata fondata nel 2019, prima dell’attuale ondata di strumenti di codifica AI. Come è evoluta la tua visione originale con l’avvento dello sviluppo assistito da AI?

Il problema di base è rimasto lo stesso, ma l’AI lo ha amplificato drasticamente. Quando abbiamo iniziato, l’infrastruttura era già il fattore limitante per team di ingegneria forti. Quando sono apparsi strumenti come Copilot, Cursor e Claude, quel collo di bottiglia è diventato impossibile da ignorare.

Improvvisamente, gli sviluppatori potevano generare applicazioni complete in pochi minuti, ma quelle app hanno incontrato un muro immediatamente. L’AI può scrivere codice, ma non può configurare e gestire in modo affidabile le risorse cloud. Il gap che stavamo risolvendo è diventato molto più ampio e più urgente. Milioni di persone stanno ora costruendo prototipi, ma solo una frazione li porta in produzione.

La visione è evoluta da “rendere l’infrastruttura più facile per gli sviluppatori” a “fare in modo che l’infrastruttura funzioni per una intera nuova generazione di costruttori” – founder solitari, piccoli team e agenti AI che possono creare codice di backend ma non hanno alcun interesse a lottare con la configurazione del cloud. Non stiamo più servendo solo ingegneri tradizionali. Il pubblico è esploso.

Strumenti AI come Cursor e GitHub Copilot hanno cambiato il modo in cui gli sviluppatori scrivono codice. Dal tuo punto di vista, quali parti del ciclo di vita del software sono migliorate di più, e dove le squadre continuano a lottare?

La generazione di codice ha fatto un grande balzo in avanti. Quella parte è quasi risolta. Puoi descrivere una funzionalità, e l’AI la crea. Il frontend ha beneficiato particolarmente perché i pattern sono ben compresi – componenti, stili, layout.

Dove le squadre lottano è in tutto ciò che segue: deploy, infrastruttura, operazioni. L’AI potrebbe generare un endpoint API, ma non può creare automaticamente il database, l’archiviazione, la coda, la rete, le autorizzazioni o il pipeline di deploy che lo rende reale. L’infrastruttura di backend non ha tenuto il passo con la generazione di codice.

Il risultato è un progresso disomogeneo. Invece di semplificare le cose dall’inizio alla fine, nuovi punti di pressione appaiono. Le squadre generano interi backend in pochi minuti, poi rimangono bloccate per giorni cercando di deployarli in modo sicuro. A volte l’AI rende le cose peggiori producendo più codice di quanto i team possano effettivamente eseguire o mantenere. È lì che si trova la vera frizione ora.

Il deploy è spesso descritto come il collo di bottiglia più grande per le applicazioni generate da AI. Cosa rende così impegnativo produrre questi sistemi rispetto alla generazione del codice stesso?

Il problema è l’affidabilità e le conseguenze. La generazione di codice è perdonabile – se l’AI fa un errore, lo vedi immediatamente e lo correggi. Gli errori di infrastruttura sono diversi. Un’autorizzazione errata, una risorsa mal configurata, un’ipotesi errata sui costi o sulla sicurezza, e hai creato un problema reale che potrebbe non emergere fino a dopo.

All’inizio, abbiamo provato a lasciare che l’AI inferisse liberamente l’infrastruttura dal codice dell’applicazione. Sembrava grande nelle demo. In sistemi reali, è crollato. L’AI avrebbe prodotto setup che erano quasi giusti ma non del tutto – autorizzazioni troppo ampie, scelte di risorse strane, configurazioni che sarebbero diventate costose in silenzio.

Ciò ci ha insegnato qualcosa di critico: in produzione, l’intelligenza senza confini crea problemi. L’AI non ha bisogno di più libertà. Ha bisogno di binari migliori. Devi progettare sistemi in cui l’AI possa suggerire e accelerare, ma non può correre selvaggia. È la sfida tecnica che rende la produzione di app generate da AI molto più difficile della generazione del codice.

Shuttle ha recentemente introdotto Neptune come l’evoluzione successiva della sua piattaforma. Neptune è descritta come una piattaforma di ingegneria universale AI – cosa significa questo in termini pratici per gli sviluppatori che passano da un prototipo a un backend di produzione pronto?

Neptune agisce come lo strato mancante tra il codice e la produzione. In termini pratici, significa che gli sviluppatori – o gli agenti AI – possono concentrarsi sulla scrittura della logica dell’applicazione, e Neptune gestisce tutto il resto: comprendere quali risorse di infrastruttura sono necessarie, provvisionare le risorse, gestire i segreti, gestire il deploy, orchestrare i servizi.

Invece di far sì che gli sviluppatori traducano la loro applicazione in infrastruttura cloud, Neptune comprende l’applicazione e genera l’infrastruttura intorno ad essa. Il tuo codice è il progetto. Neptune costruisce l’ambiente necessario per eseguirlo. Nessun Dockerfile, nessun Terraform, nessuna configurazione infinita.

Per qualcuno che passa da un prototipo a un backend di produzione, significa che non si scontra con il muro in cui improvvisamente si deve imparare DevOps. L’applicazione che hai costruito continua a funzionare mentre la si scala. Neptune collega il gap tra “ho costruito qualcosa” e “sta funzionando in modo affidabile in produzione”.

Come gli sviluppatori si affidano sempre di più all’AI per generare sistemi di backend, come bilanci la velocità e l’astrazione con la necessità di controllo, sicurezza e osservabilità?

La fiducia è la risposta. Nell’infrastruttura, la fiducia conta più della capacità. Una sola brutta sorpresa – un buco di sicurezza, un deploy rotto, una fattura cloud enorme – e hai perso le persone.

Abbiamo imparato presto che tutto ciò che l’AI tocca deve essere comprensibile e revisionabile. Anche se uno sviluppatore non ha configurato qualcosa manualmente, deve comunque vedere cosa sta succedendo e perché. È per questo che Neptune utilizza regole di infrastruttura deterministiche. L’AI può suggerire e accelerare, ma tutto ciò che fa è basato su specifiche che sono revisionabili, prevedibili e testabili.

Il passaggio che abbiamo fatto è stato da “AI decide” a “AI propone all’interno di vincoli”. È la differenza tra una demo divertente e qualcosa che puoi fidarti quando conta. Gli sviluppatori non stanno spendendo meno tempo prendendo decisioni – stanno spendendo meno tempo digitando e più tempo decidendo cosa dovrebbe esistere, cosa è accettabile, quali compromessi hanno senso. I migliori team trattano l’AI come un giovane ingegnere molto capace: utile, produttivo, ma non al comando.

Quali tipi di team stanno vedendo il valore più forte da Neptune oggi, che siano sviluppatori solitari, startup o grandi organizzazioni di ingegneria?

Il profilo è cambiato drasticamente. Inizialmente, sul lato Rust, avevamo una base diversificata – sviluppatori individuali, startup in fase iniziale, scaleup, anche team di enterprise in settori come automotive, IoT, finanza, criptovalute, ovunque conti l’affidabilità e le prestazioni. Questi team volevano il potere di Rust senza il sovraccarico di gestione di infrastrutture cloud complesse.

Ma nell’ultimo anno, l’ascesa dello sviluppo guidato da AI ha completamente cambiato chi costruisce software. Ora vediamo founder solitari, sviluppatori indipendenti, agenti AI, piccoli team e società di software tradizionali generare codice di backend a una velocità senza precedenti. Il pubblico non è più solo ingegneri senior in campi specializzati.

Vediamo regolarmente founder solitari e piccoli team passare da un’idea a un backend deployato in una sola seduta perché non devono spendere giorni sull’impostazione. Non è solo tempo risparmiato – è slancio preservato, che è tutto all’inizio. È lì che si mostra il valore più forte: persone che possono costruire ma non vogliono diventare esperti di infrastruttura solo per portare le loro idee online.

Da un punto di vista tecnico, come Neptune gestisce la configurazione dell’ambiente, la gestione dei segreti e l’orchestrazione dell’infrastruttura quando trasforma il codice generato da AI in un backend di produzione deployabile?

Neptune tratta il codice e l’infrastruttura come un sistema unificato. La maggior parte degli strumenti di deploy agisce come un servizio di consegna – ti porti un contenitore, e cercano di eseguirlo. Ciò ti lascia ancora responsabile per cucire insieme le risorse cloud, scrivere la configurazione, gestire le variabili d’ambiente, occuparti dei segreti, provvisionare i database.

Neptune capovolge quel modello. Invece di far sì che lo sviluppatore traduca l’applicazione in infrastruttura cloud, Neptune comprende l’applicazione e genera l’infrastruttura intorno ad essa. È un approccio nativo AI a DevOps: il codice è il progetto, e Neptune costruisce l’ambiente necessario per eseguirlo – compresa la gestione dei segreti, la configurazione dell’ambiente e l’orchestrazione delle risorse.

La chiave è che l’AI lavora all’interno di regole di infrastruttura deterministiche. Non può produrre configurazioni arbitrarie. Tutto rimane revisionabile e prevedibile, il che è essenziale per la sicurezza e il controllo dei costi negli ambienti di produzione.

Guardando avanti, come vedi evolversi il ruolo di Neptune in un ecosistema in cui i sistemi AI costruiscono, deployano e gestiscono sempre più software?

Stiamo andando verso un mondo in cui il gap tra un’idea e un prodotto funzionante è quasi zero. Presto, i prodotti non saranno solo costruiti più velocemente – saranno migliorati continuamente sulla base dei feedback in tempo reale su come le persone li utilizzano effettivamente.

In quel mondo, il software non sarà statico. App, agenti e sistemi saranno creati, modificati ed evoluti costantemente. Tutto ciò deve ancora essere eseguito da qualche parte. Ha ancora bisogno di infrastruttura, autorizzazioni, risorse e affidabilità.

Il nostro obiettivo a lungo termine è diventare il sistema predefinito per DevOps assistito da AI – essenzialmente l’Ingegnere di Piattaforma AI. Che il codice sia scritto da uno sviluppatore in Cursor o generato autonomamente da un agente AI, Neptune dovrebbe essere lo strato che lo porta dal codice a un servizio completamente funzionante e scalabile.

Se la creatività diventa illimitata, l’infrastruttura non può essere il vincolo. Mentre gli agenti AI e i prodotti auto-evoluti diventano normali, il nostro lavoro è rendere l’interazione con l’infrastruttura cloud senza soluzione di continuità, prevedibile e sicura. Ci concentriamo su rendere ciò invisibile, in modo che gli sviluppatori, i founder e le società possano concentrarsi sulla creazione di valore invece di lottare con l’infrastruttura. Thank you for the great interview, readers who wish to learn more should visit Shuttle.