Slovník AI

Pohyblivý názov, nie technológia. „AI“ neoznačuje pevnú vec tak, ako ju označuje model alebo token — pomenúva čokoľvek nové a pôsobivé, čo počítače dokážu. Dnes tým myslíme veľké jazykové modely. V minulosti sa tým označovali celkom iné veci:

Tento posun má známy mechanizmus, niekedy nazývaný efekt AI: keď nejaká technika začne spoľahlivo fungovať, premenuje sa — je to „iba“ vyhľadávanie, „iba“ štatistika — a „AI“ sa posunie k ďalšej nevyriešenej veci. Toto pozorovanie je staré. Bertram Raphael to v roku 1971 vyjadril takto: „AI je súhrnný názov pre problémy, ktoré zatiaľ nevieme počítačom správne vyriešiť.“ Larry Tesler okolo roku 1979 povedal: „Inteligencia je všetko, čo stroje ešte nedokázali.“

Preto sa ľudia v rozhovoroch o AI tak často míňajú. Tvrdenie ako „AI nevie uvažovať“ alebo „AI je preceňovaná“ v sebe skrýva časové zaradenie — môže sa týkať expertných systémov, klasifikátorov obrázkov z 2010. rokov alebo minulomesačného jazykového modelu a každý z týchto príkladov podporuje iný záver. Keď sa rozhovor o AI zasekne, obyčajne pomôže nahradiť toto slovo konkrétnym pojmom, ktorý sa tým myslí: model, riadiace prostredie, agent alebo kontext, ktorý dostal.

Vyhýbajte sa: používaniu „AI“ v technickom tvrdení — pomenujte konkrétnu súčasť. „Programovanie s AI“ ako názov praxe je v poriadku; „AI halucinuje“ nie.

Použitie:

„CTO chce vedieť, či by AI zvládla triedenie frontu.“

„Predtým, než určíš rozsah, to spresni — myslí tým jazykový model v riadiacom prostredí s prístupom k systému tiketov. Samotná ‚AI‘ nie je špecifikácia.“

Parametre. Bezstavový — vykonáva predpovedanie nasledujúceho tokenu a nič iné. Modelmi sú napríklad „Claude Opus 4.x“ a „GPT-5.x“. Model sám osebe nedokáže konať ako agent; musí byť zapojený do karкаса.

Modely nedokážu čítať súbory, spúšťať príkazy, prehliadať web ani si pamätať včerajšok — prijmú tokeny a raz pri každej požiadavke na poskytovateľa modelu predpovedajú výstupné tokeny. Všetko, čo vyzerá ako práca agenta — výber nástrojov, čítanie výsledkov a opakovanie cyklu až do dokončenia úlohy — je karкас, ktorý za sebou orchestruje množstvo takýchto predpovedí.

Poskytovatelia modelov ponúkajú modely v rôznych triedach: veľký a najinteligentnejší, no pomalý a drahý, a menšie, ktoré sú rýchlejšie a lacnejšie, ale menej schopné. Výber triedy je skutočné rozhodnutie — výkonný model na plánovanie a náročné ladenie, ľahší na mechanické zmeny — a karкаsy umožňujú prepnutie uprostred relácie.

Presné používanie tohto slova pomáha aj pri hľadaní príčin. Tvrdenie „model je v tomto zlý“ má konkrétny význam — ten istý model sa v inom karкасе alebo s iným kontextom často správa úplne inak. Skôr než obviníte model, skontrolujte, čo dostal: za väčšinou sklamaní stojí kontext alebo karкас, nie parametre.

Použitie:

„Máme pri plánovaní prejsť zo Sonnetu na Opus?“

„Skúste to — no pri tejto úlohe odvádza väčšinu práce karкас. Zmena modelu nepomôže, ak sú systémový pokyn a nástroje nesprávne.“

Číselné hodnoty vo vnútri modelu — často ich sú miliardy — nastavované počas tréningu. Nachádza sa v nich všetko, čo model „vie“. Tréning ich určuje; inferenciu model vykonáva bez zmien. Hovorí sa im aj váhy.

Z technického hľadiska parametre premieňajú vstup na výstup. Predpovedanie nasledujúceho tokenu je obrovský výpočet: tokeny z kontextového okna sa spracujú cez parametre a výsledkom je predpoveď ďalšieho tokenu. Model neobsahuje databázu faktov ani tabuľku na vyhľadávanie kódu — iba tieto čísla usporiadané tak, aby výpočet zvyčajne vytváral užitočný výstup. Fakty, ktoré model dokáže zopakovať z tréningu, napríklad API štandardnej knižnice, sú parametrické znalosti: ukladajú sa v parametroch, nevyhľadávajú sa inde.

Dôležité je zapamätať si, že parametre po tréningu zostávajú nemenné. Nič, čo urobíte v relácii, ich nezmení — žiadna vaša oprava, ukázaná kódová základňa ani chyba, z ktorej sa model poučí. Každá relácia používa rovnaké čísla. Preto je model bezstavový, jeho vstavané znalosti sa končia pri dátume ukončenia znalostí a všetko špecifické pre projekt treba dodať cez kontext. Parametre možno zmeniť iba ďalším tréningom, ktorého výsledkom je v podstate iný model.

Použitie:

„Môžeme model doladiť na našej kódovej základni?“

„Tým by sa zmenili parametre a vznikol by iný model. Pri jednom projekte je takmer vždy lacnejšie načítať kódovú základňu do kontextu než model znova trénovať.“

Proces, ktorý nastavuje parametre modelu tak, že ho vystavuje obrovskému množstvu textov a upravuje parametre s cieľom zlepšiť predpovedanie nasledujúceho tokenu. Ide o jednorazový, nákladný proces vykonávaný poskytovateľom modelu. Zahŕňa predtréning (hlavnú fázu) aj následný tréning (neskoršie úpravy, napríklad učenie sa nasledovať pokyny a dodržiavať bezpečnosť); na úrovni tohto slovníka na rozdiele nezáleží.

Mechanizmom je opakovanie vo veľkom meradle: model dostane úsek textu, predpovie nasledujúci token, jeho parametre sa posunú smerom k skutočnému nasledujúcemu tokenu a tento postup sa opakuje pri biliónoch tokenov. Nič sa neukladá ako fakty ani pravidlá — všetko, čo model „vie“, je vedľajším dôsledkom lepšieho predpovedania, stlačeným v parametroch ako parametrické znalosti.

V každodennej práci sú dôležité dva dôsledky. Tréning sa v určitom okamihu skončí, takže model má dátum ukončenia znalostí — nepozná verziu knižnice, na ktorú ste minulý mesiac prešli. A tréning nemôžete vykonať vy: keď model nepozná vašu kódovú základňu, konvencie ani interné API, riešením nikdy nie je „naučiť model“ — treba tieto materiály vložiť do kontextu, jediného vstupu, ktorý ovládate.

Použitie:

„Môžeme ho naučiť naše interné API?“

„Nie tréningom — ten by poskytovateľ modelu vykonával celé mesiace. Namiesto toho načítajte dokumentáciu API do kontextu; to je páka, ktorú skutočne máte.“

Spustenie natrénovaného modelu, ktorý vytvorí výstup — to, čo sa deje pri každej požiadavke na poskytovateľa modelu. Parametre zostávajú nemenné; model iba predpovedá nasledujúci token na základe zadaného kontextu. V porovnaní s tréningom je to lacné, no účtuje sa za každý token a ide o hlavný náklad pri používaní modelu.

Život modelu sa delí na dve fázy:

Nič z toho, čo urobíte počas inferencie, sa nezapíše späť do parametrov — preto sa oprava, ktorú urobíte dnes, zajtra neudrží. Model, ktorý urobí rovnakú chybu aj v ďalšej relácii, hoci ste mu nápravu starostlivo vysvetlili, vás neignoruje; nedokáže sa z výmeny poučiť. Model je bezstavový, takže kontinuita musí prichádzať zvonka — z kontextového okna alebo pamäťového systému.

Tento mechanizmus vysvetľuje aj účtovanie. Každá požiadavka spustí model nad celým kontextom, takže cena rastie podľa počtu vstupných tokenov a výstupných tokenov. Agent s desiatkami volaní nástrojov platí inferenciu za každú spiatočnú výmenu. Preto je veľkosť kontextu otázkou nákladov aj kvality.

Použitie:

„Prečo účet rastie podľa používania namiesto paušálnej licencie?“

„Platíte za inferenciu — každá požiadavka na poskytovateľa modelu ho spustí na hardvéri poskytovateľa. Tréning už prebehol, no náklady na inferenciu vznikajú pri každej požiadavke a jediný ťah sa pri volaní nástrojov môže rozrásť na množstvo požiadaviek.“

Úroveň úsilia určuje, koľko model uvažuje pred odpoveďou. Nastavuje sa pre každý požiadavke na poskytovateľa modelu a riadi dĺžku premýšľania, ktorým model prejde pred napísaním odpovede, ktorú uvidíte. Toto uvažovanie vzniká počas inferencie rovnako ako všetko ostatné; karкас ho často skryje, ale model pri ňom naozaj pracuje.

Vyššia úroveň úsilia stojí viac a trvá dlhšie. Uvažovanie sa vytvára ako tokeny, účtuje sa ako výstupné tokeny, aj keď ich nevidíte, a vzniká po jednom tokene. Zvýšenie úsilia preto predĺži čakanie na odpoveď a zvýši účet. Ide o výmenu dôkladnejšieho uvažovania za rýchlosť a cenu.

Väčšina karкасov ponúka niekoľko úrovní:

Nesprávne nastavenie má následky v oboch smeroch. Pri ťažkom probléme nastavíte úsilie príliš nízko a dostanete sebavedomú, povrchnú odpoveď, ktorá vynechala potrebné uvažovanie — znie dobre, ale neskôr vás jej chyba stojí čas. Ak naopak zvolíte maximum pri premenovaní na jednom riadku, dlho čakáte na uvažovanie, ktoré neprinesie nič navyše oproti najnižšej úrovni.

Úsilie prispôsobte úlohe, nie relácii. Zvýšte ho pre skutočne náročnú časť a znížte pri rutinných krokoch okolo nej.

Použitie:

„Stále kazí túto opravu súbežnosti — vysvetlil som mu to už trikrát.“

„Zvýšte úsilie na zložité uvažovanie a po oprave ho znova znížte.“

Najmenšia jednotka, ktorú model číta a vytvára. Je približne veľká ako slovo, no nie presne — bežné slová tvoria jeden token, zriedkavé alebo dlhé sa rozdelia na viacero. Veľkosť kontextového okna, cena aj latencia sa počítajú v tokenoch.

Text sa mení na tokeny pomocou tokenizéra: ide o pevnú slovnú zásobu desiatok tisíc fragmentov, naučenú ešte pred tréningom, ktorá rozdelí ľubovoľný vstup na postupnosť položiek tejto slovnej zásoby. Model nikdy nevidí znaky ani slová — každý text sa pri vstupe prevedie na tokeny a predpovedanie nasledujúceho tokenu vytvára výstup po jednom tokene.

Orientačne jeden token predstavuje asi tri štvrtiny anglického slova, takže tisíc tokenov je približne 750 slov. Pri kóde je to menej predvídateľné: bežné kľúčové slová a idiomy sa tokenizujú úsporne, no vytvorené identifikátory, haše, reťazce base64 a minifikovaný výstup sa rozdelia na mnoho tokenov na každé „slovo“. Text, ktorý sa často vyskytoval v zdrojových materiáloch tokenizéra, má krátke a účinné kódovanie; text, ktorý sa tam nevyskytoval, sa rozseká na množstvo malých častí. Haš ako `a3f9c2e1` sa nikde nevyskytol, preto sa rozdelí na veľa tokenov, zatiaľ čo `function` tvorí jeden token. Preto môže súbor, ktorý vyzerá malý, no obsahuje nezvyčajné reťazce, zaberať prekvapivo veľkú časť kontextového okna.

Tokeny sú jednotkou, v ktorej sa meria všetko ostatné. Cena sa účtuje za token — poskytovatelia osobitne fakturujú vstupné tokeny a výstupné tokeny. Rýchlosť sa uvádza v tokenoch za sekundu, pretože výstup vzniká po jednom tokene. Aj kontextové okno má pevný počet tokenov, takže ich počet vo vašich súboroch určuje, koľko sa ich zmestí.

Vyhýbajte sa: slovu „slovo“ — hranice tokenov sa nezhodujú s hranicami slov a v praxi záleží na jednotkách tokenov za sekundu a tokenov za dolár.

Použitie:

„Aký veľký bude tento prompt?“

„Prežeňte ho tokenizérom — schéma je úsporná, ale kľúče JSON sú nezvyčajné, takže sa rozdelia na viac tokenov, než čakáte.“

Čo model skutočne robí. Dostane kontext, vyberie jeden ďalší token, pridá ho a postup zopakuje. Každý výstup — veta, volanie nástroja či súbor s tisíc riadkami — vzniká po jednom tokene. Model nemá iný spôsob práce.

Každý krok prebieha rovnako: parametre spracujú tokeny v kontextovom okne a vytvoria pravdepodobnosť pre každý token v slovníku — jeden je veľmi pravdepodobný, iný menej. Z týchto pravdepodobností sa vyberie token, pridá sa a cyklus sa zopakuje s o trochu dlhším kontextom. Práve tento výber spôsobuje, že rovnaký prompt vytvorí pri rôznych spusteniach odlišný výstup: nedeterministickosť je súčasťou mechanizmu, nie dodatočná chyba.

Pochopenie tohto mechanizmu vysvetľuje správanie, ktoré by inak pôsobilo zvláštne. Model pred vytvorením tokenu nikdy nekontroluje, či je pravdivý — iba či je pravdepodobný — čo je príčinou halucinácií. Každý token vytvorí hneď, takže sebavedomo znejúca úvodná veta môže nasmerovať zvyšok odpovede nesprávne. A keďže výstupné tokeny vznikajú striktne po jednom, rýchlosť generovania určuje dolnú hranicu toho, ako rýchlo môže pracovať ktorýkoľvek agent.

Použitie:

„Ako sa agent ‚rozhodne‘ zavolať nástroj?“

„Nerozhoduje sa — celý proces je predpovedaním nasledujúceho tokenu. Volanie nástroja je iba štruktúrovaný reťazec vo výstupnom prúde, ktorý karкас rozparsuje.“

Rovnaký vstup môže vytvoriť odlišný výstup. Spustite model dvakrát s totožným kontextom a môžete dostať dve rôzne odpovede — niekedy sa líši jedno slovo, inokedy celý prístup. K tomu môže dôjsť aj bez akejkoľvek zmeny v kóde.

Je to vlastnosť spôsobu, akým modely vytvárajú text a ako poskytovatelia modelov obsluhujú požiadavky. Počas inferencie model vytvorí rozdelenie pravdepodobnosti pre možné ďalšie tokeny a jeden z nich vyberie náhodne — zvyčajne zámerne, pretože neustály výber najpravdepodobnejšieho tokenu vytvára opakujúci sa, menej kvalitný text. Jeden inak vybraný token na začiatku odpovede zmení každý ďalší token, takže jediné odlišné slovo môže viesť k úplne inému prístupu. Obsluhovanie na strane poskytovateľa pridáva ďalšie variácie: požiadavky sa dávkovo spracúvajú na zdieľanom hardvéri a drobné rozdiely v číslach s pohyblivou rádovou čiarkou medzi dávkami môžu rozhodnúť tesný súboj dvoch tokenov. Neexistuje nastavenie, ktorým by sa to dalo úplne vypnúť.

Pri rovnakej úlohe od agenta očakávajte rozpätie výsledkov. Väčšina odpovedí spadá do rozumnej zvonovitej krivky kvality — práve preto sa nedeterministickosť dá zniesť — no jej chvosty sú skutočné: niektoré dni sa model javí ako bystrý, inokedy akoby úplne stratil niť. Tá istá úloha, iný hod kockami. Z toho vyplývajú dva praktické dôsledky. Opakovanie je rozumnou stratégiou: neúspešný pokus je iba jeden výber z rozdelenia a nový pokus s tou istou úlohou môže dopadnúť lepšie. A overovanie je dôležitejšie než pri deterministických nástrojoch — správanie agenta nemôžete otestovať raz a spoliehať sa, že ho zopakuje, preto musia automatické kontroly zachytiť neúspešné výbery.

Nepreháňajte rozprávanie príbehov o príčinách. Ľudia hľadajú vzory a séria zlých behov môže pôsobiť ako dôkaz, že „model je tento týždeň horší“. Zvyčajne ide iba o rozdelenie výsledkov.

Použitie:

„Claude je dnes hrozný. Nevydali horšiu verziu?“

„Pravdepodobne nie — výstup modelu je nedeterministický. Pri tej istej úlohe budú dobré aj zlé dni. Skúste to znova zajtra, než začnete hľadať príčinu.“

