Harness-suunnittelu: Järjestelmien rakentaminen tekoälyagenttien ympärille (2026)

TL;DR

Mitä on harness-suunnittelu?

Harness-suunnittelu (Harness engineering) on tieteenala, jossa rakennetaan järjestelmiä, työkaluja, rajoitteita ja palautesilmukoita koodaavien tekoälyagenttien ympärille niiden luotettavuuden ja tuottavuuden parantamiseksi.

Termin loi Mitchell Hashimoto (HashiCorpin perustajajäsen), ja se sai valtavirran huomiota, kun OpenAI julkaisi Codex-artikkelinsa aiheesta alkuvuodesta 2026.

Perusidea on yksinkertainen:

Agentti = Malli + Harness

Malli tarjoaa älykkyyden. Harness tekee tuosta älykkyydestä hyödyllistä. Parempi harness on usein tärkeämpi kuin parempi malli.

Miksi se on tärkeää nyt

Vuonna 2025 jokainen tiimi otti käyttöön koodaavat tekoälyagentit. Vuonna 2026 voittavia tiimejä ovat ne, jotka suunnittelivat agenttiympäristönsä — eivät ne, jotka vain valitsivat parhaan mallin.

Mitchell Hashimoton ohjaava periaate:

"Aina kun huomaat agentin tekevän virheen, käytä aikaa sellaisen ratkaisun suunnitteluun, ettei agentti tee samaa virhettä enää koskaan."

Tämä ei ole prompt-suunnittelua. Tämä on järjestelmäsuunnittelua (systems engineering) tekoälylle.

Todisteet: Harness > Malli

LangChain suoritti kontrolloidun kokeen Terminal Bench 2.0 -alustalla. Muuttamalla vain harnessia ja pitämällä alla olevan mallin samana, he paransivat koodausagenttinsa tarkkuutta 52.8 prosentista 66.5 prosenttiin — eli 26 prosentin parannus.

Muutokset sisälsivät:

• Paremmat kontekstitiedostot (AGENTS.md)


• Rakenteelliset tulosterajoitteet


• Itsevarmistussilmukat


• Työkalujen optimointi

Harnessin 7 komponenttia

1. Kontekstisuunnittelu

Kontekstisuunnittelu on perusta. Tässä vaiheessa agentille annetaan kartta koodikannasta, käytännöistä ja rajoitteista.

• CLAUDE.md / AGENTS.md -tiedostot projektin juuressa
• Hakemistokartat ja arkkitehtuurikuvaukset
• Koodaustyylisäännöt ja nimeämiskäytännöt

# CLAUDE.md esimerkki
## Arkkitehtuuri
- src/app/ — Next.js app router -sivut
- src/lib/ — jaetut apuohjelmat ja API-asiakkaat
- src/components/ — React-komponentit (saman hakemiston tyylit)

## Säännöt
- Käytä oletuksena palvelinkomponentteja (server components)
- Älä koskaan tuo moduuleja node_modules-hakemistosta suoraan komponentteihin
- Kaikki API-kutsut kulkevat tiedoston src/lib/api.ts kautta

2. Arkkitehtuurirajoitteet

Sen sijaan, että toivoisit agentin valitsevan oikean arkkitehtuurin, pakota se.

• Jäykät kerrosarkkitehtuurit, jotka linterit varmistavat
• Rakenteelliset testit, jotka epäonnistuvat, jos malleja rikotaan
• Tuontirajoitukset ESLint-sääntöjen tai mukautettujen skriptien kautta

3. Työkalut & MCP-palvelimet

Agentit tarvitsevat työkaluja ollakseen tehokkaita. Parhaat harnessit tarjoavat sisäisiä työkaluja seuraavasti:

• CLI-kääreet — suosi tunnettuja komentorivityökaluja (git, docker, npm) räätälöityjen työkalujen sijaan
• MCP (Model Context Protocol) -palvelimet — anna agenttien kutsua sisäisiä rajapintoja, tietokantoja ja palveluita
• Tiedostojärjestelmän käyttöoikeudet — rajattu tiettyihin hakemistoihin vahinkojen välttämiseksi

4. Alagentit & kontekstipalomuurit

Pitkäkestoiset agenttisessiot kerryttävät kontekstia, mikä lopulta heikentää suorituskykyä — tätä kutsutaan kontekstin rappeutumiseksi (context rot).

Ratkaisu: alagentit kontekstipalomuureilla.

• Jaa monimutkaiset tehtävät erillisiin osatehtäviin
• Jokainen osatehtävä ajetaan omassa istunnossaan puhtaalla kontekstilla
• Välitä agenttien välillä vain rakenteellisia tuloksia, älä raakaa keskustelua

1. Alustusagentti (Initializer Agent) — suunnittelee työn, luo ominaisuuslistan
2. Koodausagentti (Coding Agent) — toteuttaa jokaisen ominaisuuden eristyksissä

5. Koukut & vastapaine (Hooks & Back-Pressure)

Automatisoidut palautesilmukat, jotka havaitsevat virheet ennen kuin ne kumuloituvat:

• Pre-commit-koukut — tyypintarkistus, linting, muotoilu
• Testien ajajat — agenttien tulisi ajaa testit jokaisen muutoksen jälkeen
• Build-varmistus — epäonnistu nopeasti, jos koontiversio rikkoutuu

6. Itsevarmistussilmukat

Pakota agentit varmistamaan oma työnsä ennen tehtävän merkitsemistä valmiiksi:

• Aja testit muutosten jälkeen
• Tarkista, että build menee läpi
• Varmista, että tuloste vastaa määrittelyä
• Ota kuvakaappaus ja vertaa (UI-työssä)

