Chat modely a kódovací agenti jsou různé nástroje
Stojí za to to hned na začátku oddělit, protože se ty dva pojmy pletou. Agentní kódovací nástroj žije ve vašem editoru nebo terminálu, čte váš repozitář a zapisuje soubory. Chatovací prostor je místo, kde přemýšlíte: vložíte stack trace, diskutujete o přístupu, zkontrolujete diff, pochopíte knihovnu, kterou jste nikdy nepoužili, a připravíte návrhový dokument.
Většina vývojářů nakonec používá obojí, a právě na chatové straně záleží na výběru modelu nejvíc, protože čtete uvažování, ne diff. Právě tady také přestává mít smysl platit za tři samostatná předplatná, jen abyste mohli porovnat tři modely.
| Co právě řešíte | Tendence modelu | Poznámky |
|---|---|---|
| Náročné uvažování: konkurence, subtilní race condition, architektonický kompromis | Claude a GPT se výrazně liší | Zeptejte se obou. Tady se druhý názor vyplatí sám |
| Rychlost implementace na osvědčené půdě | GPT | Rychlý, idiomatický, dobrý na boilerplate a konverze |
| Čtení velké neznámé kódové báze nebo dlouhé specifikace | Gemini | Nejvíce kontextové okno, takže se najednou vejde víc systému |
| Vysvětlení chyby nebo konceptu | Kterýkoli výklad zafunguje | Různé modely vysvětlují jinak, a to je smysl |
| Striktní strukturovaný výstup: konfigurace, JSON, schéma | GPT | Nejspolehlivější v přesném dodržení formátu |
Debugovací prompty, které porazí vložení stack trace
Vložit chybu a zeptat se, co je špatně, vede k odhadu. Odhad je často správný, a když není, ztratíte dvacet minut honěním se za věrohodnou opravou problému, který ani nemáte. Tyto prompty mění tvar odpovědi.
Prompt: hypotézy před opravami
Tady je chyba, kód a co jsem už vyloučil. Nedávej mi ještě opravu. Vypiš čtyři nejpravděpodobnější příčiny seřazené podle pravděpodobnosti, a u každé nejlevnější kontrolu, která by ji potvrdila nebo vyloučila. Chyba: [vlož]. Kód: [vlož]. Už vyloučeno: [seznam].
Prompt: chyba, která se objevuje jen občas
Tohle selhává přerušovaně, zhruba [frekvence], za podmínek [podmínky]. Tady je relevantní kód a co vím o prostředí. Vypiš kategorie přerušovaných chyb, které by mohly způsobit tento konkrétní symptom (časování, pořadí, vyčerpání zdrojů, externí závislost, únik stavu mezi běhy, čas nebo časové pásmo, cache). U každé napiš, jaké důkazy v tom, co jsem dal, ji podporují nebo vyvracejí, a co bych měl logovat, abych je odlišil.
Prompt: vysvětli opravu, než ji použiju
Vysvětli, proč tato oprava funguje, co neopravuje a co by mohla rozbít. Pokud je skutečná příčina jinde a tohle je jen záplata na symptom, řekni to přímo.
Tento poslední prompt zachytí nejnákladnější druh AI asistence: změnu, díky které symptom zmizí, zatímco skutečná chyba zůstane v kódové bázi.
Dva modely na stejný problém, což není trik
Když je odpověď zjevná, jeden model stačí. Tato technika se vyplatí u problémů, kde si nejste jistí, a funguje, protože modely selhávají jinak, ne stejně.
Užitečný vzor není zeptat se obou a vybrat si tu odpověď, která se vám líbí víc. Je to zeptat se jednoho a pak jeho odpověď předat druhému:
Prompt: nepřátelská revize odpovědi
Jiný inženýr navrhl toto řešení tohoto problému. Najdi, co je na něm špatně: správnost v krajních případech, konkurence, ošetření chyb, výkon při [rozsah], nebo jednodušší přístup, který unikl. Pokud je řešení skutečně v pořádku, řekni to jasně, místo abys vymýšlel námitky. Problém: [vlož]. Navržené řešení: [vlož].
Dva výsledky, oba užitečné. Buď druhý model najde skutečnou díru, o které teď víte ještě před mergem, nebo souhlasí, což je opravdový důkaz, protože měl každý důvod nesouhlasit. Porovnejte to s iterováním se stejným modelem, který má tendenci souhlasit sám se sebou.
Stejný vzor platí i pro rozhodnutí o designu:
Prompt: obhaj druhou stranu
Vybírám [přístup A] před [přístup B] pro [kontext a omezení]. Postav nejsilnější argument pro B. Co by musela platit o našich omezeních, aby bylo B správnou volbou, a platí něco z toho tady?
Whizi má přesně na tohle vedle sebe umístěné porovnání, a je zdokumentované v porovnání modelů vedle sebe.
Code review a čtení neznámého kódu
Prompt: recenzuj diff jako náročný recenzent
Zkontroluj tento diff. Kategorie v tomto pořadí: chyby ve správnosti, bezpečnostní problémy, neošetřené případy selhání, race conditions, pak styl. U každého nálezu uveď závažnost, konkrétní řádek a proč je to tady důležité, ne obecně. Nekomentuj formátování. Pokud je diff v pořádku, řekni to. Kontext: tato kódová báze používá [stack a konvence]. Diff: [vlož].
Prompt: pochop kódovou bázi, kterou jsi právě zdědil
Tady jsou hlavní zdrojové soubory. Vytvoř: vstupní body, tok dat od požadavku k odpovědi, stav, který je sdílený a kde se mění, externí závislosti a co se stane, když je každá z nich nedostupná, a tři části, které nejspíš obsahují chyby na základě složitosti a provázanosti. Explicitně řekni, co z toho, co jsem dal, nejde určit.
Ta poslední instrukce je důležitější, než se zdá. Modely rády popíšou chování souboru, který jste nevložili, odvozené z jeho názvu. Vynucení explicitního seznamu neznámých vám řekne, co si máte přečíst.
Prompt: napiš test, na který by ses nezeptal
Napiš testovací případy pro tuto funkci se zaměřením na vstupy, které jsem nejspíš nezvážil: hranice, prázdné a null, unicode, velmi velké hodnoty, souběžná volání a jakýkoli implicitní předpoklad v implementaci. U každého testu uveď, jaký předpoklad ověřuje. Funkce: [vlož].
Chybové vzorce, které skutečně stojí čas
Vymyšlená API. Modely s jistotou vytvoří názvy metod, parametry a konfigurační klíče, které neexistují, zvlášť u knihoven, které se nedávno změnily nebo jsou méně běžné. Signatura bude vypadat správně. Před stavbou na čemkoli neznámém si ověřte skutečnou dokumentaci.
Sebejistě špatné opravy. V tónu nenajdete žádný signál. Oprava, která problém rozpustí, a oprava, která vnese novou subtilní chybu, jsou podané se stejnou jistotou. Vždy se zeptejte, co by ta změna mohla rozbít.
Zastaralé vzory. Trénovací data se přiklánějí k objemu kódu napsaného o frameworku, což je často předchozí hlavní verze. Pokud odpověď působí jako z před několika lety, pravděpodobně je. V promptu uveďte, na jaké verzi jste.
Tiché rozšiřování rozsahu. Požádáte o opravu a často dostanete refaktoring. Přidejte změň co nejméně a vypiš každý řádek, který jsi změnil, a proč, aby diff zůstal přehledný pro revizi.
Bezpečnostní divadlo. Model umí pojmenovat třídy zranitelností ve vašem kódu, což je pro první průchod skutečně užitečné, ale není to audit. Nezná váš model hrozeb, vaše nasazení ani citlivost vašich dat.
Kam to zapadá do zbytku vašich nástrojů
Nenahrazuje to integraci ve vašem editoru ani agentní kódovací nástroj. Nahrazuje to tři panely v prohlížeči, kde jste porovnávali odpovědi, plus dvě předplatná, která byla potřeba, abyste je měli otevřené najednou.
Praktické nastavení, ke kterému většina vývojářů dojde: jeden výchozí model na rychlé otázky, druhý, na který přejdete, když první odpověď nepůsobí přesvědčivě, a Gemini, když potřebujete najednou předložit modelu velké množství kódu nebo dlouhou specifikaci. Vše v jednom vlákně, takže kontext, který jste už zavedli, přechází se změnou, místo aby se musel znovu vkládat.
Hlubší pokrytí najdete v AI pro programování, v porovnání alternativ zaměřených na kód a v balíčku promptů pro Claude na programování. Mechaniku provozu tohoto nastavení uvnitř Whizi najdete v psaní a debugování kódu s více modely.
- Nejdřív si vyžádejte seřazené hypotézy a levné kontroly, teprve pak opravu
- Předejte odpověď prvního modelu druhému a nechte ho najít slabé místo
- Vždy se zeptejte, co by navržená oprava mohla rozbít a jestli nejde jen o záplatu na symptom
- V promptu uveďte jazyk, framework a verzi, abyste se vyhnuli zastaralým vzorům
- Jakékoli neznámé API si ověřte proti skutečné dokumentaci, než na něm začnete stavět
- Přidejte "změň co nejméně a vypiš každou změnu", aby diffy zůstaly přehledné
- Použijte model s velkým kontextem, když otázka pokrývá víc kódu, než se vejde do běžného promptu
Časté dotazy
Proč nezůstat jen u jednoho modelu na programování?
Pro běžnou práci je jeden v pořádku. Hodnota se projeví u problémů, kde si nejste skutečně jistí, protože modely selhávají na jiných místech, ne na tom stejném. Předání navrženého řešení modelu A modelu B s žádostí, ať najde chybu, buď odhalí skutečný problém ještě před mergem, nebo vám dá smysluplné potvrzení. Iterování s jedním modelem většinou vede k tomu, že souhlasí sám se sebou.
Je to náhrada za agentní kódovací nástroj?
Ne, řeší jiné problémy. Agent žije ve vašem repozitáři a upravuje soubory. Chatovací prostor je místo, kde uvažujete: stack trace, argumenty o designu, revize diffů, pochopení neznámé knihovny a příprava návrhového dokumentu. Většina vývojářů používá obojí, a výběr modelu záleží víc na chatové straně, protože hodnotíte uvažování, ne výsledný diff.
Který model je nejlepší na programování?
Záleží na úkolu, což je upřímná odpověď a důvod, proč tato stránka existuje. GPT bývá rychlejší a idiomatičtější na osvědčené implementační práce. Claude bývá silnější v subtilním uvažování, neznámé architektuře a vysvětlování, proč se něco chová tak, jak se chová. Gemini vyhrává, když úkol vyžaduje pojmout najednou velké množství kódu nebo specifikace. Porovnání na vašich vlastních reálných problémech po dobu týdne předčí jakýkoli benchmark.
Můžu vložit proprietární kód?
Whizi netrénuje na vašich konverzacích, a zásady zpracování dat každého poskytovatele jsou k dispozici k prostudování, než daný model povolíte. Zásady vašeho zaměstnavatele bývají obvykle to závazné omezení a hodně se liší, takže si je ověřte. Kde platí omezení, praktický přístup je reprodukovat problém v minimálním příkladu, který obsahuje strukturu, ale žádnou obchodní logiku, což často dá lepší odpověď i tak.
Jak zabráním tomu, aby přepsal úplně všechno?
Řekněte to explicitně: změň co nejméně, zachovej existující strukturu a názvy, a vypiš každý řádek, který jsi změnil, s jednořádkovým důvodem. Nevyžádané refaktoringy jsou hlavní důvod, proč se AI návrhy stávají nekontrolovatelnými k revizi, a omezení diffu je rozdíl mezi změnou, kterou dokážete posoudit, a tou, kterou musíte číst znovu od začátku.