2. diel - Spec-driven development a Codex Nové

V minulej lekcii, Vývoj s AI - Príprava VS Code a Codexu , sme si predstavili vývoj s AI, pripravili VS Code a Codex a založili projekt spoločnosti EnergoSun.

V tomto tutoriále kurzu vývoja aplikácií s AI pripravíme zadanie pre portál interných požiadaviek spoločnosti EnergoSun. Vo Visual Studio Code vytvoríme dokument SPEC.md vo formáte Markdown, popíšeme súčasný firemný proces a pomocou Codexu skontrolujeme, čo v špecifikácii chýba. Budeme postupovať podľa princípu spec-driven development, teda vývoja riadeného zadaním. Programový kód zatiaľ vytvárať nebudeme.

Vibe coding a spec-driven development

Predstavme si, že chceme postaviť dom. Prídeme za staviteľom a povieme mu iba: "Postav mi dom." Staviteľ začne pracovať. Neskôr mu povieme, že chceme dve poschodia, takže musí časť práce prerobiť. Potom zmeníme rozmiestnenie miestností a následne pridáme ďalšie požiadavky.

Vibe coding a jeho obmedzenia

Podobne môžeme pracovať aj s AI. Zadáme krátky pokyn, skontrolujeme výsledok a postupne požadujeme ďalšie zmeny. Tento prístup sa často označuje ako vibe coding.

Jeho výhodou je rýchly začiatok bez podrobného zadania. Pri väčších aplikáciách ale môžu opakované zmeny prinášať rozpory a chyby, zaberať čas a rýchlejšie čerpať dostupné limity AI.

Ak napríklad zadáme iba "Vytvor aplikáciu na zamestnanecké požiadavky", nehovoríme, kto ju bude používať, ako dnes požiadavky fungujú, čo má aplikácia vedieť ani podľa čoho overíme výsledok. AI si potom niektoré rozhodnutia musia domyslieť, podobne ako kolega, ktorému sme neodovzdali úplné zadanie.

Spec-driven development

Preto v tomto kurze používame spec-driven development (SDD), teda vývoj podľa špecifikácie. Najskôr popíšeme problém a pripravíme požiadavky na aplikáciu. Až podľa nich budeme zadávať konkrétne vývojové úlohy.

AI nám môže pomôcť hľadať v špecifikácii nejasnosti, rozpory alebo chýbajúce rozhodnutia, nemala by ale sama určovať, ako firma funguje. Chýbajúce pravidlá preto musíme overiť, nie ich nechať AI domyslieť.

Špecifikácia je zdrojom pravdy pre projekt, zatiaľ čo prompt je konkrétny pracovný pokyn pre práve riešenú úlohu.

Založenie súboru SPEC.md

Otvoríme vo VS Code našu zložku interni-pozadavky/. V Prieskumníku vytvoríme súbor SPEC.md:

Formát Markdown

Prípona .md označuje dokument vo formáte Markdown. Tento jednoduchý textový formát umožňuje zapisovať nadpisy, zoznamy a ďalšiu štruktúru. Súbor bude slúžiť ako zadanie, ktorému porozumejú ľudia aj Codex.

V Markdowne vytvárame nadpis pomocou znakov #, pričom # označuje hlavný nadpis a ## nadpis nižšej úrovne. Text medzi ** zobrazíme tučne, medzi * kurzívou a položky zoznamu zapisujeme napríklad pomocou -. Odkaz zapisujeme v tvare [text odkazu](adresa) a obrázok podobne ako ![popis obrázku](adresa). Pre našu špecifikáciu nám budú stačiť hlavne nadpisy, odseky a zoznamy.

Do súboru vložíme hlavný nadpis # Portál interních požadavků EnergoSun:

Súbor uložíme klávesami Ctrl + S, na macOS Cmd + S. Ukladanie budeme opakovať pri ďalších úpravách.

Popis súčasného problému

Zamestnanci riešia napríklad nefunkčný pracovný telefón, prístup do zdieľanej zložky, potvrdenie od HR alebo chýbajúce pracovné vybavenie. Tieto požiadavky nesúvisia priamo so zákazníckymi zákazkami, ale ovplyvňujú každodenný chod firmy.

Požiadavky dnes prichádzajú e-mailom, chatom, telefonicky alebo osobne. Informácie si zamestnanci opakovane odovzdávajú a časť komunikácie zostáva iba v súkromných správach. Chýba jednotné miesto s požiadavkou, riešiteľom, stavom a výsledkom.

Pre riešenie zvolíme webovú aplikáciu, pretože ju zamestnanci môžu otvoriť v prehliadači na počítači aj telefóne bez inštalácie samostatnej aplikácie. Pre jednu malú firmu tak môžeme vytvoriť jedno rozhranie dostupné z viacerých zariadení.

Prvý zápis do špecifikácie

Do SPEC.md doplníme:

## Kontext společnosti

EnergoSun má 15 zaměstnanců v kancelářských a terénních rolích.
Interní provozní požadavky přicházejí e-mailem, chatem,
telefonicky nebo osobně.

## Současný problém

Požadavky nemají jednotnou evidenci, odpovědného řešitele
ani dohledatelný stav. Zaměstnanci nevědí, kdo se požadavku
věnuje, a vedení nemá přehled o neuzavřených případech.

## Cíl aplikace

Vytvořit jednoduchou webovou aplikaci pro evidenci a sledování
interních provozních požadavků zaměstnanců.

Tri zapísané časti oddeľujú prostredie firmy, problém a zamýšľaný výsledok. Vďaka nim bude pre nás aj pre AI jednoduchšie nájsť potrebné informácie.

Súčasný firemný proces

Než navrhneme aplikáciu, popíšeme postup, ktorý firma používa teraz. Proces si môžeme predstaviť ako cestu zásielky. Ak nepoznáme jej začiatok, jednotlivé odovzdania ani miesto, kde sa môže stratiť, nedokážeme navrhnúť spoľahlivejšiu cestu.

Súčasný proces prebieha takto:

1. Zamestnanec odovzdá požiadavku kolegovi, manažérovi alebo pracovníkovi, o ktorom sa domnieva, že ho rieši.
2. Ak príjemca nie je správnym riešiteľom, zistí, komu požiadavku odovzdať.
3. Požiadavka sa dostane k zodpovednému pracovníkovi.
4. Riešiteľ vykoná potrebnú činnosť.
5. Výsledok oznámi zamestnanci.

Hranice a slabé miesta procesu

Proces začína odovzdaním internej požiadavky a končí oznámením výsledku. Samotnú opravu telefónu, vystavenie potvrdenia alebo objednania vybavenia automatizovať nebudeme. Aplikácia bude evidovať požiadavku a jeho priebeh.

Z popisu vyplývajú hlavné problémy:

• požiadavka sa môže stratiť,
• nie je jasné, kto ho rieši,
• zamestnanec nevidí aktuálny stav,
• chýba spoločná história,
• vedenie nemá prehľad o neuzavretých prípadoch.

Priebeh aj problematické miesta ukazuje diagram súčasného stavu:

Doplnenie procesu do SPEC.md

Do špecifikácie zapíšeme:

## Současný proces

1. Zaměstnanec předá požadavek kolegovi, manažerovi nebo pracovníkovi, o kterém se domnívá, že jej řeší.
2. Pokud příjemce není správným řešitelem, zjistí, komu požadavek předat.
3. Požadavek se dostane k odpovědnému pracovníkovi.
4. Řešitel provede potřebnou činnost.
5. Výsledek oznámí zaměstnanci.

### Slabá místa

- Požadavek se může ztratit.
- Není jasný jeho aktuální řešitel.
- Zaměstnanec nevidí stav řešení.
- Chybí společná historie.
- Vedení nemá přehled o neuzavřených případech.

Náš súbor SPEC.md teraz vyzerá takto:

Kontrola procesu pomocou Codexu

Codex zatiaľ nepožiadame o vytvorenie aplikácie. Necháme ho iba hľadať nejasnosti v popísanom procese:

Přečti soubor SPEC.md.

Nevytvářej programový kód a neměň žádný soubor.
Zkontroluj pouze popis současného procesu. Upozorni:
1. na nejasné kroky,
2. na chybějící informace o předávání požadavku,
3. na místa, kde se může požadavek ztratit.

Chybějící informace nevymýšlej. Formuluj je jako otázky, které je potřeba ověřit s firmou.

Pred odoslaním promptu súbor uložíme pomocou Ctrl + S. Inak môže Codex pracovať so staršou verziou súboru. Vo VS Code môžeme tiež zapnúť Súbor -> Automatické ukladanie.

Všimnime si , že prompt stanovuje zdroj informácií, rozsah kontroly aj obmedzenia činnosti agenta. Codex má odpovedať iba na zadanú analytickú úlohu. Kliknutím na odosielaciu šípku v paneli Codexu požiadavku odošleme.

Vyhodnotenie odpovede

Codex upozorní na možné slabé miesta zadania. Jeho výstup môže vyzerať takto:

V našom príklade Codex upozornil, že v prvom kroku nie je určené, podľa čoho zamestnanec vyberá príjemcu požiadavky. Pri odovzdávaní tiež chýba postup, ako príjemca zistí správneho riešiteľa. Nie je ani popísané, ako sa potvrdzuje prevzatie požiadavky.

Codex za nás tieto rozhodnutia nerobí. Pomohol nám nájsť konkrétne otázky, ktoré musíme vyriešiť sami alebo overiť s ľuďmi, ktorí daný proces vo firme skutočne používajú.

Vytvorili sme dokument SPEC.md, popísali v ňom firemný problém aj súčasný proces a využili Codex na odhalenie nejasností. Máme tak prvý podklad pre riadený vývoj aplikácie. Než zadáme generovanie kódu, potrebujeme spresniť pravidlá, ktoré špecifikácie ešte neobsahujú.

V budúcej lekcii, Špecifikácia MVP vo VS Code s Codexom , vo Visual Studio Code rozšírime špecifikáciu portálu EnergoSun o cieľový proces, užívateľské role, rozsah MVP a základné pravidlá požiadavky.

 

Mal si s čímkoľvek problém? Stiahni si vzorové riešenie nižšie a porovnaj ho so svojím projektom, chybu tak ľahko nájdeš.