Jeg tror mange mennesker som kanskje ønsker å utvikle et nytt programvareprosjekt ofte blir snublet i begynnelsen i prosessen med å starte det, siden det virker så skremmende å starte med et tomt repo. Så jeg tenkte at jeg raskt ville gå gjennom den siste arbeidsflyten min, noe som dramatisk senker standarden når det gjelder innsatsen og tiden som trengs for å komme i gang. Den desidert viktigste delen er å ha en god idé eller hva du skal lage som faktisk ville være nyttig for mange mennesker hvis den virkelig fungerte ordentlig og gjorde det den prøver å gjøre bra. Jeg kan egentlig ikke hjelpe deg med denne delen, men det vanlige rådet om å klø din egen kløe og løse dine egne (ikke-nisje) smertepunkter er en veldig god måte å komme i gang på. Jeg tar meg selv i å tenke på prosjektideer hele tiden. Uansett, neste trinn er å skrive ut ideen uformelt, slik du kan gjøre i en rask e-post til en nær venn. Du prøver ikke å gjøre dette til en formell plan, bare den raskeste måten å formidle den grunnleggende ideen og hva den gjør og spesifisere eventuelle deler av teknologistabelen eller bibliotekene du vet du vil bruke. De vedlagte skjermbildene viser et eksempel på dette for en idé jeg tilfeldig hadde for et par dager siden. Det tok meg kanskje 10 eller 15 minutter å skrive opp. Den trenger ikke å være lang, og den kan referere til andre kilder for å holde den kortfattet. Denne første beskrivelsen blir deretter ledeteksten for GPT-5 Pro. Dette tar vanligvis minst 15 eller 20 minutter å kjøre (morsomt nok lengre tid enn det tar å skrive ledeteksten). Du kan prøve andre modeller, men de vil være mye verre. Jeg tar da ofte den samme meldingen og gir den til Grok4 Heavy eller Opus4.1 og mater disse ideene tilbake til GPT-5 Pro og oppfordrer Pro til å ta alle gode ideer den ser i de andre forslagene. Hvis det faktisk er noe smart i disse planene, vil GPT-5 Pro gjenkjenne det og innlemme det. Deretter ber jeg Pro om å lage et detaljert, detaljert markdown-plandokument basert på det første svaret, og jeg lagrer det som en fil i en nyopprettet prosjektmappe. Så vil jeg ofte iterere på dette noen ganger, starte en ny Pro-samtale i nettappen og gi hele markdown-planfilen og be den om å forbedre planen på forskjellige måter for å gjøre den mer pålitelig, robust, ytende, intuitiv, brukervennlig og andre gode adjektiver. Og jeg vil oppfordre Pro til å gjøre uttømmende nettundersøkelser om den nyeste dokumentasjonen, blogger, opplæringsprogrammer osv. Jeg vil deretter ta de foreslåtte revisjonene og lime dem inn i kodeksen og be kodeksen om å integrere revisjonene i det eksisterende markdown-plandokumentet. Etter 2 eller 3 runder med dette stabiliserer ting seg og du får en veldig god, utfyllende plan. Dette er nøkkelen til alt, for når ting fortsatt er i planfasen, er det mye lettere å justere og forbedre dem fordi du ikke har noen kode ennå. Mål to ganger, kutt en gang osv. Her er en kobling til det resulterende plandokumentet som kom fra den første ledeteksten for dette forslaget: På dette tidspunktet begynner jeg å legge til en AGENTS dot md-fil; Jeg starter med en eksisterende jeg har og ber Pro (i samme økt som det siste plandokumentet ble skrevet) om å tilpasse den for dette nye prosjektet og teknologistabelen samtidig som jeg bevarer noe generisk. Hvis det er noen kritisk viktige biblioteker, vil jeg også noen ganger lage en spesialisert veiledning for beste praksis (for eksempel hvis du lager en MCP-server, vil jeg generere en veiledning for beste praksis spesialisert for fastmcp-biblioteket, men hvor jeg også staver ut hvordan jeg skal strukturere prosjektet osv.) På dette tidspunktet ber jeg kodeksen i en enkelt økt om å begynne å bygge ut prosjektstrukturen, lage mapper og tomme plassholderfiler, lage .gitignore-filen osv. Det er her prosessen min avviker dramatisk fra den typiske tilnærmingen. Jeg bruker først Steve Yegges perleprosjekt og ber codex om å gjøre plandokumentet om til en haug med oppgaver og deloppgaver ved hjelp av perler. Så bruker jeg tmux til å lage en haug med codex-økter, så mange som 8 på en gang (jeg tror mer enn det også ville fungere bra)...

Her er lenken til tråden min om å lukke automatiseringssløyfen med tmux: