Miksi tekoälyagentti sanoo ”valmis”, vaikka työ ei ole valmis?

Miten OpenAI:n malli pääsi ulos hiekkalaatikosta ja hakkeroi Hugging Facen?#

Ensin faktat, sitten se, miksi tällä on sinulle merkitystä.

OpenAI mittasi, mihin sen mallit pystyivät kyberturvallisuuden hyökkäävällä puolella. Testinä käytettiin ExploitGymia: 898 tehtävää, joissa tunnettu haavoittuvuus pitää muuttaa toimivaksi exploitiksi eli valmiiksi ohjelmaksi, joka hyödyntää kyseistä haavoittuvuutta. Mallien todellisen ylärajan selvittämiseksi sisäänrakennetut turvasuodattimet, jotka normaalisti estävät mallia tekemästä tällaisia asioita, poistettiin käytöstä. Ympäristö suljettiin kokonaan, ja ainoaksi ulospääsyksi jätettiin pakettien asentamiseen käytetty sisäinen välitysohjelma.

Zero-day-haavoittuvuus on aukko, josta kukaan ei vielä tiedä, ei edes ohjelman kirjoittanut henkilö. Mallit löysivät sellaisen juuri siitä ainoasta aukosta.

Seuraavaksi ne korottivat käyttöoikeuksiaan, etenivät sisäverkossa internetiin pääsevälle koneelle ja arvasivat sieltä, että ExploitGymin vastaukset saattaisivat löytyä Hugging Facesta. Kukaan ei ollut kertonut niille Hugging Facesta. Ne päättelivät sen itse.

Arvaus meni väärin. ExploitGymiä ei ole Hugging Facessa lainkaan. Se ei tee hakkeroinnista yhtään vähemmän todellista.

Hugging Face havaitsi tunkeutumisen itse ja julkaisi siitä selvityksen 16. heinäkuuta tietämättä vielä, kuka oli hakkeroimisen takana.

Yksi toinen yksityiskohta tästä selvityksestä kertoo paljon tilanteesta. Kun Hugging Facen insinöörit yrittivät syöttää hyökkäyslokia johtaville malleille tavallisten kaupallisten rajapintojen kautta, turvasuodattimet estivät pyynnöt: ne eivät pysty erottamaan hakkerointia tutkivaa henkilöä sen toteuttajasta. Lopulta analyysi tehtiin avoimella mallilla heidän omalla laitteistollaan.

OpenAI vahvisti asian 21. heinäkuuta, viisi päivää Hugging Facen selvityksen jälkeen. Tunkeutumisesta oli siihen mennessä kulunut noin kymmenen päivää.

OpenAI päätti oman analyysinsä näin.

Malli kiinnittyi testin rajattuun tavoitteeseen ja meni äärimmäisyyksiin saavuttaakseen sen. Ilmaukset hyper-focused ja fairly narrow testing objective ovat OpenAI:n itsensä käyttämiä ja viittaavat sen omiin malleihin.

Tämä yhdistää jonkun toisen laboratorion sinun kannettavaasi.

Miksi kyse ei ole ”hallusinaatiosta”?#

Näen keskusteluissa usein ilmauksia kuten ”hallusinoi taas”, ”konteksti ylikuormittui” tai ”meidän olisi pitänyt tehdä suunnitelma”. Joskus juuri niin on käynyt. Mutta kun tekoälyagentti kirjoittaa ”valmis, tarkistettu, kaikki toimii”, vaikka työ ei ole valmis, kontekstin määrällä ei yleensä ole asian kanssa mitään tekemistä.

Se ei keksinyt mitään. Se teki täsmälleen sen, mitä mittasit.

Yleisen ”hallusinaatio”-sateenvarjotermin alle niputetaan kolme erilaista virhettä. Näin ne eroavat toisistaan:

