Prompt engineering pro vývojáře: Jak z AI vytěžit maximum při psaní kódu

Základní princip: kontext je všechno

Rozdíl mezi nepoužitelným a produkčním výstupem z AI je téměř vždy v množství kontextu. Když AI nemá dostatek informací, hádá. A hádání znamená halucinace, nesprávné API, špatné typy a kód, který sice vypadá rozumně, ale neprojde ani prvním code review.

Podívejme se na konkrétní příklad — validace e-mailu:

Druhý prompt specifikuje: jazyk, název, vstup/výstup, standard, omezení, dokumentaci, edge cases. AI nemá co hádat. Výstup je o řád lepší — a často použitelný přímo bez úprav.

Pravidlo pěti W funguje jako mentální checklist před odesláním promptu:

• What — co přesně chcete (funkce, třída, test, refaktoring, migrace)
• Where — jazyk, framework, verze, runtime prostředí
• Why — účel, v jakém kontextu se kód používá, business logika
• Which — jaká omezení (no any, immutable, max délka, performance budget)
• With — jaké typy, knihovny, konvence, existující patterns v codebase

V praxi to znamená, že prompt pro produkční kód je typicky 5–15 řádků. Ne proto, že byste chtěli být upovídaní, ale protože kvalitní specifikace vyžaduje prostor. Stejně jako dobrý ticket v Jira.

Technika 1: Few-shot — učení příkladem

Když potřebujete specifický formát výstupu nebo dodržení konvence, dejte AI 1–3 příklady. Extrémně užitečné pro transformace, generování testů a migraci kódu. Few-shot je nejspolehlivější technika, protože AI nemusí interpretovat abstraktní pravidla — vidí konkrétní vzor a replikuje ho.

AI pochopí vzor a aplikuje ho konzistentně — včetně edge cases. Funguje skvěle i pro refaktoring: ukažte jak jste přepsali jednu komponentu ze starého patternu na nový a AI přepíše zbytek. To ušetří hodiny při migraci codebasu.

Few-shot je obzvlášť cenný při práci s interními konvencemi, které AI nezná z trénovacích dat. Pokud máte vlastní naming convention, error handling pattern nebo specifickou strukturu modulů, dva příklady řeknou víc než odstavec popisu.

Praktická ukázka — převod React class components na hooks. Dáte AI jeden příklad transformace a řeknete „aplikuj na dalších 12 komponent". Bez few-shot by AI použil svůj vlastní styl. S few-shot dodržuje přesně vaši konvenci — pojmenování stavových proměnných, pořadí hooků, formát cleanup funkcí.

Technika 2: Chain-of-thought pro debugování

Chain-of-thought (CoT) přiměje AI přemýšlet krok po kroku. Zásadní pro debugování, optimalizaci a architektonická rozhodnutí. Nestačí říct „oprav tento bug" — chcete, aby AI problém analyzoval, protože pouze analýzou najde skutečný root cause, ne jen symptom.

CoT dává výrazně lepší výsledky než „oprav to", protože AI si vynucuje systematický postup. Bonus: naučíte se z analýzy — vidíte, jak AI o problému přemýšlí, a často to odkryje aspekty, které jste přehlédli.

Kde CoT exceluje nejvíc:

• Race conditions — AI projde timeline paralelních operací a identifikuje kde dochází ke konfliktu
• Memory leaky — systematická analýza referencí, event listenerů a subscription cleanup
• Performance bottlenecky — krok po kroku analýza complexity, N+1 queries, zbytečných re-renderů
• Architektonická rozhodnutí — trade-off analýza s explicitním zvážením pros/cons každé varianty

Tip pro pokročilé: kombinujte CoT s konkrétním výstupním formátem. Například: „Analyzuj krok po kroku, pak shrň do tabulky: Problém | Severity | Řádek | Fix". Strukturovaný výstup je snáze zpracovatelný při code review.

