Tento text jsem vygenerovala pomocí Claude na základě našich chatů ohledně vibe codingu a následně ho zeditovala.
Aplikaci, kterou jsem vytvořila popisuji tady: Generátor diáře
Tento příspěvek je o tom, co si ze zkoušení vibecoidingu odnáším bez ohledu na konkrétní projekt — tedy věci, které budou platit, i když příště nebudu dělat diář, ale cokoliv jiného.
Co vibe coding je a co není
Šla jsem do toho s představou, že řeknu, co chci, a ono se to napíše samo.
Realita je jiná v jednom podstatném bodě: nejsem tady od psaní kódu, ale od jeho řízení. Model umí napsat rychle skoro cokoliv, ale rozhodnutí, co má vlastně vzniknout, jestli je návrh dobrý a kdy mu nevěřit, zůstávají na mně a nedají se delegovat.
S tím souvisí past, která mě zajímá nejvíc, protože je nenápadná: aplikace běží, výsledek vypadá hotově, a já mám dojem, že kódu rozumím. Ve skutečnosti mu nerozumím a dozvím se to až ve chvíli, kdy se objeví chyba, kterou nechytím okem a nevím, kde ji začít hledat. Za dva týdny se z nikoho nestane programátor, ale dá se naučit něco skoro stejně užitečného — poznat, kdy mě model vede špatně.
Modely a kredity
Mám k dispozici tři úrovně modelů a chvíli mi trvalo, než jsem přestala automaticky sahat po tom nejsilnějším.
Haiku používám na drobnosti, přejmenování a rychlé dotazy typu „co znamená tenhle pojem“.
Sonnet je pracovní kůň na většinu skutečné práce.
Opus si nechávám na návrh řešení a na složitější hledání chyb, kde ostatní modely zaseknou.
Na kreditech nejvíc ušetřilo to, že na nový úkol zakládám nový chat. Každá zpráva totiž posílá celou dosavadní konverzaci znovu, takže dlouhá vlákna jsou nečekaně drahá. Dál pomohlo nechat si u větších změn napsat nejdřív plán a teprve po jeho odsouhlasení kód, a neposílat celé soubory tam, kde stačí úryvek.
Zároveň jsem si ověřila, že se šetření nedá dovést do extrému. Když se s levnějším modelem hodinu peru s úkolem, na který nestačí, stojí mě to víc času i víc iterací, než kdybych rovnou vzala silnější model. Přesně proto jsem v jednom místě přepnula ze Sonnetu na Opus — odpověď mi nevyhovovala a další kola dohadování by vyšla dráž než ten drahý model.
Jak psát zadání
Tohle mi dalo ze všeho nejvíc, protože jsem zjistila, že dobrý prompt má strukturu a nepíše se jen tak podle citu. Šablonu, kterou teď opakovaně používám, bych shrnula do pěti bodů.
Na první řádek patří technické mantinely, tedy v čem to má být napsané a jak to chci spouštět. Bez toho dostanu projekt s knihovnami a build krokem, nad kterým pak stojím a nevím, proč se nic nespustí. Druhá věc je jedna věta o tom, co aplikace dělá a k čemu je — díky ní model tam, kde nejsem konkrétní, odhaduje v můj prospěch. Třetí je oddělit data od chování, protože pak přesně vím, na který kus zadání ukázat, když chci něco změnit. Čtvrtá a asi nejužitečnější věc je rozepsat aplikaci na jednotlivé obrazovky a stavy, místo abych napsala „udělej mi appku“. A pátá je být konkrétní tam, kde mi na detailu záleží, a nechat volnost tam, kde ne; kdybych diktovala každý pixel, píšu to vlastně sama, jen pomaleji, a kdybych nediktovala nic, dostanu obecný výsledek, který mi nesedne.
K tomu mám tři pravidla pro každý další prompt.
Jeden prompt řeší jeden cíl, protože když do něj napíšu tři věci najednou, dostanu rozbředlý výsledek a nepoznám, co přesně je rozbité.
Zadání musí být testovatelné, tedy takové, u kterého po vygenerování umím říct funguje/nefunguje podle konkrétní věci — „odpočet skončí na nule“ se ověřit dá, „ať je to hezké“ ne.
A když něco opravuju, popisuju příznak, ne řešení; místo „přidej tenhle příkaz“ napíšu „odpočet se nehýbe a stojí na stejném čísle“, protože model trefí příčinu často líp než já a já se u toho něco naučím.
Návyky, bez kterých se to rozpadne
Tady jsem se spálila nejvíc, takže tyhle body beru vážně. Verzování není akademická správná praxe, ale záchranná síť. Zjistila jsem, že nevím, kde se kód ukládá, a tak nemám uloženou ani jednu verzi kódu, jen vygenerovaná PDF, a nemám se tedy kam vrátit. Od té chvíle vím, že bez uložených verzí každá další úprava přepisuje jediný existující kód.
Druhý návyk je číst navrženou změnu předtím, než ji přijmu, a ne odklikávat naslepo. A třetí zní triviálně, dokud se to nestane: vědět, kam se generovaný kód fyzicky ukládá.
Rozsah projektu
Naučila jsem se předem pojmenovat, co do projektu nepatří. U mě to bylo hlavně sdílení obsahu mezi uživateli a blokování aplikací v telefonu. Obojí znělo dobře a obojí by z projektu na pár odpolední udělalo závazek na měsíce, který bych nedokončila.
<critic>Věta „ať z toho benefitují i ostatní“ schovávala dvě různě náročné věci. Vystavit aplikaci veřejně, aby si každý navolil svoje, je jednoduché a zvládne se to hned. Sdílení obsahu mezi uživateli znamená backend, databázi, moderaci a řešení spamu. To druhé není další funkce, ale úplně jiný projekt.</critic>
Kdy zpevňovat základy
Rozdělení kódu na komponenty jsem chtěla řešit dřív, než bylo potřeba. Ukázalo se, že má smysl počkat, až budu mít druhou variantu layoutu, protože teprve tehdy je vidět, co se opakuje a co se liší. Naopak úpravy, které se dotknou celé aplikace — třeba převedení rozměrů na jednu centrální hodnotu, ze které se ostatní dopočítávají — se vyplatí udělat brzy, dokud je projekt malý a dotčených míst je málo.
Užitečný nástroj, který jsem si při tom osvojila, je diagnostický prompt: nechám si vysvětlit, jak je něco v kódu udělané, ale výslovně zakážu cokoliv měnit. Nejdřív si přečtu, jak to je, pak se rozhodnu, jestli přestavbu chci, a teprve potom ji zadám jako samostatný krok.
Chat a Code tab
Poslední praktická věc, která mě na začátku mátla: Code tab je samostatná session a nenese si kontext z chatu. Ustálila jsem si dělbu, kde v chatu přemýšlím a učím se, tedy ladím formulaci zadání nebo se ptám, co znamená chybová hláška, a v Code tabu potom pracuju se soubory. Instrukce typu „vysvětluj mi programátorské pojmy polopaticky“ se také nepřenese sama — buď ji napíšu do nastavení projektu, nebo ji musím zopakovat v prvním promptu každé nové session.