AI nesehraný tým nespraví. Jen to zamaskuje.

Problém s džinem

Když přemýšlím o AI, pořád se vracím k jednomu obrazu. AI je džin. Udělá přesně to, co řekneš, ne to, co jsi měl na mysli. A právě v té mezeře se překvapivě často rozpadá doručování softwaru.

Tu situaci znáš. Produktový člověk řeší čtyři věci najednou a během dvou minut napíše ticket do Jira. Není záměrně špatný. Je jen vágní, uspěchaný, neúplný a plný předpokladů, které nikdo nevyslovil nahlas.

Vývoj si ho převezme, postaví něco rozumného z těch slov, která v něm jsou, a o dva týdny později všichni sedí na review a říkají nějakou variantu věty: tohle jsem ale nemyslel.

Nikdo nelhal. Nikdo se neflákal. Jen se původní záměr nikdy nepojmenoval dostatečně jasně ještě před začátkem práce. S AI je tahle verze problému ještě tvrdší, protože model nemá žádný týmový kontext, který by mezery doplnil. Když ticket skoro žádný kontext nenese, džin pracuje skoro z ničeho.

Nejslabší artefakt

Zkus se zamyslet, kde vlastně žije skutečné poznání o produktu. Kódová báze zná architekturu, pojmenování, závislosti i hranice implementace. Návrhové soubory znají vizuální jazyk, vzory interakcí i rozhodnutí, která jste opakovali tak dlouho, až se z nich stal systém. Starší tickety a dokumentace znají slovník týmu a způsob, jak obvykle formulujete kompromisy.

Jira ticket nezná skoro nic z toho. Často je to nejchudší artefakt na kontext v celém stacku. Když tedy tým vloží ticket do AI nástroje a čeká kvalitní výstup, ve skutečnosti chce skvělou odpověď z nejméně informativního vstupu, který má k dispozici.

Proto výstup tak často zní uvěřitelně, ale zároveň sedí špatně. Akceptační kritéria počítají s jiným uživatelem. Návrhy designu uhýbají k vizuálnímu stylu, který byste nikdy nevydali. Technická doporučení ignorují váš stack, způsob nasazení nebo zkratky, které tým záměrně nepoužívá. AI tady „neselhává“. Jen dělá maximum s mizerně zadaným vstupem.

Sebejistý nesmysl

Většina AI nástrojů pro Jira má podobný tvar. Otevřeš issue. Klikneš na tlačítko. Dostaneš popis, akceptační kritéria a možná rozpad na podúkoly. Působí to produktivně, protože výsledek je rychlý, čistý a uspořádaný.

Obvykle to vypadá takto:

• otevřeš issue;
• klikneš na tlačítko;
• dostaneš upravený text, kritéria a možná podúkoly.

Jenže struktura není totéž co sladění. Pokud byl vstup vágní a bez kontextu, výstup je jen sebejistější verzí stejné nejednoznačnosti. V praxi může nástroj problém ještě zhoršit, protože uhlazená forma lidi odradí od toho, aby před startem práce zpochybnili původní předpoklady.

Právě v tom je tiché nebezpečí: odpad dovnitř, odpad ven, jen teď má ten odpad nadpisy, odrážky a tón jistoty. Tým se tak může pustit do realizace současně s větší sebedůvěrou a menší jasností.

Co AI doopravdy potřebuje

Než může AI vytvořit něco skutečně užitečného pro issue v Jira, musí rozumět čtyřem věcem o světě, ve kterém pracuje:

• Vašemu produktu: co dělá, jaké výsledky jsou důležité a co má daná funkce zlepšit pro uživatele i byznys.
• Vašemu designovému jazyku: vizuálním vzorům, knihovně rozhraní a zvyklostem v interakci, díky nimž výstup působí jako součást vašeho produktu, ne jako generická ukázka.
• Vašemu publiku: kdo tito uživatelé jsou, co potřebují, co čekají a co nevědí. To mění formulace, interakční návrh i hraniční případy téměř u každé funkce.
• Vašemu stacku: skutečným frameworkům, hranicím běhového prostředí, integracím, datovým omezením a technickým limitům, které mají určovat, co je ještě validní návrh.

Zajímavé je, že většina týmů už to všechno má. Je to v kódu, dokumentech, návrzích i v týmové paměti. Jen to není v Jira v podobě, kterou AI dokáže vidět. Proto jsou nástroje, které se dívají jen na Jira, slepé vůči nejdůležitějšímu kontextu projektu.

Jestli chceš praktickou podobu takové kontextové vrstvy, vaše AI si váš produkt jen domýšlí rozebírá, co ukládat a jak to znovu používat.

Váš kód ví víc

