Kuusi AI-agenttia auditoi sivustoni ennen julkaisua. Tulos: NO-GO

Rakensin Pyöräpassin yksin, ja siitä kirjoitin jo oman artikkelinsa. Se, mistä en vielä kertonut, on mitä tein viikkoa ennen kuin ensimmäinen yhteydenottokampanja lähti pyöräliikkeille. Halusin tietää, kestääkö tuote sen mitä kampanjaviestissä luvataan, koska omaan tuotteeseensa sokeutuu tavalla, jota ei itse huomaa.

Yksittäinen “tarkista tämä koodi” -kysely tekoälylle ei riitä siihen. Se löytää vain sen, mitä osaa kysyä, ja minä olin rakentanut koko jutun, joten tiesin jo mitä uskoin kysyä kannattavan.

Kuusi agenttia, kuusi eri tehtävää

Ratkaisu oli ajaa kuusi rinnakkaista read-only-agenttia, eli agenttia joille annoin luvan lukea koko koodikannan ja sisällön mutta ei oikeutta muuttaa mitään. Jokainen sai oman linssinsä: käyttäjäpolut, tietoturva, koodin oikeellisuus, live-sisältö sellaisena kuin se oikeasti näkyy tuotannossa, outreach-funneli eli se polku jota pitkin pyöräliike etenee ensimmäisestä viestistä asiakkaaksi, ja ops eli ylläpidon ja varmuuskopioiden arki.

Kuusi eri roolia sen sijaan että olisin kysynyt yhtä laajaa “onko tämä valmis” -kysymystä oli tietoinen valinta. Kapea rooli pakottaa agentin katsomaan syvälle yhteen asiaan sen sijaan että se tuottaisi pinnallisen yleiskatsauksen kaikesta. Käyttäjäpolku-agentti ei tiennyt mitään tietoturvasta, eikä sen tarvinnutkaan tietää. Se kävi läpi jokaisen lupauksen, jonka markkinointiteksti tai kampanjaviesti tekee, ja tarkisti onko lupauksen takana oikeasti toimiva ominaisuus. Live-sisältö-agentti taas ei lukenut koodia lainkaan, vaan kävi sivuston läpi samalla tavalla kuin ensikertalainen kävijä, klikaten ja lukien sen minkä tuotannossa oikeasti näkee.

Tulos oli ~70 dedupoitua löydöstä, eli samat havainnot yhdistettynä kun useampi agentti osui samaan kohtaan eri kulmasta. Rehellinen verdikti: NO-GO ennen kriittisten korjausta. En ollut valmis lähettämään yhtään viestiä ennen kuin ne oli hoidettu.

Roolijaon periaate on yksinkertainen: jokainen agentti katsoo samaa tuotetta eri kysymyksellä, jolloin löydökset eivät jää yhden näkökulman varaan. Tietoturva-agentin kysymys on mitä pääsyä kukin osa järjestelmästä antaa ulkopuoliselle, koodiagentin kysymys on toimiiko logiikka niin kuin sen pitäisi riippumatta siitä kuka sitä käyttää. Kahdesta eri kysymyksestä syntyy kaksi eri löydöslistaa, ja vasta kun kaikki kuusi listaa on koottu yhteen, syntyy kokonaiskuva siitä missä kunnossa tuote oikeasti on.

Mitä löytyi, ja miksi juuri nämä pysäyttivät minut

Kolme löydöstä erottuivat muista siksi, että ne olisivat rikkoneet kampanjan ydinlupauksen, eivät vain jotain sivupolkua.

Ensimmäinen oli kuollut oletus-URL integraatiopluginissa. Koodi viittasi osoitteeseen, joka ei enää ollut voimassa, ja käytännössä yksi koko integraation varassa oleva toiminto olisi hajonnut hiljaa ilman virheilmoitusta. Kukaan käyttäjä ei olisi nähnyt punaista laatikkoa, se olisi vain lakannut toimimasta.

Toinen oli käyttäjäpolku, joka lupasi ominaisuutta jota ei ollut rakennettu. Kolme eri kohtaa tuotteessa ohjasi käyttäjää lataamaan L1-tason kuvatodisteen, eli sen ensimmäisen tason varmennuksen, jossa käyttäjä osoittaa omistajuutensa kuvalla. Upload-UI eli se käyttöliittymän osa, josta kuva oikeasti ladattaisiin, puuttui kokonaan. Kolme viittausta yhteen paikkaan, ja se paikka oli tyhjä.