Čokoľvek, čo poskytuje modelu inferenciu. Zvyčajne ide o vzdialenú službu (Anthropic, OpenAI, Google), ale môže byť aj lokálna — napríklad Ollama, LM Studio alebo llama.cpp spustené na vašom počítači. Karкас model nespúšťa sám; požiada o to poskytovateľa.

Poskytovateľ vlastní infraštruktúru: parametre sú na jeho hardvéri a každá požiadavka na poskytovateľa modelu znamená, že karкас pošle tokeny cez sieť a prijme predpovede. Poskytovateľ je preto zdrojom celej skupiny problémov, ktoré sa nesprávne pripisujú modelu alebo karкасу — obmedzenia počtu požiadaviek, znížená kapacita aj výpadky vznikajú tu. Keď sa agent zastaví uprostred relácie alebo pri každom ťahu hlási chybu, najprv sa oplatí pozrieť na stránku stavu poskytovateľa.

Poskytovateľ určuje aj obchodné podmienky: cenu za vstupné a výstupné tokeny, zľavy za cache prefixu a to, ktoré modely sú vôbec dostupné. Poskytovateľ a tvorca modelu môžu byť rôzne spoločnosti — Bedrock, Vertex a OpenRouter ponúkajú modely iných spoločností.

Lokálni poskytovatelia vymieňajú schopnosti za kontrolu: modely, ktoré sa zmestia na váš vlastný hardvér, sú oveľa menšie než najpokročilejšie modely, no nič neopustí počítač a neplatíte za každý token.

Použitie:

„Môžeme to spustiť offline pre klienta s izolovanou sieťou?“

„Prepnite poskytovateľa modelu na lokálneho — Ollama alebo llama.cpp na jeho zariadení. Karкаsu je to jedno, iba zavolá iný koncový bod.“

Všetko okolo modelu, čo z neho vytvára agenta: nástroje, systémový pokyn, správa kontextového okna, povolenia, háčiky. Claude.ai a Claude Code používajú rovnaký model, no správajú sa odlišne, pretože majú odlišné karкасы.

Samotný model robí iba jednu vec: prijíma text a vytvára text. Nedokáže čítať súbor, spustiť príkaz ani si zapamätať predchádzajúci ťah. To všetko mu poskytuje karкас. Zostavuje kontext pre každý požiadavke na poskytovateľa modelu, vykonáva volania nástrojov, ktoré si model vyžiada, vracia mu výsledky nástrojov, ukladá históriu relácie, žiada vás o povolenie pred rizikovými krokmi a rozhoduje, kedy skrátiť kontext. Slučku agenta — model navrhne, karкас vykoná, opakuje sa — riadi karкас.

Je to dôležité pri hľadaní príčin. Keď sa správanie dvoch produktov alebo produktu včera a dnes líši, premennou často nie je model, ale karкас. Odlišný systémový pokyn, iná sada nástrojov, zmenené predvolené povolenia alebo nová stratégia správy kontextu menia správanie bez zmeny modelu. Väčšina nastavení sa nachádza práve v karкасе: súbory AGENTS.md, nastavenia povolení a háčiky sú pokynmi pre karкас, nie pre model.

Príklady: Claude Code, Cursor, Codex CLI a Claude.ai, ktorý používa chatovací, nie programátorský karкас.

Použitie:

„Rovnaký model — prečo Claude Code upravuje súbory, ale Claude.ai iba odpovedá na otázky?“

„Majú odlišné karкасы — Claude Code má nástroje súborového systému, iný systémový pokyn a vrstvu povolení. Model tu nie je tou premennou.“

Jedna spiatočná výmena medzi karкасom a poskytovateľom modelu. Karкас odošle aktuálny kontext; poskytovateľ vráti jednu odpoveď (volanie nástroja alebo konečnú odpoveď). Jedna správa používateľa môže spustiť množstvo požiadaviek na poskytovateľa modelu, ak agent volá nástroje — každý výsledok nástroja vyvolá ďalšiu požiadavku.

Každá požiadavka nesie všetko: systémový pokyn, celú doterajšiu konverzáciu a všetky výsledky nástrojov. Model je bezstavový, preto si poskytovateľ medzi požiadavkami nič neuchováva — štyridsiata požiadavka znova odošle to, čo tridsiata deviata, plus jeden ďalší výsledok nástroja. Ká cache prefixu slúži na to, aby sa toto opakovanie dalo zaplatiť.

Požiadavka je zároveň účtovnou jednotkou. Vstupné tokeny, výstupné tokeny aj zľavy za cache sa počítajú za každú požiadavku. Preto môže zdanlivo nevinná otázka stáť prekvapivo veľa: cena nie je úmerná vašej správe, ale počtu požiadaviek vynásobenému veľkosťou kontextu, ktorý každá nesie.

Je dobré rozlišovať požiadavku od ťahu. Ťah je jedna výmena s vami a jediný ťah — „oprav neúspešný test“ — sa môže odohrať ako reťaz požiadaviek:

Šesť požiadaviek na jeden ťah — každá znova odosiela celý kontext. Keď premýšľate, kam sa podeli tokeny, počítajte požiadavky, nie ťahy.

Použitie:

„Jedna otázka spotrebovala štyridsaťtisíc tokenov?“

„Pozrite sa na volania nástrojov — dvanásť vyhľadávaní, osem čítaní a štyri úpravy. Každý výsledok nástroja spustí ďalšiu požiadavku na poskytovateľa modelu a zakaždým sa znova odošle celý prefix relácie.“

Tokeny, ktoré karкас odošle pri každej požiadavke na poskytovateľa modelu — systémový pokyn, história konverzácie, výsledky nástrojov, všetko, čo model prečíta pred vytvorením odpovede. Účtujú sa nižšou sadzbou než výstupné tokeny, pretože ich spracovanie stojí menej než vytvorenie výstupu.

Pri programovaní s AI tvoria vstupné tokeny väčšinu účtu. Model je bezstavový, preto každý ťah znova odošle celú reláciu ako vstup: vašu prvú správu, každú odpoveď a každý dovtedajší výsledok nástroja. Vstup pri päťdesiatom ťahu obsahuje predchádzajúcich štyridsaťdeväť ťahov. Jedna požiadavka na poskytovateľa modelu môže vytvoriť niekoľko stoviek výstupných tokenov a pritom znova odoslať stotisíc vstupných tokenov nazbieranej histórie.

Cache prefixu znižuje náklady: história presne zhodná s predchádzajúcou požiadavkou sa účtuje ako lacné tokeny cache, nie ako vstup za plnú cenu. Keď sú vstupné náklady stále vysoké, riešením je zmenšiť množstvo opätovne odosielaného obsahu — medzi úlohami vymazať alebo skrátiť kontext.

Použitie:

„Účet je vysoký, hoci agent takmer nič nenapíše.“

„Sú to vstupné tokeny — každý ťah znova odošle celú reláciu. Bez cache prefixu by ste za históriu platili pri každej požiadavke znova.“

Tokeny, ktoré model vytvorí. Účtujú sa vyššou sadzbou než vstupné tokeny — bežne približne päťnásobnou — pretože ich vytvorenie vyžaduje viac výpočtového výkonu.

Počíta sa všetko, čo model napíše: text, ktorý čítate, vytvorený kód, volania nástrojov aj rozšírené premýšľanie pred odpoveďou. To posledné ľudí prekvapuje — tokeny uvažovania sa účtujú ako výstup, hoci ich karкас často nezobrazuje, a zvýšenie úsilia ich spotrebuje viac.

Výstupné tokeny určujú aj tempo relácie. Model číta vstup rýchlo, no výstup vytvára po jednom tokene, takže keď sa ťah zdá pomalý, takmer vždy ide o pomalé vytváranie výstupu, nie o čítanie vstupu. Dlhé čakanie zvyčajne znamená, že príde dlhá odpoveď.

Použitie:

„Relácia refaktoringu míňa kredit, hoci vstupy sú malé.“

„Agent prepisuje celé súbory namiesto vytvárania záplat. Výstupné tokeny stoja približne päťkrát viac než vstupné — nechajte ho vytvárať úpravy a účet klesne.“

Úložisko na strane poskytovateľa, ktoré umožňuje, aby po sebe nasledujúce požiadavky na poskytovateľa modelu nemuseli znova spracúvať spoločný prefix. Keď sa začiatok požiadavky zhoduje so začiatkom nedávnej požiadavky — rovnaký systémový pokyn a rovnaká história až po určitý bod — poskytovateľ znovu použije predchádzajúcu prácu a tieto tokeny účtuje ako tokeny v cache s oveľa nižšou sadzbou.

Cache sa oplatí, pretože relácie rastú iba pridávaním. Každá požiadavka znova odošle celú históriu ako vstupné tokeny (dôvod vysvetľuje príslušné heslo) a v bežnej relácii sa história mení iba na konci — každá požiadavka obsahuje predchádzajúcu a niekoľko nových správ. Poskytovateľ raz spracuje dlhý spoločný začiatok, uloží výsledok a pokračuje od konca prefixu. Bez cache by sa v 50-ťahovej relácii platilo za opätovné spracovanie prvého ťahu päťdesiatkrát.

Záznamy cache tiež vypršia. Dĺžka uchovania sa líši podľa poskytovateľa modelu — zvyčajne ide o minúty, nie hodiny. Ak necháte reláciu nečinnú dlhšie než toto okno, ďalšia požiadavka znova vytvorí prefix za plnú cenu a až potom sa cache obnoví. Je to hlavne starosť tvorcov karкаса; ako používateľ si všimnete, že požiadavky po dlhej prestávke stoja viac než pred ňou.

Použitie:

„Prečo účet v polovici relácie vyskočil?“

„Karкас začal pri každom ťahu vkladať do systémového pokynu aktuálny čas. Cache prefixu sa preruší pri prvom zmenenom tokene, takže každá ďalšia požiadavka sa účtovala plnou sadzbou.“

Vstupné tokeny, ktoré poskytovateľ uložil z predchádzajúcej požiadavky na poskytovateľa modelu, aby ich nemusel znovu spracovať. Keď majú po sebe idúce požiadavky spoločný prefix, poskytovateľ znovu použije spracovanie pomocou cache prefixu a uloženú časť účtuje oveľa nižšou sadzbou. Práve vďaka tomu sú dlhé relácie dostupné — bez toho by sa pri každom ťahu znova platila celá história.

Záleží na tom preto, ako sa relácie účtujú. Model je bezstavový, takže každá požiadavka znova odošle celú konverzáciu — systémový pokyn, každú správu a každý výsledok nástroja — ako vstupné tokeny. Pri päťdesiatom ťahu každá požiadavka nesie históriu všetkých päťdesiatich ťahov a za celý obsah by ste zakaždým platili plnú cenu. Cache mení výpočet: tokeny zhodné s prefixom predchádzajúcej požiadavky sa účtujú ako tokeny cache, často za desatinu ceny vstupu alebo menej. Pri dlhej relácii tvoria väčšinu odosielaného obsahu tokeny cache, a účet tak zostáva únosný.

Príklad ukazuje, kedy sa tokeny ukladajú do cache a kedy nie. Každé písmeno označuje blok konverzácie; každá požiadavka odošle doterajšiu konverzáciu:

Cache je krehká z jedného dôvodu: porovnáva presné prefixy. Ak sa zmení čokoľvek skôr v konverzácii — karкас preusporiada obsah, aktualizuje sa časová značka alebo sa zmení reprezentácia súboru — cache od toho bodu prestane sedieť a všetko ďalšie sa účtuje plnou cenou vstupu. Po niekoľkých minútach nečinnosti vyprší aj cache, takže relácia po dlhej prestávke raz znova zaplatí za históriu. Ak náklady relácie bez zjavnej príčiny vyskočia, v reporte použitia porovnajte tokeny cache so vstupnými tokenmi — prvým príznakom pokazenej cache je práve tento rozdiel.

Použitie:

„Dlhé relácie sú hrozne drahé — osem dolárov za refaktoring.“

„Skontrolujte tokeny cache. Ak karкас medzi ťahmi preusporadúva systémový pokyn alebo súbory, prefix sa naruší a každá požiadavka znova účtuje plnú cenu vstupu.“

Neprenáša žiadne informácie ďalej. Model nemá stav naprieč požiadavkami poskytovateľovi modelu — pri každej požiadavke sa znova posiela celé kontextové okno, pretože model nevidí nič iné. Agent je predvolene bezstavový naprieč reláciami: nová relácia sa začína prázdna a bez stopy po predchádzajúcich. Protipólom je stavovosť.

Samotný model je trvalo bezstavový: jeho parametre sú po trénovaní nemenné a nič, čo urobíte počas odvodzovania, ich nezmení. Model sa nepoučí z vašich opráv, nepamätá si, že ste mu včera povedali to isté, a postupne vás nespoznáva — akokoľvek môže rozhovor pôsobiť opačne. Pocit kontinuity v rámci relácie vytvára riadiace prostredie, ktoré uchováva prepis a znovu ho posiela pri každej požiadavke. Model si rozhovor nepamätá; číta ho znova.

Praktický dôsledok: ak chcete, aby si agent niečo pamätal naprieč reláciami, musíte to zapísať na miesto, odkiaľ si to agent znovu načíta. Na to slúžia súbory AGENTS.md, pamäťové systémy a artefakty odovzdania — načítajú sa do kontextu budúcich relácií a zastupujú pamäť, ktorú model nemá. Keď agent opakovane robí chybu, na ktorú ste ho už upozornili, otázkou nie je, prečo sa to nenaučil — nemôže sa — ale kam túto opravu zapísať, aby si ju prečítala každá ďalšia relácia.

Použitie:

„Prečo pri každom vymazaní zabudne na túto konvenciu?“

„Model je bezstavový — nová relácia sa začína prázdna. Ak ju chceš preniesť, zapíš ju do AGENTS.md alebo do súboru pamäte, ktorý riadiace prostredie načíta na začiatku relácie.“

Informácie relevantné pre úlohu, ku ktorým má agent práve prístup. Je to abstraktný pojem — nie surový vstup, ktorý model vidí (to je kontextové okno), ani bežiaca história (to je relácia), ale to, čo agent vie a čo sa týka úlohy. „Načítať niečo do kontextu“ znamená zaradiť to do tejto množiny; „práca s kontextom“ je disciplína jeho výberu a usporiadania.

Tri pojmy sa jasne odlišujú:

Rozlíšenie je dôležité, pretože kontext meria kvalitu, nie množstvo. Kontextové okno môže byť takmer plné a kontext stále nekvalitný — tisíce tokenov zastaraných výstupov nástrojov, z ktorých žiadny nesúvisí s aktuálnou úlohou. Môže byť aj takmer prázdne a kontext vynikajúci: jediná definícia typu, od ktorej úloha závisí.

Väčšina každodenných zlyhaní súvisí s kontextom. Keď agent vymyslí API, odporuje rozhodnutiu alebo háda schému, prvou otázkou je, čo mal v kontexte — zvyčajne sa relevantný fakt nikdy nenačítal alebo bol pochovaný pod zhoršením pozornosti. Riešením je výber: načítajte to, čo úloha potrebuje, a vynechajte to, čo nepotrebuje.

Použitie:

„Stále si vymýšľa polia, ktoré v type nie sú.“

„Súbor s typom nie je v kontexte — číta miesta volania a háda. Najprv načítajte definíciu.“

Všetko, čo model vidí pri každom požiadavku na poskytovateľa modelu. Je to obmedzené, závisí od modelu a je to jediná plocha, cez ktorú model čokoľvek vníma.

Ide o jedinú postupnosť tokenov: systémový pokyn, doterajšia konverzácia a každý výsledok nástroja, ktorý mu karкас vrátil. Ak je niečo v tejto postupnosti, model to môže použiť; ak tam nie je, nevie, že to existuje — ani o vašej kódovej základni, súbore, ktorý ste včera upravili, či pokyne spred troch relácií. Čokoľvek mimo okna treba priniesť dovnútra, zvyčajne cez volanie nástroja, aby to mohlo niečo ovplyvniť.

Obmedzenosť znamená, že sa okno zaplní. Každý ťah pridáva ďalší obsah — vaše správy, odpovede modelu a výsledky nástrojov — a dlhá relácia napokon narazí na limit, čo si vynúti skrátenie kontextu alebo jeho vymazanie. Zároveň všetko v okne súťaží o miesto: každý načítaný token uberá z priestoru pre ostatné a nepotrebný obsah stále zaberá modelovú pozornosť. V praxi vnímajte okno ako rozpočet — načítajte to, čo úloha potrebuje, a zvyšok vynechajte.

Vyhýbajte sa: slovu „pamäť“ — kontextové okno je pracovný stav, ktorý sa neprenáša medzi reláciami. Pamäť je samostatný koncept, ktorý sa naň vrství.

Použitie:

„Môžem do promptu jednoducho vložiť celý monorepozitár?“

„Kontextové okno má 200-tisíc tokenov — to je možno pätina repozitára. Vyberte súbory, ktorých sa úloha týka, a ostatné nechajte dostupné cez volanie nástroja.“

Prenáša informácie ďalej. Relácia si zachováva stav naprieč ťahmi — počas behu sa hromadí kontext, preto dlhé relácie skĺzavajú do hlúpej zóny. Agent si môže zachovávať stav naprieč reláciami pridaním pamäťového systému, ktorý ukladá informácie do prostredia a na začiatku budúcich relácií ich znovu načíta. Model nikdy nemá stav; zdanlivú kontinuitu vytvára riadiace prostredie, ktoré mu znova posiela kontext. Protipólom je bezstavovosť.

Kde sa stav nachádza na jednotlivých úrovniach:

Stav na každej úrovni vzniká opätovným načítaním niečoho uloženého o úroveň nižšie: relácia pôsobí súvisle, pretože riadiace prostredie znovu posiela bezstavovému modelu históriu správ; agent si pamätá naprieč reláciami, pretože riadiace prostredie načíta súbory z prostredia. Samotný model nikdy neukladá žiadny stav.

Prenášanie stavu nie je vždy žiaduce. Všetko, čo sa prenesie, ovplyvňuje ďalší priebeh, takže sa prenesie aj nesprávny predpoklad, ktorý vznikol na začiatku relácie. Vymazanie je zámerné zahodenie stavu relácie a začiatok od toho, čo je zapísané.

Použitie:

„Zapamätal si včerajšie preferencie — znamená to, že sa ich model naučil?“

„Nie, agent si zachováva stav preto, že riadiace prostredie zapísalo preferencie do súboru pamäte a na začiatku relácie ho znova načítalo. Samotný model o včerajšku nič nevidel.“

Model vybavený nástrojmi, systémovým promptom a kontextovým oknom, ktorý s používateľom vedie jednotlivé ťahy. Claude Code je agent. Cursor je agent. Claude.ai je agent. Agent je to, s čím skutočne komunikujete — model v pohybe, nastavený na konkrétny účel.

Na rozdiel od väčšiny pojmov v tomto slovníku „agent“ neoznačuje mechanickú súčasť. Model je súbor parametrov; riadiace prostredie je softvér, ktorý možno nasmerovať. Agent nie je ani jedno z toho — je to jednotka, s ktorou hovoríte. Ľudia si AI neustále poľudšťujú a agent je táto poľudštená jednotka: ten, komu delegujete úlohu, kto číta vašu správu a odpovedá, to „ono“ vo vete „zase to pokazilo zostavenie“. Keď poviete, že agent niečo urobil, myslíte tým kombináciu modelu a riadiaceho prostredia, ale prihovárate sa jej ako jedinému aktérovi.

Táto myšlienka je staršia než súčasná vlna AI. Softvérové agenty — programy, ktorým delegujete cieľ a ktoré konajú vo vašom mene — sú pojmom rovnako starým ako samotná AI.

Vyhýbajte sa: „AI“, „bot“ (sú príliš vágne — zakrývajú, či myslíte parametre alebo model vybavený riadiacim prostredím).

Použitie:

„Ktorého agenta používaš na migráciu?“

„Lokálne Claude Code, na prácu s používateľským rozhraním Cursor — pod nimi je rovnaký model, ale iné riadiace prostredie.“

Pokyny, ktoré karкас pripája na začiatok každej požiadavky na poskytovateľa modelu — trvalé zadanie agenta: kto je, ako sa má správať, ktoré nástroje môže volať a akých konvencií sa má držať. Zvyčajne zostávajú počas relácie nemenné.

Systémový pokyn píše dodávateľ karкаса, nie vy, a v programátorských karкаsoch býva rozsiahly — často obsahuje desiatky tisíc tokenov pravidiel správania, opisov nástrojov a riešení okrajových prípadov. Pri každom ťahu sa účtuje ako vstupné tokeny. Spolu s ním sa prenášajú aj vaše trvalé pokyny: súbory ako AGENTS.md sa načítajú vedľa systémového pokynu na začiatku relácie, takže model si prečíta zadanie dodávateľa aj vaše zadanie ešte predtým, než uvidí vašu správu.

Keďže je pri každej požiadavke rovnaký, tvorí začiatok cache prefixu — aj preto ho karкаsy ponechávajú počas celej relácie nemenný namiesto toho, aby ho priebežne upravovali.

Modely sa trénujú tak, aby uprednostňovali systémový pokyn pred správami používateľa. Keď teda agent trvá na konvencii, ktorú ste nikdy nepožadovali, alebo formátuje výstup spôsobom, ktorého sa neviete zbaviť, zvyčajne poslúcha systémový pokyn — a vaša správa v tomto spore prehráva. Niektoré karкаsy možno prispôsobovať: poskytujú úplný prístup k systémovému pokynu, takže si môžete prečítať, čo sa agentovi naozaj hovorí, a zmeniť to.

Použitie:

„Dva karкаsy, rovnaký model, no pri rovnakom prompte sa správajú úplne inak.“

„Majú odlišné systémové pokyny. Jeden je nastavený na stručné úpravy kódu, druhý na vysvetľovanie — rozdiel vzniká ešte predtým, než dorazí vaša správa.“

Jedno ohraničené obdobie interakcie s agentom. Začína prázdne, hromadia sa v ňom správy, výsledky nástrojov a načítané súbory a končí sa po vymazaní, zatvorení alebo skrátení do novej relácie. Práve relácia vypĺňa kontextové okno: ak je okno škatuľa, relácia je obsah, ktorý ju postupne napĺňa. Prácu väčšiu než jedno kontextové okno treba rozdeliť medzi viacero relácií.

História správ v relácii tvorí pracovnú pamäť agenta. Model je bezstavový, takže všetko, čo zdanlivo uchováva — vaše požiadavky, výsledky testov či rozhodnutia spred troch ťahov — sa nachádza v histórii správ a pri každej požiadavke na poskytovateľa modelu sa posiela znova. Čokoľvek, čo v relácii nie je, pre agenta neexistuje.

Táto pamäť sa končí spolu s reláciou. Nová relácia začína od nuly: agent, ktorý na konci včerajšej relácie dobre poznal vašu kódovú základňu, o nej dnes ráno nevie nič. Zachová sa súborový systém — súbory zapísané počas jednej relácie môže načítať ďalšia. Práve na to sa spoliehajú odovzdania práce, pamäťové systémy a súbory AGENTS.md.

Vy rozhodujete, kedy sa relácia skončí. Všetko v relácii ovplyvňuje každý ďalší ťah, preto nesúvisiace úlohy v jednej relácii zanechávajú stopy, ktoré zafarbia nasledujúcu odpoveď. Jedna úloha na reláciu udržiava kontext relevantný; dokončenie úlohy je prirodzeným okamihom na vymazanie.

Použitie:

„Ako dlho môže jedna relácia bežať, kým sa rozpadne?“

„Záleží na práci — sústredený refaktoring zostane ostrý dlhšie než otvorený výskum. Keď sa relácia nafúkne, odovzdajte prácu alebo skráťte kontext, netlačte sa cez to.“

Jedna správa používateľa a všetko, čo agent urobí v odpovedi, až kým nevráti slovo používateľovi. Obsahuje jednu alebo viac požiadaviek na poskytovateľa modelu — mnoho, ak agent volá nástroje. Spresňujúca otázka ťah uzatvára; vaša odpoveď otvára ďalší. Hierarchia je relácia > Ťah > Požiadavka na poskytovateľa modelu.

Ťah stojí za samostatné pomenovanie preto, že o jeho dĺžke rozhoduje agent, nie vy. Odovzdáte mu jednu správu a agent sa rozhodne, koľko volaní nástrojov spojí, kým vám vráti slovo. Ťah môže byť jednovetová odpoveď alebo dvadsať minút čítania, úprav a spúšťania testov. Je to tá istá vlastnosť z dvoch uhlov pohľadu: dlhé ťahy umožňujú prácu bez dozoru, ale zároveň sa pri nich môže niečo pokaziť bez dohľadu — kým agent vráti slovo, mohol sa výrazne vzdialiť od toho, čo ste mali na mysli.

Ťah je tiež prirodzenou jednotkou usmerňovania. Všetko vnútri ťahu prebieha bez vás; medzi ťahmi môžete prácu usmerniť. Väčšina karкасov to zmierňuje: môžete prerušiť prebiehajúci ťah, zastaviť agenta a usmerniť ho, alebo mu počas práce napísať správu, ktorú si prečíta po dokončení ťahu. Ak ste opakovane nespokojní s tým, kam sa ťahy dostanú, riešením je zvyčajne žiadať kratšie ťahy — najprv plán, potom jednotlivé kroky — čím vymeníte autonómiu za častejšie prestávky na usmernenie.

Použitie:

„Jeden ťah trval dve minúty?“

„V rámci toho ťahu urobil štrnásť volaní nástrojov — každé je samostatnou požiadavkou na poskytovateľa modelu. Čakanie sa sčítava, kým agent konečne vráti slovo.“

Svet, v ktorom agent koná — všetko mimo karкаса, čo agent vníma prostredníctvom výsledkov nástrojov a mení prostredníctvom volaní nástrojov. Karкас agenta spúšťa; prostredie je to, v čom agent pracuje. Súbor ako `AGENTS.md` sa nachádza v prostredí; karкас ho načíta do kontextového okna. Najbežnejším prostredím je súborový systém, no nie je jediný — prostredím môže byť aj databáza, vzdialené API či relácia prehliadača.

Agent prostredie vidí iba vtedy, keď sa doň pozrie. Všetko, čo o ňom vie, získal z výsledkov nástrojov, takže jeho obraz je súborom snímok, z ktorých každá platí v okamihu zachytenia. Ak sa súbor zmení po tom, čo ho agent prečítal — upravíte ho ručne alebo ho znovu vytvorí zostavovací krok — agent pokračuje v uvažovaní zo zastaranej kópie, kým ho niečo neprinúti prečítať ho znova. Keď agent sebavedomo opisuje súbor, ktorý už takto nevyzerá, zvyčajne sa zmenilo prostredie, nie jeho snímka.

Prostredie je aj vrstvou, ktorá pretrváva — jedinou, ktorá je vždy stavová. Kontext relácie po jej skončení zmizne, no súbory zapísané do prostredia zostanú pre ďalšiu reláciu. Spoliehajú sa na to pamäťové systémy, artefakty odovzdania práce a súbory `AGENTS.md`. Všetko, čo má agent vedieť aj zajtra, sa musí dostať do prostredia.

Vy rozhodujete o veľkosti prostredia. Sandbox ho zmenšuje a obmedzuje, kam agent dosiahne; pridaný nástroj ho rozširuje a sprístupní databázu alebo API. To, čo je v hraniciach, môže agent vnímať a meniť; všetko mimo nich pre agenta neexistuje. Kvalita prostredia vytvoreného na podporu práce agenta je AX kódovej základne.

Vyhýbajte sa: používaniu slova „prostredie“ pre behové prostredie alebo samotný karкас — karкас je obal, prostredie je pracovný priestor.

Použitie:

„Agent nevidí schému prípravnej databázy.“

„Pripojte ju k prostrediu — sprístupnite mu nástroj `psql` s právom iba na čítanie v prípravnom prostredí. Karкас je v poriadku, iba nemá čo ovládať.“

Strom súborov a adresárov, z ktorého agent číta a do ktorého zapisuje a spúšťa v ňom príkazy — predvolený druh prostredia pre programovacieho agenta. V súborovom systéme sa nachádzajú AGENTS.md, zručnosti, zdrojový kód, skripty na zostavenie aj konfigurácie nástrojov. Keď riadiace prostredie „začína vo vašom projekte“, nasmeruje agenta na súborový systém.

Agent k nemu pristupuje iba cez volania nástrojov — číta súbor, zapisuje doň alebo spúšťa príkaz shellu. Kým súbor nenačíta volanie nástroja, nič z disku nie je v kontextovom okne. Vďaka tomu môže agent pracovať v repozitári, ktorý je omnoho väčší než kontextové okno: súborový systém obsahuje všetko, kontext iba to, čo si aktuálna úloha vyžiadala. Niektoré riadiace prostredia načítajú názvy súborov v aktuálnom adresári do kontextového okna predvolene — nie ich obsah, iba strom, ktorý slúži ako ukazovateľ kontextu: agent vidí, čo existuje, a načíta súbory, ktoré potrebuje.

Súborový systém zdieľa aj s vami. Súbory, ktoré agent upravuje, sú tie isté, ktoré otvárate v editore a porovnávate v gite — súborový systém je spoločným pracovným priestorom, v ktorom kontrolujete, čo agent urobil.

Použitie:

„Prečo nenačítal môj AGENTS.md?“

„Pracuje s iným súborovým systémom — sandbox pripojil nadradený adresár, nie koreň projektu. Nasmerujte riadiace prostredie inam.“

Funkcia, ktorú riadiace prostredie sprístupňuje agentovi, aby ju mohol zavolať — Čítanie, Zápis, Bash, Hľadanie. Nástroje sú spôsob, akým agent vníma a ovplyvňuje prostredie: vidí ho iba cez výsledky nástrojov a meniť ho môže iba cez volania nástrojov. Každé volanie nástroja stojí ďalšiu požiadavku poskytovateľovi modelu, pretože výsledok sa musí vrátiť modelu, aby mohol rozhodnúť, čo urobí ďalej.

Nástroje, s ktorými prichádza väčšina programovacích agentov:

Nástroj definujú tri veci: názov, opis toho, čo robí, a schéma jeho parametrov. Riadiace prostredie posiela tieto definície modelu pri každej požiadavke a model si vyberá nástroje rovnakým spôsobom, ako tvorí všetko ostatné — generovaním tokenov, v tomto prípade štruktúrovaného volania s argumentmi. Model sám nič nespúšťa; riadiace prostredie prečíta volanie, vykoná funkciu a pošle modelu výsledok.

Zoznam nástrojov určuje, čo agent dokáže. Schopný model s úzkym výberom nástrojov je úzko zameraný agent: všetko bude smerovať cez tie nástroje, ktoré má, a preto sa agenti tak často opierajú o Bash — jediný nástroj, ktorý siaha do väčšiny systému. Ak chcete agentovi čisto sprístupniť nejakú schopnosť, pridajte na to nástroj; MCP je štandard na pripájanie nástrojov zvonka riadiaceho prostredia.

Definície nástrojov zaberajú kontext pri každej požiadavke, takže veľký súbor nástrojov predstavuje trvalé náklady ešte pred prvým volaním — a veľa nástrojov s podobnými opismi zhoršuje výber správneho nástroja.

Použitie:

„Môže agent priamo čítať tikety zo stagingu?“

„Pridajte riadiacemu prostrediu nástroj `psql` s prístupom iba na čítanie k stagingu. Bez nástroja agent nevidí nič mimo súborového systému.“

Výstup modelu, ktorý pomenuje nástroj a jeho argumenty — iba štruktúrovaný text. Sám nič nevykoná; karкас ho musí prečítať a spustiť. Vytvorí ho model v rámci jednej požiadavky na poskytovateľa modelu.

Životný cyklus volania nástroja:

Jeden ťah práce agenta zvyčajne pozostáva z mnohých takýchto nadväzujúcich spiatočných výmen.

Keďže volanie vzniká predpovedaním nasledujúceho tokenu rovnako ako čokoľvek iné, môže byť nesprávne ako každý výstup modelu: neexistujúca cesta, príznak, ktorý príkaz nepozná, alebo vierohodné, no nesprávne argumenty. Karкас vykoná to, čo bolo napísané, nie to, čo sa zamýšľalo — preklep v ceste sa nemusí bezpečne skončiť chybou, ale môže upraviť nesprávny súbor.

Použitie:

„Povedal, že spustil testy, no časy súborov sa nezmenili.“

„Pozrite si záznam — skutočne vydal volanie nástroja, alebo iba opísal, že ich spúšťa? Model vytvorí volanie, ale ak ho karкас nevykonal, nič sa nestalo.“

To, čo karкас vráti po vykonaní volania nástroja — obsah súboru, výstup príkazu alebo chybu. Je to jediný pohľad agenta na prostredie. V nasledujúcej požiadavke na poskytovateľa modelu sa vráti k modelu, ktorý rozhodne, čo s tým urobí. Volanie nástroja a jeho výsledok sú dve strany tej istej výmeny v rámci jedného ťahu.

Životný cyklus výsledku nástroja:

Výsledok zostáva v kontexte po zvyšok relácie. Výsledky nástrojov zvyčajne tvoria väčšinu kontextu programátorskej relácie: každý prečítaný súbor, spustený test a vyhľadávanie sa doň dostane celé a zaberá tokeny ešte dlho po tom, čo prestalo byť užitočné. Niekoľko veľkých výsledkov — podrobný testovací denník alebo celý načítaný vygenerovaný súbor — môže reláciu priblížiť k hranici kontextového okna rýchlejšie než samotná konverzácia.

Keďže výsledok je všetko, čo model vidí, nemôže si overiť skutočný stav prostredia. Ak bol výstup skrátený, príkaz potichu zlyhal alebo karкас vrátil chybu namiesto obsahu, model uvažuje podľa toho, čo dostal. Keď sa zdá, že predstava agenta o vašom systéme je nesprávna, skontrolujte výsledky nástrojov: niekde v zázname je výsledok, ktorý hovorí niečo iné, než čo viete, že platí.

Použitie:

„Uvažuje o súbore, akoby bol prázdny.“

„Výsledok nástroja vrátil odmietnutie prístupu, nie obsah. Model videl iba text chyby — súbor nemá ako vidieť inak.“

Model Context Protocol (protokol kontextu modelu). Protokol na pripájanie externých serverov nástrojov k riadiacemu prostrediu — spôsob, akým agent získava nástroje nad rámec toho, čo toto prostredie obsahuje samo. Agent nikdy „nevolá MCP“; zavolá nástroj a riadiace prostredie ho jednoducho získalo zo servera MCP. Protokol sprístupňuje aj zdroje (údaje iba na čítanie) a prompty (opakovane použiteľné šablóny), jeho hlavným účelom je však poskytovanie nástrojov.

Protokol rieši problém integrácie. Bez štandardu by každé riadiace prostredie potrebovalo vlastnú integráciu Linear, vlastnú integráciu Slack a vlastnú integráciu databázy — každú samostatne vytvorenú a udržiavanú. S MCP sa integrácia napíše raz ako server a môže ju používať každé kompatibilné riadiace prostredie. Prostredie sa pripojí k serveru, server oznámi, ktoré nástroje ponúka, a tie sa agentovi sprístupnia popri vstavaných nástrojoch.

Cena sa platí v kontexte. Každý nástroj, ktorý server ponúkne, sa načíta ako definícia — názov, opis a schéma parametrov — a model môže volať iba nástroje, o ktorých vie. Naivný prístup načíta všetky definície do kontextového okna hneď na začiatku: nainštalujte niekoľko štedro vybavených serverov a relácia sa začne s tisíckami tokenov v schémach nástrojov ešte predtým, ako čokoľvek napíšete; rozpočet pozornosti sa tak míňa na nástroje, ktoré úloha nikdy nevyužije.

Mnohé riadiace prostredia to dnes zmierňujú vyhľadávaním nástrojov: namiesto úplných definícií obsahuje kontext ukazovateľ kontextu na dostupné nástroje — agent vyhľadá nástroj podľa názvu alebo účelu a načíta jeho definíciu až vtedy, keď ju potrebuje. Ak to vaše prostredie nepodporuje, vstupné náklady zostávajú a oplatí sa zapnúť iba servery, ktoré projekt skutočne potrebuje.

Použitie:

„Agent potrebuje čítať tikety z Linear.“

„Nakonfigurujte prostredie tak, aby používalo server MCP pre Linear — sprístupňuje API Linear ako nástroje, ktoré môže agent volať. Ušetrí vám to písanie vlastných obalových funkcií pre nástroje.“

To, čo karкас ukáže používateľovi pred vykonaním volania nástroja, ktoré nebolo vopred schválené. Model vytvorí volanie nástroja; namiesto okamžitého spustenia sa karкас pozastaví a opýta sa. Po schválení ho vykoná; po zamietnutí odošle modelu odmietnutie ako výsledok nástroja. Takto karкас zapája človeka do slučky pri rizikových alebo citlivých činnostiach.

Životný cyklus žiadosti o povolenie:

Zamietnutím žiadosti usmerníte agenta. Model číta odmietnutie ako každý iný výsledok nástroja a reaguje — skúsi iný postup alebo sa opýta, čo uprednostňujete. Väčšina karкасov umožňuje pripojiť k odmietnutiu správu, čím sa žiadosť zmení na bod usmernenia: „nie takto, použi radšej migračný skript“ dorazí presne v okamihu, keď sa model rozhoduje, čo urobí ďalej.

Cena spočíva v tom, že každá žiadosť vyžaduje vašu okamžitú odpoveď. Agent čaká, kým odpoviete; to je v poriadku, keď ho sledujete, no problém, keď pri ňom nie ste — agent, ktorý neustále žiada o povolenie, nemôže pracovať bez dozoru. Režim povolení určuje, ktoré volania prebehnú bez otázky a ktoré sa najprv opýtajú; sandbox môže umožniť bezpečné rozšírenie skupiny volaní bez otázky.

Použitie:

„Už desať minút čaká na povolenie — bol som na porade.“

„To je cena zapojenia človeka do slučky. Vopred schváľte bezpečné nástroje, aby sa žiadosť zobrazila iba pri skutočne rizikových volaniach.“

Časť režimu agenta, ktorá riadi povoľovanie — ktoré volania nástrojov spustia žiadosť o povolenie a ktoré sa vykonajú automaticky. Išlo o pôvodný účel systémov režimov ešte predtým, než karкаsy začali pridávať pokyny o správaní.

Karкаsy ponúkajú škálu takýchto režimov:

Pri výbere stupňa vymieňate bezpečnosť za prerušenia a prejavia sa oba druhy zlyhania. Príliš prísny režim z vás urobí úzke hrdlo: agent sa každých pár sekúnd zastaví pri neškodnom čítaní, vy automaticky klikáte na povolenie a potvrdenia prestanú niečo znamenať — bezmyšlienkovité schvaľovanie je to najhoršie z oboch svetov, všetky prerušenia a žiadna ochrana. Príliš voľný režim umožní agentovi upravovať súbory a spúšťať príkazy, ktoré by ste najprv chceli vidieť.

Voľný režim sa najľahšie obhajuje v sandboxe, kde sú následky zlého volania nástroja obmedzené. Mimo sandboxu väčšina ľudí nastaví automatické schvaľovanie čítania a ponechá človeka v slučke pri všetkom, čo sa nedá vrátiť späť.

Použitie:

„Zastavil sa pri každom grepovaní — úplne zničil beh bez dozoru.“

„Uvoľnite režim povolení pre nástroje iba na čítanie, pri zápise a shelli ponechajte výzvy. Väčšina žiadostí o povolenie vo výskumnej relácii je iba šum.“

Predvoľba, ktorá určuje, ako agent funguje počas behu — spája režim povolení s pokynmi o správaní, ktoré sa vkladajú do systémového promptu. Príklady: predvolený režim, ktorý žiada o potvrdenie pri rizikových volaniach, režim plánovania, ktorý blokuje úpravy a vedie agenta k prieskumu, režim prijímania úprav, ktorý úpravy automaticky schvaľuje, alebo režim obídenia povolení (ľudovo režim YOLO), ktorý automaticky schvaľuje všetko. Dá sa zmeniť aj uprostred relácie.

Režim od obyčajného nastavenia povolení odlišuje práve toto spojenie. Režim povolení je iba brána: rozhoduje, ktoré volania nástrojov prejdú. Samotná brána vytvorí agenta, ktorý chce upravovať, ale nemôže — navrhne zápis, narazí na blokovanie a skúsi inú cestu. Vložené pokyny odstránia samotnú túžbu upravovať: režim plánovania úpravy iba neblokuje, ale povie agentovi, že je vo fáze plánovania, takže číta, pýta sa a navrhuje namiesto toho, aby sa pokúšal obísť bránu. Brána aj smerovanie vedú rovnakým smerom.

V praxi meníte režim podľa toho, ako sa počas úlohy mení vaša dôvera. Tá istá úloha môže prejsť viacerými režimami: režim plánovania, kým sa ešte tvorí prístup, predvolený režim s otázkami pri prvých citlivých úpravách, režim prijímania úprav, keď agent preukáže, že zmene rozumie, a obídenie pri behu počas vašej neprítomnosti v sandboxe. Zmena režimu nič nestojí: rozhovor pokračuje presne tam, kde bol, iba s novými povoleniami a pokynmi. Ak schvaľujete každú otázku bez toho, aby ste si ju prečítali, režim je nastavený prísnejšie, než zodpovedá vašej skutočnej dôvere; ak úpravy stále odmietate, je nastavený voľnejšie.

Pomenovania dodávateľov: Claude Code tieto režimy nazýva „režimami povolení“, Codex „režimami schvaľovania“ — oba názvy vznikli ešte pred spojením režimov s pokynmi o správaní.

Použitie:

„Stále upravuje súbory, hoci chcem iba plán.“

„Prepnite na režim plánovania — zablokuje zápisy a zostane pri prieskume.“

„A čo neskôr, keď pobeží bez dozoru?“

„Režim obídenia, ale iba v sandboxe.“

Oddelené prostredie, v ktorom agent beží — kontajner, virtuálny stroj, dočasný súborový systém alebo shell s obmedzenými povoleniami. Obmedzuje dosah činností agenta: aj keď spustí deštruktívne príkazy alebo načíta niečo škodlivé, škody zostanú uzavreté. Je to bezpečnostný základ, vďaka ktorému je práca počas neprítomnosti človeka praktická.

Sandbox a režim povolení riešia rovnaký problém z opačných strán. Povolenia sa pred spustením činnosti opýtajú; sandbox obmedzí, kam sa činnosť dostane, aj keď sa spustí. Povolenia vyžadujú, aby ste zostali v cykle — každá otázka vás preruší a relácia, ktorá sa pýta neustále, je sotva samostatná. Sandbox spotrebuje infraštruktúru namiesto pozornosti: čím silnejšia izolácia, tým menej otázok treba klásť.

Izolácia má niekoľko úrovní:

Žiadny sandbox neobmedzí činnosti, ktoré z neho legitímne odchádzajú. Agent s vašimi povereniami do gitu môže odosielať zmeny; agent s prístupom k sieti môže volať produkčné API. Ešte pred rozhodnutím, aká nepriepustná má byť hranica, určite, čo cez ňu môže prejsť.

Použitie:

„Chcem ho nechať cez noc pracovať v režime obídenia povolení, ale ešte na to nie som pripravený.“

„Spusti ho v sandboxe — čistý kontajner bez pripojených poverení a bez prístupu k sieti. V najhoršom prípade zničí vlastný súborový systém a kontajner zahodíš.“

Sebavedome súhlasný výstup modelu. Spôsobuje ho tréning: model bol nastavený tak, aby uprednostňoval odpovede, ktoré sa ľuďom páčili, a ľudia radšej počujú súhlas než to, že sa mýlia. Model sa preto naučil, že za súhlas dostane odmenu — aj keď je nesprávny.

Prejavuje sa takto:

• Ustúpenie po námietke — zmení správnu odpoveď, keď sa spýtate „si si istý?“.
• Chválenie zlého vstupu — ešte pred analýzou označí váš chybný plán za skvelý.
• Skreslené hodnotenie — kontrola vyznie priaznivejšie, keď naznačíte, že ste ju napísali vy, a nepriaznivejšie, keď poviete, že ju napísal niekto iný. Rovnaký artefakt, iný verdikt.
• Napodobňovanie — zopakuje vaše chyby a tým ich potvrdí.

Diagnostický test: povedal by to model aj bez vášho navedenia? Ak sa zmenil iba váš tón alebo spôsob podania, ide o pochlebovanie, nie o skutočnú zmenu analýzy.

Náprava: zatajte svoje preferencie. Formulujte zadania neutrálne — „skontroluj tento kód“, nie „je tento kód dobrý?“.

Vyhýbajte sa: používaniu slova „pochlebovanie“ pre každú nesprávnu odpoveď, ktorá vám náhodou vyhovuje. Bez diagnostického testu nemá tento pojem väčšiu hodnotu než „nesprávne“.

Použitie:

„Povedal, že môj plán refaktoringu vyzerá skvele, a keď som sa spýtal ‚si si istý?‘, celý ho vzal späť.“

„Klasické pochlebovanie — najprv súhlasil, lebo ste pôsobili sebavedomo, potom ustúpil, lebo ste vyzerali pochybovačne. Kvalita plánu sa nezmenila, zmenil sa váš tón. Vymažte kontext a opýtajte sa znova bez naznačovania odpovede.“

Sebavedomý, ale nesprávny výstup modelu. Má dve podoby s odlišnými príčinami a riešeniami:

Predpovedanie nasledujúceho tokenu vytvára plynulý výstup bez ohľadu na to, či je podkladový fakt skutočný. Model nemá vnútorný signál, že niečo nevie, takže vymyslená metóda znie rovnako presvedčivo ako správna. Vymyslený kód je vierohodný už svojou povahou: vyzerá tak, ako by API vyzeralo, keby existovalo. Preto pri rýchlom prečítaní ľahko unikne a zlyhá až pri spustení.

Musíte vedieť, s ktorou podobou máte do činenia, pretože riešenie jednej zhoršuje druhú. Pri faktickej nesprávnosti chýbajú znalosti, preto treba doplniť kontext — dokumentáciu, typové definície alebo súbor. Pri strate vernosti sú znalosti prítomné, ale prehrávajú súťaž o pozornosť, preto treba kontext odstrániť. Ak si zámenu vernosti za faktickú nesprávnosť vysvetlíte ako nedostatok znalostí, pridáte ďalšiu dokumentáciu, zväčšíte kontext a odklon ešte zhoršíte. Keď agent urobí chybu, pred určením problému skontrolujte, či už správna informácia bola v kontexte.

Vyhýbajte sa: používaniu slova „halucinácia“ ako všeobecného synonyma pre „nesprávne“. Ak nepomenujete konkrétnu podobu, tento pojem nemá diagnostickú hodnotu.

Použitie:

„Vymyslel si metódu `parseAsync` pre schému.“

„Išlo o faktickú nesprávnosť alebo stratu vernosti?“

„Metóda je v dokumentácii, ktorú som vložil — po štyridsiatom ťahu ju prestal čítať.“

„Takže strata vernosti. Skráťte kontext a načítajte ho znova, ďalšiu dokumentáciu nepridávajte.“

Čo model „vie“ vďaka tréningu a uchováva vo svojich parametroch. Počas tréningu sa zmrazí — model svoje parametre nevidí ani ich nedokáže aktualizovať. Pri stláčaní do nich sa strácajú podrobnosti: miliardy faktov sa natlačia do pevného počtu parametrov a zriedkavé informácie sa rozmažú. Je to zdroj plynulých odpovedí o bežných témach aj vymýšľania pri nezvyčajných témach. Je to protipól kontextových znalostí.

Parametrické znalosti sa neukladajú ako fakty. Tréning modelu neposkytuje databázu, v ktorej by mohol vyhľadávať; upravuje jeho parametre, kým model nezačne dobre predpovedať text. Model, ktorý dobre predpovedá text o téme, sa správa, akoby ju poznal. Spoľahlivosť znalostí závisí od toho, ako často sa daná vec vyskytla v tréningových dátach: milióny príkladov umožnia tému presne zopakovať, no pri niekoľkých príkladoch model háda podľa podobných tém. Pre model ide o ten istý proces, preto nevie, či informáciu reprodukuje alebo háda. Vymyslená odpoveď znie rovnako plynulo ako správna. Halucinácia je nesprávny odhad modelu.

Parametrické znalosti tiež zastarávajú. Parametre sa prestanú meniť po dátume ukončenia znalostí, takže knižnica vydaná alebo premenovaná po tomto dátume v nich nie je a zmenené API si model pamätá v starej podobe.

Pri oboch medzerách — pri zriedkavých aj pri nových informáciách — je náprava rovnaká: znalosti nemožno pridať do parametrov, preto ich treba dodať ako kontextové znalosti.

Použitie:

„Píše bezchybný React, no vymýšľa metódy nášho interného SDK.“

„React je v parametrických znalostiach zastúpený množstvom príkladov z tréningu. Vaše SDK tam nie je, preto model dopĺňa vierohodne vyzerajúce tvary. Načítajte dokumentáciu SDK do kontextu."

Dátum, po ktorom model nemá parametrické znalosti. Knižnice, API a udalosti po tomto dátume sú pascou na vymýšľanie, pokiaľ sa ich dokumentácia nenačíta ako kontextové znalosti. Každé vydanie modelu má vlastný dátum ukončenia znalostí.

Tento dátum vyplýva zo spôsobu tvorby modelov: tréning uloží snímku textov do parametrov modelu a potom parametre zostanú nemenné. Model nevie, že jeho znalosti majú hranicu — ak sa ho spýtate na niečo po tomto dátume, neodmietne odpovedať, ale extrapoluje z najbližších znalostí, ktoré má. V tom spočíva nenápadnosť tejto pasce: kód napísaný pre starú verziu knižnice vyzerá vierohodne, často sa aj skompiluje, no zlyhá v častiach, ktoré sa zmenili.

Riešenie je vždy rovnaké: vložte aktuálne informácie do kontextu. Načítajte changelog, ukážte definície typov nainštalovanej verzie alebo nechajte agenta prečítať dokumentáciu na webe. Čokoľvek v kontexte má prednosť pred tým, čo v parametroch chýba.

