AI nezruší code review. Může z něj udělat nejdražší část vývoje CIO MAG

Představte si tým, který během jednoho čtvrtletí nasadí coding agenty do běžného vývoje. Počet otevřených pull requestů během několika týdnů výrazně vzroste. Autoři připravují změny rychleji, testy se doplňují automaticky a vedení vidí zřetelný nárůst aktivity.

Počet lidí, kteří dokážou bezpečně posoudit změnu autentizace, datového modelu, transakčního chování nebo rozhraní mezi službami, se však nezměnil. Pull requesty čekají. Seniorní vývojáři přepínají mezi vlastní prací a cizími diffy. Autor po prvním komentáři požádá agenta o opravu, ale někdy nedokáže vysvětlit, proč je nový návrh správný.

Code review se potom nestává rychlým potvrzením. Stává se rekonstrukcí záměru, architektury a rizika. AI nezrušila kontrolu. Zlevnila výrobu materiálu, který musí někdo odborně přijmout.

Nejde o argument proti coding agentům. Jde o výrobní ekonomiku: když jeden krok dramaticky zrychlí a navazující kroky ne, omezení se přesune. V softwaru může novým omezením být kvalifikované pochopení a akceptace změny.

Manažerské shrnutí

01Kód není hotový, dokud mu někdo rozumí Průchod testů ani čistý diff nenahrazují porozumění záměru, hranicím a provoznímu dopadu.

02Kapacita review je výrobní omezení Počet kvalifikovaných reviewerů, jejich kontext a dostupný čas určují, kolik změn firma bezpečně absorbuje.

03AI má odstranit rutinu, ne odpovědnost Automatizace má filtrovat běžné chyby a připravit důkazy. Přijetí rizika musí zůstat u jasného člověka.

Cena zápisu klesá. Cena důkazu klesat nemusí

Empirické výsledky produktivity vývojářů s AI nejsou jednotné, a právě to je pro vedení IT důležité. Kontrolovaný experiment s 95 profesionálními programátory zjistil u pevně vymezené úlohy v JavaScriptu o 55,8 % rychlejší dokončení s GitHub Copilotem. Tři podnikové terénní experimenty s 4 867 vývojáři následně spojily používání asistenta s 26,08% růstem dokončených týdenních úloh; ve stejné analýze vzrostl počet commitů o 13,55 % a kompilací o 38,38 %.

Jiný randomizovaný experiment pracoval se 16 zkušenými open-source vývojáři, 246 reálnými úlohami a repozitáři, které účastníci dobře znali. S nástroji dostupnými na začátku roku 2025 trvali vývojáři o 19 % déle, přestože sami očekávali a následně vnímali zrychlení. METR v aktualizaci z února 2026 uvedla, že novější nástroje už pravděpodobně přinášejí větší zrychlení, ale výsledek znehodnocují silné výběrové efekty: lidé a úlohy, pro které je AI nejvýhodnější, mohou z experimentu odpadat.

Poctivý závěr proto není „AI vývojáře zrychluje“ ani „AI vývojáře zpomaluje“. Je jím, že účinek závisí na typu úlohy, znalosti systému, nástroji, senioritě, způsobu práce a na tom, co organizace považuje za dokončený výstup. Vyšší počet commitů je výrobní aktivita. Není to ještě bezpečně akceptovaná změna.

Fáze změny	Co může AI výrazně zlevnit	Co musí firma stále prokázat
Návrh varianty	Vyhledání souvislostí, skeleton řešení, alternativy a první návrh.	Jaký problém se řeší, podle kterých omezení a proč zvolená varianta odpovídá obchodnímu cíli.
Implementace	Boilerplate, lokální úpravy, migrace, testovací kostry a opakované transformace.	Že změna respektuje architekturu, kontrakty, datové invarianty a pravidla konkrétního systému.
Technické ověření	Spuštění kontrol, návrh testů, sumarizaci diffu a hledání známých vzorců chyb.	Že testy měří správné chování, pokrývají relevantní failure modes a nejsou pouze potvrzením implementace.
Akceptace	Seznam možných rizik, kontrolní otázky a přípravu podkladů pro review.	Kdo přijímá zbytkové riziko, zda je změna přiměřená a zda jsou důkazy dostatečné.
Provozní převzetí	Návrh release notes, runbooku, observability a rollback kroků.	Že tým umí změnu nasadit, sledovat, vrátit a podporovat v reálném provozu.

VÝZKUMNÉ OMEZENÍ

Studie měří odlišné nástroje, úlohy i výstupy: čas na omezenou implementaci, počet dokončených ticketů, commitů nebo dobu reálné práce ve známém repozitáři. Z žádné z nich nelze odvodit univerzální produktivní násobek ani cenu celé změny od zadání po bezpečný provoz.

Code review není korektura syntaxe

Code review se často popisuje jako hledání chyb v diffu. Výzkum moderního review ale ukazuje širší funkci. Studie Googlu spojila 12 rozhovorů, průzkum 44 lidí a logy devíti milionů změn. Popsala review jako lehký, iterativní proces, jehož významem je také srozumitelnost pro budoucí vývojáře, skupinové řešení problému a šíření znalosti.

Výzkum Microsoftu obdobně zjistil, že hledání defektů zůstává hlavní deklarovanou motivací, reálné přínosy ale zahrnují povědomí o změnách, přenos znalostí a hledání alternativních řešení. Studie vztahu review a kvality v projektech Qt, VTK a ITK pak spojila pokrytí review, účast a odbornost reviewerů s pozdější kvalitou softwaru.

Review je proto především informační a úsudková práce. Analýza 900 review vláken v OpenStacku, Androidu a Qt identifikovala sedm tříd informačních potřeb: vhodnost alternativy, správné pochopení, důvod změny, kontext kódu, nezbytnost změny, specializovanou odbornost a možnost změnu rozdělit. Reviewer se neptá jen „projde to?“. Ptá se „rozumím tomu správně a je to správná změna pro tento systém?“.

Otázka při review	Co lze dobře automatizovat	Co zůstává odborným úsudkem
Projde změna známými kontrolami?	Build, testy, linters, SAST, policy-as-code a kontrola formálních konvencí.	Zda kontroly pokrývají skutečný záměr a relevantní negativní scénáře.
Je diff lokálně konzistentní?	Styl, opakované vzorce, chybějící obsluha, nápadné závislosti a sumarizace.	Zda lokální čistota nezakrývá nesprávnou hranici modulu nebo nový dlouhodobý závazek.
Mění se kontrakt nebo invariant?	Porovnání schémat, API, typů a známých vazeb.	Kdo používá implicitní chování, jak se změna migruje a zda je kompatibilita skutečně zachovaná.
Je změna bezpečná?	Známé slabiny, secrets, oprávnění, závislosti a část statické analýzy.	Threat model konkrétní služby, přijatelnost zbytkového rizika a obchodní dopad zneužití.
Lze změnu provozovat a vrátit?	Návrh metrik, logování, rollout kroků a rollback checklistu.	Zda operátor změně rozumí, má pravomoc reagovat a rollback nepoškodí data nebo navazující systémy.

Bezpečnostní review navíc ukazuje, že ani člověk není neomylný. Empirická studie OpenSSL a PHP analyzovala 135 560 komentářů a našla bezpečnostní připomínky v 35 ze 40 kategorií slabin. Mnoho připomínek vedlo k opravě, část ale zůstala pouze vzata na vědomí, nevyřešena nebo sporná. Důsledkem není zrušit lidské review, ale dodat mu lepší automatické kontroly, specializované checklisty a jasné vlastnictví neuzavřeného rizika.

ROZHODOVACÍ PRAVIDLO

Reviewer nemá ručně dokazovat každou vlastnost změny. Musí ale dostat tolik kvalitních důkazů a kontextu, aby mohl v mezích svého mandátu říct: tomuto záměru rozumím, vím, co se mění, a přijímám způsob, kterým bylo riziko omezeno.

Když produkce roste rychleji než akceptace

DORA ve své analýze generativní AI spojila 25% růst adopce s 1,5% poklesem delivery throughputu a 7,2% poklesem stability. Autoři tento vztah vysvětlují mimo jiné většími dávkami změn: kód vzniká rychleji, pull requesty rostou, review se zpomaluje a systém hůře absorbuje změnu. Jde o asociaci, nikoli důkaz, že AI sama způsobila horší výsledky. Přesto je mechanismus pro vedení IT prakticky důležitý.

DORA v roce 2026 popsala „verification tax“: část času ušetřeného při psaní se znovu spotřebuje při auditu a promptování. Ve výzkumu pro rok 2025 uvádí, že 30 % vývojářů důvěřovalo AI generovanému kódu málo nebo vůbec. Ověření je jiný typ kognitivní práce než tvorba a nelze automaticky předpokládat, že jeho cena klesá stejným tempem.

V systému omezeném kapacitou review proto další generování nemusí zvýšit průtok. Může zvýšit rozpracovanost. Čím více změn čeká, tím více kontextů musí reviewer obnovovat, tím starší jsou podklady a tím vyšší je tlak na povrchní souhlas.

AUTORSKÝ TERMÍN

Akceptační dluh je nahromaděný objem změn, které organizace technicky vytvořila, a možná už prošly CI, ale ještě jim dostatečně nerozumí, odborně je nezpochybnila nebo za ně nepřevzala provozní odpovědnost. Nejde o standardizovanou výzkumnou metriku.

Viditelný signál	Co se může ve skutečnosti dít	Jak to ověřit
Počet pull requestů roste, počet merge operací zůstává stejný	Firma zvýšila produkci diffů, nikoli schopnost změny přijímat.	Porovnejte otevřené, sloučené a nasazené změny a věk review fronty.
Čas k prvnímu review se prodlužuje	Kvalifikovaní lidé jsou omezená sdílená kapacita a práce se koncentruje u několika expertů.	Změřte medián i 85. percentil podle týmu, domény a reviewera.
Pull requesty jsou větší a „kompletnější“	Agent vyrobil více souvisejících úprav dříve, než autor získal zpětnou vazbu.	Sledujte počet změněných souborů, logických záměrů a možnost bezpečného rozdělení.
Reviewer opravuje návrh místo jeho posouzení	Autor předal implementaci, které sám nerozumí dostatečně hluboce.	Nechte autora bez nástroje vysvětlit záměr, invarianty, alternativu a rollback.
AI reviewer přidává mnoho komentářů	Automatizace vytváří další práci: třídění, vysvětlování a opravy málo hodnotných připomínek.	Měřte podíl relevantních, přijatých, odmítnutých a duplicitních komentářů.
Stále stejní senioři schvalují vše důležité	Review chrání kvalitu, ale současně vytváří personální úzké hrdlo a knowledge silo.	Zmapujte podíl review práce u horních 10 % reviewerů a soubory bez druhého znalého člověka.

Výzkum rozdělování reviewerů potvrzuje, že workload bývá silně koncentrovaný a že review současně šíří znalost. Simulovaný recommender, který vyvažoval odbornost, workload a riziko odchodu, v analyzovaných projektech zvýšil odbornost review o 3 %, snížil koncentraci práce o 12 % a počet souborů ohrožených odchodem jediného znalce o 28 %. Produkční experimenty v Meta zase ukázaly, že určení jednoho konkrétně odpovědného reviewera zkrátilo time-in-review o 11,6 % bez zhoršení sledovaných guardrails.

TEST PRO VEDENÍ IT

U třiceti posledních změn rozdělte celkový čas na aktivní práci autora, automatické kontroly, čekání na prvního kvalifikovaného reviewera, aktivní review, opravy po review, čekání na finální akceptaci a nasazení. Jestli je největší položkou čekání nebo rekonstrukce kontextu, bottleneck už není v psaní.

DIAGNOSTIKA Z REVIEW PRAXE

Délka diffu je slabý odhad ceny review. Změna o osmdesáti řádcích, která současně mění oprávnění, datový invariant a chování při chybě, může spotřebovat více seniorního času než mechanická migrace o osm set řádků. Frontu proto třiďte podle počtu rozhodovacích hranic, nevratnosti a potřebné doménové znalosti, nikoli pouze podle velikosti změny.

AI reviewer může pomoci. Nemůže převzít akceptaci

Automatizované review má reálnou hodnotu, ale současná evidence nepodporuje jeho jednoduchou záměnu za zkušeného člověka. Průmyslová studie nástroje založeného na Qodo PR Agent zahrnula 238 praktiků, deset projektů a detailní analýzu 4 335 pull requestů. U automatických komentářů bylo 73,8 % označeno jako vyřešených. Průměrná doba uzavření pull requestu však vzrostla z 5 hodin 52 minut na 8 hodin 20 minut a dopad se mezi projekty lišil; vývojáři současně hlásili falešné, zbytečné a irelevantní připomínky.

