1.3 milionů řádků, 630 PR týdně: Jak udržujeme vibe-kódovanou codebase udržitelnou

V červenci 2026 Robert C. Martin napsal, že už nečte kód, který vytvářejí jeho kódovací agenti.

Toto prohlášení vzbudilo značnou pozornost. Zbytek jeho příspěvku je však důležitější pro pochopení jeho pracovního postupu. Martin obklopuje agenty unit testy, Gherkin akceptačními testy, QA postupy, mutation testingem, kontrolami pokrytí a kvalitativními metrikami. Důvěru v kód získává tím, že projde tímto systémem.

Podobný názor vyjádřil už o pár měsíců dříve. Místo inspekce implementace sleduje pokrytí testy, strukturu závislostí, cyklomatickou složitost, velikost modulů a výsledky mutation testingu. Když lidé jeho přístup interpretovali jako úplné vzdání se review, upřesnil: „Review dělám dost — jen ne kód.“

Jeho komentáře popisují praktický problém v softwarovém vývoji s vysokým podílem AI. Kódovací agenti dokážou produkovat změny rychleji, než je lidé stíhají číst. Jakmile objem AI-generovaného kódu překročí kapacitu týmu na review, řádková inspekce už nemůže být jediným zdrojem důvěry.

S tímto problémem se ve vm0 potýkáme posledních osm měsíců. Většinu implementace v našem repozitáři píší agenti — vibe coding, jak se dnes často říká — zatímco šest inženýrů zůstává odpovědných za to, co tento kód dělá v produkci.

Stručná verze

vm0 je vibe-kódovaná codebase: agenti píší většinu implementace a šest inženýrů vlastní to, co kód dělá v produkci. Po osmi měsících repozitář obsahuje 1,329,170 řádků a za jediný týden bylo sloučeno 630 pull requestů. Pět mechanismů nese zátěž kvality, kterou už řádková kontrola sama neunese.

• Konvergované prostředí. Inženýři i agenti pracují ve stejném dev kontejneru a každý pull request může mít vlastní databázovou větev. Příkaz, který funguje agentovi, funguje i člověku.
• Spustitelné omezení. Přísný TypeScript, přibližně 135 typovaných API kontraktů, Oxlint, ESLint a architektonická pravidla, přičemž CI nepřijímá žádná varování. Pravidlo, které lze ověřit strojově, nenecháváme na review.
• Testy zaměřené na hranice. Testing trophy místo testovací pyramidy: integrační testy přes veřejné hranice modulů, skutečný PostgreSQL a reálné migrace, mocky pouze na hranicích externích systémů. Testovací kód tvoří asi 36 procent repozitáře.
• Kompletní zpětná vazba. Agenti spouštějí aplikaci i databázi, provádějí migrace a ovládají skutečný prohlížeč, poté hlásí příkazy, které spustili, cestu, kterou testovali, a screenshoty. Medián pull requestu je sloučen za cca 53 minut.
• Průběžný úklid. Knip deterministicky odstraňuje mrtvý kód, denní workflow čistí AI zbytky, které linter nepojmenuje, a často se opakující vzor povyšujeme na lint pravidlo nebo typový systém.

Co znamená vibe coding a agentické kódování

Vibe coding znamená zadat LLM prompt na kód, spustit výsledek, požádat o změny a nevěnovat pozornost samotnému vygenerovanému kódu. Martin Fowler definuje tento pojem úzce a zdůrazňuje frázi „zapomenout, že kód vůbec existuje“. Hodí se pro prototypy, jednorázový software a malé nástroje s omezenými důsledky.

Agentické kódování, které Fowler nazývá agentic programming, je to, co týmy dělají, když očekávají údržbu výsledku. Agent čte repozitář, upravuje soubory, spouští testy a pracuje samostatně delší dobu, zatímco lidé si ponechávají vlastnictví struktury a chování a kontrolují důkazy, které běh přináší: výsledky testů, kvalitativní signály, náhledy a produkční chování.

Rozdíl není v tom, kolik kódu model napíše, ale kam směřuje lidská pozornost.

	Vibe coding	Agentické kódování
Autonomie agenta	Prompt, spuštění, další prompt	Čte repozitář, upravuje, testuje, iteruje
Kdo čte kód	Nikdo	Lidé čtou, co nese riziko
Co se ověřuje	Zda výstup vypadá správně	Typy, kontrakty, testy, náhledy, produkční signály
Nejvhodnější použití	Prototypy a jednorázové nástroje	Software s výhledem na údržbu
Typické selhání	Kód, kterému nikdo nerozumí	Ověření příliš slabé na objem