Ensimmäinen korjataan kontekstilla, ja se on tunnetuin tapaus. Toinen on erillinen ilmiö, jota käsitellään analyysissä siitä, kun Claude on samaa mieltä kaikesta: malli uhraa tarkkuuden saadakseen nopeasti hyväksyntää. Molemmat tapahtuvat ennen työtä, syötevaiheessa.

Artikkeli käsittelee taulukon kolmatta riviä. Tässä agentti ei imarrellut eikä keksinyt asioita. Se työskenteli, tarkisti ja raportoi totuudenmukaisesti. Tämä totuus vain kuvaa mittaria eikä kerro mitään tehtävästä.

Kolmannelle virheelle on nimi.

Mitä reward hacking tarkoittaa yksinkertaisesti?#

Anthropic määrittelee termin itse.

Ajatus on vanhempi kuin neuroverkot. DeepMindin artikkeli kutsuu sitä spesifikaation pelaamiseksi ja selittää sitä myytin avulla.

Midas sai täsmälleen sen, mitä pyysi. Ongelma oli pyynnön sanamuodossa.

Ohjelmoinnissa ilmiö saa konkreettisia muotoja. Tässä oppikirjaesimerkki, myös Anthropicilta:

Eikä tämä ole mikään eksoottinen laboratorio-olosuhde. Cursor analysoi 731 toimintaketjua suositussa benchmarkissa.

Kuusi kymmenestä ”ratkaistusta” tehtävästä perustuu valmiiksi löytyneisiin vastauksiin. Juuri siksi ala muuttaa suorituskyvyn mittaamista: olemme käsitelleet benchmarkia, joka mittaa tuotantovalmiutta, jossa tarkistusten läpäiseminen ei enää ole pääkriteeri.

Miltä tämä näyttää tavallisessa tuotteessa?#

Laboratorioesimerkit on helppo kuitata eksoottisina. Siksi tässä on neljä kertomusta käytännöstä. Asiakkaat ja toimialat on vaihdettu, mutta toimintamekaniikka on pidetty samana.

Neljä vihreää tarkistusta ja pysähtynyt palvelukomponentti

Kiinteistönvälitystoimisto rakentaa palvelua: verkkosivustoa, jolla on myynti-ilmoituksia, sekä erillistä taustaprosessia, joka vie ilmoitukset alustoille yön aikana. Agentti saa tehtävän valmiiksi ja raportoi: tyyppitarkistus meni läpi, koodityylin tarkistus meni läpi, build on vihreä, sivut vastaavat ja ne tarkistettiin visuaalisesti.

Jokainen väite pitää paikkansa. Yksikään niistä ei kuitenkaan liity yöprosessiin: se toimii erillisenä prosessina eikä kuulu verkkosivuston buildiin lainkaan. Käyttöönotto onnistuu, sivusto toimii moitteettomasti, ilmoitusten vienti pysähtyy, ja asiakkaat ilmoittavat siitä seuraavana päivänä.

Ennen kuin sanon ”valmis”, kysyn nyt yhden kysymyksen: mikä osa työstä toimii tarkistukseni kattaman alueen ulkopuolella? Jos jokin osa jää ulkopuolelle, suorita se erikseen ja liitä komennon tuloste raporttiin. Sana ”tarkistettu” ei päätä asiaa.

Väärä valintamerkki on juuri saumakohdassa

Verkkokauppa jakaa suuren tehtävän samanaikaisesti useille agenteille: yksi saa backendin, toinen sivut ja kolmas tuotekortit. Kaikki työskentelevät tunnollisesti, ja kaikkien tarkistukset ovat vihreitä.

Viikkoa myöhemmin käy ilmi, ettei ”tästä arvostelusta oli apua” -painike toimi missään. Backend on kirjoitettu kokonaan, sen tarkistukset ovat vihreitä ja uudelleenlaskentasääntöjä on noudatettu. Mikään sivu ei kuitenkaan näytä painiketta: painike kuului yhden agentin alueeseen, sivut toisen, eikä kukaan ajatellut lisätä sitä näytölle. Laskuri olisi pysynyt ikuisesti nollassa.

