Harness Engineering: Kompletní průvodce budováním systémů, díky kterým AI agenti skutečně fungují

Březen 2026 — Pokud byl rok 2025 rokem, kdy AI agenti dokázali, že umí psát kód, rok 2026 je rokem, kdy jsme se naučili, že agent není tou těžkou částí – tou je harness (postroj).

Tým Codex společnosti OpenAI právě vytvořil produkční aplikaci s více než 1 milionem řádků kódu, kde nula řádků byla napsána lidskou rukou. Inženýři nepsali kód. Navrhli systém, který umožnil AI psát kód spolehlivě. Tento systém — omezení, zpětné vazby, dokumentace, lintery a správa životního cyklu — je to, čemu průmysl nyní říká harness.

Harness engineering je nová disciplína navrhování těchto systémů. A mění to, co znamená být softwarovým inženýrem.

---

Co je Harness Engineering?

Metafora koně

Termín „harness“ pochází z koňského postroje – otěže, sedlo, udidlo – kompletní sada vybavení pro usměrňování silného, ale nepředvídatelného zvířete správným směrem. Metafora je záměrná:

• Kůň je AI model – výkonný, rychlý, ale sám o sobě neví, kam jít.
• Harness je infrastruktura – omezení, mantinely a zpětné vazby, které produktivně usměrňují sílu modelu.
• Jezdec je lidský inženýr – udává směr, neběží sám.

Bez harnesse je AI agent plnokrevníkem na otevřeném poli. Rychlý, působivý a naprosto nepoužitelný pro dokončení jakékoli práce.

Formální definice

Harness engineering je návrh a implementace systémů, které:

1. Omezují (Constrain) to, co AI agent může dělat (architektonické hranice, pravidla závislostí).
2. Informují (Inform) agenta o tom, co by měl dělat (context engineering, dokumentace).
3. Ověřují (Verify), že to agent udělal správně (testování, linting, CI validace).
4. Opravují (Correct) agenta, když udělá chybu (zpětné vazby, mechanismy samoopravy).

Martin Fowler to popisuje jako „nástroje a postupy, které můžeme použít k udržení AI agentů pod kontrolou“ – ale je to víc než jen bezpečnost. Dobrý harness činí agenty schopnějšími, nikoli jen kontrolovanějšími.

---

Proč na Harness Engineeringu nyní záleží

Model je komodita. Harness je konkurenční výhoda.

Zde je nepříjemná pravda, které AI průmysl čelí: na základním modelu záleží méně než na systému kolem něj.

LangChain to dokázal definitivně. Jejich kódovací agent se v testu Terminal Bench 2.0 zlepšil z 52,8 % na 66,5 % – posunul se z Top 30 do Top 5 – aniž by cokoli změnili na modelu. Změnili pouze harness:

Změna	Co udělali	Dopad
Smyčka samovybavení	Přidán middleware s kontrolním seznamem před dokončením	Zachyceny chyby před odesláním
Context engineering	Mapování adresářové struktury při spuštění	Agent od začátku rozuměl codebase
Detekce smyček	Sledování opakovaných úprav souborů	Zabránění „nekonečným smyčkám“
Reasoning sandwich	Vysoké uvažování pro plánování/ověření, střední pro implementaci	Lepší kvalita v rámci časového limitu

Stejný model. Jiný harness. Dramaticky lepší výsledky.

Důkaz OpenAI: 1 milion řádků

Experiment OpenAI je dosud nejpřesvědčivějším důkazem:

• 5 měsíců vývoje
• 1 milion+ řádků kódu ve finálním produktu
• Nula manuálně napsaných řádků – každý řádek byl vytvořen agenty Codex
• Postaveno za ~1/10 času, který by potřebovali lidé
• Produkt má interní denní uživatele a externí alfa testery
• Produkt se odesílá, nasazuje, rozbíjí a opravuje – vše agenty v rámci harnesse

Práce inženýrů? Navrhování harnesse. Specifikace záměru. Poskytování zpětné vazby. Nikoli psaní kódu.

---

Tři pilíře Harness Engineeringu

Framework OpenAI organizuje harness engineering do tří hlavních kategorií:

1. Context Engineering

Context engineering je o zajištění toho, aby měl agent správné informace ve správný čas.

Statický kontext:

• Dokumentace lokální v repozitáři (architektonické specifikace, API kontrakty, stylové příručky)
• Soubory AGENTS.md nebo CLAUDE.md, které kódují pravidla specifická pro projekt
• Propojené designové dokumenty validované lintery

Dynamický kontext:

• Data observability (logy, metriky, trasování) přístupná agentům
• Mapování adresářové struktury při spuštění agenta
• Stav CI/CD pipeline a výsledky testů

Kritické pravidlo: Z pohledu agenta cokoli, k čemu nemá přístup v kontextu, neexistuje. Znalosti v Google Docs, Slack vláknech nebo v hlavách lidí jsou pro systém neviditelné. Repozitář musí být jediným zdrojem pravdy.

2. Architektonická omezení (Architectural Constraints)

Zde se harness engineering nejvíce liší od tradičního AI promptování. Namísto toho, abyste agentovi řekli „napiš dobrý kód“, mechanicky vynutíte, jak má dobrý kód vypadat.

Vrstvení závislostí:

Types → Config → Repo → Service → Runtime → UI

Každá vrstva může importovat pouze z vrstev nalevo od ní. To není návrh – je to vynuceno strukturálními testy a CI validací.

Nástroje pro vynucování omezení:

• Deterministické lintery – Vlastní pravidla, která automaticky označují porušení
• Auditoři založení na LLM – Agenti, kteří kontrolují kód ostatních agentů z hlediska dodržování architektury
• Strukturální testy – Jako ArchUnit, ale pro kód generovaný AI
• Pre-commit hooky – Automatické kontroly před jakýmkoli commitem kódu

Proč omezení zlepšují výstup: Paradoxně, omezení prostoru pro řešení činí agenty produktivnějšími, nikoli méně. Když agent může vygenerovat cokoli, plýtvá tokeny zkoumáním slepých uliček. Když harness definuje jasné hranice, agent rychleji konverguje ke správným řešením.

3. Správa entropie („Garbage Collection“)

Toto je nejvíce podceňovaná složka. V průběhu času se v codebase generovaných AI hromadí entropie – dokumentace se vzdaluje realitě, konvence pojmenování se rozcházejí, hromadí se mrtvý kód.

Harness engineering to řeší periodickými úklidovými agenty:

• Agenti pro konzistenci dokumentace – Ověřují, zda dokumentace odpovídá aktuálnímu kódu
• Scannery porušení omezení – Hledají kód, který proklouzl dřívějšími kontrolami
• Agenti pro vynucování vzorů – Identifikují a opravují odchylky od zavedených vzorů
• Auditoři závislostí – Sledují a řeší cyklické nebo zbytečné závislosti

Tito agenti běží podle plánu – denně, týdně nebo spuštěni specifickými událostmi – a udržují codebase zdravou jak pro lidské recenzenty, tak pro budoucí AI agenty.

---

Harness Engineering v praxi: Jak to týmy skutečně dělají

Přístup OpenAI: Nula lidského kódu

Struktura týmu OpenAI pro harness engineering:

Role	Tradiční	Harness Engineering
Psaní kódu	Hlavní náplň práce	Nikdy
Návrh architektury	Součást práce	Hlavní náplň práce
Psaní dokumentace	Dodatečná myšlenka	Kritická infrastruktura
Revize PR	Revize kódu	Revize výstupu agenta + efektivita harnesse
Ladění (Debugging)	Čtení kódu	Analýza vzorců chování agenta
Testování	Psaní testů	Návrh strategií testování, které agenti provádějí

Přístup Stripe: „Mimoni“ ve velkém

Interní kódovací agenti Stripe, zvaní Minions, nyní produkují více než 1 000 schválených pull requestů týdně:

1. Vývojář zadá úkol do Slacku
2. Mimoni napíší kód
3. Mimoni projdou CI
4. Mimoni otevřou PR
5. Člověk zkontroluje a schválí (merge)

Žádná interakce vývojáře mezi krokem 1 a krokem 5. Harness zvládá vše – spouštění testů, CI validaci, dodržování stylu a aktualizace dokumentace.

Přístup LangChain: Middleware na prvním místě

LangChain strukturuje svůj harness jako složitelné vrstvy middleware:

Požadavek agenta
  → LocalContextMiddleware (mapuje codebase)
  → LoopDetectionMiddleware (zabraňuje opakování)
  → ReasoningSandwichMiddleware (optimalizuje výpočet)
  → PreCompletionChecklistMiddleware (vynucuje ověření)
  → Odpověď agenta

Každá vrstva middleware přidává specifickou schopnost bez úpravy jádra logiky agenta. Tento modulární přístup činí harness testovatelným a vyvíjetelným.

---

Budování vašeho prvního harnesse: Praktický rámec

Úroveň 1: Základní harness (Jednotlivý vývojář)

Pokud používáte Claude Code, Cursor nebo Codex pro individuální projekty:

Co nastavit:

• Soubor CLAUDE.md nebo .cursorrules s konvencemi projektu
• Pre-commit hooky pro linting a formátování
• Testovací sadu, kterou může agent spustit pro samoověření
• Jasnou adresářovou strukturu s konzistentním pojmenováním

Čas na nastavení: 1-2 hodiny Dopad: Předchází nejčastějším chybám agentů

Úroveň 2: Týmový harness (Malý tým)

Pro týmy o 3-10 vývojářích sdílejících codebase:

Přidejte k úrovni 1:

• AGENTS.md s celotýmovými konvencemi
• Architektonická omezení vynucená CI
• Sdílené šablony promptů pro běžné úkoly
• Dokumentace jako kód validovaná lintery
• Kontrolní seznamy pro revizi kódu specificky pro PR generované agenty

Čas na nastavení: 1-2 dny Dopad: Konzistentní chování agentů v celém týmu

Úroveň 3: Produkční harness (Inženýrská organizace)

Pro organizace provozující desítky souběžných agentů:

Přidejte k úrovni 2:

• Vlastní vrstvy middleware (detekce smyček, optimalizace uvažování)
• Integrace observability (agenti čtou logy a metriky)
• Agenti pro správu entropie v plánovaných spuštěních
• Verzování harnesse a A/B testování
• Dashboardy pro monitorování výkonu agentů
• Eskalační politiky pro případy, kdy se agenti zaseknou

Čas na nastavení: 1-2 týdny Dopad: Agenti fungují jako autonomní přispěvatelé

---

Časté chyby v Harness Engineeringu

1. Přehnané inženýrství toku řízení (Control Flow)

„Pokud přetechnizujete tok řízení, příští aktualizace modelu váš systém rozbije.“

Modely se zlepšují rychle. Schopnosti, které v roce 2024 vyžadovaly složité pipeline, jsou nyní řešeny jediným promptem v kontextovém okně. Navrhujte svůj harness jako „odstranitelný“ (rippable) – měli byste být schopni odstranit „chytrou“ logiku, když se model stane dostatečně chytrým, aby ji nepotřeboval.

2. Považování harnesse za statický

Harness se musí vyvíjet spolu s modelem. Když nová verze modelu zlepší uvažování (reasoning), může se váš middleware pro optimalizaci uvažování stát kontraproduktivním. Kontrolujte a aktualizujte složky harnesse s každou velkou aktualizací modelu.

3. Ignorování vrstvy dokumentace

Nejvlivnější vylepšení harnesse je často to nejjednodušší: lepší dokumentace. Pokud je váš AGENTS.md vágní, bude vágní i výstup agenta. Investujte do přesné, strojově čitelné dokumentace, která slouží jako zdroj pravdy pro agenta.

4. Absence zpětné vazby

Harness bez zpětné vazby je klec, nikoli průvodce. Agent potřebuje vědět, kdy uspěl a kdy selhal. Zabudujte:

• Samověřovací kroky před dokončením úkolu
• Provádění testů jako součást workflow agenta
• Metriky úspěšnosti agentů podle typu úkolu

5. Dokumentace pouze pro lidi

Pokud vaše architektonická rozhodnutí žijí v hlavách lidí nebo na stránkách Confluence, ke kterým agent nemá přístup, má harness mezeru. Vše, co agent potřebuje, musí být v repozitáři.

---

Harness Engineering vs. související koncepty

Koncept	Rozsah	Zaměření
Prompt Engineering	Jednotlivá interakce	Vytváření efektivních promptů
Context Engineering	Kontextové okno modelu	Jaké informace model vidí
Harness Engineering	Celý systém agenta	Prostředí, omezení, zpětná vazba, životní cyklus
Agent Engineering	Architektura agenta	Interní návrh a směrování agenta
Platform Engineering	Infrastruktura	Nasazení, škálování, provoz

Harness engineering zahrnuje context engineering a čerpá z prompt engineeringu, ale operuje na vyšší úrovni – jde o kompletní systém, díky kterému jsou agenti spolehliví, nikoli jen o vstupy do jedné interakce.

---

Co to znamená pro softwarové inženýry

Práce se mění

Harness engineering představuje skutečnou evoluci v tom, co softwaroví inženýři dělají:

Dříve	Nyní
Psát kód	Navrhovat prostředí, kde AI píše kód
Ladit kód	Ladit chování agenta
Revidovat kód	Revidovat výstup agenta + efektivitu harnesse
Psát testy	Navrhovat strategie testování
Udržovat dokumentaci	Budovat dokumentaci jako strojově čitelnou infrastrukturu

To neznamená, že inženýři budou méně techničtí. Pokud vůbec něco, harness engineering vyžaduje hlubší architektonické myšlení – navrhujete systémy, které musí fungovat bez vašeho neustálého zásahu.

Dovednosti, na kterých záleží

Na základě toho, co jsme viděli při budování produktů poháněných AI v NxCode:

1. Systémové myšlení – Pochopení toho, jak na sebe vzájemně působí omezení, zpětné vazby a dokumentace.
2. Návrh architektury – Definování hranic, které jsou vynutitelné a produktivní.
3. Psaní specifikací – Formulování záměru dostatečně přesně, aby jej agenti mohli provést.
4. Observability – Budování monitoringu, který odhaluje vzorce chování agentů.
5. Rychlost iterace – Rychlé testování a vylaďování konfigurací harnesse.

Naše zkušenost: Co funguje v praxi

Stavíme webové aplikace poháněné AI pomocí několika systémů agentů (Claude Code, Codex, Cursor). Vzorce, které u nás udělaly největší rozdíl:

• Dokumentace na prvním místě v repozitáři: Každé architektonické rozhodnutí, konvence pojmenování a proces nasazení jsou v repozitáři. Nic nežije ve Slacku nebo Google Docs.
• Inkrementální budování omezení: Začněte se základním lintingem, přidávejte architektonická omezení podle toho, jak se objevují vzorce, nesnažte se navrhnout dokonalý harness hned na začátku.
• Kontrolní seznamy pro revizi specifické pro agenty: Kód generovaný AI má jiné režimy selhání než lidský kód. Náš proces revize bere v úvahu běžné vzorce agentů (nadměrná abstrakce, zbytečné ošetření chyb, drift dokumentace).
• Návrh harnesse pro více poskytovatelů: Náš harness funguje s modely Claude, GPT i Gemini. Design nezávislý na poskytovateli znamená, že můžeme měnit modely bez nutnosti přestavovat celý systém.

---

Hlavní závěry

1. Harness engineering je nová disciplína navrhování systémů, díky kterým jsou AI agenti spolehliví – omezení, zpětné vazby, dokumentace a správa životního cyklu.
2. Model je komodita; harness je konkurenční výhoda – LangChain poskočil z Top 30 na Top 5 v benchmarcích pouze změnou harnesse.
3. OpenAI vytvořila 1M+ řádků bez lidského kódu – což dokazuje, že harness engineering funguje v produkčním měřítku.
4. Tři pilíře: Context engineering, architektonická omezení a správa entropie.
5. Začněte jednoduše: Dobrý AGENTS.md a pre-commit hooky mají větší dopad než složitý middleware.
6. Práce inženýra se vyvíjí – od psaní kódu k navrhování prostředí, ve kterých AI píše kód.
7. Budujte adaptabilní harnessy – přetechnizování se vymstí, když se modely zlepší; udržujte systém flexibilní.

---

Související zdroje

• The Agentic Web Explained: AGENTS.md, MCP vs A2A — Vrstva protokolu, na které harness engineering staví.
• Cursor Cloud Agents: Autonomous Coding on Virtual Machines — Cloudové harnessy agentů v praxi.
• Claude Code Remote Control: Terminal Handoff Guide — Vzdálená správa relací agentů.
• Sestavte si web s NxCode — Vývoj webu pomocí AI s architekturou harnesse pro více poskytovatelů.