Agenti, kteří upravují repozitář, jsou jednou větví širší změny; nedekveloperskou stránku jsme rozebrali zvlášť.

vm0 často označujeme jako vibe-kódovaný projekt, protože tento pojem se stal běžnou zkratkou pro software psaný převážně AI. Podle Fowlera je to však blíže agentickému kódování. Naši inženýři píší méně implementace než dříve, ale stále vlastní architekturu, náklady na údržbu a produkční chování.

Jak generování kódu zrychlilo, více odpovědnosti přešlo do vývojového prostředí, typového systému, testovací sady a automatizovaných workflow údržby.

Osm měsíců růstu ve vibe-kódované codebase

Repozitář vm0 vznikl v listopadu 2025. V době našeho posledního týdenního reportu o škálování engineeringu mu bylo přibližně osm a půl měsíce.

Repozitář obsahoval:

Metrika	Počet
Neprázdné logické řádky	1,329,170
Produkční řádky	850,913
Testovací řádky	478,257
Zdrojové soubory	5,549
Testovací soubory	1,327
Balíčky	44
Commity na hlavní větvi	14,005

Tyto počty pocházejí z našeho týdenního reportu za týden od 20–26, 2026, měřeno přímo z monorepa. Testovací kód tvořil asi 36 procent měřené codebase. Jde o podíl objemu kódu, nikoli o pokrytí testy, ale dává představu, kolik implementace se nahromadilo kolem ověřování.

Za tři nedávné celé týdny šest inženýrů provedlo 541, 640 a 631 commitů. Během týdne od 20–26 GitHub zaznamenal 630 sloučených pull requestů. Šest inženýrů jich vytvořilo 556, zbytek 74 vytvořila automatizace releasů.

Medián doby od otevření pull requestu po jeho sloučení byl asi 53 minut. 90. percentil byl přibližně 7.4 hodin.

Při tomto tempu změn je lidské review stále užitečné, ale nemůže nést celý systém kvality. Potřebujeme nezávislé signály v několika bodech životního cyklu změny.

Náš současný přístup má pět opakujících se témat: konvergované prostředí, spustitelné omezení, testy zaměřené na hranice, kompletní zpětnou vazbu a průběžný úklid.

Konvergence vývojového prostředí pomocí dev kontejnerů

Mnoho těžko reprodukovatelných chyb pochází ze stavu, který se v pull requestu nikdy neobjeví.

Vývojář může mít nedefinovanou proměnnou prostředí, globálně nainstalovaný nástroj, starý konfigurační soubor nebo databázi běžící měsíce. Lidé si na tyto detaily zvyknou. Agenti je obvykle nevidí.

Postupně jsme přestali považovat hostitelský stroj za standardní vývojové prostředí. Inženýři i agenti pracují uvnitř dev kontejneru. Vývojový image obsahuje projektový toolchain, PostgreSQL, pgvector, Chromium a nástroje pro automatizaci prohlížeče.

CI spouští verzované toolchain image sestavené ze stejné rodiny vícefázových Dockerfile. Vývojové a CI image slouží různým účelům a produkce má vlastní deployment. Klíčová vlastnost je konvergence: verze nástrojů, závislosti a runtime předpoklady jsou explicitní a verzované.

To nám dává jasné očekávání. Příkazy, které spustí agent, by měl být schopen reprodukovat i inženýr ve stejném vývojovém kontejneru. Kontroly, které projdou během vývoje, by měly běžet pod podobným toolchainem v CI.

Podobný princip aplikujeme na data. Každý pull-request preview může mít vlastní databázovou větev a spustit reálné migrace a seed kroky. Agent může vytvářet data, měnit je a opakovat destruktivní testy, aniž by zasahoval do databáze vývojáře nebo dědil stav z jiného pull requestu.

Změny prostředí procházejí repozitářem. Aktualizace nástrojů, verze prohlížeče a rozšíření databáze jsou reviewovány a propagovány stejně jako aplikační kód.

Zpřístupnění engineering standardů v typech a lint pravidlech

Psané standardy pomáhají lidem chápat rozhodnutí v návrhu. Méně však zaručují, že každá změna tato rozhodnutí dodrží, zvlášť během dlouhých agentních sezení.

Stabilní pravidla vkládáme do typového systému, linterů a CI, kdykoli je lze spolehlivě vyjádřit.

vm0 používá přísná nastavení TypeScriptu, včetně strict a noUncheckedIndexedAccess. Některé balíčky povolují další kontroly na nepoužité hodnoty a implicitní návraty.

API využívá schema-first typovanou REST kontraktovou vrstvu postavenou na typech tRPC a Zod schématech. Drizzle propojuje přístup k databázi s typy TypeScriptu. V době této revize obsahoval repozitář přibližně 135 kontraktových modulů.

Tato volba nezachytí špatná produktová rozhodnutí. Odhalí však odchylky v rozhraní včas. Když se pole nebo odpověď změní, související volání obvykle selžou už při statické analýze. Výsledná chyba je většinou dost konkrétní, aby ji agent využil v další iteraci.

Lintování pokrývá druhou skupinu pravidel. Platforma spouští Oxlint, typově uvědomělé kontroly a ESLint spolu s projektově specifickými architektonickými pravidly. CI nepřijímá žádná varování. Varování, která mohou zůstat neomezeně, se stávají šumem na pozadí, který snadno přehlédnou jak lidé, tak agenti.

Když se problém opakuje, zvažujeme, kam kontrolu zařadit:

1. Lze to vyjádřit typovým systémem?
2. Dokáže to přesně detekovat linter nebo strukturální nástroj?
3. Vyžaduje to sémantické posouzení napříč repozitářem?

První dvě dávají rychlou, deterministickou zpětnou vazbu na každou změnu. Třetí skupinu řešíme opakujícími se workflow popsanými dále v článku.

Zúžení chybových vzorů v AI-generovaném kódu

Některé jazykové konstrukce mají legitimní využití, ale často se objevují i v křehkém kódu generovaném agenty.

try/catch může rozmazat hranici chyby. Když agent narazí na selhání, přidání catch bloku a fallbacku je snadný způsob, jak udržet běh aktuální cesty, ale ztratit původní chybu. Kombinace Promise .then() a .catch() s async/await může rozptýlit řízení toku do několika stylů.

Reactův useEffect vytváří podobný problém ve správě stavu. Často se používá ke kopírování stavu, synchronizaci dvou zdrojů pravdy nebo zakódování závislosti na pořadí, kterou je těžké vyčíst z datového modelu.

Jádro webové platformy tyto vzory ve výchozím stavu omezuje. Oprávněná výjimka může zůstat, s explicitním vysvětlením vedle ní.

Produkční kód v jádru webové platformy aktuálně neobsahuje žádné useEffect. Používáme ccstate a další bezefektové vzory pro explicitnější modelování závislostí a vedlejších efektů. Malý počet produkčních volání useEffect stále existuje jinde v monorepu, hlavně ve sdíleném UI a desktopovém kódu, takže rozsah tvrzení je důležitý.

Tato pravidla vznikla z opakujících se selhání v tomto repozitáři. Když vzor opakovaně způsobuje stejný problém s údržbou, přesouváme jej z doporučení pro review směrem ke spustitelnému omezení.

Testování na hranicích modulů: testing trophy, ne pyramida

vm0 nesleduje klasickou testovací pyramidu. Náš testing guide popisuje testing trophy: statická analýza v základu, integrační testy jako dominantní vrstva a malé množství end-to-end testů pro klíčové uživatelské scénáře.

Unit testy jsou poměrně vzácné. Používáme je selektivně pro bezpečnostně citlivou logiku, algoritmy a stavové automaty. Většina business logiky je testována přes veřejnou hranici modulu.

API testy volají skutečnou aplikaci přes její kontrakty. Testovací data se připravují přes produkční endpointy, kde je to možné, a aserce se provádějí přes veřejné chování. Testy se vyhýbají přímému zásahu do interní služby nebo úpravě databázových tabulek, protože by je to svázalo s aktuální implementací.

Interní infrastruktura zůstává reálná, kde je to rozumné:

• PostgreSQL a pgvector
• databázové migrace
• filesystem
• interní služby
• mocky na hranicích externích systémů

Tyto integrační testy běží pomaleji než silně izolované unit testy a vyžadují plnější prostředí. Také snižují rozdíl mezi „test prošel“ a „aplikace zvládne tuto operaci se skutečnou databází“.

