Mitä opit

Tämä opas käsittelee harness-suunnittelua (harness engineering) ensimmäisistä periaatteista käytännön toteutukseen. Opit ymmärtämään, mitä se on, miksi OpenAI panosti suurimman sisäisen projektinsa sen varaan, millaiset arkkitehtuurimallit tekevät siitä toimivan ja miten voit soveltaa näitä periaatteita omiin AI-agenttien työnkulkuihin — käytitpä sitten Codex, Claude Code, OpenCode tai mitä tahansa muuta agenttijärjestelmää.

Harness-suunnittelu: Täydellinen opas AI-agenttien kehittämiseen vuonna 2026

Jos vuosi 2025 oli vuosi, jolloin AI-agentit todistivat pystyvänsä kirjoittamaan koodia, vuosi 2026 on vuosi, jolloin opimme, että agentti ei ole vaikein osa — vaan harness.

OpenAI:n Codex-tiimi julkaisi helmikuussa 2026 merkittävän blogikirjoituksen, jossa kuvattiin, kuinka he rakensivat tuotantosovelluksen, joka sisältää noin miljoona riviä koodia, joista nolla riviä oli ihmiskäden kirjoittamia. Salaisuus ei ollut parempi malli tai älykkäämpi prompt. Se oli järjestelmä, jonka he rakensivat agentin ympärille — harness. Lähde

Tämä opas purkaa jokaisen periaatteen, mallin ja käytännön tekniikan tuosta kokeilusta ja sen ympärille syntyneestä laajemmasta harness-suunnittelun liikkeestä.

Osa 1: Mitä on harness-suunnittelu?

Määritelmä

Harness-suunnittelu on tieteenala, jossa suunnitellaan koko ympäristö — tukirakenteet, palauteryhmät, dokumentaatio, arkkitehtuuriset rajoitteet ja koneellisesti luettavat artefaktit — joka mahdollistaa AI-koodausagenttien luotettavan ja korkealaatuisen työskentelyn mittakaavassa minimaalisella ihmisen väliintulolla.

Termi "harness" (valjaat) tulee hevosvarusteista: ohjakset, satula, kuolaimet — täydellinen varustesarja, jolla ohjataan voimakasta mutta arvaamatonta eläintä oikeaan suuntaan. Hallitsematon hevonen on vaarallinen. Valjastettu hevonen rakensi sivilisaatioita. Sama pätee AI-agentteihin. Lähde

Miksi se syntyi nyt

Siirtyminen prompt engineeringistä harness-suunnitteluun heijastaa AI-kehitysympäristön kypsymistä:

Lähde

Keskeinen oivallus, joka ajoi tämän muutoksen: agenteista tuli tarpeeksi kykeneviä, jolloin pullonkaula siirtyi mallin laadusta ympäristön laatuun. Huipputason malli, joka toimii huonosti jäsennellyssä repositoriossa, tuottaa huonompia tuloksia kuin keskinkertainen malli, joka toimii hyvin valjastetussa (harnessed) ympäristössä.

Osa 2: OpenAI Codex -kokeilu

Mittakaava

Viisi kuukautta kestäneessä sisäisessä kokeilussa OpenAI:n insinöörit rakensivat ja julkaisivat beta-tuotteen, joka sisälsi noin miljoona riviä koodia. Repositorio kattaa sovelluslogiikan, infrastruktuurin, työkalut, dokumentaation ja sisäiset kehittäjätyökalut. Järjestelmän ankkuroimiseksi ei ollut olemassa olevaa ihmisen kirjoittamaa koodia. Lähde

Tiimi

Projekti alkoi vain kolmella insinöörillä, jotka ohjasivat Codex-järjestelmää. Viiden kuukauden aikana avattiin ja yhdistettiin noin 1 500 pull requestia. Kun tiimi kasvoi seitsemään insinööriin, läpivirtaus kasvoi — mikä oli vastoin intuitiota ja viittasi siihen, että harness itse oli ensisijainen tuottavuuden moninkertaistaja, eivät yksittäiset taidot.

OpenAI arvioi, että he rakensivat järjestelmän noin kymmenesosassa siitä ajasta, joka koodin kirjoittamiseen käsin olisi mennyt. Lähde

