Článek
Dva týmy, stejná firma, stejný produkt. Tým A dodává osm stories za sprint a jednou za kvartál plánuje „hardening sprint“ na technický dluh. Tým B dodává šest stories za sprint, ale každý pull request zanechává kód čistší, než ho vývojář našel. Po roce má tým A velocity tři stories za sprint a backlog plný regresních bugů. Tým B stabilně dodává sedm.
Tenhle scénář není hypotetický. Je to vzorec, který se opakuje v každé organizaci, která odkládá údržbu kódu na „potom“. A data ukazují, proč.
Proč „potom“ nikdy nenastane
Stack Overflow Developer Survey 2024 ukázal, že technický dluh je dnes hlavní profesní frustrací přes 62 % z 65 000 dotázaných vývojářů — zhruba dvojnásobek jakékoli jiné stížnosti. Longitudinální studie Besker, Martini a Bosch z Chalmers University sledovala 43 vývojářů dvakrát týdně po dobu sedmi týdnů a naměřila, že vývojáři průměrně ztrácejí 23 % pracovního času kvůli technickému dluhu. Replikační studie s 258 respondenty ukázala až 36 %. Nejčastější příčinou ztráty času bylo dodatečné testování — kompenzace za zkratky, které někdo udělal „dočasně“.
Technický dluh se nechová jako hypotéka s fixní splátkou. Chová se jako kreditní karta s variabilním úrokem. Úrok platíte pokaždé, když musíte pracovat s dotčenou částí kódu — a v aktivně vyvíjeném projektu je to nepřetržitě.
Ward Cunningham, autor původní metafory z roku 1992, to sám upřesnil: nikdy neměl na mysli záměrné psaní nekvalitního kódu s plánem pozdější opravy. Mluvil o evoluci porozumění problémové doméně — o tom, že po měsících vývoje konečně chápete, jak měl systém vypadat od začátku. To je nevyhnutelné. Co nevyhnutelné není, je nechat toto poznání ležet ladem.
Exponenciální náklady odkládání
Představte si kód jako město. Každá zkratka je díra v silnici. Jedna díra je drobnost — objedete ji. Deset děr a začínáte plánovat objízdné trasy. Sto děr a nikdo neví, která cesta je průjezdná. Oprava jedné díry v prvním týdnu stojí minuty. Oprava sta děr po roce vyžaduje, abyste nejdřív zmapovali, které silnice vůbec existují.
Data GitClear z roku 2025, analyzující 211 milionů řádků kódu, tento mechanismus dokumentují. Podíl refaktorovacích operací (přesun existujícího kódu na správné místo) klesl z přibližně 25 % v roce 2021 na méně než 10 % v roce 2024. Současně celková míra kopírovaného kódu vzrostla o 48 % a počet duplikátních bloků s pěti a více opakovanými řádky se v průběhu roku 2024 zvedl osminásobně. Vývojáři přestávají refaktorovat a místo toho kopírují. Každá kopie je budoucí bug násobený počtem duplikátů.
Proč se to děje? Protože systém odměňuje krátkodobou velocity. Když tým desátý den sprintu zjistí, že dokončí pouze tři z pěti slíbených stories, stakeholdeři vnímají tři kvalitní stories jako neúspěch — ale pět stories se zkratkami jako úspěch. Agile Alliance popsala destruktivní spirálu, která z toho vzniká: tlak na deadline zvyšuje velocity na úkor kvality, to vede k hromadění dluhu, následuje pokles skutečné velocity, a ještě větší tlak na deadline.
„Konec projektu“ v agilu neexistuje
Odkládání dluhu na konec vychází z waterfallového myšlení, kde projekt má definovaný start a konec. V agilním vývoji je produkt živý organismus s neurčitým horizontem. I když máte fixní release date, kód po něm nezmizí — bude ho udržovat někdo další.
Google to zkusilo jinak. Řešili dluh jednorázovými migracemi — „přepišme modul X do nové architektury“. Nedokončené migrace se staly nejčastěji hlášenou kategorií technického dluhu v celé firmě — tak to identifikoval interní čtvrtletní průzkum mezi inženýry. Teprve kontinuální přístup s maturity modelem, pravidelnými metrikami a systematickým školením přinesl největší pozitivní trend za pět let měření.
SAFe nabízí Innovation & Planning iteraci na konci každého Program Incrementu, která má sloužit inovacím a redukci dluhu. V praxi se ale často degeneruje na odpadiště nedokončené práce z předchozích sprintů. Vývojáři ji znají jako „catch-up sprint“ — a dluh, který tam přistane, nezřídka zůstane netknutý i po něm.
Dvě vrstvy: mikro a makro
Řešení není „buď průběžně, nebo jednorázově“. Je to dvouvrstvý systém.
Vrstva 1 — mikro: každý commit, každý den. Robert C. Martin formuloval Boy Scout Rule: zanechej kód v lepším stavu, než jsi ho našel. Otevřete soubor kvůli feature, vidíte magic number, nejasný název proměnné, chybějící test — opravíte teď, v tom samém pull requestu. Netrvá to hodiny. Trvá to minuty. Ale kumulativní efekt je obrovský: při pěti vývojářích a třech commitech denně to je 75 mikro-vylepšení týdně. Bez plánování, bez vyjednávání s product ownerem, bez tech debt sprintu.
Kontext je klíčovým argumentem pro mikro-vrstvu. Vývojář, který napsal zkratku v úterý, přesně ví proč a jak ji opravit. Za tři sprinty to neví nikdo — včetně něj samotného. Studie Besker et al. identifikovala ztrátu kontextu jako hlavní příčinu, proč dodatečné testování pohltí tolik času.
Vrstva 2 — makro: dedikovaná kapacita na architektonické problémy. Boy Scout Rule neopraví špatně zvolenou messaging architekturu nebo chybějící abstrakční vrstvu. Na to potřebujete plánovanou kapacitu. Osvědčené přístupy:
Pravidlo 15–20 % kapacity každého sprintu na redukci technického dluhu doporučují shodně Scrum.org i McKinsey. Shopify rozlišuje čtyři časové horizonty: denní mikro-vylepšení (cca 10 % času), týdenní „discoveries“ (cca 10 %), měsíční cílené refaktoringy a roční systémové přepisy.
Obě vrstvy se vzájemně doplňují. Mikro-vrstva řeší entropii v každodenním kódu. Makro-vrstva řeší architektonické problémy, které přesahují jeden soubor. Ani jedna z nich se neodkládá na konec.
Protiargumenty: kdy má odkládání smysl
Férovost vyžaduje přiznat, že existují legitimní scénáře pro vědomou akumulaci dluhu.
Raný startup validující product-market fit. Pokud je pravděpodobné, že kód zahodíte celý, investice do jeho kvality je plýtvání. Investoři odměňují trakci, ne čistotu kódu. I v tomto kontextu ale dává smysl alokovat alespoň 10 % sprintu na dluh a přísně oddělovat proof-of-concept (k zahození) od produkčního kódu.
Stabilní kód, který se nemění. Fowler upozorňuje, že úrok z technického dluhu platíte pouze při práci s daným kódem. Modul, který funguje, nikdo se ho nedotýká a nemá bezpečnostní riziko, můžete nechat být. Ale pozor na sebehodnocení „stability“ — v aktivně vyvíjeném produktu je méně stabilního kódu, než si myslíte.
Jednoznačný time-to-market tlak. Vědomý, dokumentovaný kompromis s plánem nápravy je legitimní inženýrské rozhodnutí. Klíčové slovo je dokumentovaný. Nedokumentovaný dluh se stává neviditelným — a neviditelný dluh se nesplácí.
Všechny tři scénáře mají společné jedno: dluh je vědomý, ohraničený a má plán splácení. Žádný z nich neznamená „řešíme to na konci“.
Co to znamená pro váš tým zítra
Změna nevyžaduje reorganizaci, nový nástroj ani souhlas managementu. Vyžaduje tři věci.
Za prvé, dohodu v týmu, že každý pull request zanechá kód lepší, než ho našel. Ne perfektní — lepší. Přejmenování proměnné, extrakce metody, doplnění testu. Minuty práce, měsíce kumulativního efektu.
Za druhé, viditelnost dluhu. Chelsea Troy (Mozilla) na blogu Stack Overflow doporučuje přestat mluvit o „technickém dluhu“ — termín je pro business stakeholdery příliš abstraktní. Místo toho mluvte o maintenance load: kolik procent kapacity týmu pohltí údržba, která nepřidává ani neodebírá features. Pokud máte šest vývojářů a 50 % kapacity jde na údržbu, plánujte features jen pro tři. Business to pochopí okamžitě, protože inženýry vnímá jako drahé.
Za třetí, ochranu kapacity. Těch 15–20 % sprintu na architektonický dluh. Ne jako „bonus, když zbyde čas“ — jako pevnou součást sprint planningu. DORA Report 2024, založený na odpovědích přes 39 000 profesionálů, potvrzuje, že týmy s nižším technickým dluhem dosahují lepších výsledků ve všech čtyřech klíčových metrikách: frekvence nasazení, lead time, change failure rate i čas obnovy po incidentu.
AI tuhle rovnici mění — k horšímu
Jedna poznámka o elefantu v místnosti. GitHub uvádí, že 41 % kódu je dnes generováno s pomocí umělé inteligence, a podle Stack Overflow 2025 přes 84 % vývojářů AI nástroje buď používá, nebo plánuje začít. Do hry tak vstupuje nová proměnná. Studie METR z roku 2025, provedená formou randomizované kontrolované studie na 16 zkušených vývojářích a 246 úkolech, ukázala, že s AI byli o 19 % pomalejší — přičemž sami odhadovali zrychlení o 20 %. Mezi příčinami identifikovali čas strávený kontrolou a úpravou AI-generovaného kódu i kognitivní přepínání mezi psaním a promptováním.
Analýza OX Security (300+ open-source repozitářů) identifikovala v AI-generovaném kódu systematické anti-patterny: vyhýbání se refaktoringu a nadměrnou specifikaci (80–90 % výskyt), porušování principu znovupoužití kódu vedoucí k opakovaným bugům (70–80 %) a falešné testovací pokrytí, které nafukuje metriky bez skutečné validace logiky (40–50 %). DORA Report 2024 kvantifikoval vztah na makro-úrovni: nárůst AI adopce je spojen s poklesem stability dodávek o 7,2 % a propustnosti o 1,5 %.
AI je zesilovač, ne řešení. Pro tým s kulturou průběžného refaktoringu je akcelerátorem. Pro tým, který dluh odkládá na „potom“, je akcelerátorem problémů.
Pointa
Technický dluh není alternativa k dodávání hodnoty. Je to daň, která roste s každým dnem prodlení. Nejlevnější den na opravu kódu je dnes. Nejdražší je ten, kdy vám to řekne zákazník. Nebo ten, kdy vám odejde vývojář, který jako jediný věděl, jak ten modul funguje — a průzkumy ukazují, že o odchodu kvůli technickému dluhu uvažuje zhruba každý druhý vývojář.
Neřešte dluh na konci. Na konci je pozdě.
Zdroje: Stack Overflow Developer Survey 2024/2025, Besker/Martini/Bosch — Chalmers University (2018, replikace 2019), GitClear AI Code Quality Research 2025, Martin Fowler — TechnicalDebt/TechnicalDebtQuadrant, Jaspan/Green — Defining, Measuring, and Managing Technical Debt (Google, 2023), DORA Report 2024, METR Study 2025 (arXiv:2507.09089), OX Security — Army of Juniors Report 2025, Agile Alliance — Technical Debt is a Systemic Problem, Chelsea Troy — Stop saying „technical debt“ (Stack Overflow Blog, 2023).
Transparentnost tvorby
Koncepce, struktura a redakční linie článku jsou dílem autora, který vypracoval obsahovou skicu, stanovil klíčové teze a řídil celý proces tvorby. Generativní AI (Claude Opus 4.6, Anthropic) byla využita jako nástroj pro rešerši, ověřování faktů a rozepsání autorovy předlohy.
Autor ověřil klíčová zjištění a schválil finální znění. Žádná část textu nebyla publikována bez vědomé autorské kontroly. Faktické údaje byly ověřeny proti veřejně dostupným zdrojům uvedeným v textu.
Postup odpovídá principům transparentnosti Nařízení EU 2024/1689 (AI Act). #poweredByAI