Velká observační preprintová studie z července 2026 analyzovala 1,02 milionu reviewovaných pull requestů ve 207 open-source projektech. Některé formy zapojení agentů souvisely s rychlejším rozhodnutím, ne však s lepší kvalitou review; rychlá adopce LLM reviewerů byla spojena s vyšším výskytem review smells a bez zisku v efektivitě. Jde o asociace v otevřených projektech, nikoli kauzální experiment.

Také benchmarková evidence je zatím omezená. SWE-PRBench pracuje s 350 pull requesty a lidsky anotovanou ground truth. Osm testovaných modelů v konfiguraci pouze s diffem zachytilo 15-31 % problémů označených lidmi. Jde o preprint, relativně malý benchmark a hodnocení částečně založené na LLM-as-judge; výsledek proto není definitivní měřítko všech nástrojů. Je ale silnou připomínkou, že schopnost generovat řešení a schopnost spolehlivě posoudit cizí změnu nejsou stejná kompetence.

Současný návrh GitHub Copilot code review tuto hranici prakticky přiznává: Copilot odesílá review typu „Comment“, nikoli „Approve“ nebo „Request changes“, jeho stanovisko se nepočítá do povinných schválení a neblokuje merge. NIST ve svém profilu pro generativní AI současně doporučuje generovaný kód přezkoumávat kvůli rizikům nespolehlivého downstream rozhodování; SSDF vyžaduje kód analyzovat a testovat jako součást bezpečného životního cyklu.

Riziková třída změny	Minimální cesta akceptace	Nejvhodnější role AI
Lokální, vratná, nízký dopad	Automatické kontroly, AI pre-review a jeden lidský vlastník změny.	Styl, běžné chyby, sumarizace, chybějící testy a návrh drobných oprav.
Běžná produktová změna	CI, doménový reviewer a doložený záměr, testy a rollback.	Příprava review packetu, hledání dopadů, návrh edge cases a kontrola konzistence.
Změna dat, rozhraní nebo několika služeb	Doménový vlastník plus specialista vyvolaný konkrétním triggerem.	Mapa závislostí, porovnání kontraktů a seznam neověřených předpokladů.
Bezpečnostně, regulatorně nebo provozně kritická	Dvě nezávislé lidské perspektivy, specializované kontroly a explicitní vlastník rizika.	Doplňková analýza, checklisty a důkazy; nikoli finální schválení nebo přijetí výjimky.

HRANIČNÍ PODMÍNKA

Člověk nemá znovu ručně provádět kontroly, které lze spolehlivě automatizovat. Automatizace ale nemá certifikovat obchodní záměr, architektonický trade-off, bezpečnostní výjimku nebo provozní riziko, za které nemůže nést odpovědnost.

Když autor neumí změnu vysvětlit, reviewer se stane reverzním inženýrem

V klasickém review má autor mentální model změny a reviewer jej musí částečně rekonstruovat. U agentního vývoje se může vztah obrátit: model zná detaily své pracovní trajektorie, autor zná zadání a reviewer dostane výsledný diff. Jestli autor pouze předá výstup, náklady na skutečné pochopení se přesunou na nejdražšího člověka v řetězci.

Odpovědnost nelze delegovat promptem. Autor nemusí ručně napsat každý řádek, musí ale dokázat vysvětlit, jaké chování se mění, které předpoklady musí platit, jaký trade-off přijal, kde může řešení selhat a jak se změna bezpečně vrátí. Když tyto otázky neumí zodpovědět, pull request není připravený k review, je pouze připravený k dalšímu výzkumu.

Výzkum popisů pull requestů tuto potřebu podporuje. Studie 80 tisíc PR ve 156 projektech a pěti jazycích zjistila, že vývojáři považují vysvětlení účelu a kódu za důležité pro uchování důvodu a historie změny; uvedení požadovaného typu zpětné vazby nejlépe predikovalo přijetí změny a zapojení reviewerů.

Pole review packetu	Minimální obsah před přizváním člověka
1. Záměr	Jaký uživatelský, provozní nebo technický výsledek se mění a proč je změna potřebná.
2. Rozsah	Co je součástí změny, co výslovně není a zda diff obsahuje jeden rozhodovací záměr.
3. Invarianty a kontrakty	Které chování musí zůstat zachované a které rozhraní, data nebo oprávnění se mění.
4. Odmítnutá alternativa	Alespoň jedna reálná varianta a důvod, proč je horší v konkrétním kontextu.
5. Důkazy	Výsledky testů, statických kontrol, měření a negativních scénářů; nikoli jen tvrzení, že „testy procházejí“.
6. Dopad a riziko	Závislosti, bezpečnost, data, náklady, výkon, kompatibilita a známé failure modes.
7. Rollout a rollback	Jak bude změna uvolněna, sledována, zastavena a vrácena bez ztráty dat nebo kontroly.
8. AI a neověřené části	Kde AI vytvořila významnou část řešení, co autor osobně ověřil a kde žádá cílenou expertizu.
9. Požadovaná zpětná vazba	Které rozhodnutí má reviewer udělat: logika, architektura, bezpečnost, API, testy nebo provozní připravenost.

PODMÍNKA PŘIPRAVENOSTI

Pull request je připravený tehdy, když autor dokáže bez pomoci agenta vysvětlit jeho záměr, hlavní riziko a důkaz správnosti, a automatické kontroly už odstranily rutinní chyby, které nemají spotřebovávat lidské review.

Modelový příběh: tým zdvojnásobil výrobu změn a dodávka zpomalila

Následující příklad je složený z opakujících se situací z praxe; čísla jsou ilustrativní. Produktový tým měl tři zkušené reviewery a přibližně dvacet pull requestů týdně. Po zavedení coding agentů se počet otevřených změn dostal nad čtyřicet. Autoři pracovali rychleji, ale kapacita review zůstala stejná.

Nejprve se prodloužila doba k první reakci. Potom začaly růst diffy: vývojář nechal agenta dokončit celou související oblast, aby „reviewera nerušil dvakrát“. Seniorní lidé tak dostávali větší změny, častěji obnovovali kontext a v několika případech museli sami dohledat, proč model zvolil konkrétní datový nebo transakční vzorec.

Tým zkusil přidat automatického reviewera ke každému pull requestu. Počet komentářů vzrostl, ale lidé strávili další čas jejich tříděním. Teprve potom změnil pracovní systém: zavedl limit rozpracovaných review, rozdělování změn podle jednoho záměru, povinný review packet, AI pre-review před přizváním člověka, jednoho odpovědného reviewera a specialisty pouze podle jasných bezpečnostních, datových a architektonických triggerů.

Cílem nebylo vrátit se k pomalému ručnímu psaní. Cílem bylo zabránit tomu, aby levná produkce kódu vytvářela drahou zásobu nepochopených změn. Počet současně otevřených pull requestů klesl a review se znovu stalo rozhodnutím, nikoli záchranným vývojem.

POINTA PŘÍBĚHU

Coding agent zvýšil kapacitu autorů. Hodnotu ale vytvořil až nový systém akceptace: menší změny, lepší důkazy, jasný vlastník review a automatizace umístěná před lidský úsudek.

Co má vedení IT měřit

Počet vygenerovaných řádků, commitů nebo otevřených pull requestů není dostatečný ukazatel. Vedení IT potřebuje sledovat celý tok od okamžiku, kdy autor označí změnu za připravenou, až po její bezpečné nasazení a první provozní ověření.

Metrika	Co odhaluje	Varovný signál
Čas k prvnímu kvalifikovanému review	Dostupnost člověka s relevantní znalostí; sledujte medián i horní percentily.	Průměr vypadá dobře, ale část změn čeká několik dní na jednoho experta.
Podíl lead time strávený čekáním	Zda omezením zůstává implementace, nebo se přesunulo do fronty.	Aktivní práce trvá hodiny, rozhodovací čekání dny.
Aktivní reviewer time na změnu	Skutečnou cenu pochopení a diskuse, nikoli pouze kalendářní latenci.	Čas roste spolu s AI adopcí, i když počet řádků zůstává podobný.
Review WIP a věk fronty	Kolik změn současně čeká a jak rychle ztrácí aktuální kontext.	Staré PR se musí znovu rebazovat, vysvětlovat nebo přepisovat.
Koncentrace review práce	Personální závislost na několika seniorních lidech.	Horních 10 % reviewerů drží většinu kritických schválení a nemá zástup.
Velikost a blast radius změn	Zda rychlá generace vytváří příliš velké dávky nebo více záměrů v jednom diffu.	Roste počet souborů, služeb a kontraktů na jeden pull request.
Iterace a předělávky po review	Kvalitu přípravy změny, podkladů a první verze návrhu.	Reviewer opakovaně opravuje architekturu nebo autor jen přeposílá AI komentáře.
Defekty a rollbacky po merge	Zda rychlost akceptace nepřesunula náklady do provozu.	Lead time klesá, ale roste change fail rate, bezpečnostní nálezy nebo hotfixy.
Podíl změn s úplným review packetem	Připravenost autora a kvalitu předání kontextu.	Povinná pole se vyplňují obecně nebo je neumí autor při rozhovoru obhájit.
Průtok bezpečně nasazených změn	Výsledek celého systému, nikoli aktivitu jednoho kroku.	Roste počet PR a commitů, ale hodnota v produkci, stabilita a spokojenost zákazníků ne.

