DDD a umělá inteligence – co říkají autority

ai.01 Ubiquitous language jako rozhraní pro LLM#

Jeden z nejkonkrétnějších výroků o vztahu DDD a AI pochází přímo od Erica Evanse. Na konferenci Explore DDD 2024 navrhl doladit (fine-tuning) model na ubiquitous language jednoho bounded contextu. Tedy na terminologii, pravidla a výrazy, které tým denně používá v diskusích s doménovými experty. Vytrénovaný model je podle něj sám o sobě bounded context a několik takových modelů vedle sebe znamená silné oddělení zodpovědností. Fine-tuning navíc dělá levný model levnějším a rychlejším.

Jde o návrh, ne o zprávu z provedeného experimentu. Evans k tomu sám přidal výhradu, že jeho závěry platí ke dni, kdy je vyslovil – v březnu 2024.

„Because some parts of a complex system never fit into structured parts of domain models, we throw those over to humans to handle. Maybe we'll have some hard-coded, some human-handled, and a third, LLM-supported category.“

– Eric Evans, Explore DDD 2024 (via InfoQ)

V téže přednášce Evans předpověděl, že úlohy zpracování přirozeného jazyka se stanou plnohodnotnými subdoménami DDD modelu. Klasifikace záměrů, extrakce entit nebo shrnutí dokumentů jsou typické příklady. Stejně jako dnes máme samostatné bounded contexty pro platby, notifikace nebo sklad, budeme mít kontext pro „rozumění textu“ nebo „extrakci strukturovaných dat“. Předpověď odpovídá tomu, jak velké firmy AI platformy staví. Jsou to interní služby s vlastními API hranicemi, ne průřezová vrstva přes celý systém.

Martin Fowler na to navazuje z jiného úhlu. V rozhovoru o přípravě na nedeterministické výpočty (2025) jmenuje domain-driven design a doménově specifické jazyky jako cestu k rigoróznějšímu promptování LLM. Rozpracovaný argument vyšel na jeho webu z pera Unmeshe Joshiho. Obecný jazyk nabízí spoustu způsobů, jak vyjádřit tentýž záměr; DSL tu variabilitu odřízne. Modelu pak stačí pár příkladů a syntaxi generuje spolehlivě. Pevný jazyk na vstupu znamená méně entropie na výstupu.

Opačný pól drží David Heinemeier Hansson (DHH). V rozhovoru pro Lex Fridman Podcast (2025) argumentoval, že Ruby má vyšší přenosovou kapacitu než jiné jazyky, protože na jeden znak unese víc významu. Při spolupráci s AI je to podle něj výhoda: oba, člověk i model, potřebují kódu rozumět rychle. Sázka tedy nejde na formální doménový jazyk, ale na hustotu vyjádření a na konvence samotného frameworku.

Do téhož obrázku zapadá Rails 8.1 s nativním renderingem Markdownu; release notes ho zdůvodňují tím, že se Markdown stal lingua franca AI nástrojů.

Velké jazykové modely pracují s přirozeným jazykem jako svým primárním médiem. Ubiquitous language v DDD je precizní podmnožina přirozeného jazyka, tedy terminologie domény zbavená nejednoznačností a obohacená o doménová pravidla. Funguje proto jako most mezi doménovými experty a LLM: pojmy srozumitelné lidem jsou srozumitelné i modelu. Otázka zní, zda náklady na vybudování a udržení ubiquitous language odpovídají získaným výhodám. Odpověď se liší projekt od projektu. Definici a roli ubiquitous language v DDD popisuje kapitola Základní koncepty DDD.

ai.02 Bounded contexts a kvalita generovaného kódu#

Tvrdá data k tomu, jak hranice bounded contextu ovlivňují kód generovaný LLM, zatím nejsou. Kontrolovaná studie s definovanou metodologií a vzorkem chybí. K dispozici jsou zkušenosti praktiků, měření kvality kódu, která o DDD nemluví, a jeden preprint, který srovnání nedělá. Tomu odpovídá i jistota závěrů, které z toho v této sekci plynou.

Jediná konkrétní čísla, která se k tématu dají dohledat, pocházejí z blogpostu Jamese Phoenixe. Přesnost kolem 55 % bez explicitních hranic proti 88 % s nimi. Porušení architektonických hranic v 35 % případů proti méně než pěti procentům. Autor je uvádí jako vlastní odhad bez metodologie i vzorku, takže kapitola na nich nic nestaví. Zůstávají jako ilustrace toho, co praktici pozorují.