Alkuperäinen runko

Projekti alkoi siten, että Codex CLI loi alkuperäisen rungon (scaffold) käyttäen GPT-5-mallia, ohjattuna pienellä määrällä olemassa olevia malleja:

• Repositorion rakenne ja hakemistokäytännöt
• CI/CD-konfiguraatio
• Koodin muotoilu- ja linting-säännöt
• Paketinhallinnan asennus
• Sovelluskehyksen boilerplate-koodi

Tästä siemenestä kaikki muu kasvoi agenttiohjatun kehityksen kautta.

Perjantai-ongelma

Varhain kokeilun aikana tiimi huomasi kriittisen ongelman: he käyttivät jokaisen perjantain — 20 % insinööriajastaan — siivoamalla sitä, mitä he kutsuivat "AI-hötöksi" (AI slop). Tämä sisälsi epäjohdonmukaisia malleja, monistettua logiikkaa, väärin nimettyjä muuttujia ja arkkitehtuurista poikkeamaa.

Tämä ei skaalautunut. Ratkaisu oli koodata heidän standardinsa suoraan harness-järjestelmään, jotta agentit tuottaisivat puhtaampaa jälkeä alusta alkaen, ja rakentaa automaattisia siivousjärjestelmiä jäljelle jäävälle poikkeamalle.

Osa 3: Viisi ydinperiaatetta

Periaate 1: Repositoriokeskeinen tieto (Repository-First Knowledge)

Agentin näkökulmasta mitään, mihin se ei pääse käsiksi kontekstissaan ajon aikana, ei ole olemassa. Tieto, joka elää Google Docsissa, chat-ketjuissa, Slack-viesteissä tai ihmisten päissä, on näkymätöntä järjestelmälle.

Tämä tarkoittaa, että kaiken tiedon on oltava repositoriossa paikallisina, versioituina artefakteina:

• Koodi — ensisijainen artefakti
• Markdown-dokumentaatio — arkkitehtuuripäätökset, käytännöt, perehdytysoppaat
• Schemat — API-sopimukset, tietokantaskemat, tyyppimääritelmät
• Suoritettavat suunnitelmat — vaiheittaiset tehtäväjaot, joita agentti voi seurata
• Konfiguraatio — linter-säännöt, CI-putket, muotoilustandardit

Tiimi oppi, että heidän oli tuotava yhä enemmän kontekstia repoon ajan myötä. Joka kerta kun agentti teki virheen kontekstin puutteen vuoksi, korjaus ei ollut parempi prompti — se oli kyseisen kontekstin lisääminen repositiorioon. Lähde

Käytännön toteutus:

# ARCHITECTURE.md (sijaitsee repon juuressa)

## Riippuvuussäännöt
- UI-komponentit voivat tuoda Service-kerroksesta, mutta eivät koskaan Repo-kerroksesta
- Service-kerros ei saa tuoda tietoa Runtime-kerroksesta
- Kaikki toimialueiden välinen viestintä tapahtuu tyypitetyn event busin kautta

## Nimeämiskäytännöt
- React-komponentit: PascalCase, pääte tarkoituksen mukaan (UserListPage, UserCard)
- Servicet: camelCase, pääte Service (userService, authService)
- Tyypit: PascalCase, etuliite domain (UserProfile, OrderItem)

## Testausvaatimukset
- Kaikki Service-funktiot vaativat yksikkötestejä
- Kaikki API-päätepisteet vaativat integraatiotestejä
- Kattavuusraja: 80 % per paketti

Periaate 2: Kultaiset periaatteet (Golden Principles)

Kultaiset periaatteet ovat mielipiteellisiä, mekaanisia sääntöjä, jotka on koodattu suoraan repositorioon ja jotka pitävät koodikannan luettavana ja johdonmukaisena tulevia agenttiajoja varten. Ne eivät ole tavoitteellisia ohjeita — ne ovat pakotettuja rajoitteita.

Esimerkkejä OpenAI-kokeilusta:

