Váš AI si váš produkt jen domýšlí

Proč výsledek tak kolísá

Stejný prompt, odeslaný stejnému modelu, s rozdílem šedesáti sekund.

Prompt: „Napiš akceptační kritéria pro ticket: uživatel může konfigurovat nastavení poskytovatele AI."

První pokus — bez kontextu: výstup je obecný seznam. „Uživatel může vybrat poskytovatele AI z rozbalovacího seznamu. Uživatel může uložit nastavení. Uživatel vidí potvrzovací zprávu." Mohl by to být jakýkoliv produkt, jakákoliv platforma, jakékoliv desetiletí. Formálně není nic špatně. Prakticky to není k ničemu.

Druhý pokus — s kontextem produktu: výstup odkazuje na administrátorské stránky Jira Cloud, oprávnění Forge resolveru, validaci API klíčů pro každého poskytovatele (OpenAI, Anthropic, Google, Mistral, xAI), chování datového rozsahu na úrovni organizace vs. projektu a na zápis podmíněný licencí. Specifikuje, že nastavení se uchovávají přes @forge/sql a že UI používá Atlaskit komponenty s xcss tokeny. Zní to, jako by to napsal někdo, kdo v té kódové základně skutečně pracoval.

Model se nezměnil. Teplota se nezměnila. Změnil se vstup. Tato propast — mezi obecným a konkrétním — je celým tématem tohoto článku.

Když se AI výstup zdá nekonzistentní, první instinkt je vinit model: změnit poskytovatele, upgradovat tier, upravit teplotu. Téměř vždy je to špatná páka.

Každý prompt začíná od nuly. Model nemá žádnou paměť o vašem produktu, uživatelích, omezeních ani posledním rozhovoru, dokud tyto informace explicitně nezadáte. „Napiš akceptační kritéria" znamená něco úplně jiného pro Jira-nativní Forge aplikaci pro inženýrské týmy o deseti až sto lidech než pro spotřebitelský mobilní fitness tracker.

Model odpovídá na svět, který mu popíšete. Pokud nepopíšete nic, vymyslí si vlastní — a ten je vaší realitě zřídkakdy podobný.

Proto mohou dva lidé ve stejném týmu používat stejný model a získat zcela odlišné výsledky. Není to otázka dovedností. Není to struktura promptu. Je to otázka, zda model dostal dost produktové reality, se kterou by mohl pracovat.

Pokud chcete širší rámec toho, proč to v Jira způsobuje tak drahé chyby, začněte s: AI neopravuje špatně sladěné týmy. Skrývá je.

Řešením není lepší technika promptování. Je jím vybudování znovu použitelné kontextové vrstvy — kompaktní a upřímný popis světa produktu — který se přikládá před každým promptem. Napíšete ho jednou. Používáte ho všude. Model přestane hádat a začne pracovat se stejnými omezeními, se kterými pracuje váš tým.

Čtyři vrstvy

Kontext produktu není jeden velký kus textu. Přirozeně se rozpadá do čtyř vrstev, z nichž každá dělá jiné dílo.

• Shrnutí produktu popisuje, co produkt dělá, pro koho a jaké výsledky jsou důležité — provozní pravda, nikoliv marketingový text. Rozdíl je zásadní. „Nástroj pro správu projektů pro týmy" může popisovat cokoliv. „Just je Jira-nativní AI copilot pro produktové a inženýrské týmy na Jira Cloud. Hlavní úkol: přeměnit nejednoznačné Jira issues ve strukturované plány realizace — upřesnění, krokové plány a zápis zpět do polí Jira — aniž byste opustili panel issue. Není to chatbot. Není to samostatný nástroj. Postaveno na Atlassian Forge." popisuje přesně jeden produkt.
• Cílová skupina popisuje, kdo jsou uživatelé, co potřebují, co očekávají a co nevědí.
• Designový jazyk popisuje vizuální vzory, komponentovou knihovnu, interakční návyky a věci, které nikdy neděláte.
• Stack a omezení popisuje reálné frameworky, limity prostředí, integrace a explicitně zakázané volby.

Špatná verze každého pole odpovídá tisícům produktů. Ta dobrá odpovídá přesně jednomu. To je test.

Cílová skupina — místo, kde obecný kontext selhává

Cílová skupina je obvykle první pole, které týmy příliš zjednodušují. „Product manažeři a vývojáři" zní rozumně. Je to ale příliš vágní na to, aby modelu pomohlo dělat lepší rozhodnutí.

