Amit tanulni fogsz

Ez az útmutató az alapoktól a gyakorlati megvalósításig fedi le a harness engineering területét. Megértheted, mi ez, miért tette fel az OpenAI a legnagyobb belső projektjét erre, melyek azok a specifikus architekturális minták, amelyek működőképessé teszik, és hogyan alkalmazhatod ezeket az elveket a saját AI agent munkafolyamataidban — függetlenül attól, hogy Codex, Claude Code, OpenCode vagy bármilyen más agent rendszert használsz.

Harness Engineering: A teljes útmutató az AI agent fejlesztéshez 2026-ban

Ha 2025 az az év volt, amikor az AI agentek bebizonyították, hogy tudnak kódot írni, akkor 2026 az az év, amikor megtanultuk, hogy nem az agent a nehéz rész — hanem a harness.

Az OpenAI Codex csapata 2026 februárjában közzétett egy mérföldkőnek számító blogbejegyzést, amelyben leírták, hogyan építettek fel egy nagyjából egymillió sornyi kódot tartalmazó produkciós alkalmazást úgy, hogy egyetlen sort sem ember írt. A titok nem egy jobb modell vagy egy okosabb prompt volt. Hanem az a rendszer, amit az agent köré építettek — a harness. Forrás

Ez az útmutató lebont minden elvet, mintát és gyakorlati technikát ebből a kísérletből és a köré épült szélesebb harness engineering mozgalomból.

1. rész: Mi az a Harness Engineering?

A definíció

A harness engineering az a tudományág, amely a teljes környezet — állványzat (scaffolding), visszacsatolási hurkok, dokumentáció, architekturális korlátok és gépileg olvasható melléktermékek (artifacts) — megtervezésével foglalkozik, amely lehetővé teszi az AI coding agentek számára, hogy megbízható, kiváló minőségű munkát végezzenek nagy léptékben, minimális emberi beavatkozással.

A "harness" kifejezés a lovas szerszámzatból származik: gyeplő, nyereg, zabla — az eszközök teljes készlete egy erőteljes, de kiszámíthatatlan állat helyes irányba tereléséhez. Egy kontrollálatlan ló veszélyes. Egy felszerszámozott (harnessed) ló civilizációkat épített. Ugyanez vonatkozik az AI agentekre is. Forrás

Miért most jelent meg?

A prompt engineeringről a harness engineeringre való áttérés az AI fejlesztési környezet érettségét tükrözi:

Forrás

A kulcsfontosságú felismerés, amely ezt az átmenetet vezérelte: az agentek elég képessé váltak ahhoz, hogy a szűk keresztmetszet a modellminőségről a környezetminőségre helyeződjön át. Egy csúcstechnológiás modell egy rosszul strukturált repository-ban rosszabb eredményeket produkál, mint egy középszerű modell egy jól felépített harness környezetben.

2. rész: Az OpenAI Codex kísérlet

A lépték

Egy öthónapos belső kísérlet során az OpenAI mérnökei egy nagyjából egymillió sornyi kódot tartalmazó béta terméket építettek és adtak ki. A repository felöleli az alkalmazáslogikát, az infrastruktúrát, az eszközöket, a dokumentációt és a belső fejlesztői segédprogramokat. Nem létezett korábban ember által írt kód, amely horgonyként szolgált volna a rendszernek. Forrás

A csapat

A projekt mindössze három mérnökkel indult, akik a Codex-et irányították. Az öthónapos időszak alatt nagyjából 1500 pull requestet nyitottak meg és vontak össze (merge). Ahogy a csapat hét mérnökre bővült, az áteresztőképesség nőtt — ami egy ellentmondásos eredmény, sugallva, hogy maga a harness volt az elsődleges produktivitás-szorzó, nem pedig az egyéni képességek.

Az OpenAI becslése szerint a rendszert körülbelül tizedannyi idő alatt építették fel, mint amennyi ideig a kód kézzel történő megírása tartott volna. Forrás

A kezdeti állványzat (Scaffold)

A projekt a Codex CLI-vel kezdődött, amely GPT-5 használatával generálta a kezdeti állványzatot, meglévő sablonok kis készlete alapján:

• Repository struktúra és könyvtárkonvenciók
• CI/CD konfiguráció
• Kódformázási és linting szabályok
• Package manager beállítások
• Alkalmazás-keretrendszer boilerplate kódja

Ebből a magból minden más agent-vezérelt fejlesztéssel nőtt ki.

A pénteki probléma

A kísérlet elején a csapat felfedezett egy kritikus problémát: minden pénteket — a mérnöki idejük 20%-át — azzal töltötték, hogy feltakarítsák az általuk "AI slop"-nak (AI-szemétnek) nevezett dolgokat. Ez következetlen mintákat, duplikált logikát, rosszul elnevezett változókat és architekturális elhajlást (drift) tartalmazott.

Ez nem volt skálázható. A megoldás az volt, hogy a szabványaikat magába a harness-be kódolták, így az agentek már kezdettől fogva tisztább kimenetet produkáltak, és automatizált tisztító rendszereket építettek a maradék elhajlás kezelésére.

3. rész: Az öt alapelv

1. alapelv: Repository-első tudás

Az agent szemszögéből minden, amihez nem fér hozzá kontextusban futás közben, gyakorlatilag nem létezik. A Google Docs-ban, chat szálakban, Slack üzenetekben vagy az emberek fejében lévő tudás láthatatlan a rendszer számára.

Ez azt jelenti, hogy minden tudásnak a repository-ban helyi, verziózott melléktermékként (artifact) kell léteznie:

• Kód — az elsődleges melléktermék
• Markdown dokumentáció — architekturális döntések, konvenciók, onboarding útmutatók
• Sémák — API szerződések, adatbázis-sémák, típusdefiníciók
• Végrehajtható tervek — lépésről lépésre kidolgozott feladatlebontások, amelyeket az agent követni tud
• Konfiguráció — linter szabályok, CI pipeline-ok, formázási szabványok

A csapat megtanulta, hogy idővel egyre több kontextust kell a repo-ba tolniuk. Minden alkalommal, amikor egy agent hibázott a kontextus hiánya miatt, a megoldás nem egy jobb prompt volt — hanem a kontextus hozzáadása a repository-hoz. Forrás

Gyakorlati megvalósítás:

# ARCHITECTURE.md (a repo gyökerében található)

## Függőségi szabályok
- A UI komponensek importálhatnak a Service rétegből, de soha nem a Repo rétegből
- A Service réteg nem importálhat a Runtime rétegből
- Minden tartományok közötti kommunikáció típusos event bus-on keresztül történik

## Elnevezési konvenciók
- React komponensek: PascalCase, cél szerinti utótaggal (UserListPage, UserCard)
- Service-ek: camelCase, Service utótaggal (userService, authService)
- Típusok: PascalCase, tartomány előtaggal (UserProfile, OrderItem)

## Tesztelési követelmények
- Minden Service függvényhez egységteszt szükséges
- Minden API végponthoz integrációs teszt szükséges
- Lefedettségi küszöb: 80% csomagonként

2. alapelv: Arany-alapelvek

Az arany-alapelvek véleményezett, mechanikus szabályok, amelyeket közvetlenül a repository-ba kódolnak, hogy a kódbázis olvasható és következetes maradjon a jövőbeli agent futások számára. Ezek nem vágyvezérelt iránymutatások — hanem kényszerített korlátok.

Példák az OpenAI kísérletéből:

1. Preferáld a megosztott segédprogram-csomagokat a saját készítésű segítőkkel szemben — centralizálja az invariánsokat, így amikor a viselkedésnek változnia kell, az egy helyen változik meg
2. Ne próbálkozz az adatokkal YOLO-stílusban — validáld a határokat vagy támaszkodj típusos SDK-kra, hogy az agentek ne építhessenek véletlenül kitalált adatformákra
3. Egy koncepció, egy fájl — minden fájlnak egyetlen koncepciót kell képviselnie, megkönnyítve az agentek számára a megfelelő hely megtalálását és módosítását
4. Explicit az implicittel szemben — kerüld a mágikus viselkedést, amelynek megértéséhez az agentnek bennfentes tudásra lenne szüksége

Forrás

