Nodar Daneliya, Shuttle:n toimitusjohtaja ja perustaja – Haastattelusarja

Nodar Daneliya, Shuttle:n toimitusjohtaja ja perustaja – Haastattelusarja: Nodar Daneliya on toiminut Shuttle:n perustajana ja toimitusjohtajana vuodesta 2019, jolloin hän perusti yhtiön. Hän on johtanut yhtiön kasvua varhaisesta YC Summer 2020 -start-upista kehitystyökaluihin erikoistuneeksi yhtiöksi; ennen Shuttle:a hän työskenteli muun muassa Provenance Technologies Ltd:ssä, jossa hän työskenteli kvantitatiivisissa hedge-rahastojen strategioissa, ja aiemmin teknisissä ja tietotyössä Lontoossa ja Googlella.

Shuttle on avoimen lähdekoodin pilvi-infrastruktuurin alusta, joka yksinkertaa taustajärjestelmien kehittämistä ja käyttöönottoa johtamalla infrastruktuuria koodin annotaatioista, jotta kehittäjät voivat keskittyä Rust- tai muiden kielten kirjoittamiseen ilman erillisten konfiguraatiotiedostojen tai monimutkaisten pilvi-asetusten hallintaa; alusta mahdollistaa nopean käyttöönoton, valmiin resurssien varauksen ja vaivattoman skaalauksen, ja sitä käytetään kymmenien tuhansien insinöörien parissa yli 130 000 käyttöönotossa, ja sen tavoitteena on laajentaa sen nollakonfiguraation, tekoälyavusteisen kokemusta kaikkiin kielisiin ja integroida työkaluihin kuten GitHub Copilot ja Cursor.

Mikä hetki tai frustraatio lopulta ajoi sinut perustamaan Shuttle:n, ja mikä ongelma yritit ratkaista alusta?

Ratkaiseva hetki tuli aikana, jolloin johtaminen kvantitatiivisessa hedge-rahastossa. Meillä oli poikkeukselliset insinöörit – tohtorit, senioripalvelut, ML-tutkijat – mutta jopa kyseisen kyvyyn kanssa pilvi-infrastruktuuri oli jatkuvasti pullonkaula. Rakentaa kaupankäyntimalli tai taustapalvelu ei ollut vaikea osa. Ongelma oli käyttöönotto: saada se turvallisesti toimimaan, skaalata sitä, liittää pilvipalvelut yhteen. Siinä kaikki hidastui. Eräässä vaiheessa yli puolet meidän insinööritiimistä teki DevOps-työtä vain järjestelmien ylläpitämiseksi.

Se, mikä jäi minulle, ei ollut koodin monimutkaisuus tai matematiikka. Se oli katsella erittäin kykeneviä ihmisiä polttaa suurimman osan ajastaan taistellessaan pilviä vastaan sen sijaan, että he rakentaisivat sitä, mikä todella merkitsee. Kukaan ei halunnut tehdä sitä työtä, mutta se oli välttämätöntä. Se kitka – kuilu “Rakensin jotain” ja “se toimii luotettavasti” – on se, minkä Shuttle on luotu ratkaisemaan.

Shuttle perustettiin vuonna 2019, ennen nykyistä aaltoaan tekoälytyökaluja. Miten alkuperäinen visiosi on kehittynyt, kun tekoälyavusteinen kehitys on tullut valtavirtaan?

Ydinongelma säilyi samana, mutta tekoäly teki siitä dramaattisesti suuremman. Kun aloimme, infrastruktuuri oli jo rajoittava tekijä vahvoille insinööritiimeille. Kun työkalut kuten Copilot, Cursor ja Claude ilmestyivät, se pullonkaula tuli mahdottomaksi ignoreerata.

Äkkiä kehittäjät voivat luoda täydellisiä sovelluksia muutamassa minuutissa, mutta ne sovellukset osuivat välittömästi esteeseen. Tekoäly voi kirjoittaa koodia, mutta se ei voi luotettavasti konfiguroida ja hallita pilviresursseja. Kuilu, jonka ratkaisemiseen pyrimme, tuli paljon laajemmaksi ja paljon kiireemmäksi. Miljoonat ihmiset rakentavat nyt taustapalveluja, mutta vain murto-osa saa ne tuotantoon.

Visio kehittyi “tehdä infrastruktuuri helpommaksi kehittäjille” “tehdä infrastruktuuri toimivaksi täysin uuden sukupolven rakentajille” – yksinäisille perustajille, pienille tiimeille ja tekoälyagenteille, jotka voivat luoda taustakoodin, mutta eivät ole kiinnostuneita kamppailemaan pilvi-asetusten kanssa. Emme enää palvele vain perinteisiä insinöörejä. Kohderyhmä on räjähtänyt.

Tehtävätyökalut kuten Cursor ja GitHub Copilot ovat muuttaneet, miten kehittäjät kirjoittavat koodia. Miten näet, mitkä osat ohjelmistokehityksen elinkaarta ovat parantuneet eniten, ja missä tiimit edelleen kamppailevat?