1. Suosi jaettuja apupaketteja käsin kirjoitettujen sijaan — keskittää invariantit niin, että kun käyttäytymisen on muututtava, se muuttuu yhdessä paikassa.
2. Älä tutki dataa YOLO-tyylillä — validoi rajat tai luota tyypitettyihin SDK:ihin, jotta agentit eivät vahingossa rakenna arvattujen datamuotojen päälle.
3. Yksi käsite, yksi tiedosto — jokaisen tiedoston tulisi edustaa yhtä käsitettä, mikä helpottaa agenttien työtä oikean sijainnin löytämisessä ja muokkaamisessa.
4. Eksplisiittinen ennen implisiittistä — vältä "maagista" käyttäytymistä, jonka ymmärtäminen vaatisi agentilta hiljaista tietoa.

Lähde

Nämä periaatteet eivät ole vain dokumentaatiota. Niitä valvovat:

• Linter-säännöt — mukautetut linterit (itse Codexin luomat), jotka liputtavat rikkomukset.
• Rakenteelliset testit — testit, jotka validoivat arkkitehtuurin noudattamisen.
• CI-portit — pull requestit, jotka rikkovat kultaisia periaatteita, hylätään automaattisesti.

Periaate 3: Kerrosarkkitehtuuri mekaanisella valvonnalla

Jokainen liiketoiminta-alue OpenAI-projektissa on jaettu kiinteään joukkoon kerroksia, joissa on tiukasti validoidut riippuvuussuunnat:

Types → Config → Repo → Service → Runtime → UI

Riippuvuudet virtaavat vain yhteen suuntaan. UI-komponentti voi riippua Runtime- ja Service-kerroksista, mutta Service ei saa koskaan tuoda (import) UI-kerroksesta. Repo voi riippua Config- ja Types-kerroksista, mutta ei koskaan Service-kerroksesta. Lähde

Näitä rajoitteita valvotaan mekaanisesti:

// structural-test.ts — valvoo riippuvuusrajoja
import { analyzeImports } from './tools/import-analyzer';

describe('Dependency Layer Enforcement', () => {
  it('Service layer must not import from Runtime', () => {
    const violations = analyzeImports({
      sourceLayer: 'service',
      forbiddenLayers: ['runtime', 'ui'],
    });
    expect(violations).toEqual([]);
  });

  it('Repo layer must not import from Service', () => {
    const violations = analyzeImports({
      sourceLayer: 'repo',
      forbiddenLayers: ['service', 'runtime', 'ui'],
    });
    expect(violations).toEqual([]);
  });
});

Rakenteelliset testit validoivat sääntöjen noudattamisen ja estävät modulaarisen kerrostuksen rikkomukset. Tämä ei ole ehdotus — se on CI:n valvoma pakko. Jokaisen pull requestin, oli se sitten ihmisen tai agentin luoma, on läpäistävä nämä testit.

Periaate 4: Automaattinen roskienkeruu (Automated Garbage Collection)

Vaikka käytössä on kultaiset periaatteet ja rakenteellinen valvonta, agenttien tuottama koodi rappeutuu ajan myötä. OpenAI-tiimi ratkaisi tämän toteuttamalla automaattisen roskienkeruun — toistuvia taustatehtäviä, jotka:

1. Skannaavat poikkeamia kultaisista periaatteista koko koodikannassa.
2. Päivittävät laatuluokitukset kullekin moduulille sääntöjen noudattamispisteiden perusteella.
3. Avaavat kohdennettuja refaktorointi-pull requesteja, jotka korjaavat tiettyjä poikkeamatyyppejä.

Tämä korvasi manuaalisen "perjantaisiivouksen" järjestelmällä, joka toimii jatkuvasti. Roskienkerääjä itse toimii Codex-agenttien voimalla, luoden itseään ylläpitävän silmukan. Lähde

# .github/workflows/garbage-collection.yml
name: Codebase Garbage Collection
on:
  schedule:
    - cron: '0 2 * * *'  # Suoritetaan öisin klo 02:00

jobs:
  gc-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run golden principle scanner
        run: npx codex-gc scan --principles ./GOLDEN_PRINCIPLES.md
      - name: Generate refactoring PRs
        run: npx codex-gc fix --auto-pr --max-prs 5

Periaate 5: Suoritettavat suunnitelmat (Executable Plans)

Ennen kuin agentit kirjoittavat koodia, ne kirjoittavat suunnitelmia. Nämä suunnitelmat eivät ole epämuodollisia muistiinpanoja — ne ovat jäsenneltyjä, suoritettavia dokumentteja, jotka määrittelevät:

• Tavoite: Mitä tehtävällä saavutetaan.
• Muokattavat tiedostot: Eksplisiittinen luettelo tiedostoista, joihin agentti koskee.
• Riippuvuudet: Muut tehtävät tai moduulit, joista tämä työ riippuu.
• Hyväksymiskriteerit: Kuinka todentaa, että työ on valmis.
• Rajoitteet: Arkkitehtuuriset säännöt, joita ei saa rikkoa.

# Plan: Add user notification preferences

## Objective
Salli käyttäjien määrittää, mitä ilmoituskanavia (email, SMS, push) he
käyttävät hälytyksiin, kategoria-kohtaisella tarkkuudella.

## Files to Modify
- src/types/user.ts — Lisää NotificationPreferences-tyyppi
- src/repo/userRepo.ts — Lisää getPreferences/setPreferences-metodit
- src/service/notificationService.ts — Suodata ilmoitukset asetusten mukaan
- src/ui/pages/SettingsPage.tsx — Lisää asetusten UI-osio

## Constraints
- On noudatettava Types → Repo → Service → UI -riippuvuusvirtaa
- NotificationPreferences-tyypin on oltava jaettu, ei monistettu
- Kaikki uudet metodit vaativat yksikkötestejä

## Acceptance Criteria
- [ ] Käyttäjä voi kytkeä email/SMS/push päälle/pois per ilmoituskategoria
- [ ] Asetukset säilyvät istuntojen välillä
- [ ] Kanavan kytkeminen pois päältä lopettaa ilmoitukset kyseisessä kanavassa 30 sekunnin sisällä

Suunnitelmat elävät repositoriossa markdown-tiedostoina, ne ovat versiohallinnassa ja ne voidaan tarkastaa ennen suoritusta — mikä antaa ihmisille tarkistuspisteen aikomuksen ja toteutuksen välillä.

Osa 4: Codex-agenttisilmukka

Ymmärrys siitä, miten Codex-agenttisilmukka toimii harnessin sisällä, on välttämätöntä tehokkaalle harness-suunnittelulle.

Silmukan arkkitehtuuri

OpenAI julkaisi yksityiskohtaisen erittelyn Codex-agenttisilmukasta kirjoituksessaan "Unrolling the Codex agent loop." Lähde Silmukka noudattaa tätä sykliä:

Lue konteksti → Suunnittele → Suorita → Validoi → Commit (tai yritä uudelleen)

Jokainen iteraatio:

1. Lue konteksti: Agentti lukee asiaankuuluvat tiedostot, dokumentaation, skemat ja tehtäväsuunnitelman repositoriosta.
2. Suunnittele: Kontekstin perusteella agentti päättää, mitä muutoksia tehdään.
3. Suorita: Agentti kirjoittaa tai muokkaa koodia.
4. Validoi: Harness ajaa testit, linterit ja rakenteelliset tarkistukset muutoksille.
5. Commit tai yritä uudelleen: Jos validointi menee läpi, agentti tekee commitin. Jos se epäonnistuu, agentti lukee virheilmoituksen ja yrittää uudelleen.

Harnessin rooli on tehdä vaiheista 1 ja 4 mahdollisimman tietopitoisia. Mitä enemmän kontekstia agentti lukee, sitä parempi on sen suunnitelma. Mitä tarkempaa validointipalaute on, sitä nopeammin se löytää toimivan ratkaisun.

App Server -harness

Kirjoituksessaan "Unlocking the Codex harness: how we built the App Server," OpenAI kuvailee konkreettista infrastruktuuria, joka pyörittää agenttisilmukkaa. Lähde App Server tarjoaa:

• Hiekkalaatikoituja suoritusympäristöjä jokaiselle agenttitehtävälle.
• Esimääritetyn pääsyn työkaluihin (tiedostojärjestelmä, terminaali, selain).
• Automaattisen kontekstin syöttämisen repositorion artefakteista.
• Reaaliaikaista validointipalautetta, jotta agentit näkevät testien epäonnistumiset heti.

