AI pro programování: postupy, které snižují riziko

Krátká odpověď

AI pro programování používejte tak, aby pracovala z důkazů. Každou chybu začněte reprodukcí, požádejte o seřazené příčiny ještě před jakýmkoli kódem, vyžádejte si nejmenší bezpečnou opravu i seznam souborů, kterých se týká, trvejte na testech, které před opravou selžou a po ní projdou, a diff před sloučením zkontrolujte.

AI navrhuje, ale rozhoduje váš repozitář

Nejlepší způsob, jak používat AI pro programování, je zpomalit ji přesně v momentech, kdy je hádání nebezpečné. AI dokáže vysvětlit neznámý kód, proměnit chyby v hypotézy, navrhnout testy, zkontrolovat diffy a doporučit refaktoring. Stejně tak si ale může vymyslet API, přehlédnout skryté závislosti, přizpůsobit se příliš úzce vloženému úryvku nebo vytvořit opravu, která vypadá čistě, ale přitom mění chování, které jste chtěli zachovat.

Držte se pravidla: AI navrhuje, ale rozhoduje váš repozitář. Zdrojem pravdy je kódová základna, selhávající reprodukce, sada testů, logy za běhu, požadavky na produkt a lidská kontrola. Dobrý AI parťák v programování by vám měl pomáhat uvažovat na základě těchto podkladů, ne je nahrazovat.

PravidloProč záležíCo se modelu zeptat
Nejdřív reprodukceZabraňuje náhodným opravám"Než navrhneš kód, znovu popiš selhávající chování a důkazy."
Malý rozsahSnižuje riziko regrese"Navrhni nejmenší bezpečnou změnu a vyjmenuj dotčené soubory."
Zachování chováníChrání uživatele a smlouvy"Pojmenuj invarianty, které tato změna nesmí porušit."
Vyžádat testyDělá odpověď ověřitelnou"Napiš testy, které před opravou selžou a po ní projdou."
Kontrola před sloučenímOdhalí sebejisté chyby"Zkontroluj tento diff kvůli správnosti, bezpečnosti a chybějícím okrajovým případům."

Na tom záleží napříč modely, protože se skutečně liší v ceně i dosahu. Podle indexu nákladů na modely od Whizi (ceníkové sazby OpenRouter, zjištěno 2026-08-20) stojí běžná odpověď o 1 000 vstupních a 500 výstupních tokenech přibližně $0.0105 na Claude Sonnet 4.6, $0.008 na GPT-5.6 Terra a $0.00028 na DeepSeek V4 Flash, tedy rozdíl zhruba 37x mezi první a poslední hodnotou, a všechny tři přitom čtou kontext o 1M tokenech. Praktické pravidlo pro směrování je: dotazy typu vysvětli tento kód a třídění logů posílejte levnému modelu jako DeepSeek V4 Flash nebo Gemini 3.7 Flash, a Claude Sonnet 4.6 nebo GPT-5.6 Terra si nechte na kontrolu a plán refaktoringu u kódu, který si nemůžete dovolit rozbít. Dokumentace schopností od OpenAI a Anthropic vám řekne, o co se model může pokusit, nenahrazuje ale postup popsaný výše. Modely posuzujte stejně jako kolegu: ptá se na chybějící kontext, snižuje nejistotu, respektuje omezení a nechává za sebou stopu, kterou lze ověřit?

Ladění v pěti fázích: nejdřív reprodukce, pak oprava

Spolehlivý postup pro ladění chyb pomocí AI má pět fází: reprodukce, izolace, hypotéza, oprava a ověření. Nezačínejte slovy "oprav tohle". Začněte důkazy. Modelu dejte selhávající příkaz, přesné chybové hlášení, očekávané chování, pozorované chování, relevantní kód, detaily prostředí a případnou nedávnou změnu, která mohla problém způsobit.

Fáze 1: zachyťte reprodukci. U backendového kódu uveďte požadavek, odpověď, stavový kód, logy a selhávající test. U frontendového kódu uveďte cestu, akci uživatele, chybu v konzoli prohlížeče, síťovou odpověď, stav komponenty a popis snímku obrazovky, pokud je relevantní. U problémů s buildem uveďte příkaz, správce balíčků, verzi Node a celou chybu kolem prvního selhání.