Boundary testy ponechávají prostor pro velké interní refaktoringy. Agent může reorganizovat moduly, rozdělit službu nebo změnit datovou vrstvu, zatímco veřejné chování zůstává chráněno.

Uncle Bob preferuje jiné složení, s velkým využitím unit testů, Gherkinu a mutation testingu. Společným principem je nezávislé ověření. Proces, který kód vygeneroval, by neměl být jediným zdrojem tvrzení, že kód funguje.

Poskytnutí agentům kompletní zpětné vazby

Naše rané běhy kódovacích agentů často končily známou zprávou: kód byl změněn a TypeScript prošel; spusťte aplikaci a zkontrolujte stránku.

To nechává polovinu vývojové smyčky na inženýrovi. Někdo musí připravit databázi, spustit služby, otevřít prohlížeč, vytvořit data, pozorovat chybu a popsat ji zpět agentovi.

Agenti nyní mají dostatek vývojového prostředí, aby zvládli více této práce. Mohou spustit aplikaci i databázi, provést migrace, vytvořit testovací data, navštívit preview pull requestu a provádět skutečné interakce v prohlížeči.

Ověření v prohlížeči zachytí třídu problémů, které typové kontroly a API testy nepokrývají dobře: rozbitá navigace, nenačítající se stavy, chybová oprávnění, která se objeví jen v kompletním flow, a vizuální regrese.

Na konci běhu agent hlásí příkazy, které provedl, cestu, kterou testoval, a co pozoroval. U změn uživatelského rozhraní může přiložit screenshoty. Inženýr může tyto důkazy zkontrolovat před osobním otevřením preview.

Screenshot není test a nedokazuje absenci dalších chyb. Snižuje však náklady na rekonstrukci kontextu agenta. U malé změny rozhraní jsou reprodukovatelné kroky a finální screenshot mnohem užitečnější než zpráva „mělo by být opraveno“.

Kvalita práce agenta závisí výrazně na zpětné vazbě, kterou získá bez čekání na člověka.

Udržování krátkých větví pomocí trunk-based developmentu

Rychlé generování kódu může vytvořit velké množství větví.

Dlouho žijící feature větve hromadí konflikty, duplikovanou práci a zastaralý kontext. Jak pull requesty rostou, review je těžší a pomalejší. Používáme trunk-based development, abychom větve udrželi krátké a průběžně integrovali kolem main.

Naše pravidla pro hlavní větev vyžadují:

• pull requesty pro změny
• lineární historii a squash merge
• merge frontu
• Turbo, Rust a bezpečnostní kontroly
• žádné rutinní obcházení povinných bran

Automatizace postupuje stejně. Agent může vytvořit pull request a některé nízkorizikové údržbové úkoly mohou umožnit automatické sloučení, ale změna stejně projde CI a merge frontou.

Velikost a životnost pull requestů vysvětlují, jak se mohlo sloučit 630 z nich za týden. Malá změna nese méně kontextu, je snazší ji ověřit a méně pravděpodobně koliduje s produktovou prací nebo jinou automatizovanou opravou.

Knip jako garbage collection repozitáře: odstraňování mrtvého kódu

Generování kódu přirozeně přidává soubory a abstrakce. Mazání obvykle vyžaduje samostatný prompt.

Po refaktoringu mohou staré soubory zůstat v repozitáři. Odstranění funkce může zanechat exporty, závislosti a entry pointy. Tyto artefakty málokdy rozbijí testy, ale časem ztěžují orientaci v codebase.

Používáme Knip k hledání nepoužívaných souborů, exportů, závislostí a entry pointů. TypeScript může potvrdit, že kód je platný; Knip se ptá, zda se stále účastní systému.

Zbytky mají pro agenty další náklad. Repozitář je jedním z jejich nejdůležitějších zdrojů kontextu. Zastaralý helper nebo opuštěná implementace může vypadat jako schválený vzor pro dalšího agenta, který jej čte. Udržování čistého kontextu je nenápadná polovina context engineeringu: co agent čte z repozitáře, je stejně důležité jako prompt, který dostal.

Odstranění mrtvého kódu také zlepšuje vstupy pro budoucí běhy. Knip zvládá deterministickou část této práce dostatečně rychle, aby se stal pravidelnou kontrolou kvality.

Opakující se workflow pro úklid AI zbytků