Osa 5: Harness-suunnittelun soveltaminen tiimissäsi

Aloittaminen: Pienin toimiva harness (Minimum Viable Harness)

Sinun ei tarvitse kopioida koko OpenAI:n infrastruktuuria hyötyäksesi harness-suunnittelusta. Aloita näistä peruselementeistä:

Vaihe 1: Luo ARCHITECTURE.md

Dokumentoi projektisi arkkitehtuurisäännöt koneellisesti luettavassa muodossa repositorion juureen. Sisällytä:

• Moduulien rajat ja sallitut riippuvuudet
• Nimeämiskäytännöt
• Tiedostojen organisointisäännöt
• Testausvaatimukset

Tämä yksi tiedosto parantaa dramaattisesti agentin tuotoksen laatua, koska agentit lukevat sen ennen muutosten tekemistä.

Vaihe 2: Lisää rakenteelliset testit

Kirjoita testejä, jotka validoivat arkkitehtuurisääntösi. Nämä testit eivät tarkista liiketoimintalogiikkaa — ne tarkistavat, että koodi on organisoitu oikein:

// Mikään service-tiedosto ei saa tuoda tietoa UI-moduulista
test('service layer isolation', () => {
  const serviceFiles = glob('src/services/**/*.ts');
  for (const file of serviceFiles) {
    const imports = extractImports(file);
    const uiImports = imports.filter(i => i.startsWith('../ui/'));
    expect(uiImports).toHaveLength(0);
  }
});

Vaihe 3: Määritä CI-validointi

Varmista, että CI-putkesi ajaa rakenteelliset testit, linterit ja tyyppitarkistukset jokaisessa pull requestissa — myös agenttien luomissa. Agentin tulisi nähdä sama validointitulos kuin ihmiskehittäjän.

Vaihe 4: Kirjoita tehtäväsuunnitelmat ennen suoritusta

Ennen kuin pyydät agenttia toteuttamaan ominaisuuden, kirjoita jäsennelty suunnitelmadokumentti, joka määrittelee muokattavat tiedostot, noudatettavat rajoitteet ja hyväksymiskriteerit. Tallenna nämä suunnitelmat repositorioosi.

Vaihe 5: Määritä automaattinen siivous

Toteuta viikoittainen tai öinen CI-ajo, joka skannaa koodikantasi poikkeamista dokumentoiduista standardeista ja luo kohdennettuja refaktorointi-PR:iä.

Agenttijärjestelmän valinta

Harness-suunnittelun periaatteet pätevät riippumatta siitä, mitä agenttia käytät:

Harness elää repositoriossasi, ei agentissasi. Tämä tarkoittaa, että voit vaihtaa agenttia menettämättä harness-investointiasi.

Skaalaaminen yhdestä agentista moneen

OpenAI-kokeilu osoitti, että harness-suunnittelu mahdollistaa rinnakkaisen agenttien suorituksen. Koska harness valvoo arkkitehtuurisia rajoja, useat agentit voivat työskennellä koodikannan eri osissa samanaikaisesti ilman konflikteja.

Keskeiset vaatimukset rinnakkaiselle suoritukselle:

1. Selkeä moduulien omistajuus — jokainen agentti työskentelee määritellyn rajan sisällä.
2. Tyypitetyt rajapinnat moduulien välillä — agentit voivat koodata rajapintoja vasten tuntematta toteutuksen yksityiskohtia.
3. Merge-konfliktien estäminen — tehtävät rajataan minimoimaan tiedostojen päällekkäisyys.
4. Keskitetty validointi — kaikki agentit lähettävät koodinsa samaan CI-putkeen.

Osa 6: Yleiset sudenkuopat ja vastamallit (Anti-Patterns)

Vastamalli 1: Agentin kohteleminen harnessina

Agentti ei ole harness. Harness on ympäristö, jossa agentti toimii. Älykkäämmän mallin pyytäminen korvaamaan huonosti jäsennelty repositorio on väärä lähestymistapa. Korjaa ympäristö, älä promptia.

Vastamalli 2: Dokumentaatio väärässä paikassa

