Nodar Daneliya, CEO și Co-fondator al Shuttle – Interviu

Nodar Daneliya, CEO și Co-fondator al Shuttle – Interviu: Nodar Daneliya a ocupat funcția de Co-fondator și CEO al Shuttle din momentul înființării companiei în 2019, conducând creșterea acesteia de la o startup timpurie YC Summer 2020 la o companie de inginerie a platformei pentru dezvoltatori; înainte de a lucra la Shuttle, a ocupat funcții precum Chief Risk Officer la Provenance Technologies Ltd, unde a lucrat la strategii de fonduri de investiții cuantitative, și anterior a avut roluri tehnice și de date la Londra și la Google.

Shuttle este o platformă de infrastructură cloud deschisă care simplifică dezvoltarea și implementarea backend prin derivarea infrastructurii din annotări de cod, astfel încât dezvoltatorii să se poată concentra pe scrierea de cod în Rust sau în alte limbi fără a gestiona fișiere de configurare separate sau configurări complexe de cloud; platforma permite implementarea rapidă, provisionarea resurselor și scalarea fără efort, și este utilizată de zeci de mii de ingineri, cu peste 130.000 de implementări, urmărind să extindă experiența sa zero-config, asistată de IA, la toate limbile și să se integreze cu instrumente precum GitHub Copilot și Cursor.

Care a fost momentul sau frustrarea care v-a determinat să co-fondați Shuttle, și ce problemă încercați să rezolvați la început?

Punctul de cotitură a venit în timpul meu petrecut la conducerea tranzacțiilor la un fond de investiții cuantitativ. Aveam ingineri excepționali – doctori, oameni senior ai platformei, cercetători în inteligență artificială – dar chiar și cu acest talent, infrastructura cloud a fost mereu o piedică. A construi un model de tranzacționare sau un serviciu backend nu a fost partea grea. Problema a fost implementarea: a face ca acesta să fie disponibil în siguranță, a-l scala, a conecta serviciile cloud. Acolo este locul unde totul a încetinit. La un moment dat, mai mult de jumătate din echipa noastră de ingineri făcea lucrări de DevOps doar pentru a menține sistemele funcționale.

Ce m-a impresionat nu a fost sofisticarea codului sau a matematicii. A fost să văd oameni foarte capabili care ardeau cea mai mare parte a timpului lor luptându-se cu cloud-ul, în loc de a construi ceea ce conta cu adevărat. Nimeni nu a vrut să facă acea muncă, dar a fost inevitabilă. Acea fricțiune – golul dintre “am construit ceva” și “funcționează în mod fiabil” – este ceea ce Shuttle a fost creat pentru a rezolva.

Shuttle a fost fondat în 2019, înainte de valul actual de instrumente de codare cu IA. Cum a evoluat viziunea dvs. inițială, pe măsură ce dezvoltarea asistată de IA a devenit mainstream?

Problema de bază a rămas aceeași, dar IA a amplificat-o dramatic. Când am început, infrastructura era deja factorul limitativ pentru echipele puternice de ingineri. Când au apărut instrumente precum Copilot, Cursor și Claude, acea piedică a devenit imposibil de ignorat.

Deodată, dezvoltatorii puteau genera aplicații complete în minute, dar aceste aplicații au lovit un zid imediat. IA poate scrie cod, dar nu poate configura și gestiona în mod fiabil resursele cloud. Golul pe care îl rezolvam a devenit mult mai larg și mult mai urgent. Milioane de oameni construiesc acum prototipuri, dar doar o fracțiune ajung la producție.

Viziunea noastră a evoluat de la “a face infrastructura mai ușoară pentru dezvoltatori” la “a face infrastructura să funcționeze pentru o întreagă generație de constructori” – fondatori solo, echipe mici și agenți IA care pot crea cod backend, dar nu au niciun interes să se lupte cu configurarea cloud. Nu mai servim doar ingineri tradiționali. Publicul a explodat.

Instrumentele de IA, cum ar fi Cursor și GitHub Copilot, au schimbat modul în care dezvoltatorii scriu cod. Din perspectiva dvs., care părți ale ciclului de viață al software-ului s-au îmbunătățit cel mai mult, și unde echipele încă se luptă?

Generarea codului a făcut un salt enorm. Partea aceea este aproape rezolvată. Puteți descrie o funcționalitate, și IA o va crea. În special, partea frontend a beneficiat, deoarece modelele sunt bine înțelese – componente, stiluri, layout-uri.

