Context engineering: dovednost, která nahradila prompt engineering

Ještě loni jsem na školeních trávil půlku času tím, jak lidem ukazoval 'kouzelné' formulace promptů. 'Act as a senior engineer.' 'Think step by step.' 'Take a deep breath.' Fungovalo to — trochu. Dneska už tyhle triky nikoho nezajímají, protože přestaly dělat rozdíl. Modely jsou tak dobré, že přesná slova skoro neřeší.

Co řeší, je kontext. Jestli AI dostane ty správné soubory, konvence projektu, architekturu a omezení — nebo ne. Tomuhle se říká context engineering a je to dovednost, která v roce 2026 odděluje lidi, kterým AI reálně zrychluje práci, od těch, co si pořád stěžují, že 'to generuje nesmysly'.

Proč na formulaci promptu přestalo záležet

Prompt engineering vznikl v době, kdy byly modely křehké. Špatně formulovaná otázka znamenala špatnou odpověď, takže se vyplácelo pilovat každé slovo. Ale modely se posunuly. Dnešní agent pochopí, co chcete, i když to napíšete ledabyle — pokud má dost informací k tomu, aby to udělal správně.

A tady je jádro problému. Když agent selže, málokdy je to proto, že jste to špatně naformulovali. Skoro vždycky je to proto, že neznal váš kód. Nevěděl, že máte vlastní error handler a nemá psát try/except. Nevěděl, že používáte konkrétní verzi knihovny. Nevěděl, že podobnou funkci už máte napsanou o tři složky vedle. Chytřejší prompt tohle nevyřeší — chybí mu totiž informace, ne instrukce.

Co vlastně 'kontext' pro coding agenta znamená

Kontext není jen text vašeho promptu. Je to všechno, co má agent v kontextovém okně ve chvíli, kdy začne pracovat. A skládá se z několika vrstev, které se snadno přehlédnou.

• Relevantní soubory — konkrétní zdrojáky, kterých se změna týká, plus ty, na které navazují
• Konvence projektu — instrukční soubor (CLAUDE.md, rules), styl kódu, pojmenování, patterny
• Architektura — jak spolu vrstvy komunikují, kde jsou hranice, co je kde zodpovědné
• Dřívější rozhodnutí — proč to je postavené takhle a ne jinak (ADR, komentáře, historie)
• Omezení — co se nesmí měnit, jaké verze, jaké bezpečnostní a výkonnostní požadavky

Když agent některou z těchto vrstev nemá, doplní si ji dohadem. A dohad zkušeného modelu vypadá naprosto sebejistě — proto je tak nebezpečný. Kód projde review, protože 'vypadá správně', a problém se objeví až v produkci.

Konkrétní taktiky, které fungují

1. Kurátorujte soubory, nezahlcujte

Nejčastější chyba je hodit do kontextu 'radši všechno'. Deset souborů, kde jsou relevantní tři, není víc kontextu — je to víc šumu. Model musí najít podstatné mezi nepodstatným a jeho pozornost se rozmělní. Dejte mu přesně ty soubory, které task potřebuje, a nechte ho, ať si dotáhne zbytek sám.

2. Mějte instrukční soubor projektu

CLAUDE.md (nebo ekvivalentní rules soubor) je nejlevnější context engineering, jaký existuje. Napíšete konvence jednou a agent je má v každé session. Stack, příkazy, pojmenování, 'vždycky dělej X, nikdy Y'. Držte to stručné — pár desítek reálných pravidel, ne stostránkový manuál, který stejně nikdo nedodrží.

# CLAUDE.md — kontext, který agent potřebuje

## Stack
Django 5.2, Django Ninja, PostgreSQL

## Konvence
- Globální ObjectDoesNotExist handler — žádné try/except boilerplate
- select_related/prefetch_related na každém querysetu s relacemi
- Všechny API URL končí lomítkem (/)

## Nikdy
- Neměň schema migrace, které už jsou nasazené
- Nepřidávej závislosti bez souhlasu

3. Používejte retrieval a MCP pro živá data

Statický kontext nestačí, když agent potřebuje aktuální stav — schéma databáze, dokumentaci knihovny, tikety, historii chyb. MCP servery a retrieval nástroje mu umožní si tyhle informace natáhnout, když je potřebuje, místo abyste je předvídali a lepili do promptu. Kontext se tak stává dynamickým: agent si dojde pro to, co mu chybí.

4. Zužte zadání

'Předělej auth' je špatný kontext, protože je to špatně ohraničený úkol. 'Přepiš login endpoint v auth/views.py na JWT, ponech stávající signaturu, spusť testy v auth/tests.py' dává agentovi jasné hranice. Čím ostřejší scope, tím menší prostor pro dohady — a tím míň nechtěných změn v souborech, kterých se to nemělo týkat.

Časté způsoby, jak to pokazit

• Příliš mnoho nerelevantního kontextu — zahlcení šumem, ve kterém se ztratí podstatné
• Zastaralý kontext — session tažená z minulého úkolu, staré soubory, mrtvé přístupy
• Chybějící omezení — agent neví, co nesmí, tak to změní; nezná verze, tak použije špatné API
• Předpoklad, že model 'ví' váš projekt — nezná ho, dokud mu ho neukážete

Zastaralý kontext je nejzáludnější. Když s agentem řešíte třetí task ve stejné session, nese si s sebou balast z prvních dvou — soubory, které už nejsou relevantní, a slepé uličky, které aktivně kazí další pokus. Nový úkol? Nová session. Čistý kontext skoro vždy porazí nafouklý.

Praktický workflow

Když si context engineering rozložíte do rutiny, přestane to být tajemná dovednost a stane se z toho pár kroků, které uděláte skoro automaticky.

• 1. Ohraničte úkol — jedna jasná změna, ne 'oprav všechno'
• 2. Vyberte soubory, kterých se to reálně týká, a přidejte je do kontextu
• 3. Ověřte, že konvence a omezení jsou v instrukčním souboru
• 4. Nechte agenta popsat plán a zkontrolujte, jestli má správný obrázek
• 5. Nechte ho pracovat s feedback loopem — spusť testy, oprav chyby
• 6. Před dalším nesouvisejícím úkolem vyčistěte session

Context engineering není hype ani další buzzword. Je to prosté přesunutí pozornosti od toho, jak mluvíte s AI, k tomu, co jí dáváte k práci. Tuhle disciplínu učím na svých workshopech na reálném kódu týmů — protože jakmile ji jednou zvládnete, přestanete bojovat s promptem a začnete AI reálně řídit.