Koodin generointi on loikannut eteenpäin. Se osa on melkein ratkaistu. Voit kuvata ominaisuuden, ja tekoäly rakentaa sen. Etuovassa etenkin on hyödyntänyt tämän, koska mallit ovat hyvin ymmärretty – komponentit, tyylit, layoutit.

Missä tiimit edelleen kamppailevat, on kaikki se, mikä tulee koodin jälkeen: käyttöönotto, infrastruktuuri, toiminnanohjaus. Tekoäly saattaa generoida API-päätepisteen, mutta se ei voi automaattisesti luoda tietokantaa, tallennustilaa, jonot, verkkotietoja, oikeuksia tai käyttöönottoputkea, joka tekee sen toimivaksi. Taustainfrastruktuuri ei ole kestänyt koodin generoinnin tahdissa.

Käyttöönotto on usein kuvattu suurimmaksi pullonkaulaksi tekoälygeneroituille sovelluksille. Mitä tarkalleen ottaen tekee tuotannon sovellusten järjestelmistä haastavampia verrattuna itse koodin generointiin?

Ongelma on luotettavuus ja seuraukset. Koodin generointi on anteeksiantavaa – jos tekoäly tekee virheen, näet sen välittömästi ja korjaat sen. Infrastruktuurivirheet ovat erilaisia. Yksi väärä oikeus, yksi väärä resurssin konfiguraatio, yksi huonosti arvioitu kustannus- tai turvallisuusoletus, ja olet luonut todellisen ongelman, joka saattaa tulla ilmi myöhemmin.

Aluksi yritimme antaa tekoälylle vapaasti johtaa infrastruktuuria sovelluskoodista. Se näytti hyvältä demoissa. Todellisissa järjestelmissä se hajosi. Tekoäly tuotti luotettavasti asetukset, jotka olivat melkein oikein, mutta ei aivan – oikeudet liian laajat, outo resurssivalinta, konfiguraatiot, jotka tulisivat hiljalleen kalliiksi.

Se opetti meille jotain kriittistä: tuotannossa äly ilman rajoja luo ongelmia. Tekoäly ei tarvitse enempää vapautta. Se tarvitsee parempia rajoja. On suunniteltava järjestelmiä, joissa tekoäly voi ehdottaa ja kiihdyttää, mutta ei voi juosta villiin. Se on tekninen haaste, joka tekee tekoälygeneroituja sovellusten tuotannon paljon haastavammaksi kuin koodin generointi.

Shuttle esitteli äskettäin Neptunuksen seuraavana askelena alustansa kehityksessä. Neptune on kuvattu universaalina tekoälyalustana – mitä se tarkoittaa käytännössä kehittäjille, jotka siirtyvät prototyyppiin valmiiseen taustajärjestelmään?

Neptune toimii puuttuvana kerroksena koodin ja tuotannon välillä. Käytännössä se tarkoittaa, että kehittäjät – tai tekoälyagentit – voivat keskittyä sovelluslogiikan kirjoittamiseen, ja Neptune hoitaa kaiken muun: ymmärtää, mitä infrastruktuuria tarvitaan, varaa resursseja, hallitsee salaisuuksia, käsittelee käyttöönottoa, orkesteroi palveluita.

Sen sijaan, että kehittäjien pitäisi kääntää sovellustaan pilvi-infrastruktuuriin, Neptune ymmärtää sovelluksen ja luo infrastruktuurin sen ympärille. Se on tekoälyomaisen lähestymistapan DevOpsiin: koodi on suunnitelma, ja Neptune rakentaa ympäristön, jossa se toimii – ilman Docker-tiedostoja, Terraformia, äärettömän konfiguraation ja pilvi-asetusten säätämistä.

Kun kehittäjät luottavat yhä enemmän tekoälyyn taustajärjestelmien luomiseen, miten tasapainotat nopeuden ja abstraktion tarpeen hallinnan, turvallisuuden ja havainnollisuuden kanssa?

Luottamus on vastaus. Infrastruktuurissa luottamus on tärkeämpää kuin kyky. Yksi paha yllätys – turvallisuusreikä, rikkinäinen käyttöönotto, valtava pilvilasku – ja olet menettänyt ihmiset.

Olemme oppineet varhain, että kaikki, mihin tekoäly koskee, on ymmärrettävä ja tarkasteltavissa. Vaikka kehittäjä ei olisi konfiguroinut jotain käsin, heidän on edelleen nähtävä, mitä tapahtuu ja miksi. Siksi Neptune käyttää deterministisiä infrastruktuurisääntöjä. Tekoäly voi ehdottaa ja kiihdyttää, mutta kaikki, mitä se tekee, perustuu spesifikaatioihin, jotka ovat tarkasteltavissa, ennustettavissa ja testattavissa.

Mitä tyypin tiimejä näkee vahvimman arvon Neptunuksesta tällä hetkellä, olivat he sitten yksinäisiä kehittäjiä, start-upeja tai suurempia insinööritiimejä?