METRICKÁ POJISTKA

Rychlost párujte s kvalitou: time-to-review s předělávkami, merge throughput s incidenty a míru adopce AI s provozním výsledkem.

Třicetidenní reset review kapacity

Prvním krokem nemá být plošné přidání dalšího AI review bota ani obecný požadavek, aby senioři „reviewovali rychleji“. Nejdříve je potřeba zjistit, kde se cena změny skutečně přesunula a která část lidské práce vytváří rozhodnutí, nikoli rutinu.

Období	Hlavní krok	Hmatatelný výstup
0-5 dní	Vybrat třicet nedávných změn s výraznou AI asistencí a srovnatelný vzorek. Změřit aktivní práci, čekání, review iterace, velikost diffu a post-merge opravy.	Mapa skutečné ceny změny a první důkaz, zda se omezení přesunulo do review.
6-10 dní	Vymezit čtyři rizikové třídy změn, rozhodovací triggery, jednoho vlastníka review a minimální review packet.	Jednostránková politika, která rozlišuje rutinní, doménové, cross-system a kritické změny.
11-20 dní	Zavést AI pre-review před člověkem, automatické quality gates, limit review WIP a pravidlo jednoho záměru na pull request. Chránit bloky času pro review.	Pilotní tok, v němž člověk dostává menší změnu, relevantní důkazy a jasnou rozhodovací otázku.
21-30 dní	Porovnat čas k review, aktivní reviewer time, koncentraci workloadu, předělávky a escaped defects. Odstranit hlučné automatické kontroly a upravit triggery.	První provozní důkaz, že AI zvyšuje průtok akceptovaných změn, nikoli pouze počet vytvořených diffů.

PODMÍNKA ÚSPĚCHU

Po třiceti dnech musí nízkoriziková změna dorazit k člověku až po objektivních kontrolách, s jasným záměrem a rollbackem. Kritická změna musí naopak spolehlivě vyvolat odborníka, který má kontext, čas a pravomoc ji přijmout nebo zastavit.

Nejrychlejší tým nevyrábí nejvíc kódu

AI mění nákladovou strukturu vývoje. Varianta, skeleton, test i lokální oprava mohou vzniknout téměř okamžitě. Tím ale nezmizí potřeba rozhodnout, zda změna patří do systému, zda respektuje jeho implicitní pravidla a zda ji firma umí bezpečně provozovat.

Code review proto nemusí být relikt ručního vývoje. Může se stát nejcennější, a zároveň nejdražší, částí procesu, protože soustřeďuje vzácný kontext, odborný úsudek a odpovědnost. Chybou by bylo reagovat na tuto cenu povrchním schvalováním nebo prostým přidáním dalšího generátoru komentářů.

Vedení IT má řídit poměr mezi produkční a akceptační kapacitou. Musí chránit review time, rozšiřovat znalost mimo několik expertů, zmenšovat dávky, automatizovat rutinní důkazy a odmítnout změnu, jejíž autor jí sám nerozumí. Teprve potom se rychlejší výroba kódu promění v rychlejší dodávku.

AI nezruší code review. Zruší však iluzi, že nejdražší částí vývoje je psaní řádků. Když lze kód vyrábět téměř bez mezních nákladů, nejvzácnějším zdrojem se stává člověk, který dokáže změnu pochopit, zpochybnit, přijmout a nést její důsledky.

ZÁVĚREČNÁ TEZE

Kód není firemní aktivum v okamžiku, kdy jej model napsal. Je jím teprve tehdy, když jej někdo dokáže vysvětlit, ověřit, schválit a bezpečně provozovat.