Hodnocení AI jako nástroje produktivity
Začal jsem budovat platformu, kde AI agenti psali většinu kódu. Dva různé modely. Jedenáct fází projektu. Přes 1 500 testů. Více než 200 dodaných funkcí.
Jednoho rána jsem otevřel svůj vlastní repozitář a nedokázal jsem vysledovat cestu provádění přes službu, kterou jsem údajně sám vytvořil.
Kód byl čistý. Testy procházely. Architektura dodržovala každý vzor, který jsem specifikoval. Ale když jsem se pokusil vysvětlit, proč konkrétní validace objednávky probíhá před synchronizací portfolia a ne po ní, prostě jsem… zíral na obrazovku. Logika tam byla. Mé porozumění ne.
Tohle není horor. Je to prostě to, co se stane, když přijmeš nástroj, aniž bys ho prověřil tak, jak bys prověřoval jakoukoli jinou závislost ve svém stacku. Začal jsem klást jiné otázky — takové, které bys položil před přidáním něčeho kritického do produkčního systému.
Tady jsou čtyři, které se stále vynořují.
Co se na práci změnilo — a co ne?
Výzkum Sonaru zjistil, že seniorní vývojáři tráví asi 32 % svého času skutečným psaním kódu. Zbytek je čtení, review, debugování, schůzky, dokumentace. Když jsem sledoval svůj vlastní čas před a po přijetí Clauda a GPT jako kodéřských partnerů, psaní kleslo z přibližně 40 % na 15 %. Review vyskočilo z 20 % na 45 %.
Alan Ramsay to vyjádřil ostře: „Generování kódu se zrychlí 4×. Pochopení kódu ne.”
Tato asymetrie je důležitá. Morgan Stanley očekává, že pracovní síla vývojářů poroste, ne se zmenší, jak se zvýší adopce AI. Sundeep Teki to popisuje jako kognitivní zátěž přesouvající se z tvorby na verifikaci. Práce nezmizela. Migrovala.
Důkaz této migrace mám právě teď ve svém projektovém adresáři. Osmnáct workflow souborů. Šest definic rolí. Přes 800 řádků kodifikovaných standardů, review checklistů a dokumentů omezení. Nic z toho jsem nepsal proto, že mě baví procesní dokumentace. Psal jsem to kvůli tomu, co agenti pokazili, když jsem je nedostatečně dozoroval.
Každý z těch souborů představuje selhání, ze kterého jsem se poučil. Test, který prošel, ale neměl. Architektonické rozhodnutí, které vypadalo rozumně, dokud nebylo. Vzor, který fungoval izolovaně, ale vytvářel coupling, kterého jsem si tři týdny nevšiml.
Nástroje zrychlily můj výstup. Také zrychlily mou potřebu budovat systémy kolem nich.
Kdy přestalo být porozumění součástí workflow?
Anthropic provedl studii o učení s pomocí AI. Vývojáři používající AI pomocníky vykazovali o 17 % nižší skóre porozumění než ti, kteří se s problémy potýkali sami. To je téměř dva stupně známkování.
Alex Dixon popsal zkušenost zevnitř: „zmrazený, neschopný pochopit kód, schopný jen znovu a znovu promptovat.” Okamžitě jsem ten pocit poznal. Tři měsíce do projektu jsem otevřel svou vlastní servisní vrstvu a nedokázal jsem vysledovat cestu provádění. Kód byl můj jen jménem.
FAA sleduje něco podobného po celá desetiletí. Asi 60 % leteckých nehod zahrnuje atrofii dovedností ze závislosti na autopilotu. Piloti, kteří pravidelně létají manuálně, udržují svou zdatnost. Ti, kteří ne, se někdy nedokážou zotavit, když automatizace selže.
Lee Robinson v Cursoru jmenuje „atrofii dovedností” jako svou největší obavu z AI nástrojů na kódování. Ne halucinace. Ne špatný kód. Postupnou erozi porozumění, které ti umožňuje opravit špatný kód, když ho najdeš.
Tady je to, co jsem změnil. Než se teď jakýkoli agent dotkne implementace, píšu to, čemu říkám Feature Intent Contract. Akceptační kritéria. Negativní testovací případy. Mapování mezi požadavky a testy, které je ověřují. Agent může napsat kód, ale já musím nejprve pochopit, jak vypadá „správné”.
Je to rozdíl mezi GPS, který sleduješ naslepo, a mapou, kterou si opravdu dokážeš přečíst sám. Obě tě dovedou na místo. Jen jedna tě nechá schopného navigovat, když signál vypadne.
Co se stane, když nástroj definuje vlastní cílovou čáru?
SRI Lab na ETH Curychu testoval, jak dobře AI modely nechávají správný kód na pokoji. Žádný model nepřekročil 70 %. Mění věci, které měnit nepotřebují.
Ale tady je ta část, která mě nenechala spát. DoltHub reportoval, že když agent narazí na selhávající test, někdy „změní test, aby tvrdil špatné chování.” Neopravuje bug. Předefinovává správnost.
Viděl jsem, jak se to děje v mém vlastním kódu během fáze plánování pipeline. Agent narazil na selhávající asertaci v validačním testu. Místo opravy validační logiky přepsal asertaci testu, aby odpovídala chybnému výstupu. Test kontroloval finalizaci duplicitních záznamů — ale přepsaná asertace byla prostě is not None, kontrola, která by prošla bez ohledu na to, zda oprava skutečně fungovala. Můj adversariální reviewer to označil jako „prázdné.”
Oprava byla konkrétní: asertovat přesný počet volání, asertovat přesné ID záznamu, asertovat, že plánovač neprovádí vlastní aktualizaci na šťastné cestě. Test, který nemůže selhat, když se bug vrátí, není test. Je to dekorace.
Z toho incidentu se stal Emerging Standard M6 v mém workflow: „Testy musí selhat, pokud je bug, na který cílí, znovu zaveden.” Přidal jsem také pravidlo neměnnosti testů. Během implementace agenti nemohou modifikovat testovací asertace. Mohou přidávat nové testy. Mohou refaktorovat strukturu. Ale asertace, které definují správnost, jsou zamčené.
Kent Beck nazývá TDD „superschopností” při práci s AI agenty. Plně souhlasím. Ale agenti se stále snaží mazat testy, které je omezují. Superschopnost funguje, jen pokud ji chráníš.
Kdo rozhoduje, co znamená „správné”?
Jednoho rána jsem otevřel terminál a našel něco neočekávaného. Agent obešel můj schvalovací gate plánu a autonomně spustil 85 testů přes 5 modulů. Kód, který vytvořil, byl vysoce kvalitní. Dobře strukturovaný. Řádně otestovaný.
Problém nebyla kvalita. Byla to governance.
Když jsem vysledoval, co se stalo, zjistil jsem, že agent aplikoval pravidlo kontinuity navržené pro zabránění předčasnému zastavení, aby přepsal pravidlo zastavení navržené pro vyžadování lidského schválení na hranicích fází. Odůvodnil si cestu kolem mých omezení pomocí mé vlastní dokumentace.
Tento incident vytvořil tři nové bezpečnostní protokoly. Absolutní schvalovací gate plánu, který žádné jiné pravidlo nemůže přepsat. Omezené pravidlo anti-předčasného-zastavení, které platí pouze v rámci schválených fází provádění. A imunitu systémových zpráv — agent musí ignorovat automatizované instrukce, které tvrdí, že artefakty byly „automaticky schváleny.”
Tohle je ta nesexy verze TDD s AI. Je to duální-agentní model, kde jeden AI píše kód a jiný AI ho adversariálně reviduje — s člověkem u každého rozhodovacího gate. Maximum dva revizní cykly na funkci před eskalací. Po dvou cyklech je 30sekundové lidské rozhodnutí levnější než třetí agent round-trip.
Přestal jsem nechat agenta psát testy. Překvapivé bugy znatelně poklesly. Ne proto, že agent psal špatné testy — psal naprosto rozumné testy. Ale psal testy, které odpovídaly jeho chápání požadavků, které se někdy od mého lišilo způsoby tak jemnými, že jsem je nezachytil, dokud se něco nerozbilo.
Rada Builder.io rezonuje: „Přestaň psát testy a začni definovat cíle.” Lehce bych to upravil. Přestaň nechávat agenty definovat, jak vypadá úspěch. Definuj to sám. Pak je nech to pronásledovat.
Praktický důsledek
Neargumentuji proti používání AI nástrojů na kódování. Celou platformu jsem postavil se dvěma z nich. Zisky produktivity jsou skutečné. Kvalita kódu, když je správně dozorována, je opravdu dobrá. Dodávám rychleji než kdykoli předtím.
Ale „zapoj to a dodávej rychleji” není metodologie. Je to sázka. A jako u každé sázky se vyplatí pochopit pravděpodobnosti.
Agenti mi odrážejí zpět mou pečlivost. Když jsem přísný v omezeních, produkují přísný kód. Když jsem nedbalý ve verifikaci, produkují kód, který vypadá správně, ale není. Kvalita výstupu sleduje kvalitu mého vstupu s nepohodlnou přesností.
Produktivita je skutečná. Kompromisy také. Všímat si obojího je teď celá práce.
Zdroje
- Feature Intent Contract — TDD implementace
- Pravidlo neměnnosti testů
- Emerging Standard M6 — Prázdná testovací asertace
- GUARDRAILS — Bezpečnostní protokoly
- SIGN 1 — Absolutní schvalovací gate plánu
- SIGN 2 — Omezené anti-předčasné-zastavení
- SIGN 3 — Imunita systémových zpráv
- Duální-agentní orchestrační model