A/B-testasin koodausagenttini ohjeet. Suurin osa niistä ei tuottanut mitään

Lyhyt versio

• Otin yhden oikean issuen FlowHuntin backlogista ja annoin Claude Coden toteuttaa sen 13 kertaa Opus 5.5:llä seitsemässä eri ohjeasetelmassa. Jokainen ajo alkoi samasta commitista, omassa kloonissaan omalla tietokannallaan, ja kulki oikean GitHub CI:mme läpi. Kaksi sokkona tehtyä Opus-arvostelua arvioi jokaisen tuloksen.
• Repositorion 33 kt:n CLAUDE.md ei tuottanut mitattavaa laatua. Sen kanssa tehdyt ajot saivat 2,0 blokkaavaa ja merkittävää havaintoa arvostelua kohden. Ajo ilman minkäänlaista ohjetiedostoa sai saman. 5,5 kt:n tiedosto sai 1,0.
• Erillinen suunnitteluvaihe teki asioista huonompia. Molemmat asetelmat, joissa ajettiin suunnittelukehoite ja sitten toteutuskehoite, maksoivat enemmän kuin pelkän kehoitteen kaksosensa, ja ne tuottivat neljä viidestä blokkaajasta kaikissa 26 arvostelussa.
• Voittaja oli 8 kt:n CLAUDE.md, kolme skilliä, Sonnet-työntekijät ja pelkkä kehoite. Sen kaksi ajoa maksoivat keskimäärin 6,68 $ API:n listahinnalla. Täysi asetelma putken kehoitteineen maksoi keskimäärin 11,49 $, noin 1,7-kertaisesti, ja siinä oli enemmän havaintoja.
• Kaikesta rakentamastani rakenteesta jäi jäljelle brief: lyhyt, päätetty kuvaus yhdestä työn siivusta, jonka päämalli kirjoittaa halvemmalle työntekijälle. Suunnitelmat päämallille itselleen eivät kannattaneet. Malli suunnittelee aivan hyvin itse.

Tämä seuraa architect-kuvio -postausta, jossa mitattiin, kenen pitäisi kirjoittaa koodi. Tässä kysytään, kuinka paljon päämallille pitää kertoa ennen kuin se aloittaa.

Miksi ajoin testin

Monorepoomme oli kerännyt paljon agenttiohjeita. Juuren CLAUDE.md oli 33 kt: build-komennot, testaustahti, koodityyli, arkkitehtuuri, kriittiset polut, tietoturvasäännöt, oikeus- ja credit-säännöt, kaksi agenttipintaa, issueiden kirjaus, PR-käytännöt. Kymmenen skilliä oli hakemistossa .claude/skills/. Sen lisäksi CI-putkemme (kutsumme sitä nimellä harnext) ajoi issuen taggerin, triage-vaiheen, suunnitteluvaiheen, joka kirjoitti suunnitelman issuen kommentiksi, ja toteutusvaiheen, joka luki suunnitelman takaisin ja kirjoitti koodin – kullakin oma pitkä järjestelmäkehoitteensa.

Jokainen rivi lisättiin syystä, yleensä sen jälkeen kun agentti oli tehnyt jotain väärin. Kysymys, jota kukaan ei ollut esittänyt, oli se, auttoiko se enää. CLAUDE.md ladataan jokaiseen sessioon ja lähetetään uudelleen joka vuorolla. Jos malli olisi tehnyt oikein muutenkin, nuo tokenit ovat vero, ja kuten mitä konteksti-ikkuna maksaa selittää, jokaisen vuoron vero kertyy nopeammin kuin miltä näyttää.

Valmis kasvattamaan liiketoimintaasi?

Aloita ilmainen kokeilujakso tänään ja näe tulokset muutamassa päivässä.

Pyydä demo Kirjaudu sisään

Testi

Issue oli uusille rekisteröityjille tarkoitettu ajastettu sähköpostisarja: admin määrittelee vaiheita kuten “päivä 0: tervetuloa” ja “päivä 5: kokeilujaksosi päättyy pian”, ja taustatehtävä lähettää postin kullekin tilille oikeana päivänä, lopettaa heti kun henkilö ostaa maksullisen paketin ja ohittaa ennen julkaisua luodut tilit. Se tarvitsee migraation, repositorion, servicen, Celery beat -tehtävän, REST-päätepisteet, MCP-työkalut agenteille ja konsolin käyttöliittymän 11 kielellä. Se on realistinen ensimmäisen viikon ominaisuus, ja siinä on useita reunatapauksia, jotka on helppo ohittaa.

