Vnútri harnessu: ako dodávame produkčný softvér s LLM —
a nestratíme niť.

Vypromptovať z modelu kód vie hocikto. Ťažké je vyrobiť softvér, na ktorý by ste vsadili produkčný systém. Naša odpoveď je inžiniersky harness: pipeline, kde modely kontrolujú vstupy a výstupy na každom rozhraní a človek podpisuje každé rozhodnutie, na ktorom záleží.

Načo vôbec harness

Agent bez harnessu optimalizuje na to, aby vyzeral hotovo: implementácia skôr, než je problém zadefinovaný, testy vynechané, keď zavadzajú, „hotovo“ ohlásené bez dôkazu. Sú to predvídateľné spôsoby zlyhania a harness ich rieši štrukturálne, nie tvrdším promptovaním. Každá fáza má vstupné a výstupné kritériá — vstupy skontrolované pri vstupe, výstupy prekontrolované pri výstupe, najprv modelom v roli adversariálneho reviewera, potom inžinierom.

V praxi: spec sa overí voči pôvodnému problému skôr, než sa začne architektúra. Architektúra sa overí voči specu skôr, než sa začne implementácia. Každý diff sa overí voči plánu, testom a bezpečnostnému checklistu skôr, než ho prečíta človek — takže pozornosť reviewera padne na úsudok, nie na chytanie mechanických chýb.

Pozrite si beh pipeline

Pravidlá, ktoré pipeline vynucuje

Pod diagramom fáz robia skutočnú prácu štyri pravidlá:

• Špecifikácia pred kódom. Z hrubého nápadu vznikne písomný spec, prekontrolovaný po malých, čitateľných kúskoch a podpísaný skôr, než sa čokoľvek postaví.
• Úlohy dosť malé na kontrolu. Práca je rozdelená na malé kroky, každý s jasným spôsobom overenia — postup sa dá auditovať — nestojí na slepej dôvere.
• Čistý kontext na každú úlohu, kontrola dvakrát. Každá úloha beží izolovane a skontroluje sa dvakrát — voči specu, potom na kvalitu — skôr, než sa dostane k človeku.
• Testy vždy najskôr. Najprv zlyhávajúci test, až potom implementácia; kód, ktorý nie je podložený testom, neostáva.

Pipeline vynucuje aj tri tvrdé obmedzenia: modely pracujú so sandboxovaným prístupom a s obmedzenými, časovo ohraničenými prihlasovacími údajmi; automatické bezpečnostné skenovanie beží pri každej zmene; a produkčné tajomstvá ani citlivé dáta sa k modelu nikdy nedostanú. Žiadne výnimky, žiadne obchádzky.

Čo to prináša

Každú spoluprácu meriame; neodhadujeme. Či si harness zaslúži svoje miesto, nám povedia tri čísla:

• Čas kontroly človekom na jednu zmergovanú zmenu — koľko pozornosti reviewera každá zmena naozaj stojí po tom, ako ju model overil voči plánu, testom a bezpečnostnému checklistu.
• Chyby zachytené pred kontrolou človekom — podiel problémov, ktoré pipeline zastaví skôr, než človek uvidí diff.
• Nápad → nasadené MVP — kalendárny čas od prvého rozhovoru po bežiaci systém, oproti našej baseline spred harnessu.

Svoju prácu už odviedol aspoň raz: pri billing builde architektonická brána zamietla návrh, ktorý by pri retryoch počítal spotrebu dvakrát — ešte skôr, než existoval jediný riadok kódu.

Zverejňujeme ich ako priebežné priemery, keď je vzorka dosť veľká na to, aby niečo znamenala. Čísla sem pribúdajú, ako ich zbierame.

Čo to stojí

Nič z toho nie je zadarmo. Specy zaberú čas skôr, než sa objaví kód, brány prácu zamietajú a vracajú na prepracovanie a pipeline je v prvý deň pomalšia. Berieme to, lebo náklad sa ukáže skoro — tam, kde je lacný — a nie až v produkcii.

Hranica, ktorá sa neposúva

Harness nás robí zároveň rýchlejšími aj prísnejšími — o to celé ide. Nikdy však nerozhoduje. Každá voľba architektúry, každý merge, každý deploy nesie podpis človeka. Preberáte codebase, kde je každý z tých podpisov dohľadateľný.