Fáze 2: nejdřív si vyžádejte hypotézy, teprve pak kód. Pečlivý model by měl seřadit pravděpodobné příčiny a uvést, jaké důkazy pro každou z nich hovoří. Pokud mezi příčinami nedokáže rozlišit, požádejte o nejmenší diagnostický krok. Může jít o log, cílený test, kontrolu typů nebo přečtení dalšího souboru.

Fáze 3: vyžádejte si nejmenší možnou opravu. Řekněte modelu, ať nepřejmenovává proměnné, nepřepisuje okolní kód, nepřidává závislosti ani nemění veřejné chování, pokud to nedokáže zdůvodnit. Požádejte ho, ať vrátí kořenovou příčinu, nástin opravy, dotčené soubory, testy a riziko.

Fáze 4: spusťte testy lokálně. Výstup AI není ověřovacím krokem. Ověřovacím krokem je příkaz nebo uživatelský postup, který chování prokáže. Pokud neexistuje automatizovaný test, požádejte model, ať nejdřív vytvoří regresní test a teprve poté opravu implementuje.

Prompt pro ladění:

Chovej se jako pečlivý parťák při ladění chyb. Zatím nepiš kód. Nejdřív znovu popiš reprodukci, očekávané chování, pozorované chování a tři nejpravděpodobnější kořenové příčiny. Seřaď každou příčinu podle důkazů. Poté navrhni nejmenší diagnostický krok. Chyba: [popiš]. Příkaz nebo akce uživatele: [vlož]. Chyba/logy: [vlož]. Relevantní kód: [vlož]. Omezení: [stack, soubory, kterých se nedotýkat, chování k zachování].

Prompt pro opravu:

S využitím potvrzené kořenové příčiny navrhni nejmenší bezpečnou opravu. Vrať: kořenovou příčinu, soubory/funkce ke změně, nástin opravy, testy, které před tím selžou a poté projdou, okrajové případy a riziko rollbacku. Nerefaktoruj nesouvisející kód. Kontext: [vlož].

AI kontroluje diffy lépe, než je píše

AI bývá lepší jako recenzent než jako první autor. Když ji požádáte o kontrolu diffu, umí hledat přehlédnuté okrajové případy, bezpečnostní problémy, zastaralé předpoklady, mezery v testech a změny chování. Klíčové je udělat kontrolu konkrétní. Pokud se zeptáte "vypadá to dobře?", dostanete zdvořilý souhlas. Pokud se zeptáte na riziko správnosti, spíš dostanete užitečné námitky.

Modelu dejte diff, zamýšlené chování, související testy a případná omezení. Požádejte ho, ať ignoruje drobné stylistické věci, pokud neovlivňují udržovatelnost. Kontrola má upřednostnit chyby, ne prázdné výtky.

Oblast kontrolyOtázky, na které by AI měla odpovědět
SprávnostSplňuje diff skutečně daný požadavek?
Riziko regreseJaké stávající chování by se mohlo nechtěně změnit?
BezpečnostJsou ošetřené vstupy, autentizace, tajné klíče, oprávnění nebo rizika injekce?
Ošetření chybCo se stane při hodnotě null, timeoutu, opakování, špatné odpovědi nebo částečném stavu?
TestyKteré tvrzení o chování není pokryté?
UdržovatelnostDrží se to místních zvyklostí a zůstává změna srozumitelná?

Prompt pro code review:

Zkontroluj tento diff jako přísný, ale praktický správce. Zaměř se na správnost, riziko regrese, bezpečnost, okrajové případy a chybějící testy. Ignoruj drobný styl, pokud nevytváří skutečné riziko údržby. Vrať tabulku s problémem, prioritou, důkazem z diffu, navrhovanou opravou a potřebným testem. Zamýšlené chování: [vlož]. Diff: [vlož]. Stávající testy: [vlož].

U vysoce rizikových změn použijte ve Whizi postup porovnání oprav napříč modely. Spusťte stejný prompt pro kontrolu na dvou nebo třech modelech. Pokud jeden model najde možný problém, nepřijímejte ho slepě, ověřte, jestli je v kódové základně skutečně reálný. Smyslem je rozšířit rozsah kontroly ještě před sloučením, přičemž každá námitka se musí opírat o kód, ne jen počítat jako hlas. Širší verze tohoto zvyku, tedy rozhodování, který typ kódu poslat kterému modelu, je popsaná v nejlepších AI nástrojích pro vývojáře.

Před refaktoringem pojmenujte invarianty

Refaktoring pomocí AI je rizikový, protože mnoho refaktoringů se posuzuje podle toho, co se nezmění. Model může kód zkrášlit, přitom ale nenápadně změnit chování, ošetření chyb, časování nebo veřejné smlouvy. Bezpečnější postup refaktoringu začíná definováním invariantů ještě před dotykem implementace.

Krok 1: popište cíl refaktoringu. Příklady: snížit duplicitu, rozdělit velkou komponentu, oddělit přístup k datům, zjednodušit větvení, migrovat obal API nebo zlepšit testovatelnost. Poté uveďte, co musí zůstat stejné: signatury veřejných funkcí, chování tras, názvy událostí, tvary odpovědí, analytiku, oprávnění, chování přístupnosti a očekávaný výkon.

Krok 2: vyžádejte si postupný plán. Užitečný AI plán refaktoringu by měl být vratný. Každá fáze by se měla dotknout malé oblasti, obsahovat testy a vytvořit funkční mezistav. Vyhněte se jednorázovým přepisům, pokud kód není malý a dobře pokrytý.

Krok 3: napište charakterizační testy. Než začnete měnit kód, požádejte AI, ať identifikuje současné chování a navrhne testy, které zafixují důležité případy. Tyto testy jsou obzvlášť užitečné u zastaralého kódu, kde není záměr jasný. Měly by zahrnovat běžné vstupy, hraniční vstupy, cesty selhání a jeden regresní případ vázaný na důvod refaktoringu.

Krok 4: implementujte po jedné fázi. Po každé fázi spusťte testy a požádejte o cílenou kontrolu. Pokud model navrhne širokou abstrakci, ať prokáže, že abstrakce skutečně odstraňuje reálnou duplicitu nebo riziko. Jinak nechte kód nudný a lokální.

Prompt pro plánování refaktoringu:

Vytvoř postupný plán refaktoringu. Cíl: [cíl]. Současný kód: [vlož]. Omezení: zachovej veřejné chování, minimalizuj rozsah změn, dodržuj stávající vzory, nepřidávej nové závislosti, každá fáze musí být testovatelná. Vrať: invarianty, mapu závislostí, fáze, dotčené soubory, testy pro každou fázi, riziko rollbacku a kontrolní checklist.

Prompt pro unit testy:

Napiš testy ještě před implementačními změnami. Použij existující styl testů uvedený zde: [vlož]. Chování k zachování: [vlož]. Testovaný kód: [vlož]. Vrať názvy testů, přípravu, vstup, očekávaný výsledek a proč na každém testu záleží. Zahrň běžný případ, hraniční případ, chybový případ a regresní případ.

Promptové šablony, které odstraňují nejednoznačnost

Silné prompty pro programování jsou přesně tak dlouhé, aby odstranily nejednoznačnost, a nic navíc. Model potřebuje roli, úkol, kontext, omezení, formát výstupu a kritéria ověření. Ukládejte si prompty, které fungují, aby se AI stala opakovatelným inženýrským postupem, ne jednorázovým chatem. Tabulka níže spáruje každý programátorský úkol s tím, o co požádat nejdřív, a s tím, co odpověď prokazuje.

Úkol v programováníO co požádat nejdřívCo dokazuje odpověď
Ladění chybSeřazené kořenové příčiny s důkazy za každou z nichRegresní test, který před opravou selže a po ní projde
Code reviewSprávnost, riziko regrese, bezpečnost, okrajové případy a mezery v testechKaždý problém dohledatelný na konkrétní řádek diffu
RefaktoringInvarianty a postupný plán ještě před jakoukoli implementační změnouCharakterizační testy stále projdou na konci každé fáze
Psaní testůBěžný případ, hraniční, chybový a regresní případKaždý test odpovídá tvrzení o chování, které umíte pojmenovat
Vysvětlování kóduÚčel, vstupy, výstupy, tok dat, závislosti a způsoby selháníFakta viditelná v kódu jsou oddělená od domněnek

Prompt pro vysvětlení kódu:

Vysvětli tento kód pro vývojáře, který se přidává do projektu. Pokryj účel, vstupy, výstupy, tok dat, závislosti, způsoby selhání a testy, které by zvýšily důvěru. Odděl fakta viditelná v kódu od domněnek. Kód: [vlož].

Prompt pro bezpečné programování:

Zkontroluj tento kód kvůli bezpečnostním rizikům. Zaměř se na autentizaci, oprávnění, injekci, tajné klíče, validaci, nebezpečné přesměrování, práci se soubory, riziko závislostí a únik citlivých dat. Vrať pouze problémy s důkazem, dopadem, navrhovanou opravou a testem nebo manuální kontrolou. Kód/diff: [vlož].

Prompt pro porovnání oprav napříč modely:

Porovnávám AI modely pro programátorský úkol. Použij pouze poskytnutý kontext. Vrať kořenovou příčinu, nejmenší bezpečnou opravu, testy, rizika, předpoklady a otázky. Ohodnoť jistotu od 1 do 5 a uveď, jaký důkaz by tvoji odpověď změnil. Úkol: [vlož]. Kontext: [vlož].

Kontrolní seznam před přijetím kódu vygenerovaného AI:

  • Model úkol správně přeformuloval.
  • Oprava je menší než problém, ne větší.
  • Veřejné chování a smlouvy jsou pojmenované.
  • Testy přímo pokrývají chybu nebo cíl refaktoringu.
  • Okrajové případy a cesty selhání jsou vyjmenované.
  • Bezpečnostně citlivé vstupy jsou zkontrolované.
  • Diff se drží stávajících vzorů projektu.
  • Spustili jste relevantní test, lint, build nebo manuální reprodukci.
  • Finální diff zkontroloval člověk.

Jedno poctivé omezení: Whizi je chatový pracovní prostor, ne plugin do IDE. Pro průběžné doplňování kódu při psaní vyhraje specializovaný asistent v IDE. Whizi se osvědčuje v kontrolních bodech: stejný prompt na ladění nebo kontrolu vložte do Claude Sonnet 4.6, GPT-5.6 Terra a DeepSeek V4 Pro, a výstupy pak ohodnoťte podle důkazů, rozsahu, testů a rizika. Pokud chcete pomoct s výběrem modelu, začněte u alternativ k ChatGPT pro programování, porovnejte plány na stránce ceník nebo si vytvořte účet a spusťte tento postup na vlastním kódu.

Kontrolní seznam
  • Začněte se skutečnou reprodukcí, ne s vágním popisem chyby.
  • Než požádáte o kód, vyžádejte si hypotézy a důkazy.
  • Vyžádejte si nejmenší bezpečnou opravu a pojmenujte dotčené soubory.
  • Před refaktoringem definujte chování, které se nesmí změnit.
  • Napište nebo aktualizujte testy dřív, než opravě uvěříte.
  • Zkontrolujte diffy vygenerované AI kvůli správnosti, bezpečnosti a okrajovým případům.
  • Stejný rizikový prompt spusťte napříč modely a porovnejte opravy ve Whizi.
  • Před sloučením kódu s pomocí AI použijte lidskou kontrolu.

Časté dotazy

Jak bezpečně používat AI pro programování?

Používejte AI jako parťáka v programování, který navrhuje možnosti, testy a kontroly. Začněte reprodukcí, vyžádejte si malou opravu, spusťte testy a před sloučením zkontrolujte diff. Vygenerovaný kód neberte automaticky jako správný.

Umí AI pomoct s laděním kódu?

Ano. AI se hodí na proměnu chyb, logů a kódu v pravděpodobné kořenové příčiny. Nejbezpečnější postup ladění je nejdřív si vyžádat hypotézy, pak diagnostický krok a nakonec nejmenší opravu s regresními testy.

Dokáže AI napsat unit testy?

AI umí navrhnout unit testy, ale měli byste trvat na jasném pokrytí chování. Vyžádejte si běžný případ, hraniční případ, chybový případ a regresní případ, a poté zkontrolujte, jestli by testy před opravou selhaly a po ní prošly.

Který AI model je nejlepší pro programování?

Řešte to podle rizika. Levný model jako DeepSeek V4 Flash zvládne vysvětlení kódu a třídění logů za zhruba 37x nižší cenu na odpověď než Claude Sonnet 4.6 podle ceníkových sazeb, takže si Claude Sonnet 4.6 nebo GPT-5.6 Terra šetřete na kontroly a plány refaktoringu u kódu, na kterém záleží. Volbu si ověřte spuštěním stejného promptu napříč modely a ponecháním odpovědi s nejjasnějšími důkazy a nejsilnějšími testy.