Technika 3: System prompt jako .editorconfig pro AI

Pokud používáte API (OpenAI, Anthropic) nebo nástroj s custom instrukcemi, system prompt je nejsilnější nástroj pro konzistenci. Je to ekvivalent .editorconfig nebo .eslintrc — definuje pravidla, která AI dodržuje v každé odpovědi. Tady je šablona, kterou doporučuji uložit do repozitáře:

Sdílejte tento prompt v týmu — každý pak dostává konzistentní výstupy. Aktualizujte ho jak se mění stack a konvence. Funguje to jako onboarding pro AI „kolegu".

V praxi system prompt funguje nejlépe, když kombinuje tři úrovně instrukcí:

• Identita — kdo AI je (senior dev, security expert, performance engineer)
• Pravidla — co dodržovat (konvence, patterns, omezení)
• Formát — jak strukturovat odpověď (diff vs celý soubor, komentáře, vysvětlení)

Nástroje jako Cursor (v souboru .cursorrules), Claude Code (CLAUDE.md) nebo GitHub Copilot (.github/copilot-instructions.md) umožňují uložit system prompt přímo do repozitáře. To je ideální workflow — pravidla jsou verzovaná, sdílená a aktualizovaná spolu s kódem.

Technika 4: Kontextové okno — vkládejte relevantní soubory

Moderní modely mají kontext 100k–200k tokenů (Claude až 1M). Využijte to. Víc kontextu = méně halucinací. Před dotazem vložte:

• Schéma databáze (nebo relevantní tabulky)
• TypeScript typy / interfaces
• Existující kód modulu, do kterého přidáváte
• Relevantní testy (AI pochopí expected behavior)
• Konfiguraci (tsconfig, eslint rules, package.json)
• README nebo architektonické rozhodnutí (ADR)

Nástroje jako Cursor, Copilot Workspace nebo Claude Code to dělají automaticky — indexují codebase a vkládají relevantní soubory. Při práci ve webovém rozhraní vkládejte ručně. Čím víc kontextu, tím méně halucinací.

Porovnání nástrojů pro kontextové okno

Každý nástroj řeší kontext jinak. Tady je srovnání tří hlavních přístupů:

• Cursor — automaticky indexuje celý projekt. Stačí napsat prompt a Cursor vloží relevantní soubory. Výhoda: minimální effort. Nevýhoda: někdy vloží irelevantní kontext, což zabírá tokeny. Podpora @file a @codebase tagů pro manuální kontrolu.
• GitHub Copilot (Chat) — ve VS Code integrovaný chat s přístupem k otevřeným souborům. Kontext je omezený na workspace. #file tagy pro explicitní reference. Od verze s agent mode umí sám hledat v souborech.
• Claude Code (CLI) — terminálový nástroj, který čte soubory na vyžádání. Obrovský kontext (1M tokenů). Ideální pro práci s velkými codebase, migrace, refaktoring napříč mnoha soubory. Nejlepší pro komplexní úkoly, kde potřebujete pracovat s desítkami souborů najednou.

Technika 5: Generování testů — ne po, ale před implementací

AI exceluje v generování testů. Ale nejsilnější přístup je TDD s AI — nechte AI napsat testy před implementací. Proč? Protože testy definují kontrakt. Když máte testy, implementace je „jen" splnění specifikace.

AI vám vygeneruje testy včetně edge cases, na které byste sami nepomysleli. Pak implementujete kód, který testy splní. Reálná úspora: 30–60 minut na každém testovacím souboru.

Workflow v praxi vypadá takto:

1. Definujte rozhraní funkce (název, parametry, návratový typ)
2. Nechte AI vygenerovat testy na základě rozhraní
3. Projděte testy, přidejte chybějící scénáře specifické pro vaši business logiku
4. Implementujte funkci (s pomocí AI nebo ručně)
5. Spusťte testy — pokud neprochází, iterujte