Ezek az elvek nem csak dokumentációk. Ezeket a következők kényszerítik ki:

• Linter szabályok — egyedi linterek (amelyeket szintén a Codex generált), amelyek jelzik a szabálysértéseket
• Strukturális tesztek — tesztek, amelyek validálják az architekturális megfelelést
• CI kapuk — az arany-alapelveket sértő pull requesteket a rendszer automatikusan elutasítja

3. alapelv: Rétegzett architektúra mechanikus kényszerítéssel

Az OpenAI projektben minden üzleti tartomány rögzített rétegekre van osztva, szigorúan validált függőségi irányokkal:

Types → Config → Repo → Service → Runtime → UI

A függőségek csak egy irányba áramlanak. Egy UI komponens függhet a Runtime-tól és a Service-től, de egy Service soha nem importálhat a UI-ból. Egy Repo függhet a Config-tól és a Types-tól, de soha nem a Service-től. Forrás

Ezeket a korlátokat mechanikusan kényszerítik ki:

// structural-test.ts — kikényszeríti a függőségi határokat
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([]);
  });
});

A strukturális tesztek validálják a megfelelést és megakadályozzák a moduláris rétegződés megsértését. Ez nem javaslat — ezt a CI kényszeríti ki. Minden pull requestnek, legyen az ember vagy agent által készített, át kell mennie ezeken a teszteken.

4. alapelv: Automatizált Garbage Collection

Még az arany-alapelvekkel és a strukturális kényszerítéssel együtt is az agentek által generált kód idővel elhajlik. Az OpenAI csapata ezt automatizált garbage collection implementálásával oldotta meg — rendszeres háttérfeladatokkal, amelyek:

1. Eltéréseket keresnek az arany-alapelvektől a teljes kódbázisban
2. Frissítik a minőségi fokozatokat minden modulnál a megfelelőségi pontszámok alapján
3. Célzott refaktorálási pull requesteket nyitnak, amelyek kijavítják az elhajlás specifikus kategóriáit

Ez váltotta fel a kézi "pénteki takarítást" egy folyamatosan futó rendszerrel. Magát a garbage collectort is Codex agentek hajtják, egy önfenntartó hurkot hozva létre. Forrás

# .github/workflows/garbage-collection.yml
name: Codebase Garbage Collection
on:
  schedule:
    - cron: '0 2 * * *'  # Futtatás minden éjjel hajnali 2-kor

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

5. alapelv: Végrehajtható tervek

Mielőtt az agentek kódot írnának, terveket készítenek. Ezek a tervek nem informális jegyzetek — hanem strukturált, végrehajtható dokumentumok, amelyek meghatározzák:

• Célkitűzés: Mit valósít meg a feladat
• Módosítandó fájlok: Azon fájlok explicit listája, amelyeket az agent érinteni fog
• Függőségek: Egyéb feladatok vagy modulok, amelyektől ez a munka függ
• Átvételi feltételek: Hogyan igazolható a munka befejezése
• Korlátok: Architekturális szabályok, amelyeket nem szabad megsérteni

# Terv: Felhasználói értesítési beállítások hozzáadása

## Célkitűzés
Lehetővé tenni a felhasználók számára, hogy beállítsák, mely értesítési csatornákon
(e-mail, SMS, push) kapjanak riasztásokat, kategóriánkénti bontásban.

## Módosítandó fájlok
- src/types/user.ts — NotificationPreferences típus hozzáadása
- src/repo/userRepo.ts — getPreferences/setPreferences metódusok hozzáadása
- src/service/notificationService.ts — Értesítések szűrése a beállítások alapján
- src/ui/pages/SettingsPage.tsx — Beállítások UI szekció hozzáadása

## Korlátok
- Követnie kell a Types → Repo → Service → UI függőségi folyamatot
- A NotificationPreferences típusnak megosztottnak kell lennie, nem duplikáltnak
- Minden új metódushoz egységteszt szükséges

## Átvételi feltételek
- [ ] A felhasználó válthat az e-mail/SMS/push között értesítési kategóriánként
- [ ] A beállítások megmaradnak a munkamenetek között
- [ ] Egy csatorna kikapcsolása 30 másodpercen belül leállítja az értesítéseket az adott csatornán

A tervek markdown fájlokként élnek a repository-ban, verziókövetettek, és a végrehajtás előtt felülvizsgálhatók — ellenőrző pontot biztosítva az emberek számára a szándék és a megvalósítás között.

4. rész: A Codex Agent Loop

Annak megértése, hogyan működik a Codex agent loop egy harness-en belül, elengedhetetlen a hatékony harness engineeringhez.

A loop architektúrája

Az OpenAI részletes elemzést tett közzé a Codex agent loop-ról az "Unrolling the Codex agent loop" című kísérő blogbejegyzésében. Forrás A hurok a következő ciklust követi:

Kontextus olvasása → Tervezés → Végrehajtás → Validálás → Commit (vagy újrapróbálkozás)

Minden iteráció:

1. Kontextus olvasása: Az agent elolvassa a releváns fájlokat, dokumentációt, sémákat és a feladat tervét a repository-ból.
2. Tervezés: A kontextus alapján az agent meghatározza, milyen változtatásokat kell eszközölni.
3. Végrehajtás: Az agent kódot ír vagy módosít.
4. Validálás: A harness teszteket, lintereket és strukturális ellenőrzéseket futtat a változtatásokon.
5. Commit vagy újrapróbálkozás: Ha a validálás sikeres, az agent commitol. Ha sikertelen, az agent elolvassa a hibaüzenetet, és újra megpróbálja.

A harness szerepe, hogy az 1. és 4. lépést a lehető leggazdagabb információval lássa el. Minél több kontextust olvas az agent, annál jobb a terve. Minél specifikusabb a validációs visszajelzés, annál gyorsabban jut el a működő megoldásig.

Az App Server Harness

Az "Unlocking the Codex harness: how we built the App Server" című bejegyzésükben az OpenAI leírja azt a konkrét infrastruktúrát, amely az agent loop-ot működteti. Forrás Az App Server a következőket biztosítja:

• Sandbox végrehajtási környezetek minden agent feladathoz
• Előre konfigurált eszközhozzáférés (fájlrendszer, terminál, böngésző)
• Automatikus kontextus-injektálás a repository melléktermékeiből
• Streaming validációs visszajelzés, így az agentek valós időben látják a teszthibákat

5. rész: A Harness Engineering alkalmazása a csapatodnál

Kezdő lépések: A minimálisan életképes Harness

Nem kell az OpenAI teljes infrastruktúráját lemásolnod ahhoz, hogy profitálj a harness engineeringből. Kezdd ezekkel az alapvető elemekkel:

1. lépés: Hozz létre egy ARCHITECTURE.md fájlt

Dokumentáld a projekted architekturális szabályait gépileg olvasható formátumban a repository gyökerében. Tartalmazza a következőket:

• Modulhatárok és engedélyezett függőségek
• Elnevezési konvenciók
• Fájlszervezési szabályok
• Tesztelési követelmények

Ez az egyetlen fájl drámaian javítja az agent kimeneti minőségét, mert az agentek elolvassák a változtatások előtt.

2. lépés: Strukturális tesztek hozzáadása

Írj teszteket, amelyek validálják az architekturális szabályaidat. Ezek a tesztek nem az üzleti logikát ellenőrzik — hanem azt, hogy a kód megfelelően van-e rendszerezve:

// Egyetlen service fájl sem importálhat UI modulból
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);
  }
});

3. lépés: CI validáció konfigurálása

Gondoskodj róla, hogy a CI pipeline-od minden pull requesten lefuttassa a strukturális teszteket, lintereket és típusellenőrzéseket — beleértve az agentek által létrehozottakat is. Az agentnek ugyanazt a validációs kimenetet kell látnia, mint amit egy emberi fejlesztő látna.

4. lépés: Feladattervek írása az agent futtatása előtt

Mielőtt megkérnél egy agentet egy funkció implementálására, írj egy strukturált tervdokumentumot, amely meghatározza a módosítandó fájlokat, a követendő korlátokat és az átvételi feltételeket. Tárold ezeket a terveket a repository-dban.

5. lépés: Automatikus tisztítás beállítása

Implementálj egy heti vagy éjszakai CI feladatot, amely átvizsgálja a kódbázist a dokumentált szabványoktól való eltérések után kutatva, és fókuszált refaktorálási PR-eket hoz létre.

Az agent rendszer kiválasztása

A harness engineering elvei függetlenek attól, hogy melyik agentet használod:

A harness a te repository-dban él, nem az agentben. Ez azt jelenti, hogy agentet válthatsz anélkül, hogy elveszítenéd a harness-be fektetett munkádat.

Skálázás egy agentről sokra

Az OpenAI kísérlet bebizonyította, hogy a harness engineering lehetővé teszi a párhuzamos agent végrehajtást. Mivel a harness kényszeríti az architekturális határokat, több agent dolgozhat egyidejűleg a kódbázis különböző részein anélkül, hogy konfliktusokat okoznának.

A párhuzamos agent végrehajtás kulcsfontosságú követelményei:

1. Egyértelmű modultulajdonos — minden agent egy meghatározott határon belül dolgozik.
2. Típusos interfészek a modulok között — az agentek kódolhatnak interfészekre anélkül, hogy ismernék az implementációs részleteket.
3. Merge conflict megelőzése — a feladatok úgy vannak behatárolva, hogy minimalizálják a fájlok közötti átfedést.
4. Centralizált validálás — minden agent ugyanabba a CI pipeline-ba küldi be a munkáját.

6. rész: Gyakori csapdák és anti-minták

1. anti-minta: Az agent kezelése harness-ként

Az agent nem a harness. A harness az a környezet, amelyben az agent működik. Az a megközelítés, hogy egy okosabb modelltől várjuk el egy rosszul strukturált repository kompenzálását, hibás. A környezetet javítsd, ne a promptot.

2. anti-minta: Dokumentáció rossz helyen

Ha az architekturális döntéseid a Confluence-ben, Notion-ben vagy Google Docs-ban élnek, az agentek nem látják őket. A megoldás egyszerű, de fegyelmet igényel: mozgass minden fejlesztéssel kapcsolatos dokumentációt a repository-ba.

3. anti-minta: Kézi takarítás automatizált kényszerítés helyett

Ha jelentős időt töltesz az agentek által generált kód takarításával, akkor jobb kényszerítésre van szükséged, nem több takarítási alkalomra. Minden ismétlődő takarítási feladatból linter szabálynak, strukturális tesztnek vagy automatizált refaktorálási feladatnak kell válnia.

4. anti-minta: Túlkorlátozás

A túl merev harness megakadályozza az agenteket a kreatív megoldások megtalálásában. A cél az architektúra korlátozása, nem az implementációé. Mondd meg az agenteknek, mely modulokat módosíthatják és mely függőségek engedélyezettek, de hagyd, hogy ők döntsék el, hogyan implementálják a logikát ezen a határokon belül.

5. anti-minta: Az agent visszajelzéseinek figyelmen kívül hagyása

Amikor egy agent ismételten kudarcot vall bizonyos feladatokban, a kudarc általában a harness hiányosságát jelzi, nem pedig az agent korlátait. Kövesd a hiba-mintákat, és használd őket a dokumentációd, a strukturális tesztjeid vagy az architekturális korlátaid fejlesztésére.

7. rész: A Harness Engineering jövője

Martin Fowler perspektívája

Martin Fowler közzétett egy elemzést a harness engineeringről a blogján, megjegyezve, hogy ez alapvető váltást jelent a szoftveres csapatok működésében. A tudományág évtizedes szoftvermérnöki bevált gyakorlatokból merít — continuous integration, architecture decision records, dependency injection —, de azokat egy agent-vezérelt világra szabja át. Forrás

A HumanLayer keretrendszer

A HumanLayer csapata közzétette elemzését, amelyben a harness engineeringet "képességbeli kérdésnek" (skill issue) nevezi — azzal érvelve, hogy a hatékony harness-ek tervezésének képessége lesz az elsődleges különbség a nagy teljesítményű és a küszködő mérnöki csapatok között. Forrás

Mit jelent ez a fejlesztők számára?

A harness engineering nem helyettesíti a fejlesztői tudást — hanem átirányítja azt. Ahelyett, hogy kódot írnának, a senior mérnökök azokat a rendszereket tervezik meg, amelyek lehetővé teszik az agentek számára a jó minőségű kódírást. A fontos készségek az implementációról az architektúrára, a kódolásról a rendszertervezésre, a tesztek írásáról a teszt-keretrendszerek tervezésére tolódnak el.

Az alkalmazásokat építő csapatok számára az olyan platformok, mint a ZBuild, már beépítik a harness engineering elveit az app builder munkafolyamataikba. Ahelyett, hogy a fejlesztőktől elvárnák saját harness-eik tervezését a semmiből, a ZBuild előre konfigurált architekturális mintákat, függőségkezelést és validációs rendszereket biztosít, amelyek a kiváló minőségű kimenet felé terelik az AI agenteket — lehetővé téve a fejlesztőknek, hogy a termékdöntésekre koncentráljanak az infrastruktúra helyett.

A három horizont

Előre tekintve a harness engineering valószínűleg három fázison keresztül fog fejlődni:

1. Rövid táv (2026): A csapatok bevezetik a repository-első dokumentációt, a strukturális teszteket és az arany-alapelveket. Az agent-segített fejlesztés standard gyakorlattá válik a jól felszerelt projekteknél.

2. Középtáv (2027): Maga a harness generálás is agent-vezérelt lesz. Az agentek elemzik a meglévő kódbázisokat, és harness konfigurációkat — linter szabályokat, strukturális teszteket, függőségi határokat — javasolnak a megfigyelt minták alapján.

3. Hosszú táv (2028+): A harness-ek adaptívvá válnak. Statikus szabályok helyett az agentek által generált kód eredményei alapján fejlődnek, automatikusan szigorítva a korlátokat azokon a területeken, ahol az agentek gyakran hibáznak, és lazítva ott, ahol következetesen sikeresek.

8. rész: Gyakorlati ellenőrzőlista

Használd ezt az ellenőrzőlistát a csapatod harness engineering érettségének értékeléséhez:

Alapok (Kezdd itt)

• ARCHITECTURE.md létezik a repository gyökerében
• A kódformázás automatizált (Prettier, Black, gofmt)
• A linting minden pull requesten lefut
• A típusellenőrzés kényszerített (TypeScript strict, mypy stb.)

Középhaladó

• Strukturális tesztek validálják a függőségi határokat
• Az arany-alapelvek dokumentáltak és gépileg kényszeríthetők
• Feladattervek készülnek az agent futtatása előtt
• Az agent által generált PR-ek ugyanazon a CI-n mennek keresztül, mint az emberi PR-ek

Haladó

• Automatizált garbage collection fut ütemezetten
• Több agent tud párhuzamosan dolgozni konfliktusok nélkül
• Az agent hiba-mintákat követik és a harness javítására használják
• Maga a harness is verziókövetett és kódként felülvizsgált

Szakértő

• Az agentek generálják a harness részeit (linter szabályok, strukturális tesztek)
• A minőségi fokozatok automatikusan hozzárendelésre kerülnek minden modulhoz
• A harness fejlesztései adatvezéreltek az agentek sikerességi rátája alapján
• A csapat több kódot szállít mérnökönként hetente, mint az agentek bevezetése előtt

Konklúzió

A harness engineering nem hóbort. Ez a szoftvermérnökség természetes fejlődése egy olyan korszakban, ahol az AI agentek képesek produkciós kódot írni, de strukturált környezetre van szükségük ahhoz, hogy ezt jól tegyék. Az OpenAI egymillió soros kísérlete nagy léptékben bizonyította a koncepciót, és az általuk megfogalmazott elvek — repository-első tudás, arany-alapelvek, rétegzett architektúra, automatizált garbage collection és végrehajtható tervek — bármilyen méretű csapatnál alkalmazhatók.

Azok a csapatok, amelyek 2026-ban elsajátítják a harness engineeringet, gyorsabban fognak szállítani, magasabb kódminőséget tartanak fenn, és hatékonyabban skálázódnak, mint azok, akik az AI agenteket csak egy felturbózott autocomplete-ként kezelik. Az agent a ló. A harness az, ami hasznossá teszi.

Források

• 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