Jos arkkitehtuuripäätöksesi elävät Confluencessa, Notionissa tai Google Docsissa, agentit eivät näe niitä. Korjaus on yksinkertainen mutta vaatii kurinalaisuutta: siirrä kaikki kehitykseen liittyvä dokumentaatio repositoriooon.

Vastamalli 3: Manuaalinen siivous automaattisen valvonnan sijaan

Jos käytät merkittävästi aikaa agentin luoman koodin siivoamiseen, tarvitset parempaa valvontaa, et lisää siivousistuntoja. Jokaisesta toistuvasta siivoustehtävästä tulisi tulla joko linter-sääntö, rakenteellinen testi tai automaattinen refaktorointityö.

Vastamalli 4: Liiallinen rajoittaminen

Liian jäykkä harness estää agentteja löytämästä luovia ratkaisuja. Tavoitteena on rajoittaa arkkitehtuuria, ei toteutusta. Kerro agenteille, mitä moduuleja he voivat muokata ja mitkä riippuvuudet ovat sallittuja, mutta anna heidän päättää, miten logiikka toteutetaan noiden rajojen sisällä.

Vastamalli 5: Agentin palautteen huomiotta jättäminen

Kun agentti epäonnistuu toistuvasti tietyissä tehtävissä, epäonnistuminen viittaa yleensä aukkoon harness-järjestelmässä, ei agentin rajoitteisiin. Seuraa epäonnistumismalleja ja käytä niitä dokumentaation, rakenteellisten testien tai arkkitehtuuristen rajoitteiden parantamiseen.

Osa 7: Harness-suunnittelun tulevaisuus

Martin Fowlerin näkökulma

Martin Fowler julkaisi analyysin harness-suunnittelusta blogissaan todeten, että se edustaa perustavanlaatuista muutosta ohjelmistotiimien toimintatavassa. Tieteenala lainaa vuosikymmenten ohjelmistosuunnittelun parhaita käytäntöjä — jatkuva integraatio (continuous integration), arkkitehtuuripäätösten tallenteet (architecture decision records), riippuvuuksien injektointi (dependency injection) — mutta soveltaa niitä uudelleen agenttiohjattuun maailmaan. Lähde

HumanLayer-viitekehys

HumanLayer-tiimi julkaisi analyysinsa kutsuen harness-suunnittelua "taitoasiaksi" (skill issue) — väittäen, että kyky suunnitella tehokkaita harness-järjestelmiä on ensisijainen erottava tekijä huippusuoriutuvien ja vaikeuksissa olevien insinööritiimien välillä. Lähde

Mitä tämä tarkoittaa kehittäjille

Harness-suunnittelu ei korvaa kehittäjän taitoa — se suuntaa sen uudelleen. Koodin kirjoittamisen sijaan kokeneet insinöörit suunnittelevat järjestelmiä, jotka mahdollistavat agenttien koodata hyvin. Merkitykselliset taidot siirtyvät toteutuksesta arkkitehtuuriin, koodauksesta järjestelmäsuunnitteluun ja testien kirjoittamisesta testikehysten suunnitteluun.

Tiimeille, jotka rakentavat sovelluksia, alustat kuten ZBuild sisällyttävät jo harness-suunnittelun periaatteita sovellusten rakentamisen työnkulkuihin. Sen sijaan, että kehittäjien täytyisi suunnitella omat harnessinsa alusta alkaen, ZBuild tarjoaa esimääritettyjä arkkitehtuurimalleja, riippuvuuksien hallintaa ja validointijärjestelmiä, jotka ohjaavat AI-agentteja kohti korkealaatuista tuotosta — antaen kehittäjien keskittyä tuotepäätöksiin infrastruktuurin sijaan.

Kolme horisonttia

Tulevaisuudessa harness-suunnittelun uskotaan kehittyvän kolmessa vaiheessa:

1. Lähitulevaisuus (2026): Tiimit omaksuvat repositoriokeskeisen dokumentaation, rakenteelliset testit ja kultaiset periaatteet. Agenttiavusteisesta kehityksestä tulee vakiokäytäntö hyvin valjastetuissa projekteissa.

