Chyby AI asistentů pro programování a jak se jim vyhnout

Většina chyb AI asistentů pro programování vzniká ještě před generováním kódu: úkol je vágní, omezení jsou skrytá nebo nikdo nedefinuje, jak se výsledek ověří. Prevencí není vyhýbat se AI. Jde o to dát asistentovi lepší technický problém k vyřešení.

Zde jsou vzorce selhání, které dělají technicky platné změny rizikovými, a konkrétní návyk, jenž každému z nich brání.

„Přesuňte tlačítko do postranního panelu“ říká asistentovi, kam něco umístit, ale ne proč současné umístění selhává.

Prevence: Nejprve uveďte problém uživatele a výsledek.

Problém: Přepínač témat soupeří s globální navigací, ale lidé jej používají
při porovnávání lekcí v jednom kurzu.

Výsledek: Usnadněte nalezení přepínání témat u navigace kurzu, aniž byste
změnili globální akce navigační lišty.

Asistent nyní může zpochybnit volbu umístění, pokud je bezpečnější jiný vzor pro malé obrazovky.

„Ukliďte tok auth“ vybízí k rozsáhlému diffu. Asistent může zasáhnout poskytovatele, routy, testy i volání API, protože nevidí hranici.

Prevence: Pojmenujte první hranici a cíle mimo rozsah.

Prozkoumejte pouze callback přihlášení a jeho přímé testy. Neměňte propojování
účtů, fakturaci ani ochrany rout, pokud důkazy neukážou, že callback nelze
opravit izolovaně.

Pokud práce skutečně překračuje hranici, asistent by měl před jejím rozšířením vysvětlit proč.

Asistent nedokáže z komponenty odvodit každé pravidlo produktu. Může do statické aplikace zavést cestu pouze pro server, rozbít routu zachovávající locale nebo duplikovat zapisovač stavu.

Prevence: Vložte zásadní invarianty do promptu nebo trvalých pokynů projektu.

Zachovejte statický export, navigaci s aktivním locale, stávající názvy
analytických událostí a současného jediného zapisovače předvoleb oznámení.

Seznam udržujte krátký a konkrétní. Dlouhý seznam přání je méně užitečný než několik vymahatelných kontraktů.

Vygenerovaný kód může kompilovat a přesto mít nesprávný přechod stavu, chybovou cestu, chování přístupnosti nebo bezpečnostní hranici.

Prevence: Vyžádejte si plán ověření před implementací.

Uveďte cílené testy, kontrolu typů a ruční scénář, které by tuto změnu
prokázaly. Vysvětlete, jaké chování každá kontrola pokrývá a co zůstává neověřené.

Kontroly spusťte. Zrevidujte diff. Projděte cestu uživatele. Výstup AI je návrh, ne kritérium vydání.

Rozsáhlý diff skrývá, zda je skutečná chyba opravena. Těžko se reviduje a téměř není možné jej bezpečně vrátit.

Prevence: Požadujte posloupnost malých kontrolních bodů.

Nejprve reprodukujte a vysvětlete selhání. Poté proveďte pouze opravu stavu a přidejte
regresní test. Nerefactorujte související komponenty, dokud cílený test
neprojde a diff nebude zrevidován.

Menší změna může ukázat, že plánovaný refaktoring nebyl potřeba.

„Zrychlete tuto stránku“ může vést ke cachování, memoizaci nebo dělení kódu, které zakryjí skutečné úzké hrdlo a vytvoří nová rizika invalidace.

Prevence: Požádejte o měření a alternativy.

Určete, zda je zpomalení v síti, výpočtu, nebo vykreslování. Před návrhem
optimalizace uveďte měření, výchozí stav a očekávaný dopad.
Nepřidávejte perzistentní cache, dokud nejsou definovány aktuálnost a invalidace.

Práce na výkonu by měla změnit změřenou cenu, ne jen přidat známou techniku.

Asistent může odstranit postranní panel desktopu pro zlepšení mobilního rozložení nebo zjednodušit tok, na který se lidé spoléhají. Kód může být čistý, zatímco produkt se zhorší.

Prevence: Pojmenujte lidi, pracovní postup a chování, které musí zůstat zachováno.

Studenti na mobilu potřebují více vodorovného prostoru. Studenti na desktopu se
spoléhají na postranní panel pro navigaci v kurzu. Vylepšete mobilní rozložení a zachovejte
pracovní postup na desktopu i jeho cestu klávesnicí.

Tím se „odstraňte postranní panel“ promění ve skutečné omezení návrhu.

Produkční incidenty vyvolávají naléhavost, ale naléhavost není důvod nechat asistenta hádat podle příznaku.

Prevence: Použijte posloupnost od důkazů k ověření:

Důkazy -> hypotézy -> ověření -> nejmenší oprava -> regresní test ->
kontrola bezpečného rollout

Zahrňte logy s odstraněnými citlivými hodnotami, kroky k reprodukci, prostředí, nedávné změny, očekávané chování a pozorované chování. Nevkládejte vygenerované patche do produkce naslepo.

Problém: [Koho se to týká a co se děje?]
Rozsah: [Co je třeba prozkoumat jako první?]
Výsledek: [Jaký pozorovatelný výsledek je potřeba?]
Omezení: [Co se nesmí změnit?]
Důkazy: [Test, log, snímek obrazovky, výstup příkazu nebo reprodukce.]
Kritéria přijetí: [Jak poznáme, že to fungovalo?]
Ověření: [Testy, ruční kontroly nebo měření.]

Před úpravou zpochybněte předpoklad. Pokud požadované řešení není
podloženo důkazy, vysvětlete bezpečnější alternativu.

Úplný rozbor této struktury najdete v článku jak psát lepší prompty pro AI. Pro každodenní vzory implementace použijte prompt engineering pro vývojáře. Pokud jde o incident, postupujte podle šablon promptů pro ladění produkčních problémů.

Výstup terminálu je také důkaz. Procvičte si pracovní postup příkazového řádku v prohlížeči, než jej zapíšete do hlášení chyby, testu nebo promptu pro automatizaci.