Jak zkušení vývojáři používají AI jinak

Zkušení vývojáři nepoužívají AI všichni stejně, ale silné technické návyky vytvářejí rozpoznatelný vzor: poskytují kontext, žádají o analýzu, omezují změnu a ověřují výstup. Rozdíl spočívá méně v chytrém znění promptu a více v odmítnutí delegovat úsudek bez důkazů.

Jde o užitečné postupy, nikoli o tvrzení o každém zkušeném vývojáři nebo o hierarchii toho, kdo smí AI používat.

Vágní požadavky versus zadání s kontextem

Méně spolehlivý požadavek	Spolehlivější technický vzor
„Refaktorujte tuto komponentu.“	Vysvětlete duplicitu, chování, které je třeba zachovat, vymezené soubory a testy, které musí zůstat zelené.
„Opravte mobilní navigaci.“	Popište problém použitelnosti na mobilu a zároveň chraňte chování desktopu a stav routy.
„Zrychlete to.“	Požádejte o změřené úzké hrdlo, konkurenční hypotézy a nejmenší měřitelné zlepšení.

Kontext umožňuje asistentovi vybrat mezi věrohodnými technickými možnostmi. Bez něj může asistent optimalizovat viditelný kód namísto skutečného problému uživatele.

Nejdříve odpovědi versus nejdříve analýza

Krátký požadavek na implementaci je vhodný pro zřejmou utilitu. Je rizikový pro přechody stavu, vlastnictví dat, kontroly oprávnění nebo produkční selhání.

Prompt nejprve pro analýzu vypadá takto:

Před úpravou sledujte, jak se předvolby oznámení přesunou z formuláře do
uloženého uživatelského záznamu a zpět do UI.

Určete jediného zapisovače, cestu čtení a chybovou cestu. Oddělte
potvrzené chování od předpokladů. Poté uveďte nejmenší soubory, které se pravděpodobně
změní, a test, který by nahlášenou chybu prokázal.

Asistent se nejprve stává partnerem pro průzkum. Vývojář může zrevidovat model systému, než přijme patch.

Rozsáhlé změny versus přírůstkové změny

Jeden široký úkol může spojit opravu chyby, refaktoring, přepis testu a změnu stylů. Tím se těžko rozpoznává příčina a následek.

Místo toho použijte kontrolní body:

1. Zreprodukujte selhání a popište aktuální cestu.
2. Proveďte nejmenší opravu chování.
3. Přidejte cílený regresní test a spusťte jej.
4. Ukažte diff a odděleně vysvětlete zbývající úklid.

Není to zbytečná práce. Malé změny zvyšují bezpečnost revize, vrácení změn i reakce na incident.

Důvěra ve výstup versus ověřování výstupu

Kód vygenerovaný AI může být dobře formátovaný, typově bezpečný a přesto pro produkt nesprávný. Silné pracovní postupy ověřují na několika úrovních:

Statické kontroly: kontrola typů, linting, validace schématu.
Kontroly chování: cílené jednotkové nebo integrační testy.
Kontroly produktu: ruční pracovní postup odpovídající problému uživatele.
Kontroly revize: kontrola diffu kvůli regresím rozsahu, oprávnění, locale a vedlejších účinků.

Požádejte asistenta, aby tyto kontroly navrhl, a pak si relevantní z nich spusťte sami. Pokud nelze kontrolu spustit místně, zaznamenejte mezeru místo tvrzení o úspěchu.

Myšlení nejprve implementací versus nejprve problémem

První nápad na implementaci je často nejdražší způsob, jak vyřešit příznak. Začněte problémem:

Problém: Student po přepnutí karet prohlížeče na malé obrazovce ztratí aktuální
úkol.

Nepředpokládejte, že odpovědí je nová vrstva perzistence. Prozkoumejte aktuální
navigaci, vlastnictví stavu a chování obnovení. Doporučte nejmenší
změnu, která studentovi umožní vrátit se k aktivnímu úkolu, aniž by duplikovala
stav nebo oslabila soukromí.

To zachovává prostor pro jednodušší odpověď: opravu routingu, opravu zastaralého stavu nebo jinou mobilní interakci.

Návyk zkušených vývojářů je návyk revize

Nejpřenositelnějším vzorem není „používejte určitý model“ ani „pište delší prompty“. Je jím zpřístupnění práce revizi:

Vysvětlete, proč na změně záleží.
Uveďte, co musí zůstat pravdivé.
Zeptejte se, který důkaz by mohl plán vyvrátit.
Omezte první změnu.
Definujte důkaz, že fungovala.

Tak přemýšlí dobrý spolupracovník o tiketu nebo pull requestu. AI jen zviditelňuje potřebu explicitního kontextu.

Vzor promptu k osvojení

Problém: [Dopad na uživatele nebo systém.]
Důkazy: [Reprodukce, selhávající test, logy nebo aktuální chování.]
Předpoklad: [Co si myslíte, že se může dít.]
Rozsah: [Co je třeba prozkoumat jako první.]
Omezení: [Co se nesmí změnit.]
Výsledek: [Pozorovatelný úspěch.]
Ověření: [Testy, ruční cesta, měření, revize.]

Před úpravou analyzujte aktuální chování. Zpochybněte předpoklad a
navrhněte nejmenší změnu podloženou důkazy.

Úplnou strukturu najdete v článku jak psát lepší prompty pro AI, poté použijte prompt engineering pro vývojáře pro přizpůsobení práci na implementaci, ladění a revizi. Kontrolní seznam toho, co se pokazí při vynechání těchto návyků, najdete v článku chyby AI asistentů pro programování a jak se jim vyhnout.

Pro práci založenou na příkazech platí stejný princip: ověřujte skutečný vstup a výstup namísto hádání chování skriptu. Procvičujte scénáře příkazového řádku v prohlížeči, než budete psát nebo revidovat automatizaci.