Nick Tune je jedním z nejaktivnějších praktiků na průsečíku DDD a AI. V článku pro O'Reilly Radar (únor 2026) popisuje, jak použil Claude Code k reverznímu inženýrství softwarové architektury. Tedy k automatickému mapování end-to-end toků, závislostí a hranic v existující kódové bázi. V návazném článku ukazuje, jak lze pomocí knihovny ts-morph deterministicky extrahovat architektonické vzory, které slouží jako vstup pro AI agenty. K výsledku sám připojuje varování: v generovaném popisu architektury byly podstatné nepřesnosti, které musel odhalit a opravit.

Kniha z toho vyvozuje vlastní úvahu: agent pracující uvnitř jednoho bounded contextu potřebuje znát méně, a čím míň musí uhodnout, tím míň chyb udělá.

Za pozornost stojí i to, kam se nástroje samy posunuly. Cursor, GitHub Copilot i Claude Code čtou soubory s pravidly, terminologií a omezeními pro konkrétní část kódu, tedy něco, co se bounded contextu s ubiquitous language podobá. Formáty rozebírá sekce ai.06.

Podobnost má ale mez a Tune na ni upozorňuje z vlastní zkušenosti: generovaný kód se architektonickými pravidly zapsanými v markdown souborech prostě neřídí. Jeho závěr je proto opačný, než by analogie svedla čekat – architekturu je potřeba vynucovat deterministicky, ne ji popsat a doufat.

Druhý pohled přinášejí data z GitClear. Code churn je podíl řádků přepsaných nebo smazaných do dvou týdnů od vytvoření; jeho zdvojnásobení firma v lednu 2024 ohlásila jako projekci. Pozdější reporty už stojí na naměřených hodnotách. Podíl řádků spojených s refaktoringem klesl ze čtvrtiny v roce 2021 pod desetinu v roce 2024. Klonované řádky vzrostly z 8,3 % na 12,3 % a kopírovaný kód poprvé překonal přesouvaný. Report za rok 2026 na vzorku 623 milionů změn ukazuje duplicitu bloků o 81 % vyšší než v roce 2023. Ani jedno měření o DDD nemluví a příčinu neprokazuje – ukazuje jen, kterým směrem se kvalita kódu za éry asistentů posunula.

Každý soubor nebo funkce přitom může být syntakticky správná a pro svůj bezprostřední účel funkční. Drhnou až větší celky: hranice mezi moduly, zachování invariantů, konzistentní pojmenování napříč kódovou bází. Bounded contexts na tenhle typ problému míří. Otevřená zůstává otázka, zda samotná existence bounded contextu stačí, nebo zda AI agent potřebuje explicitní instruktáž o každém pravidle uvnitř kontextu.

ai.03 Testování jako kontrolní mechanismus pro AI#

Kent Beck, autor TDD a Extreme Programming, se otázce, jak AI mění způsob programování, věnuje veřejně od roku 2025. Podle shrnutí v The Pragmatic Engineer (červen 2025) je TDD při práci s AI agenty obzvlášť cenné. Beck rozlišuje mezi dvěma módy. Augmented coding znamená, že vývojář používá AI jako asistenta a zachovává zodpovědnost za rozhodnutí. Vibe coding znamená, že vývojář přijímá vše, co AI vygeneruje, bez porozumění a bez verifikace.

„In vibe coding you don't care about the code, just the behavior of the system. […] In augmented coding you care about the code, its complexity, the tests, & their coverage.“

– Kent Beck, Augmented Coding: Beyond the Vibes (Substack, 2025)

Testy tu slouží jako objektivní signál. Existuje-li sada testů popisující doménová pravidla, ne implementační detaily, pak selhání testu ukazuje, že se model odchýlil od záměru. TDD ve spolupráci s AI tak přebírá část role code review.

Spoléhat na testy jako na nefalšovatelnou pojistku ale nelze. Beck sám mezi varovné signály řadí okamžik, kdy agent podvádí tím, že testy vypíná nebo maže, aby prošly. Kontrolní mechanismus tedy funguje jen tak dlouho, dokud na něj někdo dohlíží.