Knip a ESLint mají jasné limity. Mnoho forem degradace vyžaduje projektový kontext a sémantické posouzení.

„AI slop“ používáme jako praktické označení pro tento zbytek: zbytečné fallbacky, duplikované abstrakce, testy obcházející veřejnou hranici nebo obranné větve pro nemožné stavy. Každý případ vypadá neškodně. V souhrnu však ztěžují pochopení repozitáře a dávají dalším agentům špatné příklady.

Několik opakujících se workflow vm0 tyto vzory pravidelně prohledává.

Denní úklid AI slop hledá nové zbytky a vybírá malou sadu oprav s vysokou jistotou a nízkým rizikem. Další workflow kontrolují API testy zasahující do interních služeb, antipatterny v Reactu a ccstate a technický dluh, který lze bezpečně odstranit.

Každé workflow udržuje změny úzké. Otevře pull request a spoléhá na běžné typové kontroly, lint pravidla, testy a merge frontu. Pull request nastavený na automatické sloučení musí stejně projít všemi branami.

Spouštění agentů podle plánu není zdarma a o snižování těchto nákladů jsme psali zvlášť. Workflow se nesnaží odstranit veškerý technický dluh najednou. Malá denní dávka je snazší ověřit a méně narušuje než velký úklid jednou za několik měsíců.

Když workflow najde stejný vzor dostatečně často, zvažujeme přesun kontroly do ESLintu, Knipu nebo typového systému. Sémantické workflow slouží jako místo pro pozorování a zpřesnění pravidla před jeho převedením na levnější deterministickou kontrolu.

Přeměna flaky testů na automatizované opravy

Další skupina workflow začíná selháním GitHub Actions.

Když test selže na hlavní větvi nebo v merge frontě, workflow přečte logy, zkontroluje známky flakiness, podívá se na retry, časování a environmentální faktory. Pokud důkazy podporují konkrétní opravu, aktualizuje test nebo implementaci, otevře pull request a znovu spustí celé CI.

Projití na retry neznamená, že původní selhání je neškodné. Týmy, které spoléhají na tlačítko retry, postupně ztrácejí důvěru v červené buildy. Jakmile k tomu dojde, selhané kontroly se stávají dalším šumem na pozadí.

Automatizované workflow oprav promění občasné selhání v dohledatelnou změnu kódu. Diagnóza, patch a ověření zůstávají viditelné v pull requestu. Inženýři mohou zkontrolovat rizikovější změny, zatímco úzké opravy se silnými důkazy mohou projít merge frontou.

Náš systém kvality má aktuálně tři hlavní vrstvy:

Fáze	Mechanismy	Typické oblasti
Při psaní	TypeScript, kontrakty, Drizzle, ESLint	typové chyby, odchylky rozhraní, známé vzory kódu
Před sloučením	Knip, integrační testy, reálné databáze, preview, merge fronta	mrtvý kód, chování modulů, kompletní runtime výsledky
Po sloučení	plánované a událostmi řízené workflow vm0	AI slop, sémantické antipatterny, flaky testy, architektonický drift

Vrstvy se navzájem ovlivňují. Problémy nalezené workflow se mohou stát statickými pravidly. Selhání v CI nebo produkci se mohou stát testy a novým engineeringovým doporučením.

Kam směřuje lidská pozornost při review AI-generovaného kódu

Inženýři vm0 stále čtou kód, zejména u architektonických změn, bezpečnostně citlivé práce, plateb a datových migrací. „Nikdy nečíst kód“ jsme jako týmové pravidlo nezavedli.

Změnila se však alokace pozornosti při code review. Čtení kódu je jedním signálem mezi kontrakty, testovacími hranicemi, chováním preview, screenshoty, kvalitativními metrikami a diagnostikou workflow.

Některá rozhodnutí stále vyžadují zkušený úsudek:

• zda je požadavek kompletní
• kde mají být hranice modulů
• které chyby jsou obnovitelné
• jaký obchodní dopad může chyba způsobit
• zda je bezpečnostní model vhodný
• jaký nový vzor selhání současná pravidla nepokrývají

Podobný posun nastal na designové straně, kde design-as-code přesunul vizuální rozhodnutí do stejného repozitáře a review procesu. Inženýři také udržují prostředí kolem agentů. Když se problém opakuje, rozhodujeme, zda přidat typové omezení, lint pravidlo, test nebo opakující se workflow. Vývojový systém se stal důležitým engineeringovým artefaktem sám o sobě.