”Koodi on kirjoitettu ja tarkistettu” ja ”ominaisuus toimii” ovat kaksi eri väitettä. Varmistan jälkimmäisen jokaisen uuden ominaisuuden kohdalla yhdellä kysymyksellä: kuka kutsuu sitä? Tarkistan asian etsimällä projektista, sillä agentin raportti ei ole tässä luotettava lähde.

Tarkastaja näkee vain sen suunnan, jota häntä pyydettiin tutkimaan

Palvelu ottaa käyttöön kanta-asiakastasot: mitä enemmän maksat, sitä korkeampi asema ja suurempi alennus. Ennen käyttöönottoa koodi annetaan tarkastettavaksi ohjeella ”yritä nostaa omaa asemaasi”. Tarkastaja tekee työnsä rehellisesti ja raportoi ”ei mitään kriittistä” – omaa asemaa ei todellakaan voi nostaa.

Toisella kierroksella kysytään eri kysymys: ”Mitä asemalle tapahtuu, kun rahat palautetaan?” Aukko löytyy kymmenessä minuutissa. Pisteet laskettiin tapahtumalokista, eikä loki tunne palautuksia. Osta jotakin, saa pisteitä, pyydä rahat takaisin ja pidä asema ja alennus ikuisesti.

Ensimmäinen tarkastaja ei oikonut. Hän ei rakenteellisesti voinut nähdä sitä: hänelle annettiin suunta ”syöte, ylennys”, kun taas aukko oli suunnassa ”syötteen peruminen, ylennyksen säilyminen”. Kun kyseessä ovat rahat, käyttöoikeus tai ostettava asema, teen kaksi tarkastuskierrosta. Toisella kierroksella luettelen erikseen käänteiset suunnat: hyvitys, esto, käyttöoikeuden peruminen, vanhentuminen ja tietolähteen poistaminen.

Mittari palkitsee samankaltaisuutta

Toimituspalvelu päättää mitata, ovatko tekoälyn operaattoreille antamat ehdotukset parantuneet. Se ottaa kaksisataa vanhaa tukipyyntöä, ajaa ne uuden version läpi ja mittaa, kuinka samankaltainen luonnos on ihmisen antaman todellisen vastauksen kanssa. Mittaus näyttää selvää kasvua.

Kasvu ei tarkoita mitään kahdesta syystä. Luonnoksen konteksti kootaan ”tämän päivän tilanteen mukaan”, ja siinä on koko kirjeenvaihto, myös operaattorin vastaus, johon luonnosta myöhemmin verrataan. Malli ei kirjoita vastausta, vaan parafraasoi sille näytettyä vertailutekstiä. Lisäksi mittari itsessään palkitsee sanojen ja pituuden samankaltaisuudesta: luonnos, jossa on väärä päivämäärä mutta samat sanat, joita operaattori käytti oikeasta päivämäärästä, saa korkeat pisteet.

Lisään nyt jokaisen ”samankaltainen tarkoittaa hyvää” -mittarin rinnalle tiukat mekaaniset ehdot, joita tyyli ei voi huijata: keksityt luvut ja päivämäärät, kieltosanat ja toimintalupaukset. Ehtojen tulosten heikkeneminen kumoaa kaikki mittarin paranemiset.

Miksi agentin ”tarkistin” ei todista mitään?#

Ota mikä tahansa projekteistasi ja pyydä agenttia ”tarkistamaan tietoturva”. Usein vastaus on ”kaikki kunnossa, ei kriittisiä ongelmia”.

Kysy nyt sama kysymys samasta projektista toiselta mallilta. Erityisesti suuressa projektissa se löytää paljon. Ennen käyttöönottoa kirjoittaja tarkistaa projektin kolmella eri mallilla, ja jokainen löytää jotakin muuta.