Profiili on muuttunut dramaattisesti. Alun perin Rust-puolella meillä oli monipuolinen tukkula – yksittäisiä kehittäjiä, varhaisia start-upeja, kasvuyrityksiä, jopa suuria yrityksiä, joissa luotettavuus ja suorituskyky ovat tärkeitä, kuten autoteollisuudessa, IoT:ssä, rahoituksessa, kryptossa, missä tahansa. Nämä tiimit halusivat Rustin voiman ilman monimutkaisen pilvi-infrastruktuurin hallintaa.

Mutta viimeisen vuoden aikana tekoälyohjattu kehitys on muuttanut täysin sen, ketkä rakentavat ohjelmistoa. Nyt näemme yksinäisiä perustajia, indie-kehittäjiä, tekoälyagenteja, pieniä tiimejä ja perinteisiä ohjelmistoyrityksiä, jotka generoivat taustakoodia ennennäkemättömällä nopeudella. Kohderyhmä ei ole enää vain seniori-insinöörejä erikoistuneilla aloilla.

Näemme säännöllisesti yksinäisiä perustajia ja pieniä tiimejä, jotka siirtyvät ideasta käyttöönotettuun taustajärjestelmään yhden istunnon aikana, koska he eivät tarvitse viettää päiviä asetuksien parissa. Se ei ole vain ajan säästö – se on vauhdin säilyttäminen, mikä on kaikkea alussa. Siinä on vahvin arvo: ihmisissä, jotka voivat rakentaa, mutta eivät halua tulla infrastruktuurin asiantuntijoiksi vain saadakseen ideansa toimimaan.

Teknisesti, miten Neptune käsittelee ympäristön konfiguraation, salaisuuksien hallinnan ja infrastruktuurin orkestraation, kun se muuttaa tekoälygeneroituja koodia käyttöönotettavaksi tuotantotaustajärjestelmäksi?

Neptune käsittää koodin ja infrastruktuurin yhtenäisenä järjestelmänä. Useimmat käyttöönotto-työkalut toimivat kuin toimituspalvelu – tuotat heille konteynерин, ja he yrittävät ajaa sen. Se jättää sinun edelleen vastuussa pilviresurssien ompelemisesta, konfiguraation kirjoittamisesta, ympäristömuuttujien käsittelystä, salaisuuksien hallinnasta, tietokantojen varauksesta.

Neptune kääntää tämän mallin. Sen sijaan, että kehittäjien pitäisi kääntää sovelluksensa pilvi-infrastruktuuriin, Neptune ymmärtää sovelluksen ja luo infrastruktuurin sen ympärille. Se on tekoälyomaisen lähestymistapan DevOpsiin: koodi on suunnitelma, ja Neptune rakentaa ympäristön, jossa se toimii – mukaan lukien salaisuuksien hallinta, ympäristön konfiguraatio ja resurssien orkestraatio.

Miten näet Neptunuksen roolin kehittyvän ekosysteemissä, jossa tekoälyjärjestelmät yhä enemmän rakentavat, käyttöönottoavat ja hallinnoivat muita ohjelmistojärjestelmiä?

Liikumme kohti maailmaa, jossa kuilu idean ja toimivan tuotteen välillä on lähes nolla. Hyvin pian tuotteet eivät vain rakenneta nopeammin – ne jatkuvasti paranevat itseään perustuen siihen, miten ihmiset todella käyttävät niitä.

Tässä maailmassa ohjelmisto ei ole staattista. Sovellukset, agentit ja järjestelmät luodaan, muokataan ja kehitetään jatkuvasti. Kaikkea tätä tarvitaan edelleen ajettavaksi. Se tarvitsee edelleen infrastruktuuria, oikeuksia, resursseja ja luotettavuutta.

Pitkän aikavälin tavoitteemme on tulla oletusjärjestelmäksi tekoälyavusteiseen DevOpsiin – käytännössä tekoälyalustan insinööriksi. Riippumatta siitä, onko koodi kirjoitettu kehittäjän toimesta Cursorissa tai generoitu autonomisesti tekoälyagentilla, Neptune pitäisi olla kerros, joka ottaa sen koodista täysin toimivaksi, skaalautuvaksi, tuotantovalmiiksi palveluksi.

Jos luovuus tulee rajattomaksi, infrastruktuuri ei voi olla rajoitus. Kun tekoälyagentit ja itsekehittyvät tuotteet tulevat normaaleiksi, tehtävämme on tehdä vuorovaikutus pilvi-infrastruktuurin kanssa vaivattomaksi, ennustettavaksi ja turvalliseksi. Pyrimme tekemään sen näkymättömäksi, jotta kehittäjät, perustajat ja yritykset voivat keskittyä arvon luomiseen sen sijaan, että he taistelisivat infrastruktuurin kanssa.

Kiitos hienosta haastattelusta, lukijat, jotka haluavat oppia lisää, voivat vierailla Shuttle:ssa.