Miksi tekoälyagenttiesi mikromanageeraus tekee niistä itse asiassa tyhmempiä

Avaa satunnainen system_prompt.txt modernista GitHub-reposta tänään, ja mitä näet? Yleensä se on paniikinomainen tekstimuuri. "ÄLÄ tee X. Sinun ON tuotettava tasan kolme luettelokohtaa. ÄLÄ KOSKAAN käytä tätä kirjastoa."

Kehittäjät kohtelevat ihmiskunnan historian edistyneimpiä päättelykoneistoja kuin hauraita regex-skriptejä.

Tämä vainoharhaisuus on historiallisesti täysin ymmärrettävää. Vielä vuosi tai pari sitten varhaiset LLM:t vaativat jatkuvaa kädestä pitämistä pysyäkseen edes aiheessa. Mutta ajat ovat muuttuneet. Modernit mallit ovat uskomattoman fiksuja, mutta silti kirjoitamme prompteja kuin ohjelmoisimme 1980-luvun mikroaaltouunia. Yritämme kovakoodata älykkyyttä.

Vercelillä tapahtui hiljattain jotain kiehtovaa, mikä todistaa tämän pointin. Heidän insinööritiiminsä julkaisi erittelyn siitä, miten he paransivat v0-tuotettaan, ja paljasti epäloogiselta tuntuvan siirron: he poistivat 80 % agenttinsa työkaluista.

Lopputulos? Järjestelmä ei hajonnut. Se itse asiassa parani huomattavasti. Karsimalla pois liian tarkkaan määritellyt työkalut ja jäykät suojakaiteet, he vähensivät hämmennystä ja antoivat mallin tehdä sitä, missä se on parhaimmillaan – päätellä tiensä ongelman läpi. Vähemmän kitkaa johti parempaan koodiin.

Tässä on syvällinen opetus jokaiselle, joka rakentaa tekoälyn avulla juuri nyt: Anna periaatteita, älä jäykkiä sääntöjä.

Kun kerrot LLM:lle tarkalleen ja vaihe vaiheelta, mitä sen pitää tehdä, pakotat sen käyttämään rajallisen huomionsa (laskentatehonsa) sääntöjen noudattamiseen laadun sijaan. Viet siltä kyvyn hyödyntää valtavaa opetusdataansa tyylikkäämmän ratkaisun löytämiseksi kuin se, jonka itse kovakoodasit.

Nähdäksesi eron, katso miten useimmat kehittäjät kirjoittavat agenttien prompteja verrattuna siihen, miten heidän pitäisi niitä kirjoittaa.

Huono tapa (Jäykät säännöt):

"Kirjoita Python-funktio käyttäjädatan hakemiseen. Sinun on käytettävä requests-kirjastoa. Sinun on käsiteltävä virheet try/except-lohkolla. Sinun on palautettava dictionary, jossa on tasan avaimet 'name', 'email' ja 'status'. Älä käytä asynciä. Lisää kommentti jokaiselle riville."

Hyvä tapa (Periaatteet ja tavoitteet):

"Kirjoita robusti Python-funktio käyttäjädatan hakemiseen. Suosi moderneja standardikirjastoja. Koodin tulee olla tuotantovalmista, eli sen on käsiteltävä verkkovirheet ja reunatapaukset (edge cases) tyylikkäästi. Priorisoi luettavuutta ja puhdasta arkkitehtuuria kikkailun sijaan. Downstream-järjestelmä odottaa standardeja käyttäjäprofiileja (name, email, status)."

Huomaatko eron? Ensimmäinen esimerkki kohtelee tekoälyä kuin junior-kehittäjää, johon ei voi luottaa. Toinen kohtelee sitä kuin senior-insinööriä, joka ymmärtää tavoitteen ja kontekstin. Kerrot sille, miltä hyvä lopputulos näyttää ja miksi, minkä jälkeen astut syrjään ja annat sen keksiä, miten se tehdään.

Tähän sääntöön on tietysti yksi suuri poikkeus.

Kun agentit keskustelevat toisten agenttien kanssa – tai kun upstream-agentti siirtää dataa jäykälle downstream-tietokantaparserille – tarvitaan ehdotonta tarkkuutta. Koneiden väliset tiedonsiirrot vaativat tarkkoja, joustamattomia JSON-skeemoja. Mutta kun kyse on päättelystä, generoinnista ja ongelmanratkaisusta? Höllennä otetta.

Jos haluat välittömästi päivittää koodausavustajasi tänään, kopioi ja liitä tämä täsmällinen lohko claude.md- tai memory.md -tiedostoosi tai agenttisi ydin-system promptiin:

## Prompt Writing Philosophy
When writing LLM prompts (system prompts, skill specs, subagent prompts): **give principles, not rigid rules.**
- Tell the LLM what good output looks like and why — let it figure out how
- Avoid prescribing exact fields, counts, or formats unless the output is a machine-consumed intermediate
- Exception: structured handoffs between agents can be rigid because downstream agents need consistent field names

Lopeta koneen mikromanagerointi. Luota moderniin LLM:ään. Ne ovat nopeampia, fiksumpia ja äärettömän paljon kyvykkäämpiä, kun lakkaamme kohtelemasta niitä kuin taaperoita.