Matt Shumer kertoo antaneensa Claude Codelle yhden kehotteen ja palanneensa myöhemmin noin 55 000 koodirivin selainpelin luo. Yksi kehote ei kuitenkaan tarkoittanut yhtä mallivastausta. Se käynnisti tuntikausien työn, jossa agentit rakensivat, vertasivat, arvostelivat ja korjasivat peliä kierros toisensa jälkeen.
Shumer nimesi toimintamallin Gauntlet Loopiksi. Se ei ole tutkimuksella todistettu yleismenetelmä eikä taikakehote. Se on käytännön tapa järjestää agenttityö niin, ettei keskinkertainen ensimmäinen versio pääse maaliviivalle vain rakentajan oman vakuuttelun perusteella.
Gauntlet Loop yhdessä virkkeessä: Anna agentille tarkistettava tavoite ja vertailukohta, erota rakentaminen arvioinnista ja korjaa suurinta jäljellä olevaa laatuvajetta, kunnes hyväksymisehto tai pysäytysraja täyttyy.
Tässä oppaassa muutamme Shumerin kokeilun toimintamalliksi, jota voit käyttää Claude Codessa, Codexissa tai muussa agenttisessa työympäristössä. Jos agenttisilmukat ovat uusi aihe, aloita Loop engineering -oppaasta.
Pikalukijan tiivistelmä
Yksi aloituskehote voi johtaa pitkää agenttityötä, mutta se ei poista suunnittelun, arvioinnin tai hyväksynnän tarvetta.
Rakentaja tekee version. Eri kontekstissa toimiva kriitikko tarkastaa varsinaisen artefaktin.
Hyväksymiskriteeri tarvitsee testin ja tallennettavan todisteen.
Rinnakkaista itsenäiset osat. Anna toisiinsa kytkeytyville osille yksi omistaja.
Aika- ja kulukatto pysäyttävät työn keskeneräisenä. Ne eivät muuta keskeneräistä tulosta onnistumiseksi.
Ihminen hyväksyy julkaisut, tuotantomuutokset, rahankäytön ja muut korkean riskin toimet.
Claude of Duty: Kunnianhimoinen koe ja rehellinen epäonnistuminen
Shumerin esimerkkiprojekti on Claude of Duty, jonka lähdekoodi ja paikalliset käynnistysohjeet löytyvät GitHubista. Julkisessa repossa ei ole Shumerin ylläpitämää pelattavaa verkko-osoitetta, joten turvallisin tapa tutkia peliä on ajaa virallinen repo omalla koneella.
Kuvakaappaus paikallisesti ajetusta Claude of Duty -pelistä. Lähde: Matt Shumerin avoin GitHub-repo.
Repon mukaan Claude of Duty on Three.js r180:llä ja WebGL2:lla toteutettu selain-FPS, jossa on 11 alijärjestelmää. Tekstuurit, 3D-geometriat, animaatiot ja äänet syntyvät ohjelmallisesti latauksen aikana. Ulkoisia malleja, HDRI-kuvia, kuva- tai äänitiedostoja ei käytetä.
Tulos on vaikuttava esimerkki pitkän agenttiajon mittakaavasta. Samalla repo kertoo suoraan, ettei peli saavuttanut oikean Call of Dutyn tasoa. Yhdentoista riippumattoman kriitikon raportoimat pisteet etenivät 3,59:stä 4,14:ään, laskivat 4,05:een ja nousivat lopulta 5,05:een asteikolla 0-10. Jokainen kriitikko valitsi jokaisella kierroksella sokkovertailussa oikean Call of Duty -kuvan.
Heikkouksiksi jäivät muun muassa kädet, materiaalit, hahmot, epäsuora valaistus ja ruudunpäivitys. Juuri siksi koe on hyödyllinen. Gauntlet Loop ei taannut täydellisyyttä. Se teki laatuvajeet näkyviksi ja tuotti niitä korjaavan prosessin.
Shumerin ilmaus ”one prompt” kannattaa siis tulkita yhdeksi ihmisen antamaksi aloituspyynnöksi. Julkinen repo ja alkuperäinen kehote eivät yksin todista, ettei pitkän ajon aikana tehty lainkaan käsin tehtyjä väliintuloja. Olennaista on silti nähtävissä: kehotteen tehtävä oli käynnistää kokonainen työnjohto- ja arviointijärjestelmä.
Näin kokeilet peliä
Repo vaatii Node.js:n, npm:n ja WebGL2:ta tukevan selaimen. Kloonaa tai lataa virallinen Claude of Duty -repo, avaa sen kansio terminaalissa ja suorita:
npm install
npm run dev
Vite näyttää paikallisen osoitteen, joka on repon oletusasetuksilla http://127.0.0.1:5173. Pelin suorituskyky riippuu koneesta, selaimesta ja näytönohjaimesta. Repo sisältää myös vakioituja kuvakaappaus-, testi- ja suorituskykytyökaluja. Tämän oppaan viisi pelikuvaa on otettu repon omalla baseline.mjs-työkalulla 1 920 × 1 080 pikselin koossa. Kaappausraportti tallentaa kuvat, koon, asetukset ja virheettömän ajon.
Gauntlet Loop pähkinänkuoressa
Menetelmässä on neljä roolia. Yksi johtaa, toinen rakentaa, kolmas yrittää löytää lopputuloksesta vikoja ja ihminen määrää rajat.
Rooli | Saa nähtäväkseen | Tehtävä | Ei saa tehdä |
|---|---|---|---|
Johtava agentti | tavoite, rajat ja laatukynnys | jakaa ja koordinoi työn | päättää korkean riskin toimista |
Rakentaja | oma osatehtävä ja kriitikon palaute | tuottaa ja korjaa | hyväksyä omaa työtään |
Kriitikko | tavoite, vertailukohta ja oikea tuotos | löytää suurin laatuvaje | arvioida rakentajan selitystä tuotoksen sijasta |
Ihminen | eteneminen, kustannukset ja kokonaisuus | hyväksyä, rajata tai pysäyttää | luovuttaa vastuuta, jota agentti ei voi kantaa |
Kierros etenee näin:
Johtava agentti saa tavoitteen, rajat ja laatukynnyksen.
Se jakaa työn erikseen arvioitaviin osiin.
Rakentaja tuottaa ensimmäisen version.
Tuore kriitikko tarkastaa varsinaisen tuotoksen.
Kriitikko nimeää suurimman jäljellä olevan eron.
Rakentaja korjaa juuri tuota eroa.
Uusi arviointi todentaa, auttoiko korjaus.
Tarvittaessa tuore agentti tarkistaa kokonaisuuden yhtenäisyyden.
Prosessi kuulostaa yksinkertaiselta. Vaikeat kohdat ovat laatukynnyksen määrittely, riippumattoman arvioinnin toteutus ja oikea pysäytyshetki.
Roolit voivat olla eri agentteja tai saman agenttijärjestelmän erillisiä, tuoreita konteksteja. Ratkaisevaa on tiedon rajaus. Kriitikko ei tarvitse rakentajan sisäistä pohdintaa. Se tarvitsee tavoitteen, arviointikriteerit, varsinaisen tuotoksen ja luvan käyttää sovittuja testejä.
Ensimmäinen kierros tuottaa lähtötason. Sen jälkeen jokaisella kierroksella pitää olla yksi näkyvä muutos: löydetty ero, rajattu korjaus ja uusi todiste. Jos kierros ei muuta todisteita tai kriitikon päätöstä, pelkkä agentin työmäärä ei ole edistystä.
Edistys näkyy siis todisteissa, ei käytettyjen tokenien tai agenttien määrässä.
Tavallinen chat ei riitä
Gauntlet Loop tarvitsee ympäristön, jossa agentti pystyy toimimaan. Sen pitää voida lukea ja muuttaa tiedostoja, ajaa testejä, avata sivu tai sovellus, ottaa kuvakaappauksia ja käynnistää erillisiä arvioijia.
Claude Code ja Codex ovat esimerkkejä tällaisista ympäristöistä. Tavallinen chat voi auttaa suunnitelman laatimisessa, mutta se ei pysty tarkastamaan paikallista sovellusta, jos sillä ei ole pääsyä tiedostoihin ja ajettavaan tuotokseen. Shumerin käyttämät komennot, mallit ja ominaisuudet voivat myös olla sidottuja hänen omaan ympäristöönsä.
Tarkista valmius ennen pitkää ajoa:
Agentti pääsee käsiksi varsinaiseen tuotokseen.
Tuotos voidaan ajaa, renderöidä tai muuten tarkastaa.
Rakentajalle ja kriitikolle voidaan antaa eri kontekstit.
Onnistuminen voidaan todistaa muulla kuin agentin omalla väitteellä.
Työlle on aika-, raha- ja oikeusrajat.
Julkaisu, tuotantomuutokset ja ulkoiset viestit vaativat ihmisen hyväksynnän.
Jos tehtävä ratkeaa yhdellä helposti tarkistettavalla vastauksella, pitkä looppi on turha. Käytä Gauntlet Loopia vasta, kun tuotoksessa on useita laatuulottuvuuksia ja korjauskierroksilla on todellista arvoa. Agenttiympäristön perusteet löytyvät Claude Code -oppaasta.
Todiste on vahvempi kuin tilanneraportti
Agenttiajossa toistuu yksi houkutteleva oikotie. Rakentaja kertoo johtavalle agentille työn valmistuneen, ja johtava agentti merkitsee kohdan tehdyksi. Tuossa ketjussa kukaan ei välttämättä katsonut lopputulosta.
Heikko signaali | Vahvempi todiste |
|---|---|
”Sivu näyttää hyvältä” | nimetyt kuvakaappaukset sovituilla leveyksillä |
”Testit menivät läpi” | testikomennon tuloste ja poistumiskoodi |
”Lähteet on tarkistettu” | väite-lähde-taulukko ja toimivat linkit |
”Suorituskyky parani” | sama mittaus ennen ja jälkeen muutoksen |
”Kaikki osat on tehty” | ajettava kokonaisuus ja lopun regressiotesti |
Todisteen pitää vastata väitettä. Kuvakaappaus todistaa ulkoasun yhdessä näkymässä, mutta ei lomakkeen toimintaa. Yksi onnistunut API-pyyntö ei todista kuormankestoa. Lähdeluettelo ei vielä osoita, että jokainen numero perustuu oikeaan lähteeseen. Siksi hyväksymiskriteerin yhteyteen kannattaa kirjoittaa sekä testi että se, mitä testi todella todistaa.
Anna agentille oikea laatukynnys
”Tee tästä erinomainen” ei ole laatukynnys. ”Tee tästä tuotantovalmis” ei ole sekään. Agentti tarvitsee jotain, jonka se voi nähdä, ajaa, mitata tai verrata.
Epämääräinen pyyntö | Tarkastettava laatukynnys |
|---|---|
Tee sivusta moderni | Vertaa nimettyihin viitesivuihin samoilla mobiili- ja työpöytäleveyksillä |
Tee koodista tuotantovalmis | Kaikki testit läpi, sovittu vasteaika alittuu ja palautumistesti onnistuu |
Tee tekstistä selkeä | Jokainen kappale läpäisee sovitun selkeys- ja lähdetarkistuksen |
Tee kampanjasta parempi | Brändisäännöt ja ennalta nimetyt viestikriteerit täyttyvät |
Kuvakaappaus paikallisesti ajetusta Claude of Duty -pelistä. Materiaalien lähikuva näyttää, miksi ”näyttää hyvältä” on liian epätarkka arviointiohje. Lähde: Matt Shumerin avoin GitHub-repo.
Hyvä kynnys ei määrää toteutusta tarpeettoman tarkasti. Se kuvaa hyväksyttävän lopputilan ja todisteen.
Verkkosivulla todiste voi olla sarja kuvakaappauksia, saavutettavuustesti ja suorituskykymittaus. Backendissä se voi olla testiraportti, kuormitustesti ja palautuminen virheestä. Artikkelissa todisteita ovat valmis teksti, väitekohtainen lähdetarkistus ja vertailu hyväksyttyihin malliteksteihin. Tutkimuksessa tarvitaan lähdehierarkia sekä näkyvä käsittely lähteiden välisille ristiriidoille.
Korkean riman saa asettaa. Claude of Dutyssa vertailukohteena oli maailmanluokan kaupallinen peli, vaikka yhden agenttiajon mahdollisuudet olivat kaukana siitä. Vertailukohta antoi suunnan ja paljasti puutteet. Se ei muuttunut laatutakuuksi.
Jaa työ osiin, mutta pidä kytkeytynyt työ yhdessä
Johtavan agentin kannattaa etsiä pienimmät osat, joita voi parantaa ja arvioida erikseen. Pelissä niitä ovat esimerkiksi ase, kädet, liike, viholliset, materiaalit, valaistus, äänet ja käyttöliittymä. Verkkosivulla vastaavia osia ovat navigaatio, hero, typografia, mobiilinäkymä, lomake ja suorituskyky.
Kuvakaappaus paikallisesti ajetusta Claude of Duty -pelistä. Ase ja kädet ovat rajattava alijärjestelmä, mutta niiden valaistus kytkeytyy koko näkymän renderöintiin. Lähde: Matt Shumerin avoin GitHub-repo.
Rinnakkaisuus ei ole itseisarvo. Claude of Dutyn README kertoo, että laaja rinnakkainen työ renderöinnin ja valaistuksen parissa rikkoi toisiinsa kytkeytyviä oletuksia. Kolme kuuden agentin rinnakkaiskierrosta paransivat pisteitä yhteensä 0,46, mutta vakavien vikojen määrä päätyi 66:een. Yksi peräkkäinen kierros, jossa kullakin kytkeytyvällä kokonaisuudella oli yksi omistaja, paransi pisteitä 1,00 ja vähensi viat 66:sta 26:een.
Käytä tätä päätöspuuta:
Voiko osan onnistumisen arvioida ilman muiden osien muuttamista?
|
+ Kyllä: oma rakentaja ja kriitikko, tarvittaessa rinnakkain
|
+ Ei: vaikuttaako muutos yhteen kytkeytyneeseen kokonaisuuteen?
|
+ Kyllä: yksi omistaja ja työ peräkkäin
|
+ Ei tai vaikutus on laaja: koko tuotteen tasoituskierros
Sääntö on helppo muistaa: itsenäiset osat rinnakkain, kytkeytyneet osat peräkkäin. Aja jokaisen suuren työaallon jälkeen vielä kokonaisuuden tarkistus. Claude Code Dynamic Workflows -opas auttaa rakentamaan työnjaon käytännössä.
AI-rakentaja ei hyväksy omaa työtään
AI-subagentti tietää, mitä se yritti tehdä. Tuo tieto on hyödyllistä toteutuksessa ja haitallista arvioinnissa. Sama agentti saattaa selittää puutteen parhain päin, koska se muistaa oman perustelunsa.
Tuore kriitikko saa vain arvioinnin kannalta tarpeelliset asiat:
alkuperäisen tavoitteen
tarkan laatukynnyksen
arvioitavan valmiin artefaktin
tarvittavat testit tai vertailukuvat
tiedon siitä, mitä ei saa muuttaa
ei rakentajan keskusteluhistoriaa tai puolustusta
Kuvakaappaus paikallisesti ajetusta Claude of Duty -pelistä. Taistelutilanne paljastaa liikkeen, viholliset, efektit ja käyttöliittymän paremmin kuin siisti pysäytyskuva tyhjästä kentästä. Lähde: Matt Shumerin avoin GitHub-repo.
Kriitikon pitää käyttää tuotosta normaalissa tilanteessa. Verkkosivua selataan myös puhelimen leveydellä. Peliä pelataan taistelussa. Koodia ajetaan testeillä. Artikkelista tarkistetaan väitteet lähteistä. Rakentajan lause ”testit menevät läpi” ei korvaa varsinaista testitulosta.
Hyvä kriitikko ei tuota kymmenien toiveiden sekalaista listaa. Se nimeää suurimman merkityksellisen eron, näyttää todisteen ja muotoilee seuraavalle kierrokselle rajatun korjaustavoitteen. Rakentaja saa korjata juuri sen. Näin työ etenee mitattavina askelina.
Jatka kierroksia, mutta sovi pysäytysrajat
Kiinteä kolmen kierroksen raja voi pysäyttää työn juuri ennen hyödyllistä parannusta. Rajaton ajo taas voi kuluttaa aikaa ja rahaa ilman vastaavaa laatuhyötyä.
Sovi pysäytysehdot ennen aloitusta:
Pysäytyssignaali | Toimenpide |
|---|---|
Laatuvaatimus täyttyy todisteella | luovuta ihmiselle hyväksyttäväksi |
Sama puute toistuu ilman olennaista edistystä | vaihda lähestymistapaa tai rajaa ongelmaa |
Aika- tai kulukatto täyttyy | pysäytä ja raportoi paras versio keskeneräisenä |
Kriitikot ovat keskenään ristiriidassa | pyydä ihmisen ratkaisu |
Tarvitaan julkaisu-, tuotanto- tai asiakastoimi | pysähdy hyväksyntäportille |
Osat ovat hyviä, mutta kokonaisuus on epäyhtenäinen | aja tasoituskierros |
Korkean riskin toimi ei muutu turvalliseksi sillä, että toinen agentti tarkastaa ensimmäisen. Maksullinen hankinta, asiakasviesti, julkaisu, tuotantomuutos ja oikeuksien laajennus kuuluvat hyväksyntäportin taakse.
Pidä ajon rinnalla yksinkertainen workbench.md tai muu edistymiskortti. Kirjaa siihen kierros, arvioitu osa, kriitikon päätös, havaittu ero, todiste ja seuraava tehtävä. Näet kehityksen keskeyttämättä agenttia jatkuvasti.
Budjettiraja käytännössä: Voit sopia esimerkiksi kahden tunnin aikarajan ja 20 euron kulukaton. Kun jompikumpi täyttyy, johtava agentti lopettaa uusien työvaiheiden käynnistämisen, tallentaa nykyisen version ja raportoi puuttuvat kriteerit. Tila on silloin KESKEN. Tämä pieni sanavalinta estää järjestelmää tulkitsemasta budjetin loppumista laatutodisteeksi.
Goal-opas auttaa määrittämään todistettavan lopputilan. Kun AI-agentti mokaa puolestaan auttaa suunnittelemaan virhetilanteet ja rajat.
Rakenna oma Gauntlet Loop
Käynnistä ensimmäinen kokeilu näin:
Valitse yksi oikea artefakti, kuten sovellus, sivu, raportti tai artikkeli.
Kirjoita tavoiteltava lopputila yhdellä virkkeellä.
Muuta laatu tarkastettaviksi hyväksymiskriteereiksi.
Rajaa tiedostot, oikeudet, aika, kulut ja kielletyt toimet.
Anna johtavan agentin ehdottaa työnjako ja riippuvuudet.
Käynnistä erilliset rakentaja- ja kriitikkokontekstit.
Tallenna jokaisen kierroksen todiste ja suurin laatuvaje.
Anna yksi omistaja osille, jotka vaikuttavat vahvasti toisiinsa.
Aja tarvittaessa kokonaisuuden tasoituskierros ja regressiotestit.
Luovuta tuotos ihmiselle. Agentti ei julkaise tai siirrä sitä tuotantoon omin päin.
Kuvakaappaus paikallisesti ajetusta Claude of Duty -pelistä. Kokonainen HUD näyttää, kohtaavatko yksittäin rakennetut osat samassa käyttötilanteessa. Lähde: Matt Shumerin avoin GitHub-repo.
Kopioi edistymiskortiksi tämä taulukko:
Kierros | Osa | Kriitikon päätös | Suurin ero | Todiste | Seuraava tehtävä |
|---|---|---|---|---|---|
1 | mobiilin hero | hylätty | otsikko peittää toimintopainikkeen | 390 pikselin kuvakaappaus | korjaa otsikon skaalaus |
2 | mobiilin hero | hyväksytty | ei pakollista eroa | uusi kuva ja selaintesti | siirry navigaatioon |
Älä täytä korttia rakentajan omalla selityksellä. Lisää siihen tiedosto, kuvakaappaus, testituloste tai muu tarkastettava todiste.
Aloita ensimmäinen kokeilu yhdestä rajatusta kokonaisuudesta. Hyvä pilotti on esimerkiksi yhden laskeutumissivun mobiilihero, yhden raportin lähdepeitto tai yhden rajapinnan virheenkäsittely. Näet nopeasti, pystyykö kriitikko todella havaitsemaan eroja ja tuottaako seuraava kierros paremman todisteen. Laajenna koko tuotteeseen vasta sitten.
Missä Gauntlet Loop toimii ja missä se on liikaa
Menetelmä sopii tehtävään, jossa laatua voi tarkastaa ja jossa uusi kierros voi aidosti parantaa tulosta.
Käyttötapaus | Mahdollinen laatukynnys | Todiste |
|---|---|---|
Verkkosivu | nimetyt viitesivut ja design-järjestelmä | mobiili- ja työpöytäkuvat, saavutettavuustesti |
Backend | testit, vasteaika ja palautuminen | testiraportti ja kuormitusmittaus |
Artikkeli | mallitekstit, lähdepeitto ja selkeys | valmis teksti ja väite-lähde-taulukko |
Tutkimus | hyväksytty lähdehierarkia | lähdeluettelo ja ristiriitojen käsittely |
Markkinointi | brändisäännöt ja ennalta sovittu arviointikehikko | luonnokset, jotka ihminen hyväksyy ennen julkaisua |
Valitse kevyempi tapa, kun tehtävä on triviaali, järkevää laatukriteeriä ei löydy tai tarkistus maksaa enemmän kuin virhe. Moniagenttinen hajautuskin on väärä ratkaisu, jos lähes kaikki osat riippuvat toisistaan.
Kokeile yhden minuutin testiä:
Voiko agentti nähdä tai mitata valmiin tuotoksen?
Voiko yksi rajattu korjaus tehdä siitä selvästi paremman?
Onko lisälaadulla enemmän arvoa kuin arviointikierroksen kustannuksella?
Voiko ihminen säilyttää korkean riskin päätökset itsellään?
Jos vastaat kaikkiin kyllä, Gauntlet Loop on kokeilemisen arvoinen. Jos haluat parantaa yksittäisen tuotoksen sijasta pysyvää agenttiohjetta, sovella samaa arviointimallia myös siihen.
Shumerin meta-kehote: Rakenna tehtäväkohtainen Gauntlet-kehote
Jos tehtäväsi laatukynnys on vielä epäselvä, aloita tästä. Meta-kehote valitsee tavoitteelle tarkastettavan vertailukohdan ja kirjoittaa sen pohjalta lyhyen Gauntlet-kehotteen Claude Codeen tai Codexiin.
Korvaa [GOAL] yhdellä konkreettisella tavoitteella ja valmiilla artefaktilla. Lisää [OPTIONAL REFERENCES]-kohtaan esimerkiksi tiedostoja, määrittelyjä, linkkejä, kuvakaappauksia, mallitekstejä tai mittareita, joihin agentti voi verrata työtään. Jos vertailukohtia ei ole, jätä kohta tyhjäksi.
Tässä kehote:
Tilaa AI-Sanomien Plus-jäsenyys niin näet loput sisällöstä
Tilaamalla AI-Sanomien maksullisen jäsenyyden saat pääsyn kaikkiin uutiskirjeen sisältöihin sekä tuet Suomen parasta AI-mediaa.
Tilaa jäsenyys tästä! Voit lopettaa koska tahansa.Miksi tilaus kannattaa?:
- Näet kaikki uutiskirjeen sisällöt, uudet AI-työkalut sekä vinkit tekoälyn käyttöön.
- Pääsy kaikkiin verkkokursseihin kurssit.aisanomat.fi-alustassa
- Pääsy Kehotesuunnittelija.fi Premium-tasoon (15 €/kk)
- Pääsy satoihin maksullisiin sisältöihin, oppaisiin ja artikkeleihin
