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. ...