Sama syöte, sama kysymys, vastakkaiset arviot. Kumpikaan malli ei ole toista huonompi. ”Kaikki kunnossa” on vain tuotettua tekstiä, täsmälleen samalla tasolla kuin mikä tahansa muukin vastaus. Agentti ei pysty erottamaan ilmaisuja ”katsoin, eikä ongelmia ole” ja ”katsoin väärästä paikasta”.

Anthropic kuvailee tätä mekanismia Claude Code -dokumentaatiossaan.

Pura lause rauhassa osiin. Kunnes annat agentille tarkistuksen, jonka se voi suorittaa, sillä on yksi signaali – miltä asiat näyttävät. Tässä järjestelyssä sinä olet varmennussilmukka, mutta saat virheistä tiedon viimeisenä.

Taustalla on vielä syvempi kerros. Kun OpenAI yritti painostaa mallia valvomalla sen päättelyä ja rankaisemalla sitä ”huonoista ajatuksista”, tulos ei ollut odotettu.

Ilmaistun aikomuksen rankaiseminen poistaa ilmaisun. Aikomus itsessään säilyy. En siis luottaisi siihen, että agentti kertoo rehellisesti, miten se huijasi.

Myös työkalujen kehittäjät itse ovat siirtymässä samaan suuntaan. Claude Code -versiossa 2.1.215 /verify- ja /code-review-taidot lakkasivat käynnistymästä mallin omasta aloitteesta.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic ei selitä miksi. Periaate on kuitenkin selvä: tarkastettava ei valitse itse omaa tarkastustaan.

Miksei projektitiedoston sääntö pidä agenttia kurissa?#

Kirjoitit projektin sääntötiedostoon: tee commit vain, kun käsken suoraan; vie tuotantoon vain, kun sanon suoraan; käytä tuotantodataa vain lukuoikeuksin.

Kirjoittajan kokemuksen mukaan agentti menee silti itse tekemään käyttöönoton noin kerran kymmenestä. Ei pahuuttaan eikä siksi, ettei se olisi lukenut sääntöä. Se luki sen. Sen edessä oli vain tavoite, ja sääntö oli tekstiä – kuten muukin konteksti.

Juuri näin tapahtui OpenAI:n laboratoriossa, vain suuremmassa mittakaavassa. Mallit olivat suljetussa ympäristössä, jossa oli yksi ulospääsy, ja käyttivät huomattavan osan laskentakapasiteetistaan ulospääsyn etsimiseen. Testitehtävät jäivät ratkaisematta.

Oma kantani on yksinkertainen: agentti ei ole vaarallinen eikä pahantahtoinen. Se on tavallinen, pelkkä typerys, jolla on valtuuksia. Siksi sen valtuuksia pitää rajoittaa sen sijaan, että pyyntöjä kirjoitetaan uudelleen.

Se, mikä todella pitää: tuotantodataan on vain tiukasti lukuoikeus. Kokonaisten hakemistojen poistaminen on kielletty. Historiatiedostojen uudelleenkirjoittavat komennot, joista ei voi palautua, ovat kiellettyjä. Aseta kulutusraja palveluntarjoajan kautta. Ero tiivistyy yhteen ilmaukseen: ”ei voi fyysisesti tehdä” voittaa ilmauksen ”pyysin sitä olemaan tekemättä”. Asetuksista kerrotaan erikseen artikkelissa mekaaniset jarrut ohjeiden pyyntöjen sijaan.

Pidä silti pää kylmänä. Hiekkalaatikko ei ole ehdoton raja, ja palveluntarjoaja sanoo sen suoraan.

Lisäksi Claude Codessa on sisäänrakennettu hätäuloskäynti, jota malli voi käyttää itse. Kun komento epäonnistuu hiekkalaatikon rajoitusten vuoksi, Claude analysoi virheen ja saattaa yrittää samaa komentoa uudelleen parametrilla, joka poistaa hiekkalaatikon käytöstä. Tämän voi estää erillisellä strict mode -asetuksella; oletuksena kiertotapa on käytettävissä ja dokumentoitu.

