Før du bruker opp mange tokens med en stor agentstrøm på et nytt prosjekt, er det gamle trearbeidsordtaket «Mål to ganger, kutt én gang!» verdt å revidere som «Sjekk perlene dine N ganger, implementer én gang», hvor N i praksis er så mange du tåler. Jeg har erfart at du stadig får flere og flere forbedringer, selv om de er subtile, jo flere ganger du kjører dette på rad med Opus 4.5 (merk at følgende prompt kun er til bruk ETTER at du allerede har gjort den opprinnelige markdown-planen om til perler ved å bruke den andre prompten jeg nylig ga i mitt veldig lange innlegg om arbeidsflytene mine): "Les AGENTS dot md på nytt så det fortsatt er friskt i minnet. Sjekk hver perle veldig nøye – er du sikker på at det gir mening? Er det optimalt? Kan vi endre noe for å få systemet til å fungere bedre for brukerne? Hvis ja, revider perlene. Det er mye enklere og raskere å operere i «planrom» før vi begynner å implementere disse tingene! IKKE FORENKLE TING FOR MYE! IKKE MIST NOEN FUNKSJONER ELLER FUNKSJONALITET! Sørg også for at vi som en del av disse perlene inkluderer omfattende enhetstester og e2e-testskript med god, detaljert logging, slik at vi kan være sikre på at alt fungerer perfekt etter implementering. Husk å KUN bruke 'bd'-verktøyet for å lage og endre perlene og for å legge til avhengighetene til perlene. Bruk ultratenkning.» Jeg pleide bare å kjøre det én eller to ganger før jeg startet implementeringen, men jeg eksperimenterte nylig med å kjøre det 6+ ganger, og det fortsatte å gjøre nyttige forbedringer. Hvis det begynner å flatline ut i form av gradvise forbedringer av perlene, kan du prøve å starte en helt ny CC-økt, og starte med: "Les først HELE AGENTS dot md-filen og README dot md-filen supernøye og forstå ALT av begge! Bruk deretter kodeundersøkelsesagent-modusen for å fullt ut forstå koden, den tekniske arkitekturen og formålet med prosjektet. Bruk ultratenkning.» Og deretter følger jeg opp med samme prompt som vist ovenfor, men innledet med: "Vi har nylig forvandlet en nedslagsplan til en haug med nye perler. Jeg vil at du skal nøye gjennomgå og analysere disse ved hjelp av 'bd' og 'bv'." Jo mer kompleks og intrikat nedslagsplanen din er, desto mer relevant er denne teknikken. Hvis du har en liten, triviell plan og et veldig enkelt prosjekt, er dette åpenbart overkill. Men i så fall vil du sannsynligvis se lite i form av inkrementelle gevinster/endringer for hver runde, så det bør være ganske åpenbart når det er på tide å stoppe. Bare husk: planleggingstokens er mye færre og billigere enn implementeringstokens. Selv en veldig stor, kompleks markdown-plan er kortere enn noen få substansielle kodefiler, for ikke å snakke om et helt prosjekt. Og modellene er langt smartere når de skal resonnere rundt en plan som er veldig detaljert og gjennomarbeidet, men likevel trivielt liten nok til å passe lett innenfor kontekstvinduet (dette er egentlig hovedinnsikten bak mitt obsessive fokus på planlegging og hvorfor jeg brukte 80 %+ av tiden min på den delen). Og hvis du bruker GPT Pro med Extended Reasoning i nettappen for den innledende planleggingen, slik jeg sterkt anbefaler (altså for å lage og forbedre rabattplanen din som du til slutt gjør om til perler), får du i praksis disse på en all-you-can-eat-basis med en Pro-plan, så utnytt det fullt ut! Ingen annen modell kan røre Pro på nettet når den håndterer input som lett passer inn i kontekstvinduet. Det er virkelig unikt. ...