Použitie:

„Stále píše syntax SDK verzie 3 — my používame verziu 5.“

„Verzia 5 vyšla po dátume ukončenia znalostí. Načítajte jej changelog ako kontextové znalosti, inak bude model naďalej vymýšľať podľa staršej parametrickej verzie.“

Fakty, ktoré si agent môže práve teraz priamo prečítať z kontextu — používateľskú úlohu, načítané súbory, výsledky nástrojov či obsah súboru AGENTS.md, ktorý sa načítal pri začiatku relácie. Opak parametrických znalostí: parametrické znalosti si model vybavuje z parametrov, kontextové číta z okna. Halucinácie sú oveľa zriedkavejšie, keď agent vychádza z kontextových znalostí — odpoveď má priamo pred sebou, nemusí ju loviť v rozmazanej pamäti.

Z dvoch druhov znalostí máte pod kontrolou iba kontextové. Parametre sú nemenné, takže jediný spôsob, ako modelu poskytnúť chýbajúce znalosti — interné SDK, knižnicu vydanú po dátume ukončenia znalostí alebo včerajšie rozhodnutie — je vložiť ich do kontextu. Veľká časť praktickej práce s programovaním pomocou AI spočíva v tom, že správne fakty dostanete pred model práve vtedy, keď ich potrebuje.

Keď sú kontextové a parametrické znalosti v rozpore, zvyčajne zvíťazia kontextové. Vložte aktuálnu dokumentáciu API a model sa bude riadiť ňou namiesto zastaranej pamäti o starom API — hoci stará verzia môže stále presakovať, najmä v dlhej relácii. Ak sa agent napriek načítanej dokumentácii stále vracia k zastaranému vzoru, ide o presakovanie parametrických znalostí cez kontextové; pomôže zopakovať opravu alebo ju presunúť bližšie k práci.

Na rozdiel od parametrických znalostí stojí použitie kontextových niečo navyše. Všetko načítané do okna spotrebúva tokeny a súťaží o rozpočet pozornosti, preto viac obsahu automaticky neznamená lepší výsledok — cieľom sú relevantné fakty v okne, nie všetky fakty.

Tento pojem použite iba pri porovnávaní s parametrickými znalosťami; inak jednoducho povedzte kontext.

Vyhýbajte sa: výrazu „pracovná pamäť“ — kontextové znalosti sú to, čo je v okne práve teraz; pamäťový systém prenáša obsah medzi reláciami. Ide o odlišné mierky, nezamieňajte ich.

Použitie:

„Prečo správne používa API, keď vložím dokumentáciu, ale vymýšľa si ho, keď ju nevložím?“

„S dokumentáciou má kontextové znalosti — číta priamo z nej. Bez nej používa parametrické znalosti a zriedkavé koncové body sa mu zlievajú.“

Pri predpovedaní každého tokenu model zohľadňuje všetky ostatné tokeny v kontexte — na niektoré vplývajú silno, na iné sotva. Dvojica tokenov tvorí vzťah pozornosti a významné dvojice („ju“ a „Sarah“ alebo volanie `getUser()` a definícia `function getUser`) sa navzájom ovplyvňujú viac než nesúvisiace dvojice. Kontext s N tokenmi má približne N² vzťahov.

V týchto dvojiciach spočíva zdanlivé porozumenie modelu. Zámeno vyrieši preto, že vzťah pozornosti medzi „ňou“ a „Sarah“ je silný. Keď zavolá funkciu so správnymi argumentmi, pomáha tomu vzťah medzi miestom volania a definíciou, ktorú predtým prečítal. Nič z toho sa nevyhľadáva — každý vzťah sa nanovo počíta pri každej požiadavke na poskytovateľa modelu.

Pri čísle N² sa oplatí pristaviť, pretože rastie rýchlejšie, než naznačuje intuícia:

Každá dvojica sa počíta viac než raz. Modely majú viacero hláv pozornosti — presný počet pri najpokročilejších modeloch nie je zverejnený, no rozumným odhadom je päťdesiat až sto — a každá hlava počíta vlastnú verziu každého vzťahu. Každá dvojica v tabuľke sa teda opakuje v každej hlave. To je množstvo dvojíc.

Pre konkrétnu úlohu je dôležitý iba malý počet týchto vzťahov. Dvojica medzi vaším pokynom a kódom, ktorého sa týka, je jednou z mála podstatných; takmer celý zvyšok predstavuje šum. Tieto dve množiny navyše rastú rôznym tempom: počet dôležitých vzťahov zostáva približne rovnaký, kým celkový počet rastie kvadraticky spolu s kontextom. Pri 1 000 tokenoch je dôležitý vzťah jeden z milióna; pri 100 000 jeden z desiatich miliárd. Tak sa počíta rozpočet pozornosti; zhoršovanie pozornosti cítime vtedy, keď dôležité vzťahy dostanú príliš malý podiel.

Použitie:

„Stále si zamieňa dva symboly `user` v diffe — asi sme v hlúpej zóne.“

„Áno, vzťah pozornosti medzi každým miestom volania a jeho deklaráciou súťaží s tým druhým — rovnaký tvar tokenu, iné väzby. Premenujte jeden a dvojice sa vyjasnia.“

Každý token má obmedzený vplyv, ktorý môže rozdeliť medzi zvyšok kontextu. Silný vplyv na jeden vzťah ponecháva menej priestoru ostatným. Rozpočet platí pre každý token zvlášť a nerastie spolu s kontextom, preto sa v dlhých reláciách rozriedi.

Predstavte si to ako signál a šum. Váš pokyn je signál s pevnou hlasitosťou; každý ďalší token v kontextovom okne je konkurenčný zvuk. Pokyn sa nestíši — stále tam je, znak po znaku — no keď kontext narastá, miestnosť okolo neho je čoraz hlučnejšia a pomer signálu k šumu klesá. Pokyn, ktorý bol najhlasnejší pri 10-tisíc tokenoch kontextu, sa pri 150-tisícoch zmení na šum v pozadí. Tak funguje zhoršovanie pozornosti: model nezabudne, signál sa stratí v šume.

Príznak vyzerá ako neposlušnosť — agent na začiatku súhlasil s obmedzením, neskôr sa od neho odkloní a opätovné vloženie obmedzenia pomôže iba na chvíľu. Príčinou nie je pokyn, ale všetko ostatné v okne, čo s ním súťaží.

Môžete ovplyvniť, čo sa do kontextu dostane. Obsah, ktorý úlohe neslúži, nie je neutrálny — pridáva šum ku všetkému užitočnému. Udržujte okno malé, vymažte kontext, keď sa nahromadený obsah prestane vyplácať, a dôležité obmedzenia zopakujte namiesto toho, aby ste sa spoliehali na ich skoršie spomenutie.

Použitie:

„Prečo stále ignoruje schému, ktorú som vložil na začiatku?“

„Už sme hlboko v hlúpej zóne — rozpočet pozornosti každého tokenu je pevný, ale kontext sa stále zväčšoval. Signál o schéme teraz súťaží s tisíckami novších tokenov.“

Keď relácia rastie, rozpočet pozornosti každého tokenu sa rozdeľuje medzi čoraz viac konkurujúcich si prvkov. Signál každého zmysluplného vzťahu slabne; do popredia sa tlačí šum z nepodstatného kontextu. Rovnaký model, rovnaké parametre — iba viac úst, ktoré jedia z toho istého taniera. Spôsobuje efekt inteligentnej a hlúpej zóny.

Prejavuje sa to tak, akoby sa model uprostred relácie zhoršil: obmedzenia, ktoré hodinu dodržiaval, začnú ustupovať, znovu sa pýta na veci, ktoré ste mu už povedali, a píše kód bez ohľadu na súbor, ktorý si predtým prečítal. S modelom sa nič nezmenilo — jedinou premennou je množstvo kontextu, ktorému teraz venuje pozornosť.

Je to postupná zmena, preto sa vnútri relácie ťažko zachytáva. Neobjaví sa chyba ani hranica; každý ťah je len o trochu horší než predchádzajúci a keď sú odchýlky zjavné, v hlúpej zóne už nejaký čas ste.

Nápravou je odstrániť kontext, nie pridávať ďalší. Opätovné vloženie ignorovaného pokynu pridá do toho istého preplneného okna ďalšieho konkurenta a pomôže len krátko. Pomáha: vymazať kontext a načítať iba to, čo úloha potrebuje, vykonať kompakciu alebo odovzdať prácu novej relácii. Zhoršené dodržiavanie pokynov berte ako signál o dĺžke kontextu, nie o modeli.

Použitie:

„Je hlboko v hlúpej zóne — vymýšľa generické typy, ktoré v súbore s typmi vôbec nie sú.“

„Zhoršenie pozornosti. Definície typov sú stále v kontexte, ale signál, ktorý nesú, je pochovaný pod všetkým, čo sme odvtedy pridali. Vymaž kontext a načítaj ho znova.“

Na začiatku relácie je agent v „inteligentnej zóne“ — je bystrý, sústredený a dobre si vybavuje informácie. Ako relácia rastie, prechádza do „hlúpej zóny“: je nedbanlivejší, zabúda a robí viac chýb vrátane halucinácií spôsobených stratou vernosti. Ten istý model, ten istý karкас — iba viac kontextu. Ide o pocitový prejav zhoršovania pozornosti. Pri špičkových modeloch sa hlúpa zóna často začína približne pri 125 až 150-tisíc tokenoch, hoci na tom nepanuje zhoda. Keď sa relácia nafúkne, vymažte kontext alebo ho skráťte; nesnažte sa pokračovať za každú cenu.

Pokles je postupný, preto sa ľahko prehliadne. Neobjaví sa chybové hlásenie ani viditeľná hranica; agent len začne podávať o niečo horší a potom výrazne horší výkon. Bežné príznaky: zabudne pokyn spred dvadsiatich ťahov, zopakuje už opravenú chybu alebo sebavedomo tvrdí niečo, čomu kontext odporuje. Keďže zhoršovanie je plynulé, bežnou reakciou je pokračovať a všetko vysvetliť znova — tým sa však pridá ďalší kontext a problém sa zhorší.

Tieto zóny nesúvisia s limitom kontextového okna. Relácia môže byť hlboko v hlúpej zóne, hoci je väčšina okna stále voľná: limit označuje hranicu, pri ktorej karкас odmietne pokračovať, ale kvalita klesá oveľa skôr. Plánujte podľa inteligentnej zóny, nie podľa veľkosti okna — praktický rozpočet úlohy tvorí množstvo tokenov, pri ktorom agent stále pracuje dobre, nie množstvo, ktoré dokáže technicky pojať.

Inteligentná zóna je rozpočet a nesúvisiaca práca ho míňa. Každá úloha v relácii spotrebúva tokeny, takže druhú úlohu začínate bližšie k hlúpej zóne. Jedna úloha na reláciu dá každej úlohe najbystrejšiu časť relácie. Ak je jedna úloha väčšia než jedna inteligentná zóna, rozdeľte ju: odovzdajte prácu alebo na prirodzenej hranici skráťte kontext a ďalšiu časť zverte novej relácii.

Použitie:

„Prvé tri komponenty zvládol výborne, ale štvrtý úplne pokazil.“

„Už ste mimo inteligentnej zóny — ten istý model je teraz hlboko v hlúpej zóne. Skráťte kontext a znova načítajte plán, ďalší komponent potom dopadne lepšie.“

Ukončenie aktuálnej relácie a začatie novej. Ďalšia správa začne v prázdnej relácii s prázdnym kontextovým oknom. Zvyčajne to iniciuje používateľ.

Vymazanie kontextu je riešením pre znečistený kontext. V relácii sa hromadí všetko: neúspešné pokusy, nesprávne odbočky, zastarané výsledky nástrojov, opustené plány. Model si to všetko znovu číta pri každom ťahu a zlá história zaťažuje novú prácu. V dlhej relácii je agent nejasnejší a menej poslušný — jasné pokyny ignoruje, kvalita klesá a naliehanie nepomáha, pretože šum v jeho kontexte zostáva. Vymazanie šum odstráni.

Vymazanie neodstráni konverzáciu. Väčšina karкасov uchováva históriu relácie v počítači, takže záznam si môžete prečítať alebo v nej pokračovať. Zmizne iba pracovný stav agenta: model je bezstavový, takže nová relácia nevie nič z toho, čo vedela stará. Ak obsahuje rozhodnutia alebo pokrok, ktoré bude ďalšia relácia potrebovať, najprv nechajte agenta pripraviť artefakt odovzdania a novú reláciu začnite odkazom naň.

Porovnajte to so skrátením kontextu, ktoré zhrnie reláciu do nového kontextu namiesto začatia s prázdnym. Vymazanie je hrubší nástroj: nič sa neprenesie vrátane balastu.

Použitie:

„Zasekol sa v slučke s neúspešným testom.“

„Jednoducho vymažte kontext — začnite novú reláciu s plánom a testovacím súborom. Nemá zmysel zápasiť s aktuálnym kontextom.“

Prenos agenta kontextu z jednej relácie do druhej. Spôsob prenosu sa líši — písomný artefakt odovzdania práce, súhrn v pamäti (skrátenie kontextu) a ďalšie možnosti. Líši sa od vymazania, pri ktorom sa neprenáša nič. Dôvody sú rôzne: zmena úlohy (plánovač → realizátor), spustenie práce bez dozoru, rozdelenie práce medzi súbežné relácie alebo uvoľnenie miesta v kontextovom okne.

Nová relácia začína s nulovým kontextom — model je bezstavový a zo starej relácie nevidí nič. Všetko, čo ďalšia relácia potrebuje, treba preniesť výslovne; všetko ostatné je preč. Obmedzenie „niet cesty späť“ určuje spôsob prenosu: nová relácia sa nemôže starej spýtať, čo mala na mysli, preto musí byť prenesený materiál zrozumiteľný sám osebe.

Viditeľným dôsledkom zlého odovzdania je opätovné otváranie už uzavretých otázok: nová relácia znovu rieši rozhodnutia starej, pretože prenos zaznamenal, čo sa rozhodlo, ale nie prečo. Odovzdanie posudzujte podľa toho, čo by s preneseným materiálom dokázala relácia s nulovým kontextom.

Použitie:

„Plánovacia relácia je už vyčerpaná — mám len pokračovať?“

„Odovzdajte prácu. Zapíšte rozhodnutia do dokumentu, vymažte kontext a začnite realizáciu v novej relácii, ktorá si dokument načíta.“

Pôvodný zdroj pravdy — kód, prepis rozhovoru, surový záznam alebo skutočná odpoveď API. Nie opis veci, ale samotná vec. Je protipólom sekundárneho zdroja.

Ak chcete vedieť, čo robí vaša kódová základňa, primárnym zdrojom je kód. Dokumentácia, architektonický diagram aj README ju iba opisujú — v čase vzniku boli presné, odvtedy však žijú vlastným tempom. Keď agent sebavedomo tvrdí niečo nesprávne o vašom projekte, pýtajte sa, z akého zdroja vychádzal: agent, ktorý čítal dokumentáciu, preberá jej zastaranosť; agent, ktorý čítal kód, číta aktuálny stav.

To, čo bráni tomu, aby primárne zdroje boli predvolené, sú náklady. Načítanie kontextového okna stojí veľa — celý súbor, celý prepis, každý token sa účtuje ako vstupné tokeny a súperí o rozpočet pozornosti. Za túto cenu získate úplnosť: nikto vopred neodfiltroval informácie podľa vlastného úsudku o tom, čo bolo dôležité. Súhrn napísaný minulý mesiac nemôže obsahovať detail, ktorý sa ukázal ako dôležitý dnes; primárny zdroj ho stále obsahuje.

Po primárnom zdroji siahnite, keď záleží na presnosti — na presnom podpise funkcie, skutočnej chybe či riadku, ktorý vyhadzuje výnimku. Veľká časť práce s kontextom spočíva v rozhodovaní, kedy zaplatiť za primárny zdroj a kedy stačí sekundárny.

Použitie:

„Agent tvrdí, že logika opakovaných pokusov čaká čoraz dlhšie, no ja vidím, ako neustále bombarduje koncový bod.“

„Vyčítal to z návrhového dokumentu. Nasmeruj ho na skutočný modul opakovaných pokusov — keď záleží na správaní, nech vychádza z primárneho zdroja.“

Opis primárneho zdroja sprostredkovaný z druhej ruky — dokumentácia opisujúca kód, súhrn opisujúci prepis, správa opisujúca výsledky hľadania. Do kontextového okna sa načíta lacnejšie než samotný zdroj, ktorý opisuje, a už zo svojej podstaty je stratový: autor rozhodol, čo je dôležité, a všetko vynechané zostáva čitateľovi, ktorý má iba súhrn, skryté.