2. Keskipitkä aikaväli (2027): Itse harnessin luomisesta tulee agenttiohjattua. Agentit analysoivat olemassa olevia koodikantoja ja ehdottavat harness-konfiguraatioita — linter-sääntöjä, rakenteellisia testejä, riippuvuusrajoja — havaitsemiensa mallien perusteella.

3. Pitkä aikaväli (2028+): Harness-järjestelmistä tulee mukautuvia. Staattisten sääntöjen sijaan ne kehittyvät agenttien luoman koodin tulosten perusteella, tiukentaen automaattisesti rajoitteita alueilla, joilla agentit tekevät usein virheitä, ja höllentäen niitä siellä, missä ne onnistuvat jatkuvasti.

Osa 8: Käytännön muistilista

Käytä tätä muistilistaa arvioidaksesi tiimisi harness-suunnittelun kypsyyttä:

Perusta (Aloita tästä)

• ARCHITECTURE.md löytyy repositorion juuresta
• Koodin muotoilu on automatisoitu (Prettier, Black, gofmt)
• Linting ajetaan jokaisessa pull requestissa
• Tyyppitarkistus on pakollista (TypeScript strict, mypy, jne.)

Keskitaso

• Rakenteelliset testit validoivat riippuvuusrajat
• Kultaiset periaatteet on dokumentoitu ja koneellisesti valvottavissa
• Tehtäväsuunnitelmat kirjoitetaan ennen agentin suoritusta
• Agentin luomat PR:t käyvät läpi saman CI:n kuin ihmisten PR:t

Edistynyt

• Automaattinen roskienkeruu toimii aikataulun mukaan
• Useat agentit voivat työskennellä rinnakkain ilman konflikteja
• Agenttien epäonnistumismalleja seurataan ja käytetään harnessin parantamiseen
• Itse harness on versiohallinnassa ja se katselmoidaan kuten koodi

Asiantuntija

• Agentit luovat osia harnessista (linter-säännöt, rakenteelliset testit)
• Laatuluokitukset määritetään automaattisesti jokaiselle moduulille
• Harness-parannukset ovat tietopohjaisia ja perustuvat agenttien onnistumisasteisiin
• Tiimi julkaisee enemmän koodia per insinööri viikossa kuin ennen agenttien käyttöönottoa

Johtopäätös

Harness-suunnittelu ei ole muoti-ilmiö. Se on ohjelmistosuunnittelun luonnollinen evoluutio aikakaudella, jolloin AI-agentit pystyvät kirjoittamaan tuotantokoodia, mutta tarvitsevat jäsenneltyjä ympäristöjä tehdäkseen sen hyvin. OpenAI:n miljoonan rivin kokeilu todisti konseptin toimivuuden mittakaavassa, ja heidän määrittelemänsä periaatteet — repositoriokeskeinen tieto, kultaiset periaatteet, kerrosarkkitehtuuri, automaattinen roskienkeruu ja suoritettavat suunnitelmat — ovat sovellettavissa kaikenkokoisiin tiimeihin.

Tiimit, jotka hallitsevat harness-suunnittelun vuonna 2026, julkaisevat koodia nopeammin, ylläpitävät korkeampaa laatua ja skaalautuvat tehokkaammin kuin ne, jotka pitävät AI-agentteja vain hienostuneina automaattitäydennyksinä. Agentti on hevonen. Harness on se, mikä tekee siitä hyödyllisen.

Lähteet

• Harness Engineering: Leveraging Codex in an Agent-First World — OpenAI
• Unlocking the Codex Harness: How We Built the App Server — OpenAI
• Unrolling the Codex Agent Loop — OpenAI
• OpenAI Introduces Harness Engineering — InfoQ
• Harness Engineering — Martin Fowler
• Skill Issue: Harness Engineering for Coding Agents — HumanLayer
• From Prompt Engineering to Harness Engineering — SoftmaxData
• How to Build an Agent Harness — Study Notes
• Harness Engineering — GTCode
• OpenAI Harness Engineering: Ship 1M Lines of Code — The Neuron
• How OpenAI Built 1M Lines of Code Using Only Agents — TonyLee
• Harness Engineering — The New Discipline — CodeNote