Jokainen ajo oli headless Claude Code -sessio Opus 5.5:llä, eristettynä omaan klooniinsa ja tietokantaansa, ja skripti puski sen commitin draft-PR:ään ja syötti CI:n tuloksen takaisin sessioon, enintään kolme kierrosta. Kustannus on Claude Coden oma total_cost_usd pääsessiosta ja kaikista subagenteista API:n listahinnalla. Maksan tilausta, joten tämä mittaa työtä, ei laskuani.

Seitsemän asetelmaa:

A–D tulivat ensin. E–G rakennettiin niiden osoittaman perusteella, ja B:n kolmas ajo kulki niiden rinnalla kontrollina. 8 kt:n tiedosto on 5,5 kt:n tiedosto plus lyhyt luettelo skilleistä ja siitä, milloin ne ladataan, sekä mallireitityssäännöt, jotka saavat architect-skillin delegoimaan Sonnetille.

Jokainen tulos meni sen jälkeen kahdelle Opus-arvostelijalle, jotka näkivät vain kirjaimen, diffin, repositorion ja issuen. He listasivat jokaisen muutoksen, jota pyytäisivät ennen hyväksyntää, luokittelivat ne blokkaaviksi, merkittäviksi, vähäisiksi tai niteiksi ja tarkistivat jokaisen hyväksymiskriteerin tiedostoa ja riviä vasten.

Kustannus

Voittanut asetelma G maksoi 5,96 $ ja 7,39 $. Täysi asetelma putken kehoitteilla, A, maksoi 11,12 $ ja 11,85 $. Ero on pääosin vuoroissa ja siinä, mitä kukin vuoro kantaa. A:n pääsessiot ajoivat 172 ja 144 vuoroa Opusilla 24–28 miljoonalla syöttötokenilla. G:n ajoi 79 ja 95 vuoroa 13–16 miljoonalla ja siirsi noin 60 vuoroa lisää Sonnet-työntekijöille, jotka laskutetaan murto-osalla hinnasta. G myös sai työnsä valmiiksi noin 21 minuutissa, kun A:lta meni 45.

Kaksi asiaa tässä kuvaajassa yllätti minut. Ei ohjeita lainkaan ei ole halpa vaihtoehto: sen kaksi ajoa maksoivat 7,32 $ ja 15,58 $, ja kalliimpi niistä myös epäonnistui CI:ssä ja kirjoitti testin suurimman diffin. Eikä 5,5 kt:n tiedosto ilman skillejä, F, ollut halvempi kuin täysi asetelma. Se kirjoitti enemmän koodia, 1 601 tuotantolinjaa, ja maksoi siitä. Säästö G:ssä ei tule pelkästä lyhyestä tiedostosta. Se tulee lyhyestä tiedostosta plus kahdesta skillistä, jotka muuttavat sitä, miten työ tehdään.

Liity uutiskirjeellemme

Saa uusimmat vinkit, trendit ja tarjoukset ilmaiseksi.

Sähköpostiosoite

Tilaa

Laatu

Halvimmassa asetelmassa oli myös vähiten vakavia havaintoja: ei blokkaajia ja 1,5 ja 0,5 merkittävää havaintoa arvostelua kohden sen kahdessa ajossa. Täysi CLAUDE.md, B, pysyi 2,0 merkittävässä kaikissa kolmessa ajossaan, samassa kuin ilman CLAUDE.md:tä kokonaan.

Tämä on tulos, josta välitän eniten. Tiedostossa on pitkät osiot tietoturvasta, oikeuksista ja crediteistä, kirjoitettu siksi, että agentti kerran ohitti ne. Tiedoston kanssa tai ilman arvostelijat löysivät saman määrän vakavia ongelmia, ja samat tyypit toistuivat asetelmasta toiseen: rekisteröitynyt, joka maksaa ja sitten peruu, sähköposti, joka häviää tai lähtee kahdesti, kun työntekijä epäonnistuu kesken, editori, joka ylikirjoittaa sisältöä, jota se ei pysty näyttämään. Nämä ovat päättelyaukkoja, jotka koskevat tilan muuttumista ajan myötä. Mikään CLAUDE.md:n sääntölista ei kattanut niitä, koska sääntöä ei voi kirjoittaa reunatapaukselle, jota ei ole vielä keksinyt.

Ne kattoi architect-skilliin kierrosten välillä tehty muutos. Ennen kuin päämalli kirjoittaa yhtään briefiä, se kirjoittaa nyt taulukon: jokainen hyväksymiskriteeri, mitä tapahtuu, kun sen riippuva tila muuttuu ajan myötä, ja päätetty käyttäytyminen. Jokainen rivi menee sitten briefiin nimetyn testin kanssa. G:n ajot kirjoittivat 774 ja 818 testiriviä, kun B:llä luvut olivat 510–670.

Suunnitteluvaihe

A ja E ovat ne kaksi asetelmaa, joissa ajettiin CI-putkemme kehoitteita: suunnittelukehoite, joka kirjoittaa suunnitelman, ja sitten toteutuskehoite, joka lukee suunnitelman ja toteuttaa sen. Vertaa kumpaakin sen kaksoseen, joka sai pelkän kehoitteen. A maksoi 11,49 $ ajoa kohden B:n 9,61 $ vastaan ja siinä oli blokkaajia siellä, missä B:llä ei ollut yhtään. E maksoi 10,13 $ G:n 6,68 $ vastaan ja siinä oli blokkaaja jokaisessa arvostelussaan siellä, missä G:llä ei ollut yhtään.

Luulen syyn olevan siinä, että suunnitelma on dokumentti, jonka malli kirjoittaa itselleen ja joka sen on sitten luettava takaisin ulkopuolisena ohjeena. Toinen sessio kohtelee suunnitelmaa spesifikaationa, noudattaa sitä sielläkin missä se on väärin ja käyttää vuoroja sen sovittamiseen yhteen sen kanssa, mitä löytää koodista. Näin pätevä malli suunnittelee paremmin sen session sisällä, joka on tekemässä työn, jossa suunnitelma ja koodi ovat samassa kontekstissa.

Se osa suunnittelusta, joka jäi eloon, on brief. Kun päämalli antaa siivun Sonnet-työntekijälle, työntekijä aloittaa tyhjästä kontekstista ja rakentaa täsmälleen sen, mitä sille sanotaan. Tämä siirto tarvitsee kirjoitetun, päätetyn kuvauksen: tavoite, tiedostot, peilattava käytäntö, reunatapaukset, kirjoitettava testi. Suunnitelma itselle on ylimääräistä kuormaa. Brief toiselle on ainoa tapa, jolla työ siirtyy eteenpäin.

Mitä grain-ponytail teki

Skilli postauksesta koodaa syyn mukaisesti käskee mallia peilaamaan lähintä olemassa olevaa esimerkkiä ja toimittamaan vähiten toimivaa koodia. Jokainen ajo, jossa se oli ladattuna, kirjoitti 1 068–1 353 tuotantolinjaa. Kaksi suurinta diffiä, 1 601 ja 1 752, tulivat ajoista ilman skillejä. Yksi ilman skillejä tehty ajo pysyi 1 280 rivissä, joten skilli ei yksinään päätä kokoa, mutta se poisti hännän.

Se on myös selvin esimerkki siitä, millainen ohje vielä kannattaa. “Peilaa lähintä esimerkkiä” muuttaa sitä, mitä malli tekee jokaisessa kirjoittamassaan tiedostossa. “Käytä funktioissa snake_casea” toistaa jotain, mitä se tekee jo.

Mitä arvostelut silti löysivät

Voittanut ajo ei ollut puhdas. Testin jälkeen rebasoin G2:n työn mainin päälle ja ajoin sen täyden PR-tarkistuksemme läpi, joka arvostelee diffin, todistaa jokaisen havainnon epäonnistuvalla testillä ja ajaa muutoksen oikeassa selaimessa. Se löysi, että vaihe-editori pudotti jokaisen lohkon paitsi ensimmäisen HTML-lohkon, kun admin muokkasi MCP:n kautta luotua vaihetta, ja että epäonnistunut claim-vapautus saattoi lähettää joillekin käyttäjille sähköpostin kahdesti. Molemmat korjattiin, testeineen, ennen kuin PR meni ihmisarvosteluun.

Sokkoarvostelijat merkitsivät myös enemmän ylisuunnittelua architect-ajoissa kuin täysien ohjeiden ajoissa: 2,5 kohtaa arvostelua kohden G:ssä, kun A:n ja B:n ajoissa luku oli 0–1,0. Vähemmän vakavia havaintoja, enemmän nittejä. Ottaisin tuon vaihtokaupan, mutta se on vaihtokauppa.

Mitä muutin

• 33 kt:n CLAUDE.md:stä tuli 12 kt:n AGENTS.md, jota Codex lukee myös, ja CLAUDE.md vain importoi sen. Se säilyttää komennot, testaustahdin, arkkitehtuurin ja ne säännöt, joita malli ei voi päätellä koodista, kuten mitkä polut ovat kriittisiä ja että kahden agenttipinnan on pysyttävä tahdissa.
• Suunnitteluvaihe on poistettu putkesta. Triage antaa issuen suoraan toteutusvaiheelle, jonka kehoite kutistui kuuteen vaiheeseen: lue issue, luo haara, lataa architect- ja grain-ponytail-skillit, testaa, committaa, avaa draft-PR.
• Architect-skilli sai reunatapaustaulukon, briefiin Tests-kentän ja loppukierroksen, joka tarkistaa koko diffin issuea vasten eikä briefejä vasten. Tämä versio on julkinen osoitteessa github.com/LivinTribunal/architect-skill .

Repositoriomuutos on arvostelussa tämän kirjoitushetkellä.

Mitä tästä kannattaa ottaa mukaan

Jos CLAUDE.md:si kasvoi yksi tapaus kerrallaan, se maksaa todennäköisesti säännöistä, joita malli jo noudattaa. Karsi se siihen, mitä malli ei voi selvittää lukemalla koodia, ja mittaa ennen ja jälkeen oikealla tehtävällä sen sijaan, että luottaisit siihen, että enemmän ohjausta on turvallisempaa.

Pidä ohjeet, jotka muuttavat sitä, miten työ tehdään: kuka kirjoittaa koodin, miten siivu briefataan, mitä olemassa olevaa käytäntöä kopioidaan. Luovu suunnittele-sitten-toteuta-putkesta, jos päämallisi on nykyinen huippumalli. Kirjoita briefejä työntekijöille, älä suunnitelmia itsellesi.

Menetelmä

13 headless-ajoa Claude Code 2.1.289:llä 5. lokakuuta 2026, päämallina Opus 5.5, työntekijöinä Sonnet 5.5 siellä missä architect-skilli delegoi. Kaikki ajot alkoivat yhdestä FlowHunt-monorepon commitista, kukin omassa APFS-kloonissaan omalla Postgres-tietokannallaan, eristettynä muista ajoista ja kokeen omista tiedostoista. Broker puski jokaisen ajon commitin draft-PR:ään jäädytettyä perushaaraa vasten ja jatkoi sessiota CI:n tuloksella, enintään kolme kierrosta. Kustannus on session suurin total_cost_usd summattuna pääsession ja sen subagenttien yli. Tuotantolinjat ovat ei-tyhjiä lisättyjä rivejä testien, käännösten ja migraatioiden ulkopuolella.

Jokainen tulos sai kaksi sokkoarvostelua Opusilta yhdellä arviointikehikolla: oikeellisuus, hyväksymiskriteerit, syyn mukaisuus, yksityiset kentät ja piilotettu tila, ylisuunnittelu, tietoturva ja oikeudet, testit, migraatiot. Ehdokkaat sekoitettiin kirjainten alle, ja arvostelijat pystyivät lukemaan repositorion mutta eivät ajamaan mitään. Havainnot arvostelua kohden on keskiarvoistettu asetelman ajojen yli. Kun ajoja on yhdestä kolmeen asetelmaa kohden, yksittäisen asetelman keskiarvoa kannattaa pitää kohinaisena. Yllä olevat johtopäätökset ovat ne, jotka pitivät molemmilla kierroksilla.