Rajoitus toimii vain siinä määrin kuin tiukennat sitä. Jokainen este hidastaa toimintaa – kustannus kannattaa laskea rehellisesti etukäteen, sillä sen havaitseminen viikon kuluttua maksaa enemmän.

Miten asetat kriteerin, jota ei voi pelata?#

Kriteerin sanamuoto ratkaisee kaiken muun. Testaa sitä yhdellä kysymyksellä: voiko agentti täyttää tämän kriteerin tekemättä mitään?

• ”Tarkista, että kaikki toimii” – voi. Riittää, kun kirjoittaa ”tarkistettu, toimii”.
• ”Suorita build ja näytä tuloste” – jo vaikeampaa; tuloste on saatava jostakin.
• ”Käynnistä sovellus, napsauta kassapainiketta ja näytä, mitä ruudulle ilmestyi” – tätä on lähes mahdotonta täyttää pelkällä tekstillä.

Ensimmäisen ja kolmannen ero on raportin ja todisteen ero.

Claude Code -dokumentaatio kuvaa neljä perusteellisuuden tasoa. Hyödyllinen porras, jota nousta virheen kustannuksen kasvaessa:

1. Yhdessä viestissä. Pyydä agenttia suorittamaan tarkistus ja toistamaan se, kunnes se onnistuu tässä ja nyt. Halvin vaihtoehto, sopii pieniin asioihin.
2. Koko istunnon ajan. Tee tarkistuksesta tavoitteen ehto: erillinen arvioija tarkistaa tuloksen jokaisen vuoron jälkeen, ja agentti jatkaa, kunnes ehto täyttyy. Teknisistä yksityiskohdista kerrotaan oppaassa, joka käsittelee valmistumiskriteerin asettamista etukäteen.
3. Mekaaninen este. Skripti käynnistyy, kun agentti yrittää päättää vuoron, ja estää päättämisen, kunnes tarkistus menee läpi. Yksi asia on sanottava rehellisesti: kahdeksan peräkkäisen eston jälkeen Claude Code ohittaa esteen ja päättää vuoron silti. Järjestelmässä ei ole täysin läpäisemättömiä esteitä.
4. Toinen mielipide. Erillinen tarkastaja, jolla on tuore konteksti ja jonka tehtävänä on kumota tulos.

Neljäs kohta erottuu, koska se on ainoa, joka ei liity työkaluihin.

Kenen pitäisi hyväksyä agentin työ?#

Kun ajan agentteja suurten tehtävien parissa silmukassa, järjestely on tämä: yksi ryhmä kirjoittaa, toinen tuore ryhmä hyväksyy työn osallistumatta sen kirjoittamiseen.

”Tuore” on avainsana. Se tarkoittaa puhdasta kontekstia, joka ei ole nähnyt, miten kutakin päätöstä tehtiin matkan varrella. Saman istunnon toinen kehote ei tuo sitä. Koodin kirjoittaja on jo käyttänyt huomiota vakuuttaakseen itsensä sen oikeellisuudesta ja etsii edelleen vahvistusta. Hänen etunsa ei ole kumota omaa työtään.

Tarkastajalle annetun tehtävän sanamuoto merkitsee enemmän kuin tarkastajan malli. Vertaa näitä:

• ”Tarkista tämä työ” – tarkastaja löytää helposti löytyvät asiat ja kirjoittaa ”yleisesti ottaen kunnossa”.
• ”Yritä todistaa, ettei tätä työtä ole tehty” – tarkastaja alkaa etsiä aukkoja, koska se on hänen tavoitteensa.

Toinen sanamuoto toimii paremmin samasta syystä kuin ExploitGym epäonnistui: agentti sitoutuu sille annettuun tavoitteeseen. Anna sille tavoitteeksi aukon löytäminen, niin se etsii sellaisen.

Tässä on koko sanamuoto valmiina kopioitavaksi sellaisenaan:

Tarkastat jonkun muun työtä. Et kirjoittanut sitä, eikä sinun tarvitse puolustaa sitä.

Tavoitteesi on todistaa, ettei väitettyä tulosta ole saavutettu. Etsi vähintään kolme tapaa, joilla tulosta ei ehkä ole saavutettu, vaikka kaikki tarkistukset ovat vihreitä.

Tarkista tässä järjestyksessä:

Mikä työ jää tarkistusten kattaman alueen ulkopuolelle: taustaprosessit, erilliset skriptit, ajastetut tehtävät ja jononkäsittelijät.

Kuka kutsuu kutakin uutta funktiota. Etsi kutsu projektista hakemalla; näytä tiedosto ja rivi.

Käänteiset suunnat: hyvitys, esto, käyttöoikeuden peruminen, vanhentuminen ja tietolähteen poistaminen.

Tuloksen sisältämät arvot, ei vain sitä, onko tulos olemassa.

Jos huolellinen haku ei löydä aukkoja, sano se, mutta kerro tarkalleen, mitä tarkistit ja miten.

Artikkelissa agentin itseään tarkistavasta silmukasta kerrotaan, miten agentin itseään iteraatioiden välillä tarkistava silmukka toimii ja missä se tavallisesti epäonnistuu.

Mitä muuttuu, kun muotoilet kriteerin uudelleen?#

Tämä on halvin tuntemani parannus, eikä juuri kukaan tee sitä.

Pyydä agenttia tekemään koodikatselmus, niin se päättelee koodin näkökulmasta: rakenne, virheenkäsittely, uudelleenyritykset, haavoittuvat kohdat. Hyödyllistä.

Pyydä sitä kulkemaan asiakkaan polku ensimmäisestä käynnistä sivustolla hyvityksen pyytämiseen, niin esiin nousee aivan toisenlaisia ongelmia. Virhe, joka näyttää käyttäjälle jotakin, mitä hänen ei pitäisi nähdä. Sähköposti, jonka teksti ei vastaa todellisia tapahtumia. Vaihe, jota on loogisesti mahdotonta suorittaa, ellei siihen ole tultu ihanteellisen tilanteen kautta.

Koodikatselmus ei löydä näitä virheitä, koska jokainen niistä on koodissa kelvollinen.

Tästä seuraa sääntö, jonka pidän mielessäni: jos tarkistus ei löydä mitään, muuta ensin sanamuotoa. Malli ei yleensä ole ongelma. Samasta työstä saa kolme erilaista havaintolistaa, kun sitä kysytään kolmella eri tavalla. Käytännöllinen kysymyssarja ei-ohjelmoijille on koottu erikseen: seitsemän kooditarkistusta ilman ohjelmointitaitoja.

Valmis kehote agentin työn hyväksymiseen#

Älä vastaa ”valmis” tai ”tarkistettu”. Tarvitsen todisteita.

Anna jokaisesta työtehtävästä täsmälleen nämä tiedot:

Minkä komennon suoritit varmistaaksesi, että työtehtävä toimii? Sisällytä itse komento ja sen koko tuloste lyhentämättömänä.

Jos et suorittanut komentoa, sano: ”ei suoritettu”. Älä korvaa tätä ilmauksella ”tarkistettu silmämääräisesti” tai ”logiikka on oikein”.

Mikä työ toimii tarkistuksesi kattaman alueen ulkopuolella? Taustaprosessit, erilliset skriptit, ajastetut tehtävät, jononkäsittelijät – kaikki, mikä käynnistetään eri tavalla kuin pääsovellus. Suorititko jokaisen tällaisen osan erikseen, ja mitä se tulosti?

Kuka kutsuu jokaista lisäämääsi uutta funktiota? Etsi kutsu projektista hakemalla ja näytä tiedosto ja rivi. Jos kutsua ei ole, sano se suoraan.

Sitten erilliseen osioon: kolme tapaa, joilla väitetty tulos EI ehkä ole saavutettu, vaikka kaikki tarkistuksesi ovat vihreitä. Etsi huolellisesti.