Čitelný kód stále záleží. Dalším čtenářem může být inženýr nebo další agent. Zamotaný kód spotřebuje více kontextu, rozšiřuje rozsah budoucích změn a ztěžuje ověření.

Bezpečnost a změny, které se nezrychlují

Rychlost není aplikována rovnoměrně. vm0 udržuje krátký seznam změn, které mají vlastní tempo: bezpečnostně citlivá práce, platby, datové migrace a architektonická rozhodnutí. Inženýr je čte řádek po řádku, bez ohledu na to, kdo nebo co je napsal.

Bezpečnostní riziko AI-generovaného kódu podle našich zkušeností nespočívá v exotických zranitelnostech, ale v důvěryhodně vypadajícím kódu, který nikdo nevlastní. Důležité jsou běžné kontroly, aplikované důsledně:

• Unit testy, které jinak používáme střídmě, používáme záměrně pro bezpečnostně citlivou logiku, algoritmy a stavové automaty.
• Testy mockují pouze na hranicích externích systémů. Interní infrastruktura zůstává reálná, takže změna, která poruší interní kontrakt, selže v CI, ne až v produkci.
• Agenti pracují v dev kontejneru proti databázové větvi na pull request, ne na stroji vývojáře ani ve sdílené databázi.
• Merge fronta a povinné kontroly nemají rutinní obcházení, včetně pull requestu, který agent otevřel a označil pro automatické sloučení.
• try/catch je ve výchozím stavu omezen, takže selhání je méně pravděpodobné, že bude spolknuto fallbackem, který agent přidal, aby cesta běžela dál.

Zpracování přihlašovacích údajů je samostatný návrhový problém s vlastním řešením: broker pattern, který drží tokeny mimo dosah agenta, jsme popsali v samostatném článku.

Nic z toho samo o sobě nezaručuje bezpečnost generovaného kódu. Zužuje však množinu změn, kde je lidské rozhodnutí jedinou kontrolou, a tuto množinu činí explicitní.

Co tyto údaje neukazují

Týdenní report ukazuje rozsah repozitáře a rychlost dodání. Sám o sobě však nedokládá spolehlivost produkce.

Vyhodnocení dopadu na runtime kvalitu vyžaduje dostupnost, produkční chybovost, počet incidentů, míru selhání změn, četnost rollbacků a průměrný čas obnovy. Zelený běh CI popisuje jen část dodávacího procesu.

Na těchto outcome metrikách dále pracujeme. Engineeringové praktiky vysvětlují, jak systém řídí riziko; produkční data ukazují, jak dobře toto řízení funguje.

FAQ

Co je vibe coding? Vibe coding znamená zadat LLM prompt na kód, spustit výsledek, požádat o změny a nečíst vygenerovaný kód. Definice Martina Fowlera je záměrně úzká: vývojář má „zapomenout, že kód vůbec existuje“. Hodí se pro prototypy, jednorázový software a nástroje s omezenými důsledky.

Co je agentické kódování? Agentické kódování je dlouhodobější forma AI-asistovaného vývoje, kdy agent čte repozitář, upravuje soubory, spouští testy a iteruje samostatně delší dobu. Lidé stále vlastní architekturu a chování a kontrolují důkazy, které běh přináší, místo každého řádku, který agent napsal.

Jaký je rozdíl mezi vibe codingem a agentickým kódováním? Rozdíl je v pozornosti, ne v autorství. U vibe codingu se kód nikdy neinspektuje. U agentického kódování agent pracuje samostatně, zatímco inženýři kontrolují důkazy kolem něj: výsledky testů, kvalitativní signály, náhledy a produkční chování. vm0 je obvykle popisován jako vibe-kódovaný; podle Fowlera jde o agentické kódování.

Co je AI slop? AI slop je zbytek, který AI-generovaný kód zanechává: zbytečné fallbacky, duplikované abstrakce, testy obcházející veřejnou hranici, obranné větve pro nemožné stavy. Každý případ vypadá neškodně. V souhrnu však ztěžují pochopení repozitáře a dávají dalším agentům špatné příklady.

