Programovací agent skončil, změny jsou připravené a zbývá je odeslat. V tu chvíli přijde nepříjemná otázka: co se stane, když tahle operace spadne přesně mezi zápisem výsledku a potvrzením, že je hotovo? Odpověď „AI říkala, že to funguje“ tentokrát nestačí. Právě takovou zastávku přidává do práce s Gitem nový projekt Sphinx. Místo dalšího automatického schválení zkouší přimět člověka, aby předpověděl důsledky kódu, který posílá dál.
Ten nápad je sympaticky nepohodlný. Člověka nezkouší z toho, zda pozná název funkce, ale zda chápe její chování. Má ovšem i druhou polovinu, o které se mluví méně rádo: když programátora zkouší jazykový model, musíme se ptát také na kvalitu zkoušejícího. Sphinx je zajímavý právě tím, že jeho dokumentace popisuje nejen zamýšlený postup, ale i případy, kdy hodnocení selhalo. Z toho plyne užitečnější poučení než z další ukázky bezchybně spolupracujících agentů.
Git počká, člověk má vysvětlovat
Jak jsme popsali v rychlé zprávě o Sphinxu, nástroj do vývoje přidává kontrolní otázky nad konkrétními změnami. Podle aktuální dokumentace projektu se při odpovídajícím odeslání do nastavené větve Git pozastaví a otevře se místní dotazník. Po úspěšném dokončení pokračuje původní operace. Fungovat to má i v situaci, kdy příkaz k odeslání spustil programovací agent, nikoli člověk u klávesnice.
Otázky připravuje samostatný hodnoticí model. Čte uložené změny a související kód prostřednictvím nástrojů pouze pro čtení; nedostává konverzaci, ve které program vznikal. V tom je rozumné rozdělení rolí. Zkoušející nemusí převzít autorovo přesvědčivé vysvětlení, ale má hledat oporu v samotném programu. Samostatná relace ovšem nezaručuje správný úsudek ani nenahrazuje test chování.
Dokumentace uvádí názorný příklad s frontou úloh. Pracovní proces zapíše výsledek, ale spadne ještě před potvrzením zpracování. Může se po opětovném doručení úlohy provést stejná operace podruhé? Pokud člověk odpoví chybně, nástroj vysvětlí problém a nabídne jinou situaci se stejným principem. To je autorská ukázka, ne popis incidentu. Dobře ale vystihuje rozdíl mezi čtením kódu a schopností odhadnout, co udělá při selhání.
Zkouška navíc dovoluje nahlížet do podkladů. Vývojář může číst kód a požádat agenta, aby mu ho ukázal. Nejde tedy o soutěž v paměti ani o dokazování, že člověk napsal každý řádek vlastní rukou. To je správná volba: v reálném provozu potřebujeme někoho, kdo umí dohledat a ověřit odpověď, ne vítěze kvízu o názvech proměnných.
A kdo vyzkouší zkoušejícího?
Tady se příběh láme. Sphinx používá hodnocení pomocí jazykového modelu, takže stejná technologie pomáhá vytvořit práci i rozhodnout, zda ji člověk chápe. V publikovaných vývojových měřeních datovaných 15. října 2026 autoři otevřeně rozlišují úspěšné softwarové testy od správnosti otázek a známkování. Popisují malé syntetické repozitáře a výslovně varují, že srovnání modelů není kontrolovaný benchmark a výsledky nejsou certifikací libovolného kódu.
Mezi zaznamenanými problémy je odmítnutí dostatečného vysvětlení, protože neobsahovalo konkrétní formulaci nebo název podmínky. Jiný případ ukázal nedostatek v samotných zkušebních podkladech. To jsou různé chyby a je dobře, že je projekt neslévá do jednoho čísla úspěšnosti. Program může bezchybně předat otázku, přijmout odpověď a uložit výsledek, a přesto člověka vyhodnotit nespravedlivě.
Pro tým je to zásadní rozdíl. Pokud nástroj trvá na slovníku svého vzorového řešení, může místo porozumění odměňovat schopnost trefit se do očekávané formulace. Vývojář se pak neučí lépe přemýšlet o programu, ale lépe odpovídat zkoušejícímu. V krajním případě přidáme k automaticky vyráběnému kódu automaticky vyráběné školní zkoušení — a důvod původní kontroly se ztratí.
Proto je důležitá možnost otázku rozporovat. Sphinx podle dokumentace dovoluje upozornit na chybný nebo nejednoznačný předpoklad; spor sám nemá znamenat úspěšné absolvování. Podle nás je to důležitější vlastnost než efektní počet otázek. Užitečný učitel musí být opravitelný. Model, proti jehož verdiktu není praktická obrana, by v týmu rychle začal rozhodovat o něčem, k čemu nemá spolehlivou kvalifikaci.
Podobnou hranici jsme rozebírali u vzájemných revizí mezi Claudem a Codexem. AI kontrola kódu může přidat jiný pohled, ale souhlas modelů není důkazem správnosti. U Sphinxu se k tomu přidává ještě jedna otázka: zda model správně rozpoznal dobré lidské vysvětlení. To není totožná úloha jako najít chybu v programu.
Pomůcka k učení není podnikový turniket
Autoři tuhle hranici nepřikrášlují. Sphinx označují za procvičování, nikoli bezpečnostní bránu. Místní Git hook, tedy skript spouštěný při určité operaci Gitu, může uživatel s místním přístupem obejít. Nástroj nabízí i výslovné přeskočení kontroly a vypnutí zkoušení se záznamem. Úspěšné absolvování nedokazuje, kdo kód napsal ani zda člověk odpovídal bez pomoci. Popsaná verze navíc nepokrývá slučování přes web, povinné kontroly v průběžné integraci ani nasazování.
To není automaticky nedostatek. Dobrovolný trenažér může mít cenu i tehdy, když jde zavřít. Problém by nastal, kdyby firma začala jeho výsledky vydávat za neobejitelnou kontrolu před vydáním softwaru. Záznam, že někdo prošel otázkami, není povolení pustit změnu do produkce. Oprávnění ke sloučení, testy, revize a odpovědnost vlastníka systému musí mít vlastní pravidla.
Instalace si zaslouží stejně střízlivou pozornost jako princip výuky. Podle README mění globální nastavení Git hooků pro daného uživatele a může se proto projevit ve více repozitářích. Nejde jen o doplněk jednoho projektu. Před zkoušením na pracovním počítači je rozumné zjistit, jaké existující hooky tým používá a co přesně bude nová kontrola zdržovat. Dokumentace počítá i s tím, že čekající Git může narazit na kratší časový limit prostředí programovacího agenta.
A místní dotazník neznamená místní zpracování kódu. Zvolený poskytovatel hodnoticího modelu podle dokumentace dostává změněný kód, související soubory, odpovědi i projektový kontext. Vylučování citlivých cest pomáhá, ale nezachytí tajnou hodnotu vloženou do běžného zdrojového souboru. Projekt také upozorňuje, že strop počtu modelových volání si musí uživatel nastavit sám; ve výchozím nastavení není zapnutý. Licence MIT je oprávnění používat kód nástroje, nikoli schválení odesílat firemní podklady komukoli.
Neudělejme z porozumění další razítko
Sphinx bychom zkoušeli nejdřív na omezené části práce a bez personálních důsledků. To je naše redakční doporučení, ne doložený výsledek projektu. Užitečné by bylo sledovat, které otázky opravdu odhalily chybný předpoklad, kde zkoušející odmítl správnou odpověď a kolik času zabralo spor vyřešit. Samotný počet absolvovaných kontrol by o přínosu řekl velmi málo.
Představme si úpravu platebního procesu. Člověk správně vysvětlí, že opakované doručení může vyvolat další platbu, ale model chce slyšet konkrétní technický termín. Dobrý pracovní postup neskončí přepisováním odpovědi do líbivější podoby. Naváže otázkou, jak duplicitu odhalí test a co jí v daném návrhu zabrání. Teprve spojení vysvětlení s ověřitelným chováním má cenu pro produkt; známka z dotazníku je vedlejší.
O tom, kdo vychová zkušené vývojáře v době automatického psaní kódu, jsme psali u programu PRAISE od Microsoftu a Carnegie Mellon. Sphinx řeší užší, každodenní okamžik: člověk právě předává změnu dál a má si ověřit, zda dokáže vysvětlit její důsledky. Mentor a automatický dotazník nejsou zaměnitelní. Dotazník však může včas otevřít rozhovor, který by jinak vůbec neproběhl.
Nástroj jsme v provozu netestovali; tento komentář vychází z jeho dokumentace, zveřejněných měření a statického čtení vybraných částí implementace. Je to čerstvý projekt, ne prokázané řešení úbytku programátorských znalostí. Za pozornost stojí jeho konkrétní ambice i ochota přiznat, že modelové známkování má vlastní chyby.
Nejlepší výsledek takové kontroly nebude zelené razítko. Bude to chvíle, kdy autor změny řekne: tady jsem přijal chybný předpoklad, takhle jsem ho ověřil a tohle opravím. Pokud místo toho začne jen trénovat odpovědi, které AI ráda slyší, přidali jsme do vývoje další obřad. Odpovědnost za kód se nedá převzít tím, že člověk přesvědčí další chatbot.
