Wat maakt een goed markdown-plan document voor een softwareontwikkelingsproject? Wat is het verschil tussen een goed plan en een geweldig plan? Ik blijf maar zeggen dat ik meer dan 85% van mijn tijd en energie aan de planningsfasen besteed. Maar wat houdt dat precies in? Het is moeilijk om dat abstract uit te leggen; je hebt een tastbaar voorbeeld nodig om de nuances echt te illustreren. Dus ik dacht dat ik een goed voorbeeld van vandaag zou delen. Dit behandelt ook een recente vraag die ik heb gekregen over mijn aanpak. Mensen lijken de indruk te hebben dat je alles in je project in één keer moet doen. En in mijn aanpak is dat waar, maar alleen voor versie 1! Als je besluit dat je nieuwe functies wilt toevoegen of hoe dingen werken wilt veranderen, kun je dat uiteraard doen zodra je een functionele v1 hebt. En de manier waarop je dat doet, is dezelfde manier waarop je v1 creëert, door eerst een supergedetailleerd markdown-plan te maken en dat vervolgens om te zetten in beads. Dus ik geef je een voorbeeld van Cass, mijn Coding Agent Session Search-programma, dat een vrij uitgebreid Rust-programma is dat automatisch al je eerdere sessielogs van bijna elke coding agent daarbuiten detecteert, parseert, opslaat en indexeert. Het biedt sub 50ms instant "zoeken terwijl je typt" over al die logs en heeft veel andere leuke functies. Ik besloot dat ik een functie aan Cass wilde toevoegen die vergelijkbaar is met een functie die ik al heb in MCP Agent Mail en in beads_viewer (bv): de mogelijkheid om je setup als een statische website te exporteren die kan worden gehost met GitHub Pages. Je kunt een voorbeeld voor bv voor dit specifieke project zien, wat het eindresultaat is van het planningsproces dat ik in deze post zal beschrijven: Deze functionaliteit maakt het heel snel en eenvoudig om de geëxporteerde site te genereren en te implementeren met de gh-tool. De site zelf bestaat meestal uit een sqlite-bestand en een aantal typescript en wasm die volledig in de browser draaien, maar met zeer goede prestaties en leuke functies en styling, die je kunt observeren in het zojuist gegeven voorbeeld. Nu, het delen van MCP Agent Mail-berichten of een aantal beads is één ding, maar het delen van een aantal coding agent sessielogs is heel anders; deze dingen zitten vaak vol met gevoelige informatie, API-sleutels, scheldwoorden/uitdrukkingen (tenminste die van mij!), en ander materiaal dat je absoluut niet aan de wereld wilt blootstellen. Maar GitHub Pages, hoe leuk het ook is, werkt alleen voor openbare repos (overigens ondersteunen mijn tools ook Cloudflare-pagina's, maar GH Pages is beter en gemakkelijker voor deze use case). Dus hoe ga je met deze problemen om? Het antwoord is encryptie: de gebruiker selecteert eerst welke coding agents moeten worden opgenomen, welke projectmappen, de tijdsperiode, enzovoort, en er wordt een bundel gegenereerd (let op dat deze bundel in het canonieke formaat is dat Cass intern alle coding agent-berichten omzet vanuit hun oorspronkelijke native formaten) en vervolgens geeft de gebruiker een wachtwoord op dat gebruikt zal worden voor de encryptie van die bundel. Dus het idee is dat hoewel de repo en de webpagina openbaar zijn, iedereen behalve jij en anderen aan wie je het wachtwoord vertelt, gewoon een wachtwoordveld zullen zien en niet in staat zullen zijn om een van de berichten te lezen. Zodra het wachtwoord is ingevoerd, zou het een prachtige, responsieve UI ontgrendelen die je in staat stelt om bijna net zo snel en efficiënt door de berichten te zoeken als Cass doet. En als je echt niets te verbergen hebt, kun je het wachtwoord weglaten en alles daadwerkelijk openbaar maken. Hoe dan ook, dit is een super complexe nieuwe functie om toe te voegen om veel redenen. De exportwizard alleen is extreem ingewikkeld en complex. Maar de aanvullende vereisten rond encryptie en beveiliging maken het moeilijk om dit goed te krijgen. Hoe dan ook, ik vroeg Claude Code met Opus 4.5 om eerst alle relevante code van mijn bv-project te bestuderen voor het implementeren van deze functie, en toen legde ik uit hoe de overeenkomstige functie in Cass zou moeten verschillen. Het maakte toen een eerste versie van een plan voor me. Ik vroeg CC om de bv-code opnieuw te controleren voor meer inzichten en begrip van hoe de functie in bv was geïmplementeerd en om die inzichten te gebruiken om het plandocument ter plaatse uit te breiden en te verbeteren. Uiteindelijk verplaatste ik het plan naar ChatGPT Pro in de browser met GPT 5.2 met Extended Reasoning samen met deze prompt inleiding: "Beoordeel dit hele plan zorgvuldig voor me en kom met je beste revisies in termen van betere architectuur, nieuwe functies, gewijzigde functies, enz. om het beter, robuuster/betrouwbaarder, beter presterend, aantrekkelijker/nuttiger, enz. te maken. Voor elke voorgestelde wijziging, geef me je gedetailleerde analyse en rationale/rechtvaardiging waarom het het project beter zou maken, samen met de git-diff stijl wijziging versus het originele plan hieronder:" Ik plakte de outputs in Claude Code als volgt: OK, integreer nu deze revisies in het markdown-plan ter plaatse; gebruik ultrathink en wees nauwkeurig. Aan het einde kun je me vertellen welke wijzigingen je van harte ondersteunt, welke je gedeeltelijk ondersteunt en welke je niet ondersteunt: ```[Geplakte tekst #1 +995 regels]``` Ik herhaalde dit nog 2 keer. Dit is geen snel proces: de laatste beoordeling, waarvan je hieronder een screenshot kunt zien, duurde 27 minuten om te voltooien: Je kunt het uiteindelijke ~3.500-regelige markdown-plan hier zien: Maar wat interessanter is, is om de revisies in GitHub te zien, waar je de enorme verbeteringen kunt zien die zijn aangebracht van v2 naar v3, en hoe de verbeteringen daadwerkelijk doorgaan tot het einde: Dit duurde in totaal ongeveer 3 uur. Ik vermoed dat dit is waarom de meeste mensen blijkbaar niet bereid zijn om dit niveau van planning te doen. Het voelt alsof je niet veel gedaan krijgt omdat er geen code wordt geschreven, maar als je het goed doet en dan genoeg agents in je zwerm opstart met Agent Mail, Beads en bv, dan zal de code zo belachelijk snel worden geschreven dat het deze langzame fase meer dan compenseert. En wat meer is, de code zal echt goed zijn. Terugkomend op het verhaal, was ik toen klaar om het plan om te zetten in beads. Ik heb dat proces al in een andere recente post uitgelegd, maar de essentie ervan is om deze prompt met Claude Code te gebruiken: "OK, lees nu ALLES van PLAN_TO_CREATE_GH_PAGES_WEB_EXPORT_APP.md; neem ALLES daarvan en werk het uit en gebruik het om een uitgebreide en gedetailleerde set beads voor dit alles te creëren met taken, subtaken en afhankelijkheidsstructuur overlaid, met gedetailleerde opmerkingen zodat het geheel volledig zelfvoorzienend en zelfdocumenterend is (inclusief relevante achtergrond, redenering/rechtvaardiging, overwegingen, enz.-- alles wat we onze "toekomstige zelf" willen laten weten over de doelen en intenties en het denkproces en hoe het de overkoepelende doelen van het project dient). De beads moeten zo gedetailleerd zijn dat we nooit meer naar het oorspronkelijke markdown-plandocument hoeven te verwijzen. Vergeet niet om ALLEEN de `bd`-tool te gebruiken om de beads te maken en te wijzigen en de afhankelijkheden toe te voegen. Gebruik ultrathink." Daarna deed ik gewoon ronde na ronde van deze vervolgprompt in Claude Code: "Herlees AGENTS dot md zodat het nog vers in je geheugen zit. Lees dan ALLES van PLAN_TO_CREATE_GH_PAGES_WEB_EXPORT_APP.md. Gebruik ultrathink. Controleer elke bead super zorgvuldig-- ben je zeker dat het logisch is? Is het optimaal? Kunnen we iets veranderen om het systeem beter te laten werken voor gebruikers? Als dat zo is, herzie de beads. Het is veel gemakkelijker en sneller om in "planningsruimte" te opereren voordat we deze dingen gaan implementeren! OVERSIMPLIFICEER DE DINGEN NIET! VERLOREN GEEN FUNCTIES OF FUNCTIONALITEIT! Zorg er ook voor dat we als onderdeel van de beads uitgebreide eenheidstests en e2e-testscripts met geweldige, gedetailleerde logging opnemen, zodat we er zeker van kunnen zijn dat alles perfect werkt na de implementatie. Het is cruciaal dat ALLES van het markdown-plan in de beads wordt ingebed, zodat we nooit meer naar het markdown-plan hoeven te verwijzen en we geen belangrijke context of ideeën of inzichten in de nieuwe functies die gepland zijn en waarom we ze maken, verliezen." Na ongeveer 8 of 9 rondes bereikt het eindelijk een stabiele staat. Ik liet Codex met GPT 5.2 hoge redenering inspanning een laatste ronde doen met dezelfde prompt. Het uiteindelijke resultaat is te zien op de link die hierboven is gedeeld. En dat, vrienden, is wat een goed plan eruit ziet. En ook wat een goede set beads op basis van een plan eruit ziet. Die beads zijn zo gepolijst en gedetailleerd dat je mechanisch een grote zwerm agents kunt ontketenen om het te implementeren met Agent Mail, Beads en bv, en het zal vrijwel perfect uitkomen zonder veel gedoe. Ik ben te moe om vanavond met dat implementatiewerk te beginnen, maar ik zal het morgen doen en dan de nieuwe functie delen, waarvan ik denk dat Cass-gebruikers het echt leuk gaan vinden.

Voordat je veel tokens verbrandt met een grote agentenzwerm voor een nieuw project, is de oude houtbewerkingsmaxime "Meet twee keer, snijd één keer!" het waard om te herzien als "Controleer je kralen N keer, implementeer één keer," waarbij N in feite zoveel is als je kunt verdragen. Ik heb ontdekt dat je steeds meer verbeteringen krijgt, zelfs als ze subtiel zijn, hoe vaker je dit achter elkaar uitvoert met Opus 4.5 (let op dat de volgende prompt alleen gebruikt mag worden NADAT je je oorspronkelijke markdownplan in kralen hebt omgezet met de andere prompt die ik onlangs in mijn recente zeer lange post over mijn workflows heb gegeven): "Lees AGENTS dot md opnieuw door zodat het nog vers in je geheugen zit. Controleer elke kraal super zorgvuldig-- ben je zeker dat het logisch is? Is het optimaal? Kunnen we iets veranderen om het systeem beter te laten werken voor gebruikers? Zo ja, herzie de kralen. Het is veel gemakkelijker en sneller om in "planningsruimte" te opereren voordat we deze dingen gaan implementeren! OVERSIMPLIFICEER DE ZAKEN NIET! VERLOREN GEEN FUNCTIES OF FUNCTIONALITEIT! Zorg er ook voor dat we als onderdeel van deze kralen uitgebreide eenheidstests en e2e-testscripts opnemen met geweldige, gedetailleerde logging, zodat we zeker kunnen zijn dat alles perfect werkt na de implementatie. Vergeet niet om ALLEEN de `bd`-tool te gebruiken om de kralen te maken en te wijzigen en om de afhankelijkheden aan de kralen toe te voegen. Gebruik ultrathink." Ik voerde dat vroeger maar één of twee keer uit voordat ik met de implementatie begon, maar ik experimenteerde onlangs met het zes keer of meer uitvoeren, en het bleef nuttige verfijningen opleveren. Als het begint te stabiliseren in termen van incrementele verbeteringen aan de kralen, kun je proberen een gloednieuwe CC-sessie te starten, te beginnen met: "Lees eerst ALLE AGENTS dot md-bestand en README dot md-bestand super zorgvuldig en begrijp ALLES van beide! Gebruik vervolgens je code-onderzoeksagentmodus om de code, de technische architectuur en het doel van het project volledig te begrijpen. Gebruik ultrathink." En volg dan op met dezelfde prompt als hierboven weergegeven, maar voorafgegaan door: "We hebben onlangs een markdownplanbestand omgevormd tot een heleboel nieuwe kralen. Ik wil dat je deze heel zorgvuldig beoordeelt en analyseert met behulp van `bd` en `bv`." Hoe complexer en ingewikkelder je markdownplan is, hoe relevanter deze techniek is. Als je een klein, triviaal plan en een heel eenvoudig project hebt, is dit uiteraard overkill. Maar in dat geval zul je waarschijnlijk weinig zien aan incrementele winsten/wijzigingen met elke ronde, dus het zou vrij duidelijk moeten zijn wanneer het tijd is om te stoppen. Vergeet niet: plannings tokens zijn veel minder en goedkoper dan implementatietokens. Zelfs een heel groot, complex markdownplan is korter dan een paar substantiële codebestanden, laat staan een heel project. En de modellen zijn veel slimmer als het gaat om het redeneren over een plan dat zeer gedetailleerd en uitgewerkt is, maar nog steeds triviaal klein genoeg om gemakkelijk binnen hun contextvenster te passen (dit is echt de sleutel tot mijn obsessieve focus op planning en waarom ik meer dan 80% van mijn tijd aan dat deel besteed). En als je leunt op GPT Pro met Uitgebreide Redenering in de webapp voor de initiële planning zoals ik sterk aanbeveel (dat wil zeggen, om je markdownplan te creëren en te verbeteren dat je uiteindelijk in kralen omzet), krijg je die in feite op een all-you-can-eat basis met een Pro-plan, dus maak daar volledig gebruik van! Geen ander model kan Pro op het web evenaren wanneer het om input gaat die gemakkelijk in zijn contextvenster past. Het is echt uniek. Nu kun je nog steeds veel extra kilometers maken door slimme ideeën van Gemini3 in de webapp met Deep Think ingeschakeld, of van Grok4 Heavy, of Opus 4.5 in de webapp te mengen, maar je wilt nog steeds GPT Pro op het web gebruiken als de uiteindelijke arbiter van wat je van welk model moet nemen en hoe je het het beste kunt integreren. En aangezien deze post nog steeds zelfs nog komisch lang zou kunnen zijn, laat ik je achter met mijn prompt voor het integreren van die concurrerende plannen in één enkel canoniek "beste van alle werelden" markdownplan: "Ik vroeg 3 concurrerende LLM's om exact hetzelfde te doen en ze kwamen met behoorlijk verschillende plannen die je hieronder kunt lezen. Ik wil dat je hun plannen HEEL zorgvuldig analyseert met een open geest en intellectueel eerlijk bent over wat ze beter hebben gedaan dan jouw plan. Vervolgens wil ik dat je de best mogelijke herzieningen van jouw plan bedenkt (je moet gewoon je bestaande document voor jouw oorspronkelijke plan bijwerken met de herzieningen) die kunstzinnig en vaardig de "beste van alle werelden" mengt om een waarachtige, ultieme, superieure hybride versie van het plan te creëren die het beste onze gestelde doelen bereikt en het beste zal werken in de praktijk om de problemen op te lossen waarmee we worden geconfronteerd en onze overkoepelende doelen, terwijl we het extreme succes van de onderneming zo goed mogelijk waarborgen; je moet me een complete reeks git-diff-stijl wijzigingen geven om jouw oorspronkelijke plan om te zetten in het nieuwe, verbeterde, veel langere en gedetailleerdere plan dat het beste van alle plannen integreert met elk goed idee inbegrepen (je hoeft niet te vermelden welke ideeën van welke modellen in het uiteindelijke herziene verbeterde plan kwamen):" (Hell, nog een prompt voor de lol; ik gebruik deze om een bestaand markdownplan iteratief te verbeteren): "Beoordeel dit hele plan zorgvuldig voor mij en kom met jouw beste herzieningen in termen van betere architectuur, nieuwe functies, gewijzigde functies, enz. om het beter, robuuster/betrouwbaarder, beter presterend, aantrekkelijker/nuttiger, enz. te maken. Voor elke voorgestelde wijziging, geef me jouw gedetailleerde analyse en rationale/rechtvaardiging voor waarom het het project beter zou maken, samen met de git-diff-stijl wijziging ten opzichte van het oorspronkelijke plan hieronder:"

Satanische betrokkenheidsniveaus hier... 𖤐⁶⁶⁶𓃶