Nodar Daneliya, CEO i współzałożyciel Shuttle – Wywiad

Nodar Daneliya, CEO i współzałożyciel Shuttle – Wywiad: Nodar Daneliya pełnił funkcję współzałożyciela i CEO Shuttle od momentu założenia firmy w 2019 roku, prowadząc jej rozwój od wczesnego startupu YC Summer 2020 do firmy inżynieryjnej skupionej na developerach; przed Shuttle zajmował stanowiska, w tym Chief Risk Officer w Provenance Technologies Ltd, gdzie pracował nad strategiami kwantytatywnymi funduszy hedgingowych, a wcześniej pełnił role techniczne i analityczne w Londynie i w Google.

Shuttle to platforma infrastruktury chmury otwartego źródła, która upraszcza rozwój i wdrożenie backendu, wykorzystując adnotacje kodu, aby pozwolić developerom skupić się na pisaniu kodu w Rust lub innych językach bez zarządzania oddzielnymi plikami konfiguracyjnymi lub złożonymi ustawieniami chmury; platforma umożliwia szybkie wdrożenie, automatyczne przydzielanie zasobów i płynne skalowanie, a także jest używana przez dziesiątki tysięcy inżynierów z ponad 130 000 wdrożeń, dążąc do rozszerzenia swojego doświadczenia zero-konfiguracyjnego, wspomaganego przez AI, na wszystkie języki i integrację z narzędziami takimi jak GitHub Copilot i Cursor.

Jaki moment lub frustracja ostatecznie skłoniły Cię do współzałożenia Shuttle, a jaki problem próbowaliście rozwiązać na samym początku?

Punktem zwrotnym było moje doświadczenie w czasie, gdy kierowałem handlem w funduszu hedgingowym kwantytatywnym. Mieliśmy wyjątkowych inżynierów – doktorów, seniorów, badaczy ML – ale nawet z takim talentem, infrastruktura chmury była stałym bottle neck. Budowanie modelu handlowego lub usługi backend nie było trudne. Problemem było wdrożenie: umieszczenie go na żywo w sposób bezpieczny, skalowanie, łączenie usług chmury. To tam wszystko zwalniało. W pewnym momencie ponad połowa naszego zespołu inżynierskiego zajmowała się pracą DevOps, aby tylko utrzymać systemy w działaniu.

To, co utkwiło mi w pamięci, nie było związane z złożonością kodu czy matematyką. Było to obserwowanie wysoko wykwalifikowanych ludzi, którzy spalali większość swojego czasu, walcząc z chmurą, zamiast budować to, co naprawdę się liczyło. Nikt nie chciał wykonywać tej pracy, ale była nieunikniona. Ta fraktura – luka między “zbudowałem coś” a “działa niezawodnie” – to właśnie to, czego Shuttle został stworzony, aby rozwiązać.

Shuttle został założony w 2019 roku, zanim nastąpiła fala narzędzi kodowania AI. Jak Twoja pierwotna wizja ewoluowała, gdy rozwój wspomagany przez AI stał się mainstreamem?

Podstawowy problem pozostał ten sam, ale AI znacznie go spotęgował. Gdy zaczynaliśmy, infrastruktura była już czynnikiem ograniczającym dla silnych zespołów inżynierskich. Gdy pojawiły się narzędzia takie jak Copilot, Cursor i Claude, ta wąska garść stała się nie do pominięcia.

Nagle, deweloperzy mogli generować pełne aplikacje w ciągu kilku minut, ale te aplikacje natychmiast uderzały w ścianę. AI może pisać kod, ale nie może niezawodnie konfigurować i zarządzać zasobami chmury. Przerwa, którą rozwiązywaliśmy, stała się znacznie szersza i bardziej pilna. Miliony ludzi teraz budują prototypy, ale tylko ułamek z nich dociera do produkcji.

Wizja ewoluowała od “upraszczania infrastruktury dla deweloperów” do “uczynienia infrastruktury działającej dla całego nowego pokolenia budowniczych” – solo założycieli, małych zespołów i agentów AI, którzy mogą tworzyć kod backend, ale nie mają zainteresowania walką z konfiguracją chmury. Nie służymy już tylko tradycyjnym inżynierom. Publiczność wybuchła.

Narzędzia AI, takie jak Cursor i GitHub Copilot, zmieniły sposób, w jaki deweloperzy piszą kod. Z Twojego punktu widzenia, które części cyklu życia oprogramowania zostały najbardziej poprawione, a gdzie zespoły nadal mają trudności?

Generowanie kodu skoczyło do przodu. Ta część jest prawie rozwiązana. Możesz opisać funkcję, a AI ją opracuje. Szczególnie frontend skorzystał, ponieważ wzorce są dobrze zrozumiane – komponenty, style, układy.

