Agentti ei tarvitse lisää intoa. Se tarvitsee paremman maalin.
OpenAI Codexin uusi /goal-ominaisuus näyttää ensisilmäyksellä pieneltä komentoriviuudistukselta. Todellisuudessa se muuttaa Codexin käyttötapaa: yksittäisen pyynnön sijaan annat agentille pysyvän tavoitteen, jota se voi edistää useiden kierrosten ajan.
Tämä opas näyttää, mitä /goal tekee, miten se otetaan käyttöön ja ennen kaikkea miten sille kirjoitetaan sellainen tavoite, joka ei muutu loputtomaksi säätämiseksi.
Mikä /goal on?
/goal on Codex CLI:n tila pitkäkestoisille tehtäville.
Tavallisessa Codex-keskustelussa annat pyynnön, agentti vastaa, tekee muutoksia tai ajaa komentoja, ja keskustelu jatkuu siitä. /goal toimii eri tavalla. Kun asetat tavoitteen, Codex pitää sen aktiivisena säikeen taustalla. Se voi jatkaa työn suunnittelua, koodin muuttamista, testien ajamista, tuloksen arviointia ja seuraavan askeleen valintaa, kunnes tavoite valmistuu, pysäytetään, poistetaan tai budjetti tulee vastaan.
Yksinkertaisesti:
Tavallinen prompti |
|
|---|---|
Yksi tehtävänanto | Pysyvä tavoite |
Ihminen ohjaa seuraavan askeleen | Codex jatkaa itse, jos tavoite on aktiivinen |
Sopii lyhyisiin pyyntöihin | Sopii monivaiheisiin töihin |
"Korjaa tämä bugi" | "Korjaa bugi, lisää regressiotesti ja todista korjaus ajamalla testit" |
Lopputulos voi jäädä väitteeksi | Lopputulos pitää sitoa todisteisiin |
Hyvä tapa ajatella asiaa on tämä: tavallinen prompti on pyyntö. /goal on eräänlainen työpaketti.
Työpaketilla on tavoite, rajaus, hyväksymiskriteerit ja tarkistustapa. Jos nämä puuttuvat, Codex kyllä tekee asioita, mutta ei välttämättä oikeita asioita. Pitkäkestoisessa agenttityössä ahkeruus ei yksin riitä. Agentti tarvitsee tavan tietää, milloin työ on oikeasti valmis.
Tämä on koko ominaisuuden ydin.
Mitä OpenAI julkaisi?
Codexin /goal tuli julkisesti näkyviin OpenAI Codex CLI:n 0.128.0-julkaisussa 30.4.2026. Julkaisutiedoissa ominaisuutta kuvataan pysyviksi /goal-työnkuluiksi, joissa on app-server API:t, mallille näkyvät työkalut, runtime-jatkaminen sekä TUI-komennot tavoitteen luomiseen, pysäyttämiseen, jatkamiseen ja tyhjentämiseen.
Ominaisuus ei ilmestynyt yhteen tiedostoon. OpenAI rakensi sen Codex-repoon viidessä päävaiheessa, jotka yhdistettiin main-haaraan 25.4.2026:
Pysyvä goal-tila, jotta tavoitteella on säikeessä oma tila.
App-server API, jotta käyttöliittymät voivat lukea ja ohjata tavoitetta.
Mallityökalut, joiden avulla Codex voi tarkistaa tavoitteen ja merkitä sen valmiiksi.
Core runtime, joka päättää milloin työtä jatketaan, milloin budjettia seurataan ja milloin tavoite pysähtyy.
TUI-käyttökokemus, jossa käyttäjä näkee tavoitteen ja voi käyttää slash-komentoja.
Tämä kerrosrakenne on tärkeä. /goal ei ole pelkkä tekstitemppu, jossa promptiin lisätään "jatka kunnes valmis". Codexin sisällä tavoite on oma säikeen (thread) tila. Sillä on elinkaari. Se voi olla aktiivinen, pysäytetty, budjetin rajoittama tai valmis.
Paikallisesti ominaisuus näkyy esimerkiksi näin:
codex --version
codex features list
Kun ominaisuus on käytössä, goals näkyy feature listassa aktiivisena. Jos se ei ole päällä, sen voi ottaa käyttöön:
codex features enable goals
OpenAI:n yleinen Codex CLI -dokumentaatio kuvaa Codexin paikallisena agenttina, joka voi lukea, muokata ja ajaa koodia valitussa hakemistossa. Tätä kirjoittaessa erillinen slash-komentodokumentaatio ei vielä avaa /goal-komentoa yhtä tarkasti kuin julkaisutiedot ja GitHubin PR:t. Siksi kannattaa nojata uusimpaan CLI-versioon ja julkaisutietoihin.
Komennot käytännössä
Peruskäyttö on lyhyt.
/goal <tavoite>
Esimerkiksi:
/goal Korjaa kirjautumisvirhe, lisää regressiotesti ja varmista, että auth-testit menevät läpi.
Nykyisen tavoitteen voi näyttää pelkällä komennolla:
/goal
Jos tavoite pitää keskeyttää:
/goal pause
Jos haluat jatkaa pysäytettyä tavoitetta:
/goal resume
Jos haluat poistaa tavoitteen:
/goal clear
Komentojen helppous on vähän petollista. Itse komento on lyhyt, mutta hyvä tavoite ei yleensä ole. X:ssä moni ensimmäisistä käyttäjistä huomasi saman asian: /goal toimii parhaiten silloin, kun tavoite on kirjoitettu kuin GitHub-issue, testisuunnitelma ja luovutuskriteeri samassa paketissa.
Huono goal:
/goal Tee dashboardista parempi.
Parempi goal:
/goal Rakenna dashboardiin loading-, empty-, error- ja populated-tilat nykyistä design systemiä noudattaen. Säilytä nykyiset API-kutsut. Lisää tai päivitä testit tilojen renderöinnille. Aja frontend-tarkistukset ja tarkista lopuksi desktop- ja mobiilinäkymä. Merkitse tavoite valmiiksi vasta, kun jokaiselle hyväksymiskriteerille on konkreettinen todiste.
Ero on valtava.
Ensimmäinen pyyntö jättää Codexille liian monta auki olevaa kysymystä. Mitä "parempi" tarkoittaa? Saako vaihtaa arkkitehtuuria? Pitääkö tehdä testit? Miten ulkoasu tarkistetaan? Milloin työ loppuu?
Toinen antaa agentille maalin.
Hyvä /goal kertoo mitä pitäisi saada aikaan.
Onnistuneet käyttäjät eivät pyytäneet Codexia "jatkamaan". He määrittelivät, mitä valmis tarkoittaa.
Keskustelu ei ollut vain hypeä, vaikka sitäkin oli. Pääteemat olivat yllättävän käytännöllisiä:
hyväksymiskriteerit ratkaisevat
testit estävät agenttia huijaamasta itseään
pitkä ajo kuluttaa tokeneita
tavoite pitää rajata ennen käynnistystä
agentin pitää tietää, milloin sen pitää pysähtyä kysymään
lopussa pitää tehdä auditointi, ei vain ilmoittaa valmiiksi
Matthew Kalenuik kiteytti asian hyvin kutsumalla hyvää Codex-goalia "completion contractiksi". Suomeksi sanoisin: hyvä /goal on valmiuden sopimus.
Se sisältää ainakin nämä seitsemän osaa:
Osa | Mitä kirjoitat |
|---|---|
Tavoite | Yksi selkeä lopputulos |
Rajaus | Missä tiedostoissa, kansioissa, järjestelmissä tai aiheissa työskennellään |
Tuotokset | Mitä pitää syntyä: koodi, testi, dokumentti, raportti, PR, kuvakaappaus |
Rajoitteet | Mitä ei saa muuttaa, poistaa, asentaa tai julkaista |
Hyväksymiskriteerit | Mistä tiedämme, että työ on valmis |
Tarkistus | Mitä komentoja, testejä tai manuaalisia tarkistuksia pitää ajaa |
Auditointi | Miten Codex raportoi lopuksi todisteet |
Tämä muistuttaa SPDD-ajattelua. Prompti ei ole hetken mielijohde, vaan työbriefi. Mitä pidempään agentin annetaan työskennellä, sitä tärkeämpi briefistä tulee.
Yksi hyödyllinen termi on done_when: milloin tavoite on valmis?
Kirjoita se suoraan.
Done when:
- Kirjautumisbugille on regressiotesti.
- Testi epäonnistuu ennen korjausta tai juurisyy on muuten dokumentoitu.
- Korjaus on tehty pienimpään vastuulliseen moduuliin.
- Auth-testit menevät läpi.
- Lopuksi raportoidaan muutetut tiedostot, testikomennot ja jäljelle jäävät riskit.
Jos done_when puuttuu, agentti tekee helposti jommankumman virheen. Se lopettaa liian aikaisin tai jatkaa liian pitkään.
Molemmat ovat huonoja.
Valmis /goal-pohja
Jos haluat aloittaa nopeasti, käytä tätä runkoa. Se on tarkoituksella vähän pidempi kuin tavallinen prompti, koska pitkäkestoinen agenttiajo tarvitsee enemmän kontekstia.
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
