Ze software engineeringu do context engineeringu

Programuju pořád. Jen většinu času neřeším kód

Posledních pár let dělám něco, co se navenek tváří jako vývoj software, ale uvnitř je to jiná disciplína. Pořád čtu kód, pořád rozumím architektuře. Ale velkou část dne netrávím psaním funkcí — trávím ji tím, že řídím kontext, ve kterém AI pracuje. Tomu říkám posun ze software engineeringu do context engineeringu.

Není to slogan. Je to změna toho, kde leží práce. Dřív byla hodnota v tom, jak rychle a čistě napíšu řešení. Dnes je čím dál víc v tom, jak dobře dokážu předat stroji kontext naší domény, našich konvencí a našich hranic — a jak to změřím.

A hned na začátku jedna věc, ať není pochyb: AI je nástroj, ne náhrada. Posiluju tým, nenahrazuju ho. Tenhle text není o tom, že vývojáře nahradí agent. Je o tom, že se mění řemeslo.

Co je context engineering v praxi

Context engineering je řízení toho, co AI dostane k dispozici, než začne pracovat. Anthropic to popisuje jako „strategii pro kurátorování optimální množiny tokenů během inference“. V praxi to pro tým znamená pět věcí:

• Instrukce — verzované soubory v repu (copilot-instructions.md, AGENTS.md, CLAUDE.md), které popisují konvence, stack a co se nesmí. Reviewujeme je jako kód.
• Skills — opakovatelné postupy (napsat PR description, vygenerovat arch dokumentaci) jako přenositelné SKILL.md, ne jako prompt, který si pamatuju v hlavě.
• MCP servery — most mezi agentem a vašimi systémy: specifikace v Confluence, ticket v Jiře, schéma databáze — just-in-time, ne nacpané natvrdo.
• Data / grounding — kurátorovaný kontext (Spaces, retrieval) místo „tady máš celý monorepo, poraď si“.
• Měření — bez čísel je to víra. DORA metriky, podíl mergnutých AI návrhů, čas na review. Co neměřím, neumím obhájit ani zlepšit.

Klíčový pojem je context rot: čím plnější okno, tím horší recall. Víc kontextu ≠ lepší kontext. Disciplína je v kurátorování, ne v nacpání všeho.

Proč to je víc než ladění promptů

Nejčastější frustrace s AI, kterou slyším, není „AI je hloupá“. Je to „skoro správně, ale ne úplně“ — vygeneruje komponentu se špatnou state knihovnou, špatným importem, naming, co nesedí. A pak strávím víc času opravováním almost-right kódu, než kdybych to napsal sám.

Lidi na to typicky reagují tím, že vylepšují prompt. Přidají „prosím použij naše konvence“, „buď přesný“. Pomáhá to minimálně. Protože problém nebyl v tom, co jsem řekl, ale v tom, co jsem poskytl.

Prompt engineering = co AI řeknu. Context engineering = co AI dám.

Když stejný prompt pustím dvakrát — jednou bez kontextu, jednou s instruction filem, který popisuje náš stack — dostanu dva úplně jiné výstupy. Nezměnil jsem prompt. Změnil jsem kontext. A tady je ta evidence: almost-right výstup nezachráníte lepší formulací. Zachráníte ho lepším groundingem.

Čím se to liší od „prostě používám Copilot / ChatGPT“

„Používáme Copilot“ obvykle znamená: každý vývojář si sám chatuje s autocomplete, bez sdíleného kontextu, bez měření, bez záruk. Funguje to pro snippety. Nefunguje to pro tým a neškáluje to.

Context engineering je rozdíl mezi:

• ad hoc — každý si promptuje po svém, kvalita kolísá člověk od člověka;
• disciplína — sdílené verzované instrukce, skills v repu, guardrails přes CODEOWNERS a code review, MCP napojené na vaše zdroje pravdy, a metriky, které ukážou, jestli to vůbec pomáhá.

Druhá věc, která mě baví: investice je přenositelná. Nástroje se za rok vymění. Ale dobře napsaný SKILL.md nebo instruction file přežije migraci z jednoho coding agenta na druhý. Neinvestujte do nástroje, investujte do kontextu.

A nezapomínejte na guardrails — člověk vlastní výstup. AI navrhne, vývojář schválí. To není jen dobrá praxe, je to i směr, kterým tlačí regulace typu EU AI Act: dohledatelnost a lidská odpovědnost za rozhodnutí.

Čtyři věci, které tým může udělat tento týden

Žádný velký rollout. Malé, zero-risk kroky na čistém kódu, ne na legacy:

1. Založte copilot-instructions.md (nebo AGENTS.md). Deset řádků: stack, konvence, co se nesmí. Commitněte do repa.

   # Konvence projektu
   - State management: Zustand (NE Redux)
   - Komponenty: funkční, TypeScript strict
   - Testy: Vitest, povinné u nové business logiky
   - NIKDY needituj soubory v /generated
   

2. Vyberte jeden nudný opakovaný úkol a udělejte z něj skill. PR descriptions nebo generování testů. Nízké riziko, vidíte výsledek hned, a tým si osahá, jak skill vypadá.

3. Napojte jeden MCP server na váš zdroj pravdy. Nejčastěji Confluence/Jira/DB schéma. Cíl: agent si tahá specifikaci just-in-time místo halucinací.

4. Změřte jedno číslo před a po. Třeba podíl AI návrhů, co projdou review bez velkého přepisu. Bez baseline nevíte, jestli si pomáháte, nebo si jen hrajete.

Závěr

Context engineering není magie a není to ani trik na lepší prompt. Je to disciplína: kurátorování kontextu, verzování instrukcí, napojení na vaše data a poctivé měření. Nudné, opakovatelné, reviewovatelné.

Začněte malým krokem tento týden — jedním instruction filem, jedním skillem. Za měsíc nechcete „setup od konzultanta“. Chcete vlastní kit instrukcí a skills, který si sami reviewujete jako kód. To je ten posun.