Tam, gdzie zespoły mają trudności, jest wszystko, co następuje po tym: wdrożenie, infrastruktura, operacje. AI może wygenerować punkt końcowy API, ale nie może automatycznie utworzyć bazy danych, magazynu, kolejki, sieci, uprawnień lub potoku wdrożeniowego, który to uczyni realnym. Infrastruktura backend nie nadążyła za generowaniem kodu.

Wynikiem jest nierówny postęp. Zamiast tego, że rzeczy stają się prostsze od końca do końca, pojawiają się nowe punkty nacisku. Zespoły generują całe backends w ciągu kilku minut, a potem utknąją na dni, próbując je wdrożyć bezpiecznie. Czasem AI sprawia, że jest gorzej, produkując więcej kodu, niż zespoły mogą naprawdę uruchomić lub utrzymać. To tam żyje prawdziwa fraktura.

Wdrożenie jest często opisywane jako największa wąska garść dla aplikacji wygenerowanych przez AI. Co konkretnie sprawia, że produkcja tych systemów jest tak wyzwaniem w porównaniu z samym generowaniem kodu?

Problemem jest niezawodność i konsekwencje. Generowanie kodu jest wybaczące – jeśli AI popełni błąd, widzisz to natychmiast i naprawiasz. Błędy infrastruktury są inne. Jeden błędny pozwolenie, jeden źle skonfigurowany zasób, jeden błędny założenie dotyczące kosztów lub bezpieczeństwa, i stworzyłeś prawdziwy problem, który może nie pojawić się aż później.

Na początku próbowaliśmy pozwolić AI swobodnie wnioskować infrastrukturę z kodu aplikacji. Wyglądało to świetnie w demo. W rzeczywistych systemach to się rozpadło. AI z pewnością produkowałoby ustawienia, które były prawie dobre, ale nie do końca – pozwolenia zbyt szerokie, dziwne wybory zasobów, konfiguracje, które byłyby cicho drogie.

To nauczyło nas czegoś krytycznego: w produkcji, inteligencja bez granic tworzy problemy. AI nie potrzebuje więcej wolności. Potrzebuje lepszych torów. Musisz zaprojektować systemy, w których AI może sugerować i przyspieszać, ale nie może działać dziko. To jest techniczne wyzwanie, które sprawia, że produkcja aplikacji wygenerowanych przez AI jest o wiele trudniejsza niż generowanie samego kodu.

Shuttle niedawno wprowadził Neptune jako następną ewolucję swojej platformy. Neptune jest opisywany jako uniwersalny inżynier platformy AI—co to oznacza w praktyce dla deweloperów przechodzących od prototypu do produkcyjnego backendu?

Neptune działa jako brakująca warstwa między kodem a produkcją. W praktyce oznacza to, że deweloperzy – lub agenci AI – mogą skupić się na pisaniu logiki aplikacji, a Neptune zajmie się wszystkim innym: zrozumieniem, jakiej infrastruktury potrzeba, przydzieleniem zasobów, zarządzaniem sekretami, obsługą wdrożenia, orchestracją usług.

Zamiast zmuszać deweloperów do tłumaczenia swojej aplikacji na infrastrukturę chmury, Neptune rozumie aplikację i generuje infrastrukturę wokół niej. Twój kod jest planem. Neptune buduje środowisko potrzebne do jego uruchomienia. Żadnych plików Docker, żadnego Terraform, żadnej nieskończonej konfiguracji.

Dla kogoś, kto przechodzi od prototypu do produkcji, oznacza to, że nie uderzysz w ścianę, gdzie nagle musisz nauczyć się DevOps. Aplikacja, którą zbudowałeś, nadal działa, gdy ją skalujesz. Neptune mostkuje przepaść między “zbudowałem coś” a “działa niezawodnie w produkcji”.

Jak deweloperzy coraz bardziej polegają na AI do generowania systemów backend, jak Ty balansujesz prędkość i abstrakcję z potrzebą kontroli, bezpieczeństwa i obserwowalności?

Zaufanie jest odpowiedzią. W infrastrukturze zaufanie ma większe znaczenie niż zdolność. Jeden zły zaskoczenie – dziura w zabezpieczeniach, złamana wdrożenie, ogromny rachunek za chmurę – i straciłeś ludzi.

Nauczyliśmy się wcześnie, że wszystko, co AI dotyka, musi być zrozumiałe i podlegać przeglądowi. Nawet jeśli deweloper nie skonfigurował czegoś ręcznie, nadal musi zobaczyć, co się dzieje i dlaczego. Dlatego Neptune używa reguł infrastruktury deterministycznych. AI może sugerować i przyspieszać, ale wszystko, co robi, jest ugruntowane w specyfikacjach, które są podlegające przeglądowi, przewidywalne i testowalne.

Zmiana, którą wprowadziliśmy, była od “AI decyduje” do “AI proponuje w ramach ograniczeń”. To jest różnica między fajnym demo a czymś, co możesz zaufać, gdy ma to znaczenie. Deweloperzy nie spędzają mniej czasu na podejmowaniu decyzji – spędzają mniej czasu na pisaniu i więcej czasu na decydowaniu, co powinno istnieć, co jest akceptowalne, jakie kompromisy mają sens. Najlepsze zespoły traktują AI jak bardzo zdolnego młodszego inżyniera: pomocnego, produktywnego, ale nie odpowiedzialnego.

Jakie typy zespołów widzą największą wartość z Neptune dzisiaj, czy to solo deweloperzy, startupy, czy większe organizacje inżynierskie?

Profil zmienił się dramatycznie. Początkowo, po stronie Rust, mieliśmy zróżnicowaną bazę – indywidualnych deweloperów, wczesnych startupów, scaleupów, a nawet zespołów korporacyjnych w motoryzacji, IoT, finansach, kryptowalutach, wszędzie tam, gdzie liczy się niezawodność i wydajność. Te zespoły chciały mieć moc Rust bez nakładu zarządzania złożoną infrastrukturą chmury.

Ale w ciągu ostatniego roku wzrost rozwoju wspomaganego przez AI całkowicie zmienił, kto buduje oprogramowanie. Teraz widzimy solo założycieli, niezależnych deweloperów, agenci AI, małe zespoły i tradycyjne firmy oprogramowania, które wszystkie generują kod backend z niespotykaną dotąd szybkością. Publiczność nie składa się już tylko z seniorów inżynierów w specjalistycznych dziedzinach.

Regularnie widzimy solo założycieli i małe zespoły, które przechodzą od pomysłu do wdrożonego backendu w jednym posiedzeniu, ponieważ nie muszą spędzać dni na ustawieniach. To nie tylko czas zaoszczędzony – to zachowany impet, co jest wszystkim na początku. To tam pojawia się największa wartość: ludzie, którzy mogą budować, ale nie chcą stawać się ekspertami od infrastruktury, aby tylko dostać swoje pomysły na żywo.

Z technicznego punktu widzenia, jak Neptune radzi sobie z konfiguracją środowiska, zarządzaniem sekretami i orchestracją infrastruktury, gdy zmienia kod wygenerowany przez AI w wdrożony backend produkcyjny?

Neptune traktuje kod i infrastrukturę jako jeden zjednoczony system. Większość narzędzi wdrożeniowych działa jak usługa dostarczania – przynosisz im kontener, a oni próbują go uruchomić. To nadal pozostawia Cię odpowiedzialnym za szycie razem zasobów chmury, pisanie konfiguracji, radzenie sobie z zmiennymi środowiskowymi, zarządzaniem sekretami, przydzielaniem baz danych.

Neptune odwraca ten model. Zamiast zmuszać dewelopera do tłumaczenia swojej aplikacji na infrastrukturę chmury, Neptune rozumie aplikację i generuje infrastrukturę wokół niej. To podejście AI-do DevOps: kod jest planem, a Neptune buduje środowisko potrzebne do jego uruchomienia – w tym zarządzanie sekretami, konfigurację środowiska i orchestrację zasobów.

Kluczem jest to, że AI działa w ramach reguł infrastruktury deterministycznych. Nie może produkować arbitralnych konfiguracji. Wszystko pozostaje podległe przeglądowi i przewidywalne, co jest niezbędne do bezpieczeństwa i kontroli kosztów w środowiskach produkcyjnych.

Spójrzając w przyszłość, jak widzisz ewolucję roli Neptune w ekosystemie, w którym systemy AI coraz bardziej budują, wdrażają i zarządzają innymi systemami oprogramowania?

Poruszamy się w stronę świata, w którym przepaść między pomysłem a działającym produktem jest bliska zeru. Bardzo szybko produkty nie tylko będą budowane szybciej – będą ciągle się poprawiać na podstawie rzeczywistej informacji zwrotnej od tego, jak ludzie je naprawdę używają.

W tym świecie oprogramowanie nie będzie statyczne. Aplikacje, agenci i systemy będą tworzone, modyfikowane i ewoluowały ciągle. Wszystko to nadal potrzebuje gdzieś działać. Nadal potrzebuje infrastruktury, uprawnień, zasobów i niezawodności.

Naszym długoterminowym celem jest stać się domyślnym systemem dla DevOps wspomaganego przez AI – podstawowo Inżynierem Platformy AI. Niezależnie od tego, czy kod jest napisany przez dewelopera w Cursor, czy wygenerowany autonomicznie przez agenta AI, Neptune powinien być warstwą, która zabiera go od kodu do w pełni działającej, skalowalnej usługi produkcyjnej.

Jeśli kreatywność staje się nieograniczona, infrastruktura nie może być ograniczeniem. Gdy agenci AI i auto-ewoluujące produkty staną się normalne, naszym zadaniem jest uczynienie interakcji z infrastrukturą chmury bezproblemową, przewidywalną i bezpieczną. Skupiamy się na tym, aby to uczynić niewidocznym, aby deweloperzy, założyciele i firmy mogli skupić się na tworzeniu wartości zamiast walki z infrastrukturą.

Dziękujemy za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Shuttle.