Eszközök

Mesterséges intelligenciával generált szöveg

Válasszon kódolási harness-t a szükséges ellenőrzés szerint, ne a gyártó alapján

A cikk szerzője Nicole Koenigstein azt javasolja, hogy a fejlesztők ne a gyártó alapján válasszanak kódolási harness-t, hanem annak alapján, melyik réteg fölött akarnak kontrollt.

Válasszon kódolási harness-t a szükséges ellenőrzés szerint, ne a gyártó alapján

A 2019-es világ, amikor csak néhány nyelvi modellt lehetett választani rövid kontextusablakkal, eltűnt. Ma több zászlóshajó-szolgáltató és nyílt forráskódú projekt verseng modellcsaládok, méretek, képességek és telepítési opciók mentén. Hasonló átalakulás zajlik a kódolási harness-eknél is.

Első pillantásra Claude Code, Codex, Pi, DeepSeek Harness és a többi kódoló keretrendszer ugyanazt csinálja: segít szoftvert építeni modellek segítségével. Ha azonban közelebbről megnézzük, minden egyes harness más-más részek felett ad kontrollt: mit láthat és változtathat a modell, hogyan használ eszközöket, hol fut, és mi történik hiba esetén. Így a kulcskérdés nem az, hogy melyik harness a „legjobb általánosságban”, hanem:

Melyik réteget kell kontrollálnia a projektnek?

Mihez ad hozzá egy harness — és mi marad önnél

A választás nem csak arról szól, melyik modell ír jobb kódot. A döntés arról is szól, hogy mit nyújt a harness, mit szabhat meg a fejlesztő, és mit kell saját maga megépítenie. Ha a harness nem biztosít verifikációt, tartós állapotkezelést, javítási útvonalakat vagy végrehajtási határokat, ezek a feladatok önre maradnak. Ön marad felelős a munkafolyamat megbízhatóságáért és irányításáért.

Minden harnessnak van egy „gravitációs központja”: egy réteg, amin belül a legtöbb kontrollt adja. A szerző szándékosan magas szintű összehasonlítást ad; a határok átfednek és a termékek gyorsan változnak. A cél megmutatni, hol ad alapértelmezetten előnyt egy-egy harness, és hol marad a mérnöki munka önnél.

Claude Code — kontroll a végrehajtáson belül

Claude Code részletes irányítást ad arra, hogyan alakul az implementáció: a CLAUDE.md állandó utasításokat tartalmaz, a skills feladat-specifikus playbookokat, a subagents felosztják a munkát, és a hooks interceptálják a műveleteket eszközhívások előtt és után. Egy hook nem csak elutasít egy műveletet, hanem magyarázatot adhat vagy azonnal visszaadhat egy fordítói vagy szabályzati hibát az ügynöknek.

Ezekkel az eszközökkel széles körben lehet kormányozni a kódolási ciklust, de a vezérlés Claude Code meglévő életciklusán belül működik. Ha az egész külső életciklus felett akar kontrollt, szüksége lesz egy másik rétegre.

Codex — kontroll a szétválasztás által

Codex különválasztást biztosít a kódolási feladat és annak végrehajtási környezete között. Egy noninteractive codex exec futtatás szűk feladatra dolgozik egy megadott repozitóriumban, OS-által érvényesített sandbox alatt, és sémával korlátozott eredményt ad vissza.

Ez független verifikációhoz hasznos: tiszta checkout-ot adhat Codexnek, kizárhatja a builder utasításait, korlátozhatja az írható útvonalakat, és külön review-kat futtathat kódminőség, teszthiány, perzisztencia vagy felhasználó által látható viselkedés ellenőrzésére. A sandbox az operációs rendszertől függ, de a korlátozás érvényesítését a prompt helyett a végrehajtási határba helyezi.

Pi — kontroll a kódolási ciklus felett

Pi a kódolási ciklus fölötti kontrollt adja: eszközök, parancsok, eseménykezelők, kontextus, modellek és munkamenet-állapot kiterjeszthető vagy cserélhető. Ez lehetővé teszi, hogy eldöntse, mely lépések maradnak ügynöki jellegűek és melyek követnek determinisztikus szabályokat.

Például egy lokális hiba visszakerülhet implementációra, ismétlődő hiba kötelező újratervezést indíthat, ellentmondó megállapítások újracheckelést vagy emberi felülvizsgálatot váltanak ki. Pi képes ügynököket futtatni ezen az életcikluson belül, tehát nem pusztán determinisztikus orkestrátor. A szerző saját példájában a külső döntéseket determinisztikussá tette a Pi programmabilitásával — ez tervezési döntés volt, nem Pi definíciója.

DeepSeek Harness — kontroll a komponálhatóságon keresztül

DeepSeek harness akkor hasznos, ha az egész harness egyes részeit szeretné kicserélni ahelyett, hogy csak körülirányítaná vagy becsomagolta volna őket. Az eszközök, sessionök, életciklus-viselkedés, verifikáció és kormányzás mind plug-in jellegűen komponálhatók, akárcsak a loop maga. Így egy alkatrészt kicserélhet anélkül, hogy az egész rendszert újraépítené.

A kompromisszum az, hogy a kontroll annyira jó, amennyire a komponált plug-inek minősége. Míg Pi egy minimális magot ad, amit fejleszthet, DeepSeek inkább részeket ad összeillesztésre.

Egy gyakorlati példa: Python 2.7 migráció