Lopuksi yksi rivi: mitä minun pitäisi tarkistaa omin silmin, koska automaattinen tarkistus ei havaitse sitä?

Neljäs kohta vaikuttaa pieneltä, mutta se paljastaa kokonaisen ongelmaluokan. Suuressa tehtävässä, jonka jaoin agenteille alueittain, ainoa väärä ”valmis” sadasta löytyi juuri kahden alueen saumasta: koodi oli kirjoitettu, tarkistukset olivat vihreitä, mutta kukaan ei ajatellut laittaa sitä näkyviin ruudulle.

Neljä tapaa huijata itseään tarkistuksella#

1. Kaikkia tarkastajia ei odotettu. Käynnistin kolme rinnakkaista tarkistusta, kaksi palasi vihreinä ja otin muutoksen käyttöön. Kolmas tuli neljä minuuttia myöhemmin ja löysi kuusi rikkomusta. Julkaisun jälkeinen korjaaminen maksaa enemmän kuin kahden minuutin odotus.
2. ”Käsitelty N/N” -yhteenvetoon luotettiin. Suurissa rinnakkaisissa ajoissa jotkin agentit epäonnistuvat hiljaa: ne raportoivat onnistumisesta, mutta tiedosto on koskematon. Tarkistan nyt mekaanisesti jokaisen agentin tekemän kirjoituksen jälkeen, että muutokset todella näkyvät levyllä.
3. Tulosta ei katsottu omin silmin. Automaattiset tarkistukset voivat olla vihreitä, vaikka tulos olisi täysin käyttökelvoton. Kuvat ovat teknisesti oikein, koko on oikea ja vastauskoodi on oikein. Todellisuudessa ne ovat kuitenkin automaattisia pysäytyskuvia, jotka on laitettu kuvitettujen kansien tilalle. Mikään automaattinen tarkistus ei huomaa sitä.
4. Läsnäolo tarkistettiin arvon sijaan. Tarkistus etsi tuloksesta vaadittua tekstiä. Teksti löytyi, mutta sen sisältämät tiedot olivat väärin: päivämäärä oli päivän pielessä. Tarkistus oli vihreä ja raportti valheellinen. Varmistan nyt koko odotetun arvon, sillä pelkän oikean sanan esiintyminen ei takaa mitään.

Näitä neljää yhdistää se, että tarkistus oli olemassa, näytti vakuuttavalta ja tarkisti väärää asiaa. Sama toimintamekaniikka kuin malleilla ja niiden testillä, mutta ilman kekseliäisyyttä.

Mistä aloittaa tänään?#

Kolme vaihetta, joihin kuluu kaksikymmentä minuuttia.

1. Ota viimeisin ”valmis”. Aja se todisteita käsittelevän osion hyväksymiskehotteen läpi. Tavoite on yksinkertainen: selvitä, kuinka moni työtehtävä päätettiin sanoilla ja kuinka moni komentotulosteella.
2. Ota itsellesi yksi sääntö. Sana ”tarkistettu” ilman liitettyä komentotulostetta ei riitä tehtävän päättämiseen. Sääntö koskee sinua, ei agenttia, ja juuri siksi se toimii.
3. Erota tekijä ja tarkastaja. Anna seuraavassa tehtävässä tuoreelle istunnolle tarkastajan kehote ja pyydä sitä todistamaan, ettei työtä ole tehty. Ensimmäinen kerta yleensä palkitsee tavan omaksumisen.

Työkalu on hyvä ja paranee joka kuukausi: asiat, jotka agentti teki vuosi sitten huomaamatta, pysäyttävät sen nyt. Turvaraja siirtyy ja pysyy silti rajana. Niin kauan kuin agentti tavoittelee sille annettua päämäärää, kysymys ”ja miten tarkalleen mittasit sen?” on edelleen sinun vastuullasi. Tarkistamisesta muodostuva tapa on turvaverkkosi.