Tenhle přístup je výrazně efektivnější než „napiš funkci a pak k ní testy", protože testy vás přinutí přemýšlet o edge cases před implementací. AI je v tom skvělé — vymyslí scénáře, které byste přeskočili: prázdné vstupy, unicode znaky, extrémně dlouhé stringy, negativní čísla, null vs undefined.

Technika 6: Code review promptem

Než pošlete PR na review, prožeňte ho přes AI. Ne jako náhradu lidského review, ale jako první filtr. Lidský reviewer se pak může soustředit na architekturu a business logiku místo triviálních chyb.

Tohle zachytí většinu běžných chyb — chybějící null check, nezavalidovaný vstup, N+1 query. Reálný příběh z praxe: AI review zachytilo SQL injection v parametrizovaném query, kde developer omylem použil string interpolaci místo prepared statement. Lidský reviewer to přehlédl, protože kód „vypadal" bezpečně.

Pro systematické code review v CI/CD pipeline existují nástroje jako CodeRabbit nebo Sourcery, které automaticky reviewují každý PR. Ale i manuální prompt ve webovém rozhraní je extrémně hodnotný — zvláště pro solo developery, kteří nemají koho požádat o review.

Technika 7: Bezpečnostní audit

Security review je jedna z oblastí, kde AI poskytuje obrovskou hodnotu, protože má „přečteno" tisíce zdokumentovaných zranitelností. Většina vývojářů nemá security background — AI tuto mezeru efektivně vyplní.

AI nenahradí pentest, ale zachytí 80 % běžných chyb v každodenním vývoji. SQL injection, hardcodovaný API klíč, chybějící rate limiting — věci, které se snadno přehlédnou pod časovým tlakem.

Konkrétní příklady, co AI běžně najde:

• eval() s uživatelským vstupem — command injection
• JWT token v URL query parametru — exposure přes server logy a referer header
• Chybějící httpOnly flag na session cookie — přístupný přes XSS
• CORS s origin: '*' na API s autentizací — bypass same-origin policy
• Logování celého request body včetně hesel — PII leak do log systému
• Použití Math.random() pro generování tokenů — predikovatelné výstupy

Technika 8: Refaktoring s jasným cílem

„Vylepši tento kód" je nejhorší prompt pro refaktoring. AI potřebuje vědět co přesně a proč — jinak dostanete over-engineered abstrakcí, které nikdo v týmu nepochopí. Každý z těchto promptů dá konkrétní, použitelný výstup:

• „Rozděl tuto 200-řádkovou funkci. Každá výsledná funkce max 30 řádků, single responsibility. Zachovej API."
• „Převeď tyto callbacks na async/await. Zachovej error handling semantiku."
• „Extrahuj duplicitní logiku z těchto 3 komponent do shared utility. Ukázat diff pro každou komponentu."
• „Přepiš tento imperativní kód na funkcionální styl (map/filter/reduce). Žádné mutace."
• „Tady jsou 3 soubory, které dělají podobnou věc. Navrhni abstrakci, ale jen pokud ušetří víc než 30 % kódu. Jinak je nech odděleně."

Poslední bod je důležitý: explicitně řekněte AI, kdy nemá abstrahovat. Jinak dostanete over-engineered řešení pro triviální problém. „Premature abstraction" je horší než duplikace.

Všimněte si explicitního pořadí priorit a omezení. Bez nich AI typicky začne tím, co je nejzajímavější (abstrakce, design patterns), ne tím, co přináší největší hodnotu (čitelnost, error handling).

Technika 9: Dokumentace existujícího kódu

Zdědili jste legacy codebase bez dokumentace? Tohle je killer use case pro AI. Za den dokáže jeden vývojář s AI zdokumentovat codebase, na který by bez AI potřeboval týden.

Protože AI nemá „curse of knowledge", dokumentace bývá srozumitelnější než ta, kterou by napsal autor kódu. AI vysvětluje to, co je čtenáři nejasné — ne to, co je zajímavé z technického pohledu.

Rozšířený workflow pro dokumentaci celého projektu:

1. Začněte entry pointem (main, index, app) — nechte AI popsat high-level architekturu
2. Pokračujte po modulech — každý modul zdokumentujte zvlášť
3. Nechte AI vytvořit dependency graf — kdo volá koho
4. Na konec: nechte AI napsat onboarding dokument pro nového vývojáře

Technika 10: Iterativní zpřesňování — pair programming dialog

Nejefektivnější workflow není napsat dokonalý prompt napoprvé. Je to dialog — stejně jako pair programming s kolegou:

1. Zadejte hrubý prompt.
2. Zhodnoťte výstup — co je dobře, co ne.
3. Zpřesněte: „Dobrý základ, ale přidej error handling pro network failures a použij Result type místo try-catch."
4. Opakujte: „Ještě uprav ten retry logic — exponential backoff, max 3 pokusy, timeout 5s."

AI si pamatuje kontext konverzace. Tohle je rychlejší než psát dokonalý 500-slovný prompt — stejně jako je rychlejší říct kolegovi „ještě uprav tohle" než specifikovat vše předem.

Klíčové fráze pro iteraci, které dobře fungují:

• „Dobrý základ, ale..." — zachová dobrý kód, upraví specifické části
• „Zachovej X, ale změň Y" — explicitně říká co nechat a co měnit
• „Zkus jiný přístup: ..." — kompletně nový směr bez ztráty kontextu
• „Tohle je příliš složité. Zjednodušit na..." — prevence over-engineering
• „Přidej edge case pro..." — inkrementální vylepšení

Důležité: ukládejte si osvědčené prompty. Vytvořte ve firemním repu složku /prompts nebo sdílený dokument. Standardizované prompty dávají konzistentní výsledky napříč týmem a šetří čas při opakujících se úkolech (generování testů, code review, migrace).

Bonus: Časté chyby při promptování

Většina vývojářů dělá při práci s AI stále dokola stejné chyby. Tady je seznam těch nejčastějších — a jak se jim vyhnout:

• Příliš vágní zadání — „vylepši tento kód" místo konkrétního cíle. AI nemůže čist myšlenky.
• Žádný kontext — prompt bez typů, bez existujícího kódu, bez informace o frameworku. AI pak generuje generický kód, který nesedí do vašeho projektu.
• Slepé kopírování — přijmout výstup AI bez review. Vždy čtěte vygenerovaný kód. AI dělá subtilní chyby — špatné typy, chybějící error handling, deprecated API.
• Ignorování kontextového limitu — dlouhá konverzace, kde AI „zapomíná" počáteční instrukce. Řešení: začněte novou konverzaci s aktualizovaným system promptem.
• Over-prompting — 50-řádkový prompt pro triviální funkci. Pokud je úkol jednoduchý, prompt může být krátký. Složitost promptu by měla odpovídat složitosti úkolu.

Shrnutí: Co funguje v praxi

Prompt engineering není magie — je to strukturované zadávání úkolů. Stejné principy jako dobrý ticket nebo code review request. Tři pravidla, která pokryjí 90 % situací:

1. Kontext — vložte relevantní kód, typy, schéma. Čím víc, tím líp.
2. Specifikace — jazyk, framework, konvence, omezení, formát výstupu.
3. Iterace — nezkoušejte napsat dokonalý prompt napoprvé. Zpřesňujte dialogem.

A jedno meta-pravidlo: investujte čas do system promptů a prompt library. Upfront investice 2–3 hodin vám ušetří desítky hodin měsíčně. AI je nejsilnější, když ho používáte systematicky — ne ad hoc.

Chcete se naučit tyto techniky v praxi? Na našich workshopech pro vývojáře procvičujeme všechny zmíněné techniky na reálných příkladech z vašeho stacku.