Veľká časť práce s kontextom spočíva vo vytváraní sekundárnych zdrojov. Kompakcia premení históriu relácie na súhrn, ktorý poslúži ako základ ďalšej relácie. Podriadený agent spotrebuje vlastný kontext pri hlučnom hľadaní a vráti krátku správu. Artefakt odovzdania zhustí rozhodnutia z relácie do dokumentu, ktorý si prečíta ďalšia relácia. Pamäťové systémy zhrnú, čo sa relácia naučila, do poznámok. Každý z nich robí rovnaký kompromis: menej vernosti výmenou za voľný priestor.

Sekundárne zdroje zlyhávajú dvoma spôsobmi. Sú stratové — súhrn po kompakcii môže vynechať rozhodnutie o schéme, správa okrajový prípad. A zastarávajú — primárny zdroj sa zmení, ale jeho opis ho nenasleduje; dokumentácia potom opisuje architektúru z minulého štvrťroka s istotou platnou pre tento štvrťrok. Keď agent pracuje so sekundárnym zdrojom, ktorý zlyhal jedným z týchto spôsobov, sebavedomo vychádza z nesprávnych informácií; nápravou je vrátiť ho k primárnemu zdroju.

Ani jedno z týchto zlyhaní neznamená, že sekundárne zdroje netreba používať. Kontextové okno má obmedzenú veľkosť a primárne zdroje sú nákladné; bez súhrnov, správ a dokumentov na odovzdanie by sa doň nezmestilo nič rozsiahle. Zručnosť spočíva v tom, vedieť, ktoré podrobnosti prežijú toto zjednodušenie — a overiť ich podľa primárneho zdroja, keď neprežijú. Dobrý sekundárny zdroj obsahuje ukazovateľ kontextu späť na svoj originál — súhrn uvedie prepis, z ktorého vznikol, dokument pomenuje súbor, ktorý opisuje — takže ak opis nestačí, čitateľ môže ukazovateľ nasledovať namiesto toho, aby pracoval iba so zvyškami.

Použitie:

„V dokumente na odovzdanie sa píše, že overovanie totožnosti je hotové, ale nová relácia stále nachádza pokazené obnovovanie tokenov.“

„Dokument je sekundárny zdroj — predchádzajúca relácia zapísala, čomu verila, nie to, čo je pravda. Nech nová relácia spustí testy overovania totožnosti a dôveruje primárnemu zdroju.“

Dokument, ktorý slúži ako nosič informácií pri odovzdaní — jedna relácia ho zapíše do prostredia, aby si ho prečítala ďalšia. Špecifikácie, tikety aj plánovacie dokumenty sú artefakty odovzdania.

Prečo ho písať: model je bezstavový, takže po jeho vymazaní z relácie nič nezostane. Rozhodnutia, obmedzenia, nedokončené plány — všetko zmizne spolu s kontextom, ktorý ich obsahoval. Prostredie pretrváva. Zapísaním dôležitého stavu do súboru ho presuniete na miesto, odkiaľ si ho ďalšia relácia môže znovu načítať.

Artefakt je sekundárny zdroj — záznam o práci relácie, nie samotná práca. Vďaka tomu je dosť stručný na to, aby uviedol do témy novú reláciu, ale aj preto môže zavádzať: zaznamenáva to, čomu verila relácia, ktorá ho napísala, a čokoľvek vynechané alebo nesprávne v ňom zostáva čitateľovi skryté. Ak na tvrdení záleží, ďalšia relácia by si ho mala overiť podľa primárneho zdroja — kódu či testov — a nie ho iba prevziať.

Dobrý artefakt je napísaný tak, aby ho bolo možné načítať do relácie bez akéhokoľvek kontextu. Používajte konkrétne cesty k súborom namiesto „toho súboru, o ktorom sme hovorili“. Zaznamenajte, o čom sa rozhodlo a prečo, aby ďalšia relácia znovu neotvárala už uzavreté otázky. Uveďte, čo je hotové a čo zostáva. Pomôže, keď relácii, ktorá artefakt píše, poviete, kam smeruje: „Napíš dokument na odovzdanie pre novú reláciu, ktorá o tejto práci nič nevie.“

Alternatívnym spôsobom prenosu je kompakcia, ktorá zhrnie obsah priamo v pamäti. Artefakt má dve výhody: zostáva na disku, takže ho môžete prečítať a opraviť skôr, než od neho bude niečo závisieť, a dá sa opakovane použiť — tá istá špecifikácia môže uviesť do témy päť paralelných relácií.

Použitie:

„Ako to rozdeliť medzi plánovacieho agenta a toho, ktorý bude prácu vykonávať?“

„Nech plánovací agent napíše artefakt odovzdania — cesty k súborom, rozhodnutia, obmedzenia. Relácia agenta, ktorý bude prácu vykonávať, sa začne ukazovateľom na artefakt a bude z neho čerpať zadanie.“

Artefakt odovzdania opisujúci prácu rozloženú do viacerých relácií — čo sa vytvára, nie ako každá relácia vykoná svoj diel. Mení sa podľa postupu práce. Tvoria ho tikety.

Špecifikácia existuje preto, že relácie sú jednorazové, zatiaľ čo rozsiahla práca nie. Čokoľvek, čo si vyžaduje viac než jedno kontextové okno, potrebuje miesto mimo kontextu — v prostredí agenta, ktoré pretrvá aj po jeho vymazaní, či už ide o súbor v repozitári, problém na GitHube alebo nástroj na sledovanie problémov, ku ktorému má agent prístup. Týmto miestom je špecifikácia: cieľ, obmedzenia, doterajšie rozhodnutia a zoznam tiketov s ich stavom. Každá nová relácia si ju môže prečítať a zistiť, v akom stave je práca, bez toho, aby zdedila nahromadený šum z predchádzajúcej relácie.

Špecifikácie mávajú rozpoznateľné štýly, väčšinou prevzaté zo zaužívaných spôsobov tímového zapisovania. Dokument požiadaviek na produkt (PRD) sa sústreďuje na to, čo používateľ uvidí a prečo — funkcie, správanie a kritériá prijatia. Návrhový dokument alebo RFC sa zameriava na technickú stránku — zvolený prístup, zamietnuté alternatívy a kompromisy. Pri menšom projekte poslúži aj obyčajný `plan.md` so zoznamom tiketov, ktoré treba vybaviť. Na štýle záleží menej než na jeho úlohe: pre agenta je každý z týchto dokumentov to isté — trvalý záznam zámeru, ktorý si prečíta na začiatku každej relácie.

Použitie:

„Má sa to celé zmestiť do jednej relácie?“

„Nie, spíšte to ako špecifikáciu — rozdeľte ju na tikety a každý riešte vo vlastnej relácii. Pri pokuse urobiť všetko v jedinom kontexte narazíte na hlúpu zónu ešte pred polovicou.“

Artefakt odovzdania, ktorý vymedzuje jednu reláciu práce. Môže stáť samostatne alebo byť jedným z podriadených tiketov v rámci špecifikácie. Tikety môžu blokovať súrodenecké tikety alebo byť blokované nimi, takže poradie práce vyplýva z grafu závislostí, nie z lineárneho plánu.

Rozhodujúce je obmedzenie rozsahu: jedna relácia. Tiket by sa mal dať dokončiť skôr, než relácia opustí inteligentnú zónu — a toto obmedzenie sa dá overiť. Ak sa relácie pri vašich tiketoch pravidelne zhoršujú skôr, než je práca hotová, tikety sú príliš veľké; rozdeľte ich. Ak každá relácia strávi väčšinu svojho kontextu prípravou a potom urobí päť minút práce, tikety sú príliš malé; spojte ich.

Dobrý tiket je napísaný pre čitateľa, ktorý nemá žiadny ďalší kontext. Obsahuje cieľ, kritériá prijatia a ukazovatele kontextu na príslušné súbory a rozhodnutia — toľko, aby relácia mohla začať pracovať bez opätovného odvodzovania toho, čo vedela predchádzajúca.

Práve graf závislostí umožňuje aj paralelnú prácu. Nezávislé tikety — listy grafu — môžu súčasne bežať každý vo vlastnej relácii. Je to účinný spôsob, ako naraz spúšťať viacerých agentov. V softvérovej továrni je označenie tiketu ako pripraveného samo osebe spúšťačom jeho relácie.

Použitie:

„Kde mám začať pri špecifikácii migrácie?“

„Pozrite si graf tiketov — zmena schémy blokuje doplnenie existujúcich údajov a to blokuje prepnutie API. Vyberte si koncový tiket a spustite na ňom reláciu.“

Odovzdanie vykonané v pamäti: história predchádzajúcej relácie sa zhrnie a súhrn poslúži ako základ novej relácie. Zámerne je stratové: prepis je primárny zdroj, súhrn sekundárny zdroj — za viac voľného priestoru sa platí stratou podrobností. Spúšťa ho používateľ manuálne alebo automaticky cez automatickú kompakciu.

Mechanizmus funguje takto: kontextové okno má obmedzenú veľkosť a dlhá relácia ho zaplní — každý výsledok nástroja, každé prečítanie súboru aj každá slepá ulička zostáva v histórii. Keď je toho priveľa, riadiace prostredie požiada model, aby reláciu zhrnul, zahodí pôvodnú históriu a spustí novú reláciu so súhrnom. Všetko, čo sa do súhrnu nedostalo, z kontextu zmizne. Niektoré riadiace prostredia to zmierňujú tým, že starý prepis ponechajú na disku a do súhrnu vložia ukazovateľ kontextu — sekundárny zdroj tak odkazuje späť na primárny, aby sa strata detailu dala napraviť opätovným prečítaním originálu.

Súhrn píše model, takže ho možno ovplyvniť promptom. Pokyn „Zachovaj rozhodnutia o schéme“ vedie k premyslenejšiemu výslednému artefaktu. Záleží aj na načasovaní — kompakciu vykonajte na hranici fázy, keď je plán ustálený, nie uprostred úlohy.

Porovnajte to s vymazaním, ktoré všetko zahodí a začína od nuly: kompakcia sa pokúša preniesť podstatné informácie ďalej, zatiaľ čo vymazanie predpokladá, že už sú zapísané na vhodnejšom mieste.

Použitie:

„Kontext sa začína zapĺňať a ešte musím dokončiť testy.“

„Predtým reláciu skompaktujte — v pokyne pre súhrn uveďte, čo sa musí zachovať, aby si nová relácia ponechala rozhodnutia o schéme a zahodila prieskum.“

Skrátenie kontextu, ktoré karкас spustí automaticky, keď sa kontextové okno takmer zaplní.

Karкас sleduje zaplnenie kontextového okna. Keď prekročí hranicu — často približne 80 % — pozastaví sa, požiada model, aby zhrnul doterajšiu reláciu, a novú reláciu začne s týmto súhrnom. Práca potom pokračuje, akoby sa nič nestalo.

Niečo sa však stalo. Skrátenie stráca informácie a automatické skrátenie ich stráca v čase, ktorý ste si nevybrali. Manuálne skrátenie prebieha na hranici fázy, keď môžete modelu povedať, čo má zachovať. Automatické skrátenie sa spustí uprostred úlohy po dosiahnutí hranice — možno v polovici refaktoringu; súhrn potom sám rozhodne, ktoré vaše rozhodnutia stoja za zachovanie. Typickým príznakom je agent, ktorý sebavedomo pokračuje, no potichu zabudol obmedzenie stanovené pred hodinou. Všimnete si to, až keď mu jeho práca začne odporovať.

Obranou je nedovoliť, aby sa spustilo. Sledujte ukazovateľ kontextu a skracujte ho ručne na prirodzenej hranici alebo zapíšte rozhodnutia do plánovacieho dokumentu či artefaktu odovzdania práce na disku, kde ich nijaký súhrn nestratí. Väčšina karкасov tiež umožňuje nastaviť rezervu — posunúť hranicu skôr alebo neskôr, prípadne automatické skracovanie úplne vypnúť — a vybrať tak, koľko priestoru chcete ponechať.

Použitie:

„Zdá sa, že si nepamätá, na čom sme sa predtým dohodli pri schéme.“

„Automatické skrátenie sa spustilo medzi ťahmi — skoršie rozhodnutia zhrnulo a zrejme sa niečo stratilo. Znova načítajte plán alebo nabudúce skráťte kontext ručne, aby ste vybrali, čo sa zachová.“

Systém, ktorý sa pokúša zachovať stav agenta naprieč reláciami. Počas relácie ukladá informácie do prostredia a na začiatku budúcich relácií ich znova načíta do kontextového okna, takže agentovi zostáva kontinuita aj po tom, čo používateľ reláciu vymaže.

Pamäťový systém má dve polovice. Zápis: počas relácie agent zaznamenáva, čo sa dozvedel — napríklad vašu preferenciu alebo fakt o projekte — do súborov v prostredí. Čítanie: na začiatku relácie riadiace prostredie tieto súbory alebo ich index načíta späť do kontextového okna. Mnohé riadiace prostredia majú vlastný pamäťový systém — napríklad príkaz `/memory` v Claude Code — môžete si ho však vytvoriť aj sami: adresár s poznámkami a pokyn v AGENTS.md, aby si ich agent prečítal.

Platia rovnaké kompromisy ako pri každom obsahu, ktorý sa načítava vždy. Spomienky sa hromadia, preto väčšina systémov načítava jednoradový index a samotné texty ponecháva za ukazovateľmi kontextu, namiesto toho, aby vložila všetko naraz. Spomienky sú aj sekundárne zdroje, takže zastarávajú: fakt zaznamenaný v marci sa v júni načíta s rovnakou istotou, hoci sa projekt odvtedy zmenil. Pamäťový systém treba priebežne prečisťovať, rovnako ako AGENTS.md.

Použitie:

„Stále mu musím opakovať, že používam Postgres, nie MySQL.“

„Nastav pamäťový systém — pri prvom ťahu nech zapíše, čo sa naučí, do súborového systému a na začiatku relácie to znovu načíta. Samotný model je bezstavový; kontinuitu predstiera vrstva pamäte.“

Súbor v prostredí, ktorý riadiace prostredie načíta do kontextového okna na začiatku relácie — trvalé zadanie projektu pre agenta. Ide o konvenciu spoločnú rôznym riadiacim prostrediam; niektoré majú aj vlastnú obdobu (napríklad Claude Code používa CLAUDE.md).

Keďže sa načítava automaticky, pomáha vyhnúť sa opakovaniu pokynov v každej relácii. Model je bezstavový — oprava, ktorú mu dáte v jednej relácii, sa v ďalšej stratí. Potom musíte každému novému agentovi vysvetľovať, že projekt používa pnpm, že testy sa spúšťajú s určitým príznakom alebo že adresár je generovaný a nemá sa upravovať. Keď musíte agenta na tú istú vec opraviť druhýkrát, môže sa z nej stať riadok v AGENTS.md.

Vhodný je obsah, ktorý agent nedokáže vyvodiť z kódu: príkazy na zostavenie a testovanie, konvencie, ktoré z kódu nie sú zrejmé, či pevné obmedzenia („nikdy neupravuj generovaného klienta“). Buďte struční a vecní — je to zadanie, nie dokumentácia.

Nevýhodou je, že sa vždy načíta celý súbor. Pokyny sa hromadia, väčšina z nich je pre danú úlohu nepodstatná a dlhý AGENTS.md stojí tokeny a oslabuje vlastný účinok — čím viac pokynov obsahuje, tým menej spoľahlivo agent dodrží ktorýkoľvek z nich.

Vyhýbajte sa: používaniu AGENTS.md na obsah, ktorý sa má postupne odhaľovať — každý takýto obsah stojí tokeny pri každom ťahu v každej relácii, aj keď ho daná relácia nepotrebuje. Sprievodca štýlom môže byť ukrytý za zručnosťou alebo ukazovateľom kontextu; v AGENTS.md ponechajte len pokyny platné všade.

Použitie:

„Prečo sa v každej relácii hneď na začiatku minú 4k tokenov?“

„Pozri sa do AGENTS.md — niekto tam vložil celý sprievodca štýlom namiesto toho, aby ho sprístupnil cez zručnosť.“

Načítanie iba toho kontextu, ktorý agent práve potrebuje, a použitie ukazovateľov kontextu na zvyšok. Pojem pochádza z návrhu používateľských rozhraní, kde znamená zobrazovanie iba tých ovládacích prvkov, ktoré sú potrebné pre aktuálnu úlohu; ostatné sú skryté za kliknutím.

Táto technika existuje preto, že kontext má dvojité náklady. Každý vopred načítaný token sa účtuje ako vstupný token pri každom ťahu a každý token spotrebúva rozpočet pozornosti, či ho agent potrebuje alebo nie. Súbor AGENTS.md naplnený celou príručkou štýlu, prevádzkovým postupom nasadenia a pravidlami databázy zhorší schopnosť agenta dodržiavať všetky tieto pokyny — tie, ktoré sú dôležité pre aktuálnu úlohu, sa rozriedia medzi ostatnými. Signálom je agent, ktorý ignoruje pravidlá, o ktorých viete, že ich má v kontexte: sú tam, ale sú pochované.