Jak reviewujete AI-generovaný kód při 630 pull requestech týdně? Ne řádek po řádku. Ve vm0 jde lidské review tam, kde je potřeba úsudek: architektura, bezpečnostně citlivá práce, platby, datové migrace. Vše ostatní nesou mechanismy: přísné typy a kontrakty, integrační testy na hranicích modulů, reálné databáze v preview na pull request, ověření v prohlížeči, Knip a merge fronta, kterou žádná změna rutinně neobchází.

Jaké jsou osvědčené postupy pro vibe coding ve velkém? Pět se osvědčilo za osm měsíců ve vm0: konvergovat vývojové prostředí, aby agenti i lidé spouštěli stejné příkazy; zpřístupnit standardy v typech, linterech a CI místo dokumentů; testovat na hranicích modulů proti reálné infrastruktuře; dát agentům kompletní zpětnou vazbu včetně prohlížeče; a uklízet průběžně místo občasných velkých úklidů.

Jaká jsou bezpečnostní rizika AI-generovaného kódu? Běžné riziko není exotická zranitelnost, ale důvěryhodně vypadající kód, který nikdo nevlastní. vm0 drží bezpečnostně citlivou práci, platby a datové migrace na lidském review, používá unit testy záměrně pro tuto logiku, udržuje interní infrastrukturu reálnou v testech, omezuje vzory jako try/catch, které polykají chyby, a nedovoluje rutinní obcházení povinných kontrol.

Vytváří AI-generovaný kód technický dluh? Vytváří specifický druh: kód, který stále kompiluje a prochází testy, ale už se neúčastní systému, plus sémantický zbytek, který linter nepojmenuje. Knip odstraní deterministickou část. Opakující se workflow řeší zbytek v malých denních dávkách a často se opakující vzor se stává lint pravidlem nebo typovým omezením.

Kolik kódu ve vm0 je napsáno AI? Většina implementace. Šest inženýrů vytvořilo 556 z 630 pull requestů sloučených během týdne od 20–26, 2026, zbytek vytvořila automatizace releasů a agenti napsali většinu kódu uvnitř těchto pull requestů. Inženýři vlastní architekturu, omezení a produkční chování.

Co je testing trophy a proč ne testovací pyramida? Testing trophy staví statickou analýzu do základu, integrační testy jako dominantní vrstvu a malé množství end-to-end testů navrch. vm0 ji používá, protože testy psané přes veřejnou hranici modulu chrání chování i při reorganizaci implementace agentem, což velká vrstva unit testů nezajistí.

Jak najdete mrtvý kód v AI-psaném repozitáři? Generování kódu přidává soubory a abstrakce; mazání obvykle vyžaduje samostatný prompt. vm0 spouští Knip jako pravidelnou kontrolu pro hledání nepoužívaných souborů, exportů, závislostí a entry pointů. TypeScript potvrdí, že kód je platný; Knip se ptá, zda se stále účastní systému, což je klíčová otázka pro mrtvý kód.

Je vibe-kódovaný kód bezpečné spouštět v produkci? To závisí na tom, co jej ověřuje, ne na tom, kdo jej napsal. Požadované signály se nezměnily: typy a kontrakty, testy přes veřejné hranice, reálná infrastruktura a pipeline, která musí být zelená. Údaje v tomto článku popisují rozsah repozitáře a rychlost dodání. Dostupnost, chybovost a míra selhání změn jsou metriky, které odpovídají na produkční otázku, a stále je sestavujeme.

Po osmi měsících

Osm měsíců je příliš brzy na vyhlášení finální metody. Modely, agentní nástroje i repozitář se dál mění a naše pravidla a workflow s nimi.

Jedna změna je už jasná. Jak generování kódu zrychlilo, prostředí, omezení, testy a zpětnovazební systém převzaly větší část zátěže kvality. Inženýři tráví méně času psaním implementace a více času definováním chování, navrhováním hranic a zlepšováním ověření.

Codebase vm0 bude dál růst. Knip odstraňuje deterministické zbytky. Statická pravidla blokují vzory selhání, které už známe. Integrační testy chrání chování modulů. Opakující se workflow řeší degradaci, kterou zatím neumíme vyjádřit strojově.

Kód stále záleží. Osvědčené postupy v tomto článku nejsou o psaní menšího množství kódu, ale o rozhodování, co musí být pravda, než změna patří na hlavní větev. Dnes používáme více strojově ověřitelných důkazů k rozhodnutí, zda změna patří na hlavní větev a zda její implementace má v repozitáři zůstat.