Unde echipele se luptă este tot ceea ce vine după: implementarea, infrastructura, operațiunile. IA poate genera un punct de acces API, dar nu poate crea automat baza de date, stocarea, coada, rețeaua, permisiunile sau pipeline-ul de implementare care face ca acesta să funcționeze. Infrastructura backend nu a ținut pasul cu generarea codului.

Rezultatul este un progres inegal. În loc ca lucrurile să devină mai simple de la cap la coadă, apar noi puncte de presiune. Echipele generează întregi backends în minute, apoi se blochează timp de zile, încercând să le implementeze în siguranță. Uneori, IA face lucrurile mai grave, producând mai mult cod decât echipele pot chiar rula sau menține. Acolo este locul unde trăiește fricțiunea reală.

Implementarea este adesea descrisă ca fiind cea mai mare piedică pentru aplicațiile generate de IA. Ce face ca sistemele de producție să fie atât de provocatoare, comparativ cu generarea codului în sine?

Problema este fiabilitatea și consecințele. Generarea codului este îngăduitoare – dacă IA face o greșeală, o vezi imediat și o corectezi. Greșelile de infrastructură sunt diferite. O singură permisiune greșită, o resursă configurată incorect, o presupunere greșită despre cost sau securitate, și ai creat o problemă reală care poate să nu apară până mai târziu.

La început, am încercat să lăsăm IA să inferă în mod liber infrastructura din codul aplicației. A arătat bine în demo-uri. În sisteme reale, s-a destrămat. IA a produs cu încredere configurații care erau aproape corecte, dar nu chiar – permisiuni prea largi, alegeri de resurse ciudate, configurări care ar fi devenit scumpe în mod neașteptat.

Ne-a învățat ceva critic: în producție, inteligența fără limite creează probleme. IA nu are nevoie de mai multă libertate. Are nevoie de căi ferate mai bune. Trebuie să proiectezi sisteme în care IA poate sugera și accelera, dar nu poate alerga sălbatic. Aceasta este provocarea tehnică care face ca sistemele de producție generate de IA să fie atât de mult mai greu de realizat decât generarea codului.

Shuttle a introdus recent Neptune, ca următoarea evoluție a platformei sale. Neptune este descrisă ca o platformă universală de inginerie pentru IA – ce înseamnă acest lucru, în termeni practici, pentru dezvoltatori care trec de la un prototip la un backend de producție gata?

Neptune acționează ca stratul lipsă între cod și producție. În termeni practici, înseamnă că dezvoltatorii – sau agenții IA – pot se concentra pe scrierea logicii aplicației, iar Neptune se ocupă de tot restul: înțelegerea infrastructurii necesare, provisionarea resurselor, gestionarea secretelor, gestionarea implementării, orchestrarea serviciilor.

În loc să facă dezvoltatorii să traducă aplicația lor în infrastructură cloud, Neptune înțelege aplicația și generează infrastructura în jurul acesteia. Codul dvs. este planul. Neptune construiește mediul necesar pentru a-l rula. Fără fișiere Docker, fără Terraform, fără configurări infinite.

Pentru cineva care trece de la un prototip la un backend de producție, înseamnă că nu lovește peretele unde trebuie să învețe DevOps. Aplicația pe care ați construit-o continuă să funcționeze pe măsură ce o scalați. Neptune podeste golul dintre “am construit ceva” și “funcționează în mod fiabil în producție”.

Cum echilibrați viteza și abstractizarea cu nevoia de control, securitate și observabilitate, pe măsură ce dezvoltatorii se bazează mai mult pe IA pentru a genera sisteme backend?

Încrederea este răspunsul. În infrastructură, încrederea contează mai mult decât capacitatea. O singură surpriză proastă – o gaură de securitate, o implementare stricată, o factură uriașă la cloud – și ați pierdut oamenii.

Am învățat devreme că orice atins de IA are nevoie să fie înțeleasă și revizuită. Chiar dacă un dezvoltator nu a configurat ceva manual, el tot trebuie să vadă ce se întâmplă și de ce. De aceea, Neptune utilizează reguli de infrastructură deterministice. IA poate sugera și accelera, dar tot ceea ce face este bazat pe specificații care pot fi revizuite, previzibile și testate.

Schimbarea pe care am făcut-o a fost de la “IA decide” la “IA propune în limite”. Acesta este diferența dintre un demo distractiv și ceva în care puteți avea încredere atunci când contează. Dezvoltatorii nu petrec mai puțin timp luând decizii – petrec mai puțin timp tastând și mai mult timp decidând ce ar trebui să existe, ce este acceptabil, ce compromisuri au sens. Cele mai bune echipe tratează IA ca pe un inginer junior foarte capabil: util, productiv, dar nu responsabil.