Užitečné pole cílové skupiny je konkrétní ohledně složení týmu, obeznámenosti s AI, očekávání důvěryhodnosti a toho, co uživatelé nechtějí. Pro Just to znamená PMs a senior inženýry v týmech Jira Cloud čítajících 10–100 lidí, se střední obeznámeností s AI, kteří spravují vlastní API klíče a záleží jim více na spolehlivém výstupu než na efektním.

Řádek „Není pro" je stejně důležitý. Říct, že to není pro týmy mimo Jira Cloud ani pro uživatele, kteří chtějí plně autonomní agenty, předem eliminuje celé kategorie chybných předpokladů.

Právě to dělá kontext zakotveným spíše než dekorativním. Modelu není jen řečeno, kdo je uživatel. Zároveň je mu vysvětleno, v jakém světě tento uživatel funguje a jaké typy workflow by se cítily špatně.

Vytěžte to, co už existuje

Většina týmů má všechny čtyři kontextové vrstvy k dispozici — jsou jen roztroušeny po kódové základně, designových souborech, dokumentaci a týmové paměti, místo aby byly v podobě, kterou může AI použít.

Z vašeho repozitáře: nasměrujte coding agenta — Claude Code, Codex nebo podobné — na vaši kódovou základnu a požádejte o markdown shrnutí pokrývající účel produktu, stack, hranice implementace a známá omezení. Dobře strukturovaný repozitář vyprodukuje použitelný první návrh během minut.

Z designových souborů: identifikujte název komponentové knihovny, tři až pět klíčových interakčních vzorů, na které se váš produkt spoléhá, a tři věci, které UI nikdy nedělá. Anti-patterny jsou stejně důležité jako patterny.

Z existující dokumentace: onboardingové poznámky, README soubory, interní briefy nebo marketingové podklady mohou poskytnout fragmenty shrnutí produktu a definice cílové skupiny. Nemusí být dokonalé, aby byly užitečné.

Z vlastní hlavy: pokud nic z výše uvedeného ještě neexistuje, otevřete prázdný dokument a napište hned teď jeden odstavec pro každé pole. Bude to nedokonalé. Nedokonalý kontext je bezkonkurenčně lepší než žádný.

Nepotřebujete dokonalou dokumentaci. Potřebujete kompaktní a upřímný popis světa, ve kterém váš produkt žije.

Uložte jednou, používejte všude

Kontext se vyplatí jen tehdy, když je znovu použitelný. Napsat ho jednou a vložit do jediné session pomáhá té session. Učinit ho trvalým pomáhá každé session.

• V Just má administrátorský panel vyhrazenou sekci pro každé ze čtyř kontextových polí — Shrnutí produktu, Cílová skupina, Designový jazyk a Stack. Obsah do každého pole vložíte jednou za projekt. Každý budoucí insight, upřesnění, plán a krok realizace v tomto projektu bude tímto kontextem automaticky podložen.
• Pokud Just nepoužíváte, vytvořte jeden soubor context.md v kořeni vašeho repozitáře nebo ve sdílené dokumentaci. Strukturujte ho do stejných čtyř sekcí. Vkládejte ho na začátek každé AI session — coding asistenti, chat nástroje, generátory dokumentů. Formát je méně důležitý než návyk: nejdřív kontext, pak prompt.

Přistupujte ke kontextové vrstvě jako k živému dokumentu, ne jako k artefaktu z dne spuštění. Revidujte ji, když se produkt výrazně změní — nová integrace, zásadní posun cílové skupiny, migrace designového systému. Nerevidujte ji každý sprint. Pokud se vaše shrnutí produktu mění každé dva týdny, není to shrnutí produktu — jsou to poznámky ze schůzky.

Kontext není prompt engineering

Kontext produktu není prompt engineering. Není to trik, šablona ani chytrý hack. Je to dát modelu stejný briefing, jaký byste dali novému externistovi první den: tady je, co stavíme, pro koho, jak by to mělo vypadat a na čem to běží.

Týmy, které to udělají jednou — a důsledně to znovu používají — dostávají výstupy, které vypadají, jako by přišly od někoho, kdo produktu skutečně rozumí. Protože ve všech funkčních ohledech tomu tak je. Model nebyl chytřejší. Vy jste mu jen přestali říkat, aby házel.