Myslím, že mnoho lidí, kteří by mohli chtít vyvinout nový softwarový projekt, často zakopne na začátku v procesu jeho spuštění, protože se zdá být tak skličující začínat s prázdným repozitářem. Tak jsem si řekl, že rychle projdu svůj nejnovější pracovní postup, který dramaticky snižuje laťku, pokud jde o úsilí a čas potřebný k zahájení. Zdaleka nejdůležitější je mít dobrý nápad nebo to, co by bylo užitečné pro mnoho lidí, pokud by to opravdu fungovalo správně a dělalo to, co se snaží dělat dobře. S touto částí vám opravdu nemohu pomoci, ale běžná rada poškrábat se na vlastním svědění a vyřešit své vlastní (nespecializované) bolestivé body je velmi dobrý způsob, jak začít. Přistihl jsem se, že neustále přemýšlím o nápadech na projekty. Každopádně dalším krokem je napsat nápad neformálně, stejně jako byste to mohli udělat v rychlém e-mailu blízkému příteli. Nesnažíte se z toho udělat formální plán, jen nejrychlejší způsob, jak sdělit základní myšlenku a to, co dělá, a specifikovat všechny části technologického stacku nebo knihoven, o kterých víte, že je chcete použít. Přiložené snímky obrazovky ukazují příklad tohoto nápadu, který jsem náhodně dostal před několika dny. Trvalo mi asi 10 nebo 15 minut, než jsem to napsal. Nemusí být dlouhý a může odkazovat na jiné zdroje, aby byl stručný. Tento počáteční popis se pak stane výzvou pro GPT-5 Pro. To obvykle trvá nejméně 15 nebo 20 minut (zábavně déle než trvá napsání výzvy). Můžete zkusit i jiné modely, ale budou mnohem horší. Často pak vezmu stejnou výzvu a předám ji Grok4 Heavy nebo Opus4.1 a vložím tyto nápady zpět do GPT-5 Pro a povzbudím Pro, aby přijal všechny dobré nápady, které vidí v ostatních návrzích. Pokud je v těchto plánech skutečně něco chytrého, GPT-5 Pro to rozpozná a začlení. Poté požádám Pro, aby na základě jeho první odpovědi vytvořil podrobný, podrobný dokument plánu markdownu a uložím jej jako soubor do nově vytvořené složky projektu. Pak to často několikrát zopakuji, zahájím novou konverzaci Pro ve webové aplikaci a dám celý soubor plánu markdown a řeknu mu, aby plán vylepšil různými způsoby, aby byl spolehlivější, robustnější, výkonnější, intuitivnější, uživatelsky přívětivější a další dobrá přídavná jména. A povzbudím Pro, aby provedl vyčerpávající webový průzkum nejnovější dokumentace, blogů, tutoriálů atd., aby našel lepší knihovny nebo způsoby, jak věci dělat. Pak vezmu jeho navrhované revize a vložím je do codexu a požádám codex, aby tyto revize integroval do existujícího dokumentu markdown planu. Po 2 nebo 3 kolech se věci stabilizují a dostanete opravdu dobrý, propracovaný plán. To je klíč ke všemu, protože když jsou věci ještě ve fázi plánu, je mnohem snazší je ladit a vylepšovat, protože ještě nemáte žádný kód. Dvakrát měřit, jednou řezat atd. Zde je odkaz na výsledný dokument plánu, který pochází z původní výzvy k tomuto nápadu: V tomto okamžiku začnu přidávat soubor AGENTS dot md; Začnu s existujícím, který mám, a požádám Pro (ve stejné relaci, kdy byl napsán nejnovější dokument plánu), aby jej přizpůsobil pro tento nový projekt a technologický stack při zachování čehokoli obecného. Pokud existují nějaké kriticky důležité knihovny, někdy také vytvořím specializovaného průvodce osvědčenými postupy (řekněme, že pokud vytváříte server MCP, vygeneruji průvodce osvědčenými postupy specializovaný na knihovnu fastmcp, ale kde také vysvětlím, jak strukturovat projekt atd.) V tomto okamžiku pak požádám Codex, aby během jednoho sezení začal vytvářet strukturu projektu, vytvářet složky a prázdné zástupné soubory, vytvářet soubor .gitignore atd. Zde se můj proces dramaticky liší od typického přístupu. Nejprve použiji projekt korálků Steva Yeggeho a řeknu kodexu, abych z dokumentu plánu udělal hromadu úkolů a dílčích úkolů pomocí korálků. Pak použiji tmux k vytvoření několika sezení kodexu, až 8 najednou (myslím, že více než to by také fungovalo dobře)...

Zde je odkaz na mé vlákno o uzavření automatizační smyčky pomocí tmux: