A „harness” szó angolul lószerszámot, hámot jelent. A hám feladata kordában tartani egy nagy erővel bíró állatot, azaz irányítani az erejét. Ez a metafora adja a nevét a mesterséges intelligencia (AI) alapú szoftverfejlesztés legújabb, 2026-os fázisának, amelyről a nemrég publikált Agentic Engineering-bejegyzésünk folytatásaként érdemes beszélnünk.
A kifejezést Mitchell Hashimoto, a Terraform (a piacvezető infrastruktúra-mint-kód-eszköz) és a Ghostty (egy népszerű nyílt forráskódú terminálalkalmazás) megalkotója vezette be 2026 februárjában, saját hatlépcsős AI-adoptációs folyamatának ötödik szintjeként. Napokon belül több fontos iparági vállalat (OpenAI, Anthropic, LangChain, akik széleskörű gyakorlati tapasztalattal rendelkeznek AI coding agentek nagy léptékű bevetéséről) szakamberei is ugyanerre a felismerésre jutottak egymástól függetlenül.
Mára eljutottunk oda a szoftverfejlesztésben, hogy a szűk keresztmetszet nem az AI coding agentek képességei határozzák meg, hanem a környezet adottságai, amelyben használjuk őket. Ennek kialakításában segít a harness engineering, ami nem egy marketing-buzzword, hanem a szoftverfejlesztői szakma egy rohamosan növekvő területévé vált.
Hogyan jutottunk ide? A prompttól a harness-ig
Ahhoz, hogy megértsük, miért pont most van itt a harness engineering ideje, érdemes végignézni, hogyan alakult a fejlesztők és az AI-támogatott kódolás viszonya az elmúlt évek során:
- Prompt engineering (2022–2024): a fejlesztő a chatablakban szereplő egyetlen kérdést optimalizálta annak érdekében, hogy izolált feladatok (egy kódrészlet, egy függvény, egy unit teszt) kontextusában jó választ kapjon. Egyetlen input-ra vártunk egyetlen, jól körülhatárolt outputot.
- Context engineering (2025): felismertük, hogy a jó kérdés önmagában nem elég. Sokkal inkább az számít, mit lát a modell. Agentic Memory, MCP-szerverek, AGENTS.md-szerű projektszabályok és funkciók jelentek meg a legtöbb kódolástámogató eszközben annak érdekében, hogy a modell fel tudja térképezni a kódbázist és a megfelelő kontextust. A fejlesztő szerepe “felkészíteni” a modellt, tehát arról gondoskodni, hogy a kérdéséhez releváns dokumentáció, projektszabályok és a kódbázis megfelelő része elérhető legyen a kontextusablakban. Ez már önmagában egy kvalitatív ugrást jelent, hiszen a modell nem vakon, a projektről mit sem tudva válaszol, hanem igyekszik figyelembe venni a már használt szabályokat, konvenciókat és a rendelkezésre álló üzleti környezetet.
- Harness engineering (2026): mivel az LLM-ek képességei ugrásszerűen javultak, egyre összetettebb feladatok megoldására lettek képesek. Lehetségessé vált, hogy a fejlesztő akár teljesen rábízza magát az agent-re nem csak egy függvény megírásában, hanem órákig tartó, többlépéses feladatok önálló végrehajtásában is. Ehhez a fejlesztőnek már nem elég csak a kontextust megadnia, hanem meg kell tervezni azt a teljes rendszert (konvenciókat, constraint-eket, feedback loopokat, verifikációt, biztonsági korlátokat), amelyben az agent akár órákig, önállóan dolgozhat. A fejlesztő feladata innentől kezdve nem csak a helyes kontextus beállítása, hanem annak a szabályrendszernek a karbantartása is, ami lehetővé teszi a helyes megoldás előállítását. Amennyiben ez adott, maximalizálni tudjuk annak esélyét, hogy az agent olyan kódot írjon, melyet mi magunk fejlesztőként látni szeretnénk.
Louis Bouchard a következő autós analógiával foglalja össze a lényeget.
A modell az autó motorja: nélküle nem megy semmi, de önmagában még nem egy gépjármű.
A kontextus az üzemanyag és a műszerfal. A harness az autó különböző elemeit tartalmazza: a kormányt, a pedálokat, a lámpákat és a holttér-figyelőt, melyek összessége az a biztosíték, hogy az autót biztonsággal irányíthatjuk. Ezeknek köszönhetően bízhatunk meg a járműben, hiszen tudjuk, hogy az ajtók nem fognak leesni az autópályán magas sebesség mellett sem.
Amire a harness nem gyógyír
A harness engineering nem csodaszer. Az agentek által generált kód entrópiát (inkonzisztens elnevezés, rossz architektúra, duplikált logika kerülhet a kódba) halmoz fel idővel, amit az OpenAI csapata „technológiai adósság szteroidokon” néven emleget. Más szóval,
ha nem törődünk a kódbázissal és az azt körülvevő harness naprakészen tartásával, az idővel elavul, amivel egyidejűleg az agent teljesítménye romlani fog.
Minél szűkebb keretek között dolgozik az agent, annál kiszámíthatóbb és megbízhatóbb az eredmény. A szűkített megoldási tér nem korlátozás, hanem tudatos irányítás annak érdekében, hogy olyan kimenetet érjünk el, amilyet látni szeretnénk. Ugyanakkor ennek tükörképe az over-engineering (túl sok tool, túl sok szabály) ugyanúgy ronthatja az eredményt és szükségtelenül bonyolult kódbázishoz vezethet. Ezért nem érdemes túl sok szabályt meghatározni: ez kiszámíthatóbbá teszi ugyan az agent kimenetét, de egyben bonyolultabbá is. A széttöredezett, rossz absztrakciókkal és túlzottan szoros összekapcsolással rendelkező kódbázisokat nehéz átlátni, és egy gyorsan változó üzleti környezetben könnyen túl merevvé válhat a rendszer.
Bizonyos esetekben a siker kulcsa a cél pontos meghatározása mellett az, ha az agent kevesebb, de általánosabb célú eszközből válogathat.
A mai modellek már sokoldalúak annyira, hogy kitalálják, mikor melyik lesz a feladat megoldásához a megfelelő. Ez a megfigyelés a modellek rohamos fejlődésére és növekvő önállóságára mutat rá, viszont ez a tendencia a Harness Engineering-témakörét ettől még koránt sem teszi szükségtelenné.
Mi a mérnök szerepe ebben a közegben?
Kief Morris (a Thoughtworks szoftverfejlesztő mérnöke, az „Infrastructure as Code” című könyv szerzője) a fejlesztő és az agent viszonyát három pozícióban írja le:
- Out of the loop (Vibe Coding): a fejlesztő rábízza az agentre a teljes kódbázist és reménykedik a legjobbakban;
- In the loop (Agentic Engineering): a fejlesztő alaposan, kód szinten, lépésről-lépésre irányítjaés felügyeli az agent munkáját. Ez felelősebb megközelítés, viszont az AI eszközök fejlődésével az emberi figyelem és erőforrás szűk keresztmetszetté válik;
- On the loop (Harness Engineering): a fejlesztő nem kódot ír, hanem a rendszert tervezi és felügyeli.
Az AI nem helyettesít, hanem kiegészít
Ez pontosan az a szemlélet, amit korábbi cikkünkben, az Agentic Engineeringben is képviselünk: az AI nem helyettesíti, hanem kiegészíti a mérnöki kultúrát, ha egy érett, tudatosan felépített környezetbe illesztjük be. A harness védővonalaival fejlesztett kód
- megbízhatóbb,
- kevesebb biztonsági sérülékenységet rejt magában,
- jobb architektúrát követ,
mint az AI-eszközök által alapértelmezetten adott válaszok. A mindennapokban ez kevesebb utómunkát, kevesebb hibát, gyorsabb hibajavítást és hosszabb távon fenntarthatóbb, alacsonyabb kockázatú kódbázist eredményez.
A Webstarnál az a törekvés vezet minket, hogy tudatosan használjunk AI-eszközöket és építsünk köréjük olyan harness-elemeket, amik a modellek fejlődésével (remélhetőleg) nem évülnek el.
Továbbra is figyelmet fordítunk a szakmaiságra és arra, hogy milyen ellenőrzési pontokkal építjük köréjük a mérnöki munkát. Ezzel célunk azt elérni, hogy a gyors haladás ne menjen a minőség rovására.
Ez a blogbejegyzés backend szakmai vezetőnk, Thomas szakértői dokumentumainak felhasználásával készült.
Szeretne többet megtudni a projektről?
Ez neked azért jó, mert ipsum dolor sit amet, consectetur adipiscing elit. Aliquam faucibus risus quis lectus hendrerit.
Adja meg email címét ahová külhetjük!
SIKERES FELIRATKOZÁS
A megadott e-mail címre hamarosan küldjük!