Kolmas oli hienovaraisin: 301-uudelleenohjaus, joka muutti API:n POST-kutsut GET:iksi. Selittääkseni auki, 301 on pysyvä uudelleenohjaus ja POST/GET ovat kaksi eri tapaa lähettää pyyntö palvelimelle, joista POST kantaa mukanaan dataa ja GET ei. Kun selain seuraa 301-ohjausta, se saattaa muuttaa alkuperäisen POST-kutsun GET-kutsuksi, jolloin data katoaa matkalla. Tämä olisi näkynyt satunnaisena, vaikeasti toistettavana rikkoutumisena juuri niissä tilanteissa joissa käyttäjä eniten tarvitsisi toiminnon toimivan.

Kaikki kolme korjattiin, ja vasta sen jälkeen lähetettiin. Loput noin 70 löydöksestä olivat vaihtelevan kokoisia, osa pieniä copy-virheitä, osa ops-tason huomioita varmuuskopioiden aikataulusta. Ei kaikki 70 ollut julkaisua estäviä, mutta kriittiset kolme olivat, ja niiden löytäminen ennen kampanjaa oli koko harjoituksen pointti.

Erityisen opettavainen oli juuri se upload-UI-löydös. Kolme eri viestiä sivustolla ohjasi käyttäjää samaan ominaisuuteen, joka ei ollut olemassa. Kukaan yksittäinen viesti ei paljastanut virhettä yksinään, koska jokainen niistä luki ihan järkevältä irrallaan muista. Vasta kun agentti vertasi kaikkia kolmea viittausta yhteen todelliseen käyttöliittymän tilaan, ristiriita tuli näkyviin.

Miksi tämä toimii paremmin kuin yksi iso kysymys

Uskon, että suurin osa ihmisistä käyttää tekoälyä vahvistamaan omaa suunnitelmaansa. Kysytään “toimiiko tämä”, ja kun malli vastaa myöntävästi, se tuntuu varmistukselta vaikka ei olisikaan tarkistanut mitään syvällisesti. Tekoälyn suurin arvo ei ole se, että se kertoo suunnitelman olevan hyvä. Se on siinä, että se kaataa suunnitelman ennen kuin asiakas kaataa sen puolestasi, julkisesti ja huonompaan aikaan.

Adversariaalinen tarkistus, eli tarkistus jossa agentin tehtävä on nimenomaan etsiä syitä miksi jokin ei toimi eikä vahvistaa että se toimii, vaatii kaksi asiaa. Ensimmäinen on eri roolit, koska yksi geneerinen “auditoi tämä” ei pakota mitään tiettyä näkökulmaa syvälle. Toinen on lupa sanoa ei, eli agentin täytyy saada palauttaa NO-GO-verdikti eikä vain listaa parannusehdotuksia jotka voi jättää huomiotta. Kirjoitin aiemmin siitä, mitä AI-avusteinen kehitys oikeasti rikkoo, ja sama teema toistuu tässä: riskit eivät ole siinä että malli kirjoittaa huonoa koodia, vaan siinä miten sitä käytetään. Vahvistuksen hakeminen on eri työkalu kuin kaatamisen hakeminen, ja useimmat tavoittelevat vahvistusta silloinkin kun tarve olisi kaatamiselle.

Mitä tästä jää käteen

Read-only-rajaus oli tässä yhtä tärkeä kuin roolijako. Kun agentti ei voi muuttaa mitään, sen ainoa keino vaikuttaa on löytää ja raportoida, ei korjata ohi omistajan. Se pitää päätöksen minulla, ja pakottaa jokaisen löydöksen näkyväksi ennen kuin mitään korjataan.

Käytännön ohje, jos kokeilet vastaavaa omassa työssäsi: älä kysy yhdeltä agentilta “onko tämä valmis”. Anna useammalle agentille kapea, eri rooli, ja anna kaikille lupa vastata ei. Kolme kriittistä löydöstä kuudesta linssistä maksoi itsensä takaisin moninkertaisesti verrattuna siihen, mitä olisi maksanut selittää pyöräliikkeelle miksi lupaamani ominaisuus ei toiminutkaan sinä päivänä kun he yrittivät sitä käyttää.

Seuraavaksi jäin miettimään, kannattaisiko sama kuuden linssin auditti ajaa uudelleen aina ennen isompaa julkaisua, ei vain ensimmäistä kertaa. Jos olet kokeillut vastaavaa moniagenttiauditointia omassa tuotteessasi, kerro mielelläni mitä linssejä sinä valitsisit.