Ce tipuri de echipe văd cel mai puternic beneficiul de la Neptune în prezent, fie că sunt dezvoltatori solo, startup-uri sau organizații de ingineri mai mari?

Profilul a fost dramatic schimbat. Inițial, pe partea Rust, am avut o bază diversă – dezvoltatori individuali, startup-uri timpurii, scaleup-uri, chiar și echipe de ingineri din companii mari din domenii precum automotive, IoT, finanțe, criptomonede, oriunde securitatea și performanța contează. Aceste echipe doreau puterea Rust fără supraîncărcarea gestionării infrastructurii cloud complexe.

Dar, în ultimul an, apariția dezvoltării conduse de IA a schimbat complet cine construiește software. Acum vedem fondatori solo, dezvoltatori independenți, agenți IA, echipe mici și companii de software tradiționale care generează cod backend la o viteză fără precedent. Publicul nu mai este doar ingineri seniori în domenii specializate.

Vedem în mod regulat fondatori solo și echipe mici care trec de la o idee la un backend implementat într-o singură ședință, pentru că nu trebuie să petreacă zile pentru configurare. Nu este doar timp economisit – este impuls păstrat, ceea ce contează foarte mult la început. Acolo este locul unde valoarea cea mai puternică apare: oameni care pot construi, dar nu vor să devină experți în infrastructură doar pentru a-și pune ideile în aplicare.

Din punct de vedere tehnic, cum gestionează Neptune configurarea mediului, gestionarea secretelor și orchestrarea infrastructurii atunci când transformă codul generat de IA într-un backend de producție implementabil?

Neptune tratează codul și infrastructura ca un sistem unitar. Cele mai multe instrumente de implementare acționează ca un serviciu de livrare – aduceți-le un container, și ele încearcă să-l ruleze. Încă vă lasă responsabil pentru a coase împreună resurse cloud, a scrie configurări, a face față variabilelor de mediu, a gestiona secrete, a provisiona baze de date.

Neptune inversează această abordare. În loc să facă dezvoltatorul să traducă aplicația în infrastructură cloud, Neptune înțelege aplicația și generează infrastructura în jurul acesteia. Este o abordare nativă de IA pentru DevOps: codul este planul, iar Neptune construiește mediul necesar pentru a-l rula – inclusiv gestionarea secretelor, configurarea mediului și orchestrarea resurselor.

Cheia este că IA lucrează în interiorul unor reguli de infrastructură deterministice. Nu poate produce configurări arbitrare. Totul rămâne revizuit și previzibil, ceea ce este esențial pentru securitate și controlul costurilor în medii de producție.

Privind înainte, cum vedeți evoluția rolului Neptune într-un ecosistem în care sistemele de IA construiesc, implementează și gestionează din ce în ce mai mult software?

Ne îndreptăm spre o lume în care golul dintre o idee și un produs funcțional este aproape zero. Foarte curând, produsele nu vor fi doar construite mai repede – ele se vor îmbunătăți în mod continuu pe baza feedback-ului real de la modul în care oamenii le folosesc.

În acea lume, software-ul nu va fi static. Aplicații, agenți și sisteme vor fi create, modificate și evolute în mod constant. Toate acestea tot trebuie să ruleze undeva. Tot necesită infrastructură, permisiuni, resurse și fiabilitate.

Obiectivul nostru pe termen lung este să devenim sistemul implicit pentru DevOps asistat de IA – esențialmente, Inginerul de Platformă pentru IA. Indiferent dacă codul este scris de un dezvoltator în Cursor sau generat în mod autonom de un agent IA, Neptune ar trebui să fie stratul care ia codul de la cod la un serviciu de producție complet implementat și escalabil.

Dacă creativitatea devine nelimitată, infrastructura nu poate fi constrângerea. Pe măsură ce agenții IA și produsele care se auto-evoluează devin normale, sarcina noastră este să facem interacțiunea cu infrastructura cloud să fie fără efort, previzibilă și sigură. Ne concentrăm să facem acest lucru invizibil, astfel încât dezvoltatorii, fondatorii și companiile să se poată concentra pe crearea de valoare, în loc de a se lupta cu infrastructura.

Mulțumim pentru acest interviu minunat, cititorilor care doresc să afle mai multe despre Shuttle.