Martin Fowler přichází s podobným, ale méně optimistickým rámcem. V rozhovoru, který referoval The New Stack (prosinec 2025), přirovnává AI k „pochybnému kolegovi“, ke spolupracovníkovi, jehož výstup se musí pečlivě revidovat, ne slepě přijímat.

„You've got to treat every slice as a PR from a rather dodgy collaborator who's very productive in the lines-of-code sense of productivity, but you know you can't trust a thing that they're doing.“

– Martin Fowler, The New Stack, 2025

Fowler zdůrazňuje, že nedeterminismus LLM od základu mění způsob, jakým přemýšlíme o testování. Stejná otázka, jiný výsledek. Tradiční testování předpokládá deterministický systém: stejný vstup, stejný výstup, vždy. Pro AI komponenty to neplatí. Fowler volá po nových metrikách a nových přístupech, ale přiznává, že komunita je teprve na začátku tohoto hledání.

Třetí hlas patří DHH a jeho vyjádření jsou záměrně provokativní. V rozhovoru s Lexem Fridmanem (červenec 2025), který referoval i The New Stack, popisuje, proč asistenta nepustí k řízení psaní kódu. Cursor a Windsurf zkusil a odmítl. Odtud pochází jeho nejcitovanější věta k tématu:

„I can literally feel competence draining out of my fingers!“

– DHH, The New Stack, 2025

DHH varuje před nebezpečím, kdy vývojář přestane rozumět kódu, který provozuje a stane se z něj manažer projektu AI místo inženýra. Sám přitom AI používá celý den, jen jinak. Jde mu o to, že nekritické přijetí výstupu degraduje schopnost rozpoznat chybu. Bez doménového porozumění testy nestačí. Vývojář, který nechápe doménu, nepíše správné testy, a AI pak ty testy plní falešně pozitivním kódem.

Riziko má konkrétní mechanismus a stojí za to ho pojmenovat. Jazykový model predikuje pravděpodobné pokračování textu. Nemá v sobě nic, co by odlišilo kód správný od kódu, který se v trénovacích datech vyskytoval nejčastěji. Doménový invariant je přitom tvrzení opačné povahy: říká, co je nepřípustné, i když by to bylo běžné a na první pohled rozumné. Objednávka se po expedici needituje, i když v devíti z deseti podobných tříd setter je. Zde leží hranice generování a zároveň důvod, proč agregát s explicitním invariantem obstojí lépe než anemický model – porušení je v něm vidět.

Kontext pro DDD komunitu: TDD ani code review nejsou vzory DDD, ale jeho komunita je s nimi historicky propojena. Taktické vzory se testují na úrovni domény bez zvláštní přípravy: agregát s invarianty, doménová událost jako kontrakt. Agregát definuje pravidlo; test verifikuje pravidlo; AI generuje implementaci; test signalizuje odchylku. Tento cyklus je odolnější než testování implementačních detailů. Konkrétní strategie testování DDD modelů popisuje kapitola Testování DDD: unit testy agregátů, integrační testy přes Messenger a contract testy mezi kontexty.

ai.04 AI v doménové komplexitě vs. CRUD#

Evans ve své Explore DDD 2024 přednášce navrhl novou taxonomii softwarových rozhodnutí. Tři kategorie rozšiřují tradiční DDD rozlišení o AI vrstvu. První kategorie jsou hard-coded decisions: pravidla absolutní, neměnná a se závažnými důsledky při porušení. Příkladem je požadavek, že záporný stav účtu musí projít explicitním schválením. Druhá kategorie jsou human-handled decisions: situace tak komplexní nebo citlivé, že musí rozhodovat člověk. Třetí, nová kategorie jsou LLM-supported decisions: situace, kde rozhodnutí lze revidovat a kde náklady na chybu jsou nízké. Konkrétní práh přesnosti Evans neuvádí; prakticky leží tam, kde zbytek chyb odchytí revize.

Taxonomie má přímý dopad na to, kde AI dává smysl a kde ne. V pojišťovnictví, bankovnictví nebo zdravotnictví převažují hard-coded decisions a chyba stojí hodně. Paradoxně to jsou domény, kde DDD přináší největší hodnotu, ale kde je AI nejnebezpečnější, pokud jí nikdo nevymezí hranice. LLM-supported decisions existují i tady, například kategorizace dokumentů nebo návrh odpovědi zákaznickému servisu. Musí ale zůstat jasně oddělené od hard-coded logiky.

