Cursor kertoo, että sen pilviagentit käynnistyvät jopa kolme kertaa nopeammin. Taustalla on builds-niminen ominaisuus, joka pitää kehitysympäristöstä valmista kopiota taustalla. Yhtiön blogin mukaan ominaisuus kytkeytyy 17. elokuuta päälle oletuksena kaikissa uusissa ja olemassa olevissa ympäristöissä.
Muutos ei koske mallia vaan sen ympäristöä. Pilviagentti on aiemmin joutunut pystyttämään koneen, kloonaamaan repositorion ja ajamaan asennusskriptit ennen ensimmäistäkään hyödyllistä komentoa. Suurissa repositorioissa tuo vaihe on voinut kestää minuutteja.
Mitä builds tarkoittaa
Build on kopio kehitysympäristöstä, jonka Cursor valmistelee taustalla. Oletusasetuksella uusi kopio rakennetaan kerran tunnissa. Kopiossa repositoriot on kloonattu, riippuvuudet asennettu ja asennuskomento ajettu loppuun.
Kun build valmistuu onnistuneesti, siitä tulee ympäristö, josta seuraavat agentit lähtevät liikkeelle. Agentti ei palauta konetta levykuvasta vaan haarauttaa käynnissä olevasta koneesta. Ero näkyy suoraan käynnistysajassa.
Ominaisuus sisältyy Cloud Agents -palveluun ilman lisämaksua. Uudet ympäristöt käyttävät sitä automaattisesti. Vanhoissa ympäristöissä sen on voinut ottaa käyttöön Builds-välilehdeltä, mutta nyt asetus vaihtuu oletukseksi kaikkialla.
Ero aiempaan on käytännössä välimuistin siirtäminen istunnon ulkopuolelle. Aiemmin jokainen istunto maksoi saman asennuskustannuksen uudelleen. Nyt kustannus maksetaan kerran tunnissa riippumatta siitä, montako agenttia ympäristöä käyttää.
Nopeus syntyy valmiiksi lämmitetyistä koneista
Cursorin mukaan agentti vastaa jopa kolme kertaa nopeammin kuin ennen. Yhtiön omissa sisäisissä ympäristöissä käynnistys on kymmenkertaistunut ja ensimmäiseen tokeniin kuluva aika lyhentynyt kolmasosaan.
Luvut ovat yhtiön itse mittaamia eivätkä riippumattomia vertailuja. Ne kuvaavat sitä, kuinka nopeasti agentti alkaa vastata, eivät sitä, kuinka nopeasti se saa tehtävän valmiiksi. Ero on syytä pitää mielessä.
Cursor kertoo ajavansa itse yli 2 000 automaattista agenttiajoa viikossa. Tuolla volyymilla käynnistyksen minuutit muuttuvat nopeasti tunneiksi. Yhtiö mainitsee myös asiakkaita, joilla käynnistysajat ovat pudonneet minuuteista sekunteihin.
Sama ilmiö on tuttu jatkuvan integraation puolelta. Rakennusvaiheen välimuistit ja esiladatut levykuvat ovat vuosia lyhentäneet putkien läpimenoaikoja. Agenttien kohdalla vaikutus on suurempi, koska ajoja käynnistetään tiheämmin ja usein ilman ihmistä.
Rikkinäinen build ei pysäytä agentteja
Kiinnostavin suunnitteluratkaisu koskee virhetilanteita. Jos riippuvuuspäivitys tai konfiguraatiomuutos rikkoo asennuksen, kyseinen build ei koskaan siirry käyttöön. Agentit jatkavat viimeisimmällä toimivalla versiolla.
Kehittäjä saa ilmoituksen ongelmasta. Vika voidaan korjata taustalla joko käsin tai toisen agentin avulla, ja käynnissä olevat istunnot jatkuvat keskeytyksettä.
Ratkaisussa on myös kääntöpuoli. Agentti voi työskennellä koko istunnon ympäristössä, joka on vanhentunut suhteessa siihen haaraan, jota ihminen samaan aikaan korjaa. Vakaus vaihtuu tällöin vanhentumisriskiin.
Cursorin vastaus tähän on säädettävä raja-arvo. Se estää agenttia käynnistymästä liian kaukana oletushaarasta. Lisäksi hallintanäkymä sitoo jokaisen agenttiajon täsmälleen siihen buildiin ja commit-tunnisteeseen, jota se käytti.
Jäljitettävyys on tässä olennainen osa. Kun ajo on sidottu tiettyyn buildiin ja commitiin, vanhentuneella pohjalla tehty työ voidaan tunnistaa jälkikäteen. Ilman tuota kirjausta virheen alkuperää olisi vaikea selvittää.
Mitä kehittäjän kannattaa tarkistaa
Asennuskomento kannattaa käydä läpi. Kaikki, minkä voi valmistella etukäteen, kuten riippuvuudet, kuuluu sinne. Huonosti jäsennelty asennusskripti syö suuren osan nopeushyödystä.
Salaisuudet vaativat oman huomionsa. Jos asennus tarvitsee tunnuksia yksityisiin pakettivarastoihin, ne annetaan tiimin tai ympäristön salaisuuksina. Käyttäjäkohtaiset salaisuudet jäävät buildin ulkopuolelle ja lisätään vasta agentin käynnistyessä.
Käynnistyskomento ajetaan edelleen vasta ensimmäisen kehotteen yhteydessä. Sinne kuuluvat palvelut, joiden pitää olla tuoreita istunnon alkaessa, kuten Docker-kontit ja muut pitkään käynnissä olevat prosessit.
Hallintanäkymässä jokaisella ympäristöllä on oma Builds-välilehti. Sieltä näkee buildin tilan, lokit, commit-tunnisteet ja version. Vanhassa ympäristössä siirtymän voi testata ensin setup-agentilla ja tarkistaa ehdotetut asetusmuutokset.
Suurten repositorioiden kanssa tarkistus kannattaa tehdä ennen kuin oletusasetus vaihtuu. Tunnin välein toistuva rakennussykli koskee kaikkia ympäristöjä repositorion koosta riippumatta. Raskas asennusvaihe näkyy silloin sekä nopeudessa että epäonnistuneiden buildien määrässä.
Yhteenveto
Cursor siirtää pilviagenttien ympäristöt esivalmisteltuihin buildeihin ja ottaa ominaisuuden oletukseksi 17. elokuuta. Käynnistys nopeutuu yhtiön omissa mittauksissa kolminkertaisesti, ja rikkinäinen build jää pois käytöstä ilman että agentit pysähtyvät.
Kilpailuetu on siirtymässä mallin laadusta sen ympärillä olevaan infrastruktuuriin. Ympäristön valmistelu ei ole ominaisuus, jota kehittäjät osaavat pyytää nimeltä. Se kuitenkin ratkaisee, alkaako agentti työn sekunneissa vai minuuteissa.