A szerző valós problémája egy örökölt Python 2.7 alkalmazás megbízható migrálása volt úgy, hogy ne változzon meg az évek alatt felhalmozott viselkedés és ne sérüljön a perzisztált adat. A Python 3-ra futtatás csak egy része volt a feladatnak: meg kellett őrizni a viselkedést, verifikálni az adatokat mindkét runtime-on, kontrollálni, mit változtathatnak az ügynökök, és eldönteni, mi történjen hiba vagy verifikációs kudarc esetén.

A szerző ezért a harness választást a kontroll, izoláció és életciklus-kezelés szempontjából közelítette meg, és végül többet használt egyszerre:

  • Claude Code: a port építése belső steerigért, specializált skills-ért, hook-okért és implementációs/ellenőrző subagentek gyáráért.
  • Codex: izolált futtatásokban történő verifikáció, független modellkörnyezetért, tiszta munkaterületekért, korlátozott írásért és strukturált megállapításokért.
  • Pi: a külső életciklus birtoklása, mert tartós állapotot, bizonyíték-verifikációt, határolt javításokat, újratervezési szabályokat és emberi eszkalációt akart kezelni.
  • A fagyasztott átadás (frozen acceptance), beleértve a Playwright és Python 2/3 differenciális ellenőrzéseket, az ügynökökön kívül futott, hogy se a builder, se a verifier ne redefiniálhassa a siker fogalmát.

A DeepSeek Harness-t ezúttal azért nem használta, mert egy nagyon kis külső életciklust akart, amit végig átlát, nem azért, mert a DeepSeek ne tudta volna megoldani a feladatot.

A teszteléshez először készített egy kicsi Python 2 alkalmazást hasonló csapdákkal, majd összehasonlította a komponált setupot egyetlen Claude Code sessionnel, amelyben Claude maga verifikálhatta és tesztelhette a saját kódját.

Érdekes módon mindkét setup átment a 25 rejtett viselkedési teszten. Ugyanakkor az egy-session megoldás csendben összemosott két különböző Python 2 dictionary kulcsot — a Unicode u'é' és a byte string 'é' értékek egy Python 3 stringgé olvadtak, és miután az adat elmentődött, egy bejegyzés végleg elveszett. Az egy-session setup továbbá egyik Unicode értéket bájtokká alakította dokumentáció nélkül.

A tesztcsomag és Claude saját tesztjei sem találták meg a hibát; több száz viselkedés-összehasonlítás sem hozta felszínre. Később két izolált Codex verifikáló függetlenül reprodukálta a hibát. Claude nem fogadta el automatikusan a megállapítást; vitatta azt. Pi pedig elindított egy új Codex futtatást, amely csak a megállapítást és Claude érvelését kapta. Az újraellenőrzés megerősítette a hibát, Claude elfogadta, Pi egy határolt javítási munkafolyamatba irányította a problémát, és a következő verifikációs kör megerősítette, hogy mindkét kulcs és azok eredeti típusai megmaradtak.

Ez rávilágít egy fontos pontra: a modelleket gyakran a szolgalelkűségük miatt bírálják (azonnal javítanak, ha rákérdezünk), de itt az ellenkezője történt: Claude vitatta a független verifikáció által talált hibát, mert a saját session-könyvelése és a sikeres tesztek arra horgonyozták. A friss, független verifikáció megtörte ezt az önmegerősítő keretet. A független verifikáció fontossága nem azért van, mert a második modell automatikusan igaz, hanem mert nincs ugyanahhoz a történethez kötve.

Melyik harness illik önhöz?

A választásnál kezdje azzal, milyen szintű kontrollra van szüksége és mennyit hajlandó saját maga megépíteni. Néhány segítő kérdés:

  • Egy meglévő kódolási loopot konfigurálni, kiterjeszteni vagy egyes részeit lecserélni akarom?
  • Tudom-e kontrollálni az eszközöket, kontextust, memóriát és modellválasztást a projekt igényeinek megfelelően?
  • Hol érvényesülnek a jogosultságok, allow listek és szabályzatok: utasításokban, alkalmazási logikában vagy az operációs rendszerben?
  • Interceptálhatok-e műveleteket és életciklus eseményeket azok végrehajtása előtt és után?
  • Mennyit változtathatok az orchestráción, állapotkezelésen és munkamenet-életcikluson?
  • Mit ad a harness megfigyelhetőség, verifikáció és strukturált bizonyítékok terén?
  • Mely megbízhatósági és kormányzási kontrollokat adja a harness, és melyek maradnak az én feladatom?
  • Képes-e a harness együttműködni más eszközökkel és harness-ekkel, ha több kontrollréteg átívelésére van szükség?

Ezek példák, nem teljes lista. A fontos kérdések függnek attól, mit épít, mennyi autonómiát ad az ügynöknek, és miért felel, ha az kudarcot vall.

A döntés eredményeként Claude Code, Codex, Pi, DeepSeek harness vagy más megoldás is megfelelhet. A gyártó neve csupán azt mondja meg, ki csomagolta a runtime-ot, nem azt, hol vannak a garanciák. Akár egy harness-t választ, akár többtől épít rendszert, az elv ugyanaz: azt a megoldást válassza, amely azt a kontrollhatárt adja meg, amit birtokolni akar, és kérdezze meg, akarja-e, hogy az ügynök maga határozza meg a saját sikerének feltételeit.