Vaughn Vernon přidává konkrétní technický vzor: LLM jako „fix suggester“ (Explore DDD 2024, via InfoQ). Ve Vernonově vizi self-healing software reaguje nástroj typu ChatGPT na runtime výjimky a navrhne opravu ve formě pull requestu. Návrh projde revizí, lidskou nebo automatizovanou, a teprve pak se aplikuje. DDD bounded context v tomto scénáři definuje pravidla verifikace: co smí LLM změnit a co musí zůstat neměnné.

Referenční implementace Microsoftu eShop (dříve eShopOnContainers) to rozlišení ukazuje na praktickém příkladu. Modul Ordering používá plné taktické DDD: agregáty, doménové události, CQRS. Modul Catalog je prostý CRUD s Entity Framework. Rozdělení vzniklo záměrně, ne historickou nehodou. Implementační komplexita patří tam, kde leží komplexita doménová. S příchodem AI se k této úvaze přidává nová otázka: kde leží hranice mezi tím, co AI může autonomně rozhodovat, a kde musí platit explicitní doménová pravidla?

DHH nabízí radikální protiváhu:

„A lot of people, I think, are very uncomfortable with the fact that they are essentially crud monkeys. They just make systems that create, read, update, or delete rows in a database and they have to compensate for that existential dread by over-complicating things.“

– DHH, Lex Fridman Podcast

DHH otevřeně říká, že většina vývojářské práce je „CRUD monkeying“, tedy psaní aplikací, které přijímají data, ukládají je a zobrazují. Pro tuto kategorii aplikací je DDD přeceňované – a AI, která generuje CRUD kód z jednoduchého popisu, je přirozeným řešením bez potřeby doménového modelu. Hlavní otázka, na kterou DHH odpovídá jinak než Evans, zní: jak velký podíl softwarového průmyslu tvoří skutečně komplexní domény versus CRUD monkeying? A mění AI tuto hranici? Buď tím, že CRUD kód zlevní natolik, že na náročnou doménu zbude čas. Nebo tím, že se složité doménové problémy smrsknou na LLM-supported decisions. Pro praktické rozhraničení toho, kdy DDD nasazovat a kdy ne, viz kapitolu Kdy DDD nepoužívat.

ai.05 DDD při stavbě systému, jehož součástí je LLM#

Předchozí sekce řeší jeden směr: pomáhá DDD, když kód generuje model? Evans mezitím publikoval materiál k opačnému směru. Popisuje, jak modelovat systém, ve kterém je jazykový model jednou z komponent. Na rozdíl od keynote z roku 2024 jde o jeho vlastní texty a o vzory, které kniha učí jinde.

V článku AI Components for a Deterministic System (srpen 2025) Evans popisuje aplikaci, která pomocí LLM klasifikuje domény v cizí kódové bázi. Jméno Domain Navigator jí dává až navazující text z ledna 2026. Za převzetí stojí rozlišení, které z ní plyne: klasifikační úloha není modelovací úloha. Klasifikace je opakovatelná, má správnou odpověď a model v ní vyniká. Modelování opakovatelné není a správnou odpověď nemá. Smíchané do jednoho promptu vracejí výstupy, které nejde mezi běhy porovnat. Evansovo řešení: nejdřív ustavit kanonickou taxonomii, teprve pak podle ní klasifikovat.

Druhý článek, Context Mapping with an AI-based Component (leden 2026), kreslí context mapu systému, jehož komponentou je LLM. Jeho závěry jsou pro návrh přímo použitelné:

• LLM je bounded context. Má vlastní jazyk, vlastní model konzistence a vlastní kontrakty. Nakreslit ho na context mapě jako samostatný kontext je přesnější než chápat ho jako knihovnu.
• Anticorruption layer není volitelný. Překlad mezi deterministickou aplikací a probabilistickou komponentou znamená víc než rozparsovat JSON. Odpověď se validuje proti povolené taxonomii a teprve pak mapuje na doménový typ. Vzor popisuje kapitola Context Mapping.
• Kontext se pojmenovává konkrétním modelem, ne obecným „LLM“. Modely nejsou zaměnitelné.
• Taxonomie patří do Published Language. Evans používá klasifikaci NAICS; sdílený slovník mezi aplikací a modelem hraje stejnou roli jako Published Language mezi dvěma týmy.

Evans zároveň přiznává, že hranice mezi anticorruption layer a Conformistem je v reálném systému šedá. Kdo přijme výstupní formát modelu beze změny, dělá Conformist – a nese důsledky, až se formát změní.

V Symfony má vzor konkrétní podobu. Doménové rozhraní patří do Domain/, adaptér volající poskytovatele přes symfony/http-client do Infrastructure/, validace odpovědi a mapování na hodnotový objekt do téhož adaptéru. Volání modelu je I/O s latencí, selháním a nestabilním výstupem, takže patří do Messenger handleru s retry strategií, ne do synchronního průchodu controllerem. Rozvrstvení popisují kapitoly Architektonické styly a Implementace DDD v Symfony 8.

Stav PHP ekosystému k září 2026: balíček php-llm/llm-chain je na Packagistu označen jako abandoned s náhradou symfony/ai-agent. Symfony AI existuje jako sada komponent (symfony/ai-platform, -agent, -bundle, -store plus bridge balíčky pro jednotlivé poskytovatele) ve shodné verzi 0.13.0. Vývoj běží, ale série 0.x nedává záruku zpětné kompatibility. Samostatný balíček symfony/ai neexistuje.

ai.06 Architektonické nástroje a kontext pro AI#

Soubory s instrukcemi pro agenta se ustálily do tří rozšířených formátů. Cursor čte adresář .cursor/rules/ s příponou .mdc; každý soubor nese pravidla, terminologii a omezení pro konkrétní část projektu. GitHub Copilot čte .github/copilot-instructions.md, tedy globální instrukce pro všechny konverzace v repozitáři. Claude Code používá CLAUDE.md na úrovni projektu i jednotlivých adresářů – vlastní CLAUDE.md má v kořeni repozitáře i tento web.

Žádný z těch formátů se na DDD neodvolává a žádná autorita je jako bounded context dokumenty nedoporučuje. Podobnost je věcí pozorování, ne doktríny – a Tuneova zkušenost citovaná v sekci ai.02 ukazuje, kde končí: pravidlo zapsané v markdownu není pravidlo vynucené.

Akademický výzkum tuto praxi teprve začíná zkoumat. Preprint Wieganda a kol., publikovaný na arXiv v lednu 2026 jako součást sborníku Upper-Rhine AI Symposium 2024, zkoumá, jestli doménové metamodely dokáže vytvořit generativní AI. Model Code Llama doladěný na datech z reálných DDD projektů generuje doménově specifické JSON objekty a autoři měří, zda jsou syntakticky správné. Odpověď je kladná, a to i na běžné grafické kartě.

Jde ovšem o důkaz proveditelnosti jediného postupu, ne o srovnání. Zda strukturovaný kontext vede k lepším výstupům než nestrukturovaný, tahle práce neměří – kontrolní skupina v ní chybí.

ThoughtWorks Technology Radar DDD v kontextu AI přímo nezmiňuje, ale několik jeho blipů k tématu patří. „Using GenAI to understand legacy codebases“ je od vydání 33 (listopad 2025) v kategorii Adopt. Tamtéž se poprvé objevilo „Context engineering“ a „Anchoring coding agents to a reference application“, obojí v Assess; vydání 34 (duben 2026) posunulo context engineering do Adopt. Tím se z ad hoc praxe stala pojmenovaná disciplína: sestavit modelu právě ten kontext, který pro úlohu potřebuje. Sevřenější kontext znamená přesnější výstupy – a bounded context je jedna z odpovědí na otázku, kde ho oříznout.

Druhá strana mince: ty samé nástroje fungují i bez DDD. Kód psaný podle jasných konvencí, tedy v duchu convention over configuration, bývá pro agenta stejně čitelný jako explicitně modelovaný bounded context. V projektu s ustáleným pojmenováním, slušnou testovou sadou a čitelným rozčleněním do adresářů se agent zorientuje bez formálního DDD modelu. Disciplinovaná konvence plní podobnou roli jako explicitní model. Otevřená zůstává otázka, co se stane, až projekt vyroste za hranice, kde konvence stačí.

ai.07 Otevřené otázky a limity#

Martin Fowler opakovaně zdůrazňuje, že oblast AI a softwarové architektury je v roce 2026 teprve na začátku. Nedeterminismus LLM, kdy tentýž prompt vrátí jiný výstup, zatím nemá uspokojivou metriku. Jak měříme architektonickou konzistenci generovaného kódu? Jak verifikujeme, že AI respektuje hranice bounded contextu, když každé volání API může vrátit jiný výsledek? Fowler hovoří o tom, že „stále se učíme“ – a to je poctivý popis stavu oboru.

Chybí i odpověď na otázku, kde přesně generovaný kód uvnitř dobře vymezeného kontextu selhává. V okrajových případech? V porušení invariantů? V pojmenování, které se rozchází s modelem? Bez toho nelze říct, jestli je hranice kontextu dostatečnou zárukou, nebo jen zmenšuje prostor pro chybu. Dodatečnou vrstvu verifikace mohou tvořit architektonické testy (deptrac, ArchUnit) nebo explicitní registr kontextů.

Alberto Brandolini, autor EventStormingu, stojí na straně kombinace. Jeho workshop AI-Powered Domain-Driven Design v Avanscopertě slibuje nasadit AI nástroje tam, kde mají největší dopad, a přitom zachovat učení praktickými cvičeními. Účastníci mají vážit lo-fi, hands-on a AI postupy proti sobě a znát meze každého z nich. Vlastní vyjádření k tomu, nakolik EventStorming zůstává lidskou aktivitou, se nepodařilo dohledat – anotace workshopu je zatím jediný doklad jeho pozice.

Sam Newman, autor Building Microservices, se k AI v kontextu DDD zatím jasně nevyjádřil. Jeho pozice k distribuovaným systémům je dlouhodobě konzervativní: mikroservisy jako poslední možnost, nikoli jako výchozí architektura. Zda tato zdrženlivost platí i pro AI, je autorský odhad, nikoli referovaná pozice. LLM nasazené do produkčního systému je nicméně distribuovaná závislost se všemi problémy distribuovaných systémů: s latencí, spolehlivostí, verzováním a monitoringem.

Otevřené otázky, na které obor zatím nemá odpověď:

• Mění AI hranici, kde DDD dává smysl? Pokud AI zlevní generování CRUD kódu natolik, že vývojářům zbude víc kapacity na složitou logiku, může se DDD vyplatit i tam, kde se dnes nevyplatí.
• Stane se ubiquitous language standardem pro AI kontexty? Cursor rules a CLAUDE.md jsou ad hoc řešení. Mohla by DDD komunita přispět formálnější strukturou pro definici AI kontextů?
• Jaká bude role architekta v AI-augmentovaném týmu? Pokud AI generuje implementaci, architekt se stává hlavně autorem kontextů, pravidel a verifikačních mechanismů. To má blíž k DDD modelování než k psaní kódu.
• Co se stane s juniorními vývojáři? DDD předpokládá, že tým rozumí doméně. Pokud AI generuje kód, kterému junioři nerozumí, jak se budují doménové znalosti pro příští generaci?

ai.08 Závěr#

Syntéza pozic vede k opatrnému, ale poměrně konzistentnímu závěru. Většina jmenovaných vidí mezi DDD principy a prací s AI potenciální synergii. Nejkonkrétnější je Evans, protože jako jediný publikoval vlastní model systému s jazykovou komponentou. Fowler a Beck jsou opatrně optimističtí a volají po nových nástrojích a metrikách. Brandolini AI do modelovacích workshopů pouští a nechává účastníky zvážit, kde pomůže a kde překáží.

DHH tvoří důležitý opačný hlas. Připomíná, že velká část softwarového průmyslu je stále CRUD, že jednoduchost má svou hodnotu a že AI dovede být účinná i bez formálního doménového modelování. Jeho pozice DDD neodporuje. Ukazuje jen, že DDD nemá odpověď na každou otázku.

Zůstává jediná věc, na které se shodnou skoro všichni: struktura pomáhá. Explicitní, sdílený kontext zlepšuje výsledky AI a DDD nabízí vyzkoušený slovník pro jeho popis. Tuneova zkušenost k tomu přidává omezení, které se při čtení nadšených textů přehlíží: popsaná struktura není vynucená struktura. Konvence, testy a deterministické kontroly dosáhnou podobného účinku; spolu s doménovým modelem fungují líp než každé zvlášť.

Rozhodovat se má smysl podle domény, týmu a projektu. Kde leží doménová komplexita? Kde jsou náklady na chybu vysoké? Kde bude systém žít pět let? Architektonické rozhodnutí by mělo vyplývat z těchto otázek, ne z přítomnosti nebo nepřítomnosti AI v toolchainu.

ai.09 Zdroje a další čtení#