Jedna z opravdu silných věcí na dnešních coding agentech je ta, že umějí velmi dobře číst repozitář a převádět ho do srozumitelného kontextu. Můžeš nasměrovat Claude Code, Codex nebo jiného schopného agenta na svůj repozitář a požádat ho o markdown shrnutí: k čemu produkt slouží, jaký má stack, kde jsou hranice implementace, jaké jsou známé mezery a jaké obchodní signály už jsou vidět. Zabere to minuty, ne týden dokumentace.

Tím se mění celá rovnice. Místo toho, aby AI generovala něco z dvouvětého ticketu ve vakuu, dostane opřený souhrn produktu, design systému, publika a stacku. Model už pak neimprovizuje potmě. Uvažuje uvnitř světa, který vašemu projektu opravdu odpovídá.

Odpovědi v sobě váš kód nesl celou dobu. Názvy komponent prozrazují designový jazyk. Doménové modely ukazují, jak produkt přemýšlí. Integrace a knihovny vysvětlují technické hranice. Kontext není potřeba vymýšlet od nuly. Je potřeba ho vytáhnout do formátu, který jiná AI umí spolehlivě použít.

Skrytá rozhodnutí

I s výborným projektovým kontextem zůstává druhý problém, který AI nevyřeší odhadem: rozhodnutí, která ještě nikdo neudělal. Každé issue v Jira v sobě nese skryté předpoklady o oprávněních, pravidlech rolloutů, hraničních případech, zpětné kompatibilitě, detailech interakce i o tom, jak vlastně poznat úspěch ve chvíli, kdy funkce dorazí k reálným uživatelům.

Tato rozhodnutí nezmizí jen proto, že se práce rozběhne. Jen se znovu vynoří uprostřed sprintu, tedy v nejdražší možný okamžik. Designér se ptá, která existující obrazovka je referenční. Vývojář potřebuje vědět, zda pro tento tok už existuje API. Někdo si uvědomí, že akceptační kritéria počítala s přihlášenými uživateli, zatímco polovina zážitku je anonymní. Nic z toho není zpětně překvapivé. Bylo to tam od začátku.

Proto samotný kontext nestačí. Potřebujete i otázky: konkrétní otázky ukotvené zároveň v ticketu i ve skutečném produktovém kontextu. Týká se to stávajících uživatelů, nebo jen nových? Co se stane, když se prohlížeč zavře uprostřed průchodu? Je ta funkce jen pro administrátory? Je to jednorázová akce, nebo opakované chování? Krátká série poctivých odpovědí vytvoří víc sladění než další uhlazená specifikace.

Jak to funguje v Just

Přesně tento workflow jsem postavil do Just: AI Assistant for Jira:

1. Jednou nastavíš projektový kontext přes čtyři strukturovaná pole: shrnutí produktu, design systém, publikum a stack. Just k tomu dává i zadání, která můžeš pustit přes Claude Code nebo jiného coding agenta, aby ta shrnutí vytáhl přímo z repozitáře. Výsledek vložíš jednou a ten samý kontext se pak znovu používá u dalších ticketů.
2. Otevřeš Jira issue. Žádné kouzlení s prompty, žádné zvláštní nastavování pro každý úkol. Just si issue přečte spolu s uloženým kontextem a vytáhne postřehy, které jsou skutečně formované vaším projektem. Pak položí doplňující otázky, které nejsou obecné, ale vycházejí z vašeho produktu, technické reality a designového jazyka týmu.
3. Postavíš plán. Just z odpovědí udělá požadavky, směr designu, hraniční případy, očekávané výsledky a strukturovanou cestu realizace, podle které může tým opravdu pracovat. Umí si také přitáhnout čerstvý webový kontext tam, kde to dává smysl, a funguje se všemi pěti velkými AI poskytovateli, takže lze pro každý krok použít nejlepší model. Smyslem není působit magicky. Smyslem je pomoct týmu vytvořit správnou věc, ne jen něco rychlého. Celý průchod je vidět na aiapps.me.

Co to mění

Proč tedy většina AI nástrojů pro Jira problém se sladěním spíš zhoršuje, než aby ho řešila? Protože obvykle přicházejí až ve chvíli, kdy je nejednoznačnost už uvnitř ticketu, a pak jí jen dají uhlazenou a dokončeně působící podobu.

Skutečná páka je dřív. Tým si musí ujasnit, co vlastně chce, vytáhnout skrytá rozhodnutí ještě před začátkem implementace a dát AI dost kontextu, aby pracovala uvnitř skutečné podoby produktu, místo aby hádala z chudého zadání.

To je celé. Když tým ví, co chce, ještě před startem práce, AI začne být užitečná. Když ne, výstup může pořád působit působivě, ale ten zmatek se velmi pravděpodobně vrátí později jako předělávky.