7. Edistymisen dokumentointi

Pitkäkestoisissa tehtävissä (yli 30 minuuttia):

• Pidä yllä edistymistiedostoa, joka seuraa suoritettuja vaiheita
• Tee commit-viestejä usein, jotta seuraavat istunnot voivat jatkaa
• Käytä rakenteellisia tehtävälistoja, älä vapaamuotoisia muistiinpanoja

Tuloksia tosielämästä

OpenAI Codex -tiimi

3 insinööriä tuotti miljoonan rivin koodikannan ilman yhtäkään manuaalisesti kirjoitettua koodiriviä 5 kuukauden aikana. He keskiarvottivat 3,5 hyväksyttyä PR:ää per insinööri per päivä — suorituskyky, joka on mahdoton ilman kypsää harnessia.

Heidän harnessinsa sisälsi: tiukat commit-käytännöt, automatisoidun testauksen jokaisessa PR:ssä ja agenttitietoiset CI/CD-putket.

Stripen "Minionit"

Stripen sisäinen järjestelmä tuottaa yli 1 000 hyväksyttyä PR:ää viikossa tekoälyagenttien avulla. Heidän harnessinsa sisältää:

• Tiukasti rajatut tehtävämäärittelyt
• Pakollinen koodikatselmointi ihmisen toimesta
• Automaattinen regressiotestaus
• Palautusautomaatio (rollback)

Anthropicin kahden agentin arkkitehtuuri

Anthropic julkaisi lähestymistapansa tehokkaisiin harnesseihin pitkäkestoisille agenteille:

• Rakenteelliset ominaisuuslistat agenttien välisenä kättelymuotona
• Git-pohjainen edistymisen seuranta, jotta agentit voivat jatkaa keskeytyksen jälkeen
• Selkeät poistumiskriteerit, jotta agentit tietävät milloin lopettaa

Näin aloitat harnessisi rakentamisen

Vaihe 1: Luo kontekstitiedosto

Lisää CLAUDE.md (tai AGENTS.md) projektisi juureen:

# Projekti: [Projektisi nimi]

## Teknologiapino
[Framework, kieli, tietokanta, houstaus]

## Arkkitehtuuri
[Hakemistorakenne lyhyillä kuvauksilla]

## Säännöt
[5-10 ehdotonta sääntöä, joita agentin on noudatettava]

## Yleiset tehtävät
[Kuinka ajaa testit, buildata, julkaista]

Vaihe 2: Lisää rakenteellisia rajoitteita

# Esimerkki: ESLint-sääntö, joka estää suorat DB-tuonnit komponenteissa
# .eslintrc — no-restricted-imports -sääntö

Määritä pre-commit-koukut, jotka valvovat sääntöjäsi automaattisesti.

Vaihe 3: Rakenna varmistussilmukat

Varmista, että agenttisi voi:

1. Ajaa testit (npm test, pytest jne.)


2. Tarkistaa tyypit (tsc --noEmit, mypy)


3. Tehdä lint-tarkistuksen (eslint ., ruff check)

Vaihe 4: Rajaa agentti-istunnot

Älä anna agentille koko tehtävälistaa kerralla. Sen sijaan:

• Yksi ominaisuus per istunto
• Yksi bugin korjaus per istunto
• Selkeät hyväksymiskriteerit jokaiselle tehtävälle

Vaihe 5: Kehitä harnessia iteratiivisesti

Joka kerta kun agentti tekee virheen:

1. Tunnista perisyy
2. Lisää sääntö, rajoite tai koukku, joka estää sen
3. Testaa korjaus

Harness-suunnittelu vs. Prompt-suunnittelu

Prompt-suunnittelu on edelleen hyödyllistä, mutta se on vain pieni osa kokonaisuutta. Harness-suunnittelu on se tekijä, joka moninkertaistaa hyödyn.

Nouseva rooli: Harness-insinööri

Ohjelmistosuunnittelu on jakautumassa kahteen osaan:

1. Ympäristön rakentaminen — rakenteen, työkalujen, rajoitteiden ja palautesilmukoiden luominen
2. Työn hallinta — rinnakkaisten agenttisessioiden suunnittelu, katselmointi ja orkestointi

Ei pidä sekoittaa: Harness.io

Jos etsit "Harness Engineeringiä" ja tarkoitit DevOps-alustaa — Harness.io on täysin eri asia. Se on tekoälypohjainen CI/CD-alusta, jonka arvoksi arvioitiin 5,5 miljardia dollaria (joulukuussa 2025). Se tarjoaa jatkuvaa integraatiota, toimitusta, feature flageja, pilvikustannusten hallintaa ja tietoturvatestausta.

Vaikka Harness.io ja harness-suunnittelu jakavat nimen, ne ratkaisevat eri ongelmia. Niiden välillä on kuitenkin mielenkiintoinen yhteys: Harness.io:n tekoälypohjainen DevOps on tavallaan harness-suunnittelun periaatteiden soveltamista julkaisuputkeen.

Loppupäätelmä

Malli on moottori. Harness on auto. Kukaan ei voita kisaa pelkällä moottorilla.

Jos käytät tekoälyagentteja koodaamiseen vuonna 2026 etkä investoi harnessiin, jätät suurimman osan hyödystä käyttämättä. Aloita kontekstitiedostosta, lisää rajoitteita, rakenna varmistussilmukoita ja iteroi aina, kun jokin menee vikaan.

Tiimit, jotka toimittavat nopeimmin, eivät käytä parempia malleja. He käyttävät parempia harnesseja.