Když začínáte nový projekt na zelené louce, AI kódování působí jako čistá magie. Zadáte prompt a model bez zaváhání vygeneruje čistou komponentu nebo fungující backendový endpoint.
Jenže s tím, jak codebase roste, přichází tvrdé vystřízlivění.
Kolem 100 000 řádků kódu začíná běžná AI znatelně ztrácet dech. Zkouší hádat, prohledává repozitář naslepo a halucinuje neexistující funkce. Kolem 300 000 řádků už samostatný úsudek modelu prakticky kolabuje - kontextové okno nestačí, klasické grepování celého projektu pálí tisíce tokenů a vývoj se mění v nekonečný koloběh oprav rozbitého kódu.
Právě v tomto bodě přebírají otěže systémové kontrakty.
Co je to kontrakt v AITM?
Kontrakt není běžný inline komentář v kódu ani řádek v zapomenutém README.md, který po dvou sprintech přestane platit.
Je to strojově dotazovatelné systémové chování.
Přesně popisuje, co má konkrétní část aplikace dělat, a odkazuje na exaktní zdrojové soubory, testy a UI prvky. Místo aby agent tápal a pročítal desítky souborů, položí systému přímý dotaz: „Kde a jak je implementováno tohle chování?" - a okamžitě dostane přesnou odpověď.
Každý kontrakt v AITM stojí na třech klíčových pilířích:
- behavior - Jednořádková esence toho, co kód dělá. Nejdůležitější pole ze všech. Agent toto pravidlo porovnává se skutečnou implementací v souboru. Pokud vznikne rozpor, systém okamžitě ví, že jde buď o bug, nebo o neaktuální kontrakt.
- confidence - Metrika důvěryhodnosti informace. Nese informaci o spolehlivosti daného popisu vůči ostatním datům v systému (např. zda je chování ověřeno reálnými testy).
- variables - Propojení na společný komunikační jazyk systému (např.
BL.PIPELINE). Funguje jako most mezi byznys logikou na frontendu a backendu, takže kontrakty lze bleskově filtrovat podle konkrétní části UI nebo datové vrstvy.
Reálná ukázka z produkce
V AITM je kontrakt strukturovaný a okamžitě dostupný přes GraphQL API:
contractsForFile(path: "src/pipeline/MergeQueueService.ts", projectId: "ctm-dashboard") {
id # "GM-057"
module # "Git/Merge"
behavior # "Self-merge restart je manuální: po mergi dev-watch dál servíruje
# pre-merge kód, dokud uživatel neklikne Restart v menu, nebo
# Settings.selfMergeRestartMode není 'auto'."
confidence # "tested"
}
Tohle je zásadní rozdíl oproti statické dokumentaci. Agent si kontrakt vyžádá dříve, než vůbec otevře nebo napíše jediný řádek kódu. Nekoná naslepo, neplýtvá kontextem a přesně ví, jakou váhu danému pravidlu přisoudit.
Šetříme tokeny i výpočetní čas: Claude Sonnet na Low-Medium effort
Jedním z největších přínosů přesného navádění přes kontrakty je efektivita samotného AI modelu.
V AITM naši agenti pracují na modelu Claude Sonnet s nastavením Low až Medium effort (thinking). Když má model k dispozici přesný kontrakt, nepotřebuje minuty „přemýšlet", spekulovat nad architekturou celého repozitáře ani pálit obří reasoning budget na triviální rešerši.
Díky kontraktu dostane model do ruky hotovou mapu:
- Ví přesně, do kterého souboru jít.
- Zná očekávané chování (
behavior). - Ví, jak moc informaci věřit (
confidence).
I při nižším úsilí (effortu) modelu tak Claude Sonnet odvádí stoprocentně deterministickou a čistou práci, protože se nemusí spoléhat na svůj „odhad", ale řídí se striktně danou specifikací.
Výsledek na 500K řádcích kódu
Skutečná síla tohoto přístupu se neukáže v prvních dnech projektu, ale ve chvíli, kdy codebase naroste do enterprise rozměrů.
V našem vlastním systému s více než 500 000 řádky kódu dnes spolehlivě běží zhruba 3 500 kontraktů:
- Konec naslepo spouštěného grepování: Agent neprohledává stovky souborů, ale jde rovnou na jistotu.
- Radikální redukce tokenů a halucinací: Kontextové okno zůstává čisté a model netrpí informačním přetížením.
- Konzistentní výsledky: I na půlmilionovém projektu dosahuje AI stejné rychlosti a přesnosti jako při prvním promptu na prázdném repozitáři.