Postupné odhaľovanie informácií tento prístup obracia. Vrstva načítaná vždy má byť malá — veta o každej téme a ukazovateľ na podrobnosti. Agent si príručku štýlu načíta pri písaní komponentu, prevádzkový postup pri nasadzovaní a ani jedno pri oprave testu. Zručnosti sú vzor zabudovaný do karкаса: krátky opis sa načíta pri každej relácii, úplné pokyny až po aktivovaní.

Použitie:

„Mám vložiť celú príručku štýlu do súboru AGENTS.md?“

„Nie — použite postupné odhaľovanie informácií. Uveďte príručku štýlu ako zručnosť, ktorú si agent načíta, keď bude písať komponent. AGENTS.md by inak stál tokeny pri každom ťahu.“

Odkaz v jednom dokumente na iný dokument, vďaka ktorému si agent môže načítať obsah do kontextového okna až vtedy, keď si to úloha vyžaduje. Práve na tom je postavené postupné odhaľovanie.

Dôvodom používania ukazovateľa namiesto vloženia celého obsahu je cena. Ukazovateľ zaberie jeden riadok v kontextovom okne. Dokument, na ktorý odkazuje, môže mať tisíce tokenov, ale nič nestoja, kým agent ukazovateľ nenasleduje. Vložte do AGENTS.md prevádzkový postup s 2 000 tokenmi a zaplatí zaň každá relácia; nahraďte ho textom „postup nasadenia: pozri `internal/deploy.md`“ a načítajú si ho iba relácie, ktoré nasadzujú. Keď sa úloha zhoduje s obsahom ukazovateľa, agent ho nasleduje pomocou volania nástroja.

Aby ukazovateľ fungoval, potrebuje dve veci: stabilnú cestu a dostatočný opis, aby agent vedel, kedy sa oplatí naň kliknúť. Samotná cesta je ukazovateľ bez dôvodu, prečo by ju mal niekto nasledovať; text „pozri `internal/deploy.md`“ bez vysvetlenia obsahu preskočí relácia, ktorá ho potrebuje. Formulujte riadok tak, aby zodpovedal tomu, ako sa úlohy zadávajú: „vydanie, nasadenie alebo návrat k predchádzajúcej verzii — najprv si prečítaj `internal/deploy.md`“.

Ukazovatele sú všade, keď si ich začnete všímať: riadky v AGENTS.md, opisy zručností (riadiace prostredie načíta opis, samotné pokyny zostanú skryté), názvy súborov vo výpise adresára aj odkazy medzi dokumentmi.

Ukazovateľ môže tiež spájať sekundárny zdroj so primárnym zdrojom, z ktorého vznikol — súhrn po kompakcii pomenuje pôvodný prepis, dokument uvedie zdrojový súbor, ktorý opisuje. Tak sa strata informácií dá napraviť: ak súhrn nestačí, relácia nasleduje ukazovateľ a prečíta si originál namiesto toho, aby pracovala iba s tým, čo v ňom zostalo.

Vyhýbajte sa: „odkaz“ — pôsobí príliš sucho a nevystihuje, že jeho nasledovanie načíta ďalší kontext. „Portál“ — je príliš ozdobné.

Použitie:

„AGENTS.md je už príliš dlhý.“

„Väčšina jeho obsahu by mala byť ukazovateľmi kontextu, nie samotným obsahom. Nechajte pokyny platné všade priamo v súbore; postup nasadenia a sprievodcu štýlom presuňte do zručností a ponechajte na ne ukazovatele kontextu.“

Naučiteľná schopnosť zabalená do samostatnej jednotky — pokyny a zdroje, vďaka ktorým sa dá jedna úloha robiť dobre. Zostáva v prostredí, kým ju ukazovateľ kontextu nenačíta do kontextového okna pre aktuálnu úlohu. V riadiacom prostredí je to jednotka postupného odhaľovania.

Zručnosti sú otvoreným štandardom definovaným na agentskills.io — pôvodne ich vyvinula spoločnosť Anthropic a odvtedy ich prijala väčšina hlavných riadiacich prostredí, takže raz napísaná zručnosť funguje naprieč nimi. Formát tvorí priečinok s týmito súčasťami:

• Súbor `SKILL.md` — metadáta (minimálne názov a opis) a samotné pokyny
• Voliteľné skripty, ktoré môže agent spúšťať
• Voliteľné šablóny a referenčné materiály, na ktoré pokyny odkazujú

V kontexte sú predvolene iba názov a opis. Keď sa úloha agenta zhoduje, načíta zvyšok. Dovtedy zručnosť zaberá takmer žiadne miesto — jednu či dve vety tokenov, nech sú jej úplné pokyny akokoľvek dlhé.

Tým sa zručnosti líšia od AGENTS.md, ktorý sa načíta v každej relácii bez ohľadu na úlohu. Zručnosť sa načíta až pri konkrétnom druhu práce — vydávaní, príprave novej služby alebo písaní migrácie — a po zvyšok času sa ignoruje.

Vyhýbajte sa: zamieňaniu so „nástrojom“ — nástroj agent volá, zručnosť číta ako pokyny.

Použitie:

„Kam mám uložiť postup nasadenia?“

„Do zručnosti — agent ju načíta iba vtedy, keď úloha zahŕňa nasadenie. V AGENTS.md by sa tokeny míňali pri každom ťahu, hoci ju používame raz za týždeň.“

Agent, ktorého iný agent spustil pomocou volania nástroja. Beží vo vlastnej relácii s vlastným kontextovým oknom a vracia jeden výsledok nástroja. Líši sa od odovzdania — nadradený agent výslovne očakáva návrat výsledku, kým odovzdanie nemá cestu späť. Nemôže spúšťať ďalších podriadených agentov — strom má iba jednu úroveň. Podriadení agenti slúžia na oddelenie kontextu, nie na skladanie hierarchií.

Cieľom je udržať hlučnú prácu mimo kontextu nadradeného agenta. Ak sa rozsiahle hľadanie alebo dlhé čítanie súborov vykoná v nadradenej relácii, všetky výsledky nástrojov v nej zostanú po zvyšok relácie. Ak sa vykoná v podriadenom agentovi, šum zaplní jeho jednorazové kontextové okno — v kontexte nadradeného agenta skončí iba záverečná správa. Tá je sekundárnym zdrojom: nadradený agent dostane opis toho, čo podriadený našiel, nie surové výsledky, takže všetko, čo správa vynechá, mu zostane skryté.

Podriadení agenti bežia aj súbežne — nadradený agent ich môže spustiť niekoľko naraz na nezávislých častiach práce.

Použitie:

„Výsledky grep mi zapĺňajú kontext.“

„Spusti podriadeného agenta na hľadanie — šum spotrebuje vo vlastnom kontextovom okne a vráti ti iba dve cesty k súborom, ktoré potrebuješ.“

Spôsob práce, pri ktorom jeden alebo viacerí ľudia počas relácie spolupracujú s agentom — priebežne kontrolujú, usmerňujú ho alebo pracujú po jeho boku. Človek je prítomný a zapojený, nie je iba bránou pre jednotlivé úkony.

Opakom je práca počas neprítomnosti človeka, pri ktorej agent beží bez dozoru a výsledok posúdite až potom. Keď je človek súčasťou cyklu, problémy zachytí, kým sa dajú lacno napraviť: vidíte, že agent siaha po nesprávnom súbore, nesprávne pochopil požiadavku alebo sa vydáva slepou uličkou, a jednou vetou ho nasmerujete — namiesto toho, aby ste po dvadsiatich minútach objavili sebavedomo odvedenú prácu postavenú na omyle. Agenti spoľahlivo nevedia rozpoznať, kedy zišli z cesty; keď zostanú sami, zvyknú pokračovať namiesto toho, aby sa zastavili a opýtali.

Vhodný spôsob závisí od práce. Dobre špecifikované úlohy s nízkym rizikom a ľahko overiteľným výsledkom sa hodia na beh bez dozoru. Nejednoznačné alebo nezvratné úlohy, prípadne také, ktorých výsledok by sa vám ťažko kontroloval — migrácia schémy, zložité návrhové rozhodnutie či čokoľvek, čo zasahuje do produkcie — si vyžadujú, aby ste zostali pri práci. Rozhodujúca otázka znie: aké nákladné bude nesprávne odbočenie a ako neskoro by ste ho odhalili?

Niektorá práca je zo svojej podstaty prácou za účasti človeka, pretože vstupom sú jeho reakcie. Vyspovedávanie funguje iba vtedy, keď ste tam a odpovedáte na otázky; prototypovanie potrebuje vašu reakciu na artefakt.

Zostať zapojený stojí vašu pozornosť — vzácny zdroj. Súčasťou zlepšovania práce s agentmi je bezpečne presúvať viac práce mimo cyklu, a to pomocou plánov, automatických kontrol a záverečnej ľudskej kontroly namiesto priebežného dohľadu. Softvérová továreň ide ešte ďalej: spúšťa relácie na základe podnetov, takže ani začiatok práce od vás nemusí závisieť.

Použitie:

„Mám to nechať cez noc bežať bez dozoru?“

„Nie, ide o migráciu schémy — nechaj pri tom človeka. Chcem vidieť každý krok a usmerniť ho, ak si vyberie nesprávny stĺpec na doplnenie hodnôt.“

Doslova „preč od klávesnice“. Spôsob práce, pri ktorom používateľ spustí reláciu a nechá agenta pracovať bez dozoru. Zvyšuje priepustnosť programovania s AI: súbežne môže bežať veľa relácií agentov, kým spíte, jete alebo pracujete na niečom inom. Bezpečný beh zvyčajne vyžaduje voľnejší režim povolení a zároveň sandbox.

Keď pri práci nie ste, agent pristupuje k nejednoznačnostiam inak. Keď ho sledujete, nejasné rozhodnutie sa prejaví otázkou a vy odpoviete; keď odídete, agent zvolí predvolenú možnosť, pokračuje a každé ďalšie rozhodnutie nadväzuje na tento odhad. Typickým zlyhaním je návrat k hodinám hotovej, sebavedomej práce postavenej na nesprávnom rozhodnutí z prvých desiatich minút. Práca nie je odfláknutá — je súdržná, len vychádza z nesprávneho predpokladu.

Keďže počas behu nemôžete poskytnúť vstup, dajte ho agentovi pred začiatkom a po dokončení. Pred začiatkom: vyriešte nejednoznačnosti vopred — napríklad pomocou relácie vyspovedávania alebo písomnej špecifikácie — aby mal agent menej medzier na samostatné vypĺňanie. Počas behu: automatické kontroly a automatická revízia zastúpia pozornosť, ktorú mu nevenujete, a rýchlo zlyhajú pri problémoch, ktoré sa dajú zachytiť mechanicky. Po dokončení: výsledkom behu musí byť niečo, čo možno skontrolovať — PR, nie zmeny už zlúčené do projektu. Práca bez dozoru neodstraňuje ľudskú kontrolu, iba ju odkladá na koniec, preto musí byť výsledok hodný kontroly. Aj preto je AX pri takýchto behoch najdôležitejšia — bez dozoru je prostredie jedinou oporou, ktorú agent má.

Vyhýbajte sa: výrazu „agent na pozadí“ — kladie dôraz na stroj („beží na pozadí“) namiesto spôsobu práce človeka („používateľ odišiel“). AFK pomenúva podstatnú skutočnosť: používateľ nesleduje, čo sa deje.

Použitie:

„Nechávam to bežať bez dozoru — traja agenti v sandboxe prerábajú kód a ráno skontrolujem PR.“

„Obídenie povolení?“

„Áno, súborový systém iba na čítanie a bez siete.“

Deterministické overenie, ktoré sa spúšťa v prostredí — testy, kontrola typov, lintery, zostavenie, hooky pred commitom. Výsledkom je úspech alebo neúspech, bez úsudku. Je to signál, podľa ktorého sa agent dokáže sám opraviť bez zapojenia kohokoľvek ďalšieho. Nestabilný test je pokazená kontrola, nie absencia kontroly; automatické kontroly sú z princípu deterministické.

Samopravovanie funguje ako cyklus. Agent vykoná zmenu, spustí kontrolu ako volanie nástroja a výstup o zlyhaní sa objaví v jeho kontextovom okne — chyba typu s názvom súboru a riadkom, neúspešné tvrdenie s očakávanou a skutočnou hodnotou. To agentovi stačí na opravu problému a opätovné spustenie kontroly, znova a znova, až kým neprejde, bez účasti človeka. Práve deterministickosť robí tento cyklus dôveryhodným: rovnaký kód vždy prinesie rovnaký verdikt, takže úspešný výsledok niečo znamená. Nestabilná kontrola tento princíp narúša — agent „opravuje“ kód, ktorý bol v poriadku, alebo opakuje pokusy, až kým neprehliadne skutočné zlyhanie.

Preto sú kvalitné kontroly významnou súčasťou AX kódovej základne. Agent v repozitári s prísnou kontrolou typov, rýchlou súpravou testov a linterom odhalí väčšinu vlastných chýb skôr, než ich uvidíte; agent v repozitári bez týchto nástrojov odošle čokoľvek, čo vytvorí. Rozdiel je najdôležitejší pri behoch počas vašej neprítomnosti, keď sú kontroly jediným overovaním počas behu. Kontrola však zachytí iba to, čo tvrdí. Zelené kontroly znamenajú, že deklarované vlastnosti platia, nie že je kód správny. Medzery vyžadujúce úsudok pokrývajú automatická revízia a ľudská kontrola.

Vyhýbajte sa: „spätnoväzbová slučka“ / „spätný tlak“ — oba výrazy zlievajú kontroly a revíziu. Vyhýbajte sa: „test“ — testy sú automatické kontroly, ale nie všetky automatické kontroly sú testy.

Použitie:

„Agent v behoch počas mojej neprítomnosti stále dodáva pokazený kód.“

„Aké automatické kontroly sú zapojené do sandboxu?“

„Iba jednotkové testy.“

„Pridaj kontrolu typov a linter — agent sa podľa ich výsledkov opraví ešte predtým, než PR vôbec vznikne.“

Agent, ktorý kontroluje prácu iného agenta, často s iným modelom alebo systémovým promptom. Je nedeterministická: vytvára úsudok. Môže bežať kdekoľvek — pred zlúčením pri PR, dodatočne nad históriou commitov alebo uprostred relácie ako podriadený agent. LLM posudzujúci kód v CI predstavuje automatickú revíziu, nie automatickú kontrolu; kategóriu určuje to, čo tvrdenie overuje, nie miesto jeho spustenia.

Funguje práve vďaka oddeleniu od agenta, ktorý na práci robil. Ak požiadate agenta, ktorý kód napísal, aby skontroloval vlastnú prácu, veľa sa nedozviete — relácia, v ktorej vznikla chyba, obsahuje aj uvažovanie, ktoré k nej viedlo, a agent si vlastné závery znovu prečíta ako potvrdenie. Kontrolór s čerstvým kontextovým oknom nemá rovnakú zaujatosť: vidí rozdiel tak, ako by ho videl cudzí človek, a práve na tom kontrola závisí. Iný model alebo systémový prompt určený na revíziu to ešte zlepšuje — iné slepé miesta a prompt zameraný na to, na čom vám skutočne záleží (bezpečnosť, zmluvy API, výkon), namiesto vágneho pokynu „hľadaj problémy“.

Táto kontrola vypĺňa miesto medzi ostatnými úrovňami revízie. Automatické kontroly sú deterministické a zachytávajú to, čo možno overiť mechanicky; ľudská kontrola je nákladná a škáluje sa najhoršie. Automatická revízia je medzi nimi: za cenu strojového behu zachytáva problémy vyžadujúce úsudok — zavádzajúci názov funkcie či prehliadnutý okrajový prípad. Keďže nie je deterministická, môže niečo prehliadnuť alebo označiť neproblém; berte ju ako filter, ktorý zvýši minimálnu kvalitu pred ľudskou kontrolou, nie ako bránu, ktorá ju nahradí.

Vyhýbajte sa: výrazom „AI revízia“ alebo „revízia agentom“ — sú príliš vágne a nerozlišujú túto kontrolu od samotného pracovného agenta.

Použitie:

„Z behov počas neprítomnosti človeka nám chodí priveľa zlých PR.“

„Pred zlúčením pridajte krok automatickej revízie — iný model, samostatný systémový prompt zameraný na bezpečnosť a zmeny zmlúv.“

Používateľ číta kód, ktorý vytvoril agent, a vytvára si o ňom úsudok. Počíta sa čítanie diffu alebo zmenených súborov; čítanie agentovho opisu toho, čo urobil, nie — rozprávanie nie je artefakt. Opis je sekundárny zdroj, ktorý napísala kontrolovaná strana; diff je primárny zdroj a kontrola znamená jeho prečítanie.

Agenti zvyšujú objem vytvoreného kódu, a preto sa kontrola stáva úzkym hrdlom. Užitočným prístupom je vrstviť rôzne stratégie kontroly. Automatické kontroly zachytia mechanické chyby, automatická kontrola odhalí chyby, ktoré sa dajú opísať, a ľudská kontrola zostáva pre to, čo dokážete posúdiť iba vy — či ide o správnu zmenu, či sa prístup hodí do kódovej základne a či to vôbec má existovať.

Kontrola je tiež lacnejšia, keď príde skôr. Prečítať plán pred začiatkom práce alebo malý priebežný diff trvá pár minút; prehrabávať sa dokončenou vetvou po behu bez dozoru trvá dlhšie. Umiestnenie kontrolného bodu je rozhodnutím o človeku v slučke, nie dodatočnou myšlienkou.

Vyhýbajte sa: samotnému výrazu „kontrola kódu“ — nie je jasné, či ide o ľudskú alebo automatickú kontrolu.

Použitie:

„Osobne som skontroloval výstup behu bez dozoru.“

„Prečítali ste diff alebo iba zhrnutie?“

„Diff. V zhrnutí sa písalo, že odstránil nepoužívaný kód — ukázalo sa, že funkciu volal vygenerovaný súbor.“

Spôsob práce, pri ktorom používateľ prijíma kód agenta bez ľudskej kontroly. Rozdiel je nepriehľadný — dôležité je, či sa program správa správne, nie čo obsahuje. Automatická revízia a automatické kontroly môžu stále prebiehať; vibe coding sa k nim nevyjadruje.

Tento výraz vytvoril Andrej Karpathy, ktorý ho zaviedol začiatkom roka 2025: „úplne sa poddáte atmosfére“ a „zabudnete, že kód vôbec existuje“ — opíšete, čo chcete, prijmete výsledok a posúdite ho spustením.

Vibe coding vymieňa kontrolu za rýchlosť. Čítanie rozdielov býva pri práci s agentmi zvyčajne najpomalším krokom, takže jeho vynechaním odstránite hlavné úzke miesto. Pri kóde, ktorého zlyhania majú nízku cenu — prototypy, jednorazové skripty či interné nástroje — je to rozumný kompromis. Riziko rastie s dĺžkou života kódu a závažnosťou jeho dôsledkov.

Cena sa prejaví neskôr. Zmeny vytvorené vibe codingom sa hromadia v kódovej základni, ktorú nikto nečítal, a kontrolovalo sa iba správanie — takže všetko, čo sa správaním neprejaví, zostane neviditeľné. Môže ísť o tajný údaj zapísaný do záznamov, chýbajúci okrajový prípad alebo nenápadne nesprávne spracovanie údajov. Prvýkrát niekto ladí systém zároveň znamená, že niekto prvýkrát číta jeho kód. Keď chýba ľudská kontrola, jedinou bránou pre kód sú všetky zvyšné automatické overenia — testy, typy a automatická revízia. Ak sa rovnaký prístup uplatní na celú kódovú základňu alebo jej časť, ktorej zmeny vytvára softvérová továreň, vzniká temná továreň.

Vyhýbajte sa: používaniu „vibe coding“ ako synonymu pre „nekvalitné programovanie s AI“ — tento výraz označuje postoj ku kontrole, nie výsledný kód.

Použitie:

„Čítal si, čo zmenil v prihlasovacom procese?“

„Vytvoril som to vibe codingom — prihlasovanie stále funguje, to je všetko, čo som skontroloval.“

„Pred odoslaním si prečítaj rozdiel. Keď sa pri prihlasovaní spoliehaš iba na vibe coding, tajné údaje uniknú do záznamov.“

Spoločné chápanie toho, čo sa vytvára — zdieľajú ho používateľ a agent, no je oddelené od akéhokoľvek artefaktu. Pojem pochádza od Brooksa (The Design of Design): rozhovor, artefakty odovzdania práce aj kód sú artefakty, ktoré sa snažia zachytiť návrhový koncept alebo sa k nemu priblížiť, no žiadny z nich ním nie je. Kvalitu návrhového konceptu cítiť na kvalite rozhovoru, v ktorom vznikol.

Pojem pomenúva príčinu známej frustrácie: agent vytvorí presne to, o čo ste požiadali, a napriek tomu je to zlé. Zvyčajne ste si ešte úplne neuvedomili, čo vlastne chcete. Návrhový koncept ešte nebol vo vašej hlave dokončený — prompt zachytil časti, ktoré ste si ujasnili, a o tých nejasných mlčal. Agent vyplnil tieto tichá vlastnými predpokladmi, pretože sa nemal s čím zosúladiť. Nič sa nepokazilo. Zdieľaný návrhový koncept neexistoval, pretože ešte nebol dostatočne ucelený, aby sa dal zdieľať.

Zdieľaný návrhový koncept spoznáte podobne ako pri kolegovi: druhá strana začne odpovedať na nevyslovené otázky tak, ako by ste odpovedali vy. Dovtedy prebieha rozhovor — sokratovský rozhovor je jeho zámernou podobou — a príliš skorá špecifikácia iba zachytí nesúlad do trvácnejšieho artefaktu. Návrhový koncept sa navyše mení, keď sa učíte; artefakty za ním zaostávajú, preto môže špecifikácia verná minulému týždňu stále zavádzať dnešnú reláciu.

Použitie:

„Píše presne to, o čo som žiadal, a aj tak je to nesprávne.“

„Ešte nemáte spoločný návrhový koncept — agent vypĺňa medzery predpokladmi. Rozprávajte sa, kým sa nezhodnete na zrušení, vrátení platieb aj čiastočnom plnení objednávky, a až potom ho nechajte písať špecifikáciu.“

Postup na tvorbu návrhového konceptu s agentom: agent vedie s používateľom sokratovský rozhovor, v ktorom navrhuje odporúčanú odpoveď na každé rozhodnutie zvlášť. Spomaľuje unáhlený postup k hotovému plánu — artefakt odovzdania sa napíše až vtedy, keď sa koncept ustáli.

Tento postup existuje preto, že agenti potichu dopĺňajú medzery. Ak majú z dvojriadkového zadania napísať špecifikáciu, nezastavia sa pri rozhodnutiach, ktoré ste neurobili — zvolia predvolené možnosti a zapíšu ich. Výsledok vyzerá úplne, no odhadnuté možnosti sa nedajú odlíšiť od vašich rozhodnutí. Zistíte to neskoro: pri revízii alebo až vtedy, keď hotová funkcia rieši okrajový prípad spôsobom, ktorý ste nikdy nezvolili. Tento postup to obracia — namiesto hádania musí agent klásť otázky.

Ide o postup, v ktorom je človek súčasťou cyklu: vstupom sú vaše odpovede. Ak sa na otázku nedá odpovedať v rozhovore — museli by ste si vec najprv pozrieť — prejdite k prototypovaniu.

Použitie:

„Rovno začal písať špecifikáciu a nesprávne vyriešil logiku zrušenia.“

„Najprv ho vyspovedajte — nech sa vás opýta na čiastočné zrušenia, vrátenie peňazí a načasovanie, skôr než čokoľvek zapíše do dokumentu. Vyriešiť to v rozhovore je lacnejšie než v kóde.“

Nechať agenta vytvoriť rýchlu, hrubú verziu niečoho v situácii, keď je rozhovor príliš nepresný a potrebujete skutočný artefakt, o ktorom sa dá hovoriť.

Sokratovský rozhovor pomáha vyriešiť návrhové rozhodnutia v konverzácii. Rozhovor je lacný, no má nízku vernosť: na niektoré otázky sa nedá odpovedať slovami — aký je pocit z interakcie, či sa API pohodlne používa v skutočnom kóde alebo či rozloženie funguje pri reálnom objeme dát. Pri rozhovore narazíte na otázku a úprimná odpoveď znie: „Neviem, musel by som to vidieť.“ Potom sa diskusia začne točiť v kruhu. Namiesto toho nechajte agenta vytvoriť prototyp, prezrite si ho a vráťte sa k rozhovoru s odpoveďou.

Agenti znižujú cenu tvorby, vďaka čomu je tento postup praktický. Hrubá verzia, ktorej vytvorenie kedysi trvalo deň, vznikne za pár minút, takže sa oplatí robiť to pravidelne. Je to technika človeka v slučke: prototyp slúži na to, aby ste naň mohli reagovať.

Zvyčajne sa nezastavíte pri jednom prezretí. Pracujte s prototypom iteratívne — zareagujte, požiadajte o zmenu a zareagujte znova — aby každé kolo vyriešilo ďalšie rozhodnutie nad skutočným artefaktom a s vyššou vernosťou, než umožňuje rozhovor.

Prototyp nemusí byť celý narýchlo zbúchaný. Časti, ktoré hodnotíte, môžete vytvoriť v produkčnej kvalite, takže keď padne rozhodnutie, komponent alebo API, na ktoré ste reagovali, možno preniesť do skutočnej kódovej základne. Preto je prototypovanie dôležitým podkladom, na ktorý sa môže odvolávať špecifikácia.

Použitie:

„Už pol hodiny sa hádame, či má byť sprievodca na jednej stránke alebo v troch krokoch.“

„Slovami to nevyriešime — nechajte agenta vytvoriť oba prototypy. Preklikáme si ich a za päť minút budeme vedieť.“

Skúsenosť vývojárov — miera, do akej kódová základňa a jej nástroje uľahčujú ľuďom kvalitnú prácu. Dobrá DX znamená rýchlu spätnú väzbu, zrozumiteľné chybové hlásenia, dokumentáciu, ktorá odpovedá na skutočnú otázku, a nastavenie fungujúce hneď na prvý pokus. Tento pojem existuje dávno pred vývojom s AI; v tomto slovníku slúži najmä ako kontrast k AX.

DX opisuje interakciu človeka s kódovou základňou — nič viac. Hlavný rozdiel medzi týmito dvoma skupinami používateľov je, že ľudia majú stav, kým agenti sú bezstavoví. Človek sa naučí pracovať s kódovou základňou a tieto znalosti si prenáša do každého ďalšieho dňa. Preto sa dá so zlou DX prežiť: pomalé CI obíde tým, že spojí viacero pushov, chýbajúcu dokumentáciu tým, že sa raz opýta na Slacku, a neprehľadnú štruktúru tým, že si zapamätá, kde čo je. Tieto obchádzky sa hromadia a tím zostáva produktívny aj v kódovej základni, ktorá mu prácu sťažuje.

Agenti pracujú s tou istou kódovou základňou bez takto nahromadených znalostí. Keďže medzi reláciami nemajú stav, zakaždým sa s ňou oboznamujú od začiatku. Pomáha im rýchla sada testov a jasné chybové hlásenia, no všetko, na čo prišli včera, sa stratí, pokiaľ sa to nezapísalo do prostredia. Agent ho vníma len prostredníctvom výsledkov nástrojov. Práve tento rozdiel pomenúva AX: tie časti DX, ktoré fungujú aj vtedy, keď vývojárom je agent, a tiež potreby, ktoré ľudia nemajú, napríklad udržiavanie voľného miesta v kontextovom okne.

Prekryv znamená, že investície do DX často bez ďalšej práce zlepšia aj AX — prísne typy, rýchle testy a predvídateľná štruktúra pomáhajú obom. Rozdiely však znamenajú, že to neplatí vždy: kvalitná príručka pre nových zamestnancov pomáha človeku prvý týždeň, no agentovi vôbec, pokiaľ nie je dostupná cez AGENTS.md.

Použitie:

„Naša DX je v poriadku — noví zamestnanci sú produktívni už po týždni.“

„Produktívni sú preto, že s nimi niekto celý týždeň sedí. Agent taký týždeň nemá; AX treba posúdiť osobitne.“

Skúsenosť agenta — to, ako dobre je prostredie pripravené na to, aby agent odviedol kvalitnú prácu v kódovej základni. Ide o náprotivok DX z pohľadu agenta. Keď ten istý agent pracuje dobre v jednom repozitári a zle v inom — s rovnakým modelom aj rovnakým riadiacim prostredím — príčinou býva zvyčajne AX. Prvým impulzom je obviniť model alebo prepísať prompt; riešenie sa však častejšie nachádza v repozitári.

Dobrá AX má tri hlavné rozmery:

AX a DX sa prekrývajú — kvalitné kontroly a čistá architektúra pomáhajú obom skupinám — ich potreby sa však rozchádzajú. Ľudia tolerujú neformálne tímové znalosti, pomalé CI aj pokyn „spýtaj sa Sarah na fakturačný modul“; agenti nie. Agentom nepomáhajú nápovedy v IDE ani pekné panely; potrebujú chybové hlásenia ako text vo výsledku nástroja. Kódová základňa môže ponúkať dobrú DX a pritom zlú AX.

Vyhýbajte sa: považovaniu AX za synonymum DX — obe skupiny potrebujú odlišné investície.

Použitie:

„Agent píše skvelý kód v repozitári API a hrozný kód vo frontende.“

„Repozitár API má prísnu kontrolu typov a rýchlu súpravu testov; frontend nemá ani jedno a má štyridsať zručností, ktoré sa vždy načítavajú. To je nedostatok AX, nie problém modelu.“

Systém práce, v ktorom sa relácie agentov spúšťajú na základe podnetov — vytvorenia tiketu, naplánovaného času, zlyhania CI či ukončenia inej relácie — nie na pokyn človeka. Vďaka tomu viac práce prebieha počas neprítomnosti človeka a ľudská pozornosť sa venuje zostávajúcim rozhodnutiam, pri ktorých je človek súčasťou cyklu.

Bez továrne sa každá relácia začne preto, že ju niekto spustí. Aj úplne automatizovaná práca čaká na človeka, ktorý otvorí reláciu, nasmeruje ju na tiket a spustí ju. Tímy chcú dodávať viac, než im to umožňuje. Továreň odstraňuje človeka zo spúšťania relácií, ale nie nevyhnutne z ostatných činností.

Bežné spúšťače a relácie, ktoré začínajú:

Továreň nemusí pokrývať celý softvérový proces. Jedna cron úloha, ktorá spustí jeden druh relácie a otvorí jedno PR vhodné na kontrolu, už tvorí továreň. Začať takto v malom je užitočné: úzky cyklus vytvára malé a podobné PR a ich kontrola ukáže, do akej miery sa dá cyklu dôverovať, než ho rozšírite.

Ľudia môžu byť v továrni zapojení kdekoľvek — písať a označovať tikety, ktoré spúšťajú relácie, schvaľovať plán pred začiatkom implementácie alebo vykonávať ľudskú kontrolu pred zlúčením. Hlavnou návrhovou otázkou je, ktoré z týchto rozhodnutí zostanú v rukách ľudí. Kódová základňa alebo jej časť, ktorej výstupy nikto nekontroluje, je temná továreň.

Použitie:

„Kto opravil všetky porušenia pravidla `no-floating-promises`?“

„Továreň. Cron úloha každú noc vyberie jedno pravidlo lintera a otvorí PR. Ráno ho už iba skontrolujem.“

Kódová základňa alebo jej časť, v ktorej kód píše softvérová továreň a nečíta ho žiadny človek. Neexistuje ľudská kontrola. Ľudia môžu stále písať zadania, ktorými sa práca začína. Výsledný kód však nikto nečíta. Názov pochádza z tovární s „vypnutým osvetlením“, v ktorých sa vyrába bez prítomnosti ľudí na pracovisku.

Temná továreň je vibe coding pre oblasť kódu, nie pre jednu zmenu. Keď robíte vibe coding, rozhodnete sa nečítať zmenu, o ktorú ste požiadali. Viete však, že táto zmena existuje. V temnej továrni sa tím takto rozhodne raz pre celú oblasť. Potom už žiadny človek nežiada o jednotlivé zmeny ani ich nevidí. Zmeny prichádzajú tak rýchlo, ako spúšťače začínajú novú prácu.

Problém sa ukáže, keď sa niečo pokazí. Neviete, čo sa zmenilo, pretože zmeny nikto nečítal. Musíte ladiť kód, ktorý si nikto z tímu neprečítal. Príčina môže byť v ktorejkoľvek z mnohých zmien a každá z nich prešla kontrolami.

Jedinými bránami sú automatické kontroly a automatická revízia. Ak problém neodhalia, dostane sa do kódu.

Vyhýbajte sa: označovať kódovú základňu za „temnú“ iba preto, že jej továreň beží bez dozoru. Ak relácie agenta bežia počas vašej neprítomnosti a človek kontroluje ich PR, ide o softvérovú továreň. Nie je to temná továreň.

Použitie:

„Kto zmenil logiku opakovaných pokusov v fakturačnej službe? Nikto z tímu si na to nespomína.“

„Fakturačná služba je temná továreň. Agenti zlučujú všetky zmeny, ktoré prejdú CI. Túto zmenu nikto nečítal.“