Ik heb de miniatuurversie van deze prompt hier opgenomen omdat de serie "Mijn Favoriete Prompts" compact, hapklare, zelfvoorzienende stukjes moet zijn. Maar vandaag heb ik dit omgevormd tot een werkelijk krankzinnig systeem. Het doet er niet toe of je een andere CRUD-programma in React of een TODO-lijst maakt, maar als je iets behoorlijk ingewikkelds doet in Rust of Golang, of iets dat complexe gegevens omvat, dan is deze aanpak bijna eng in wat het kan doen. Het is een proces van 2 rondes. Hier is Ronde 1: --- 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. Dan, zodra je een extreem grondige en nauwkeurige klus hebt geklaard en de hele bestaande systeem en wat het doet, zijn doel, en hoe het is geïmplementeerd en hoe alle onderdelen met elkaar verbonden zijn, diep hebt begrepen, moet je hyper-intensief onderzoeken en studeren en nadenken over deze vragen zoals ze betrekking hebben op dit project: Zijn er andere grote inefficiënties in het kernsysteem? Plaatsen in de codebasis waar 1) wijzigingen daadwerkelijk het verschil zouden maken in termen van algehele latentie/responsiviteit en doorvoer; 2) zodanig dat onze wijzigingen aantoonbaar isomorf zijn in termen van functionaliteit zodat we zeker weten dat het de resulterende outputs niet zou veranderen gegeven dezelfde inputs; 3) waar je een duidelijke visie hebt op een obviously betere aanpak in termen van algoritmen of datastructuren (let op dat je voor dit, in je overpeinzingen, minder bekende datastructuren en meer esoterische/sophisticated/wiskundige algoritmen kunt opnemen, evenals manieren om de probleem(en) opnieuw te formuleren zodat een ander paradigma wordt blootgelegd, zoals de lijst hieronder (Opmerking: Voordat je enige optimalisatie voorstelt, stel baseline-metrics vast (p50/p95/p99 latentie, doorvoer, piekgeheugen) en leg CPU/allocation/I/O-profielen vast om daadwerkelijke hotspots te identificeren): - N+1 query/fetch patroon eliminatie - zero-copy / buffer hergebruik / scatter-gather I/O - serialisatieformaatkosten (parse/encode overhead) - begrensde wachtrijen + terugdruk (voorkom geheugenexplosie en tail latentie) - sharding / gestreepte sloten om concurrentie te verminderen - memoization met cache-invalideringsstrategieën - dynamische programmeertechnieken - convexe optimalisatietheorie - luie evaluatie / uitgestelde berekening - iterator/generator patronen om grote collecties te vermijden - streaming/chunked verwerking voor geheugenbeperkt werk - voorcalculatie en opzoektabellen - index-gebaseerde opzoeking vs lineaire scanherkenning - binaire zoekopdracht (op gegevens en op antwoordruimte) - twee-pointer en sliding window technieken - prefix sommen / cumulatieve aggregaten - topologische sortering en DAG-bewustzijn voor afhankelijkheidsgrafieken - cyclusdetectie - unie-vinden voor dynamische connectiviteit - graf traverseren (BFS/DFS) met vroege beëindiging - Dijkstra's / A* voor gewogen kortste paden - prioriteitswachtrijen / heaps - tries voor prefixbewerkingen - bloomfilters voor probabilistische lidmaatschap - interval/segmentbomen voor bereikqueries - ruimtelijke indexering (k-d bomen, quadtrees, R-bomen) - persistente/onveranderlijke datastructuren - copy-on-write semantiek - object/verbinding pooling - cache-evictiebeleid selectie (LRU/LFU/ARC) - batch-bewuste algoritme selectie - async I/O batching en coalescing - lock-vrije structuren voor hoge concurrentiescenario's - werk-stelen voor recursieve parallelisme - geheugenlay-out optimalisatie (SoA vs AoS, cache-lokalisatie) - short-circuiting en vroege beëindiging - string interning voor herhaalde waarden - geamortiseerde analyse redenering taking in overweging deze algemene richtlijnen waar van toepassing: DP TOEPASBAARHEID CONTROLES: - Overlappende subproblemen? → memoize met stabiele staat sleutel - Optimale partitionering/batching? → prefix sommen + interval DP - Afhankelijkheidsgrafiek met herhaalde traversie? → single-pass topologische DP CONVEX OPTIMISATIE CONTROLES: - Brute-forcing exacte allocatie/planning? → LP / min-kostenstroom met deterministische tie-breaking - Continue parameter fitting met expliciete verlies? → geregulariseerde kleinste kwadraten / QP - Grote decomposable convexe doelstelling? → ADMM / proximale methoden Let ook op dat als er goed geschreven derde partij bibliotheken zijn waarvan je weet dat ze goed zouden werken, we ze in het project kunnen opnemen). METHODOLOGIE EISEN: A) Baseline eerst: Voer de test suite en een representatieve werklast uit; registreer p50/p95/p99 latentie, doorvoer en piekgeheugen met exacte commando's. B) Profiel voordat je voorstelt: Leg CPU + allocatie + I/O-profielen vast; identificeer de top 3–5 hotspots op % tijd voordat je wijzigingen voorstelt. C) Equivalentie-orakel: Definieer expliciete gouden outputs + invarianten. Voor grote invoerruimten, voeg eigenschap-gebaseerde of metamorfische tests toe. D) Isomorfisme bewijs per wijziging: Elke voorgestelde diff moet een korte bewijs schets bevatten die uitlegt waarom outputs niet kunnen veranderen (inclusief ordening, tie-breaking, floating-point gedrag, en RNG zaden). E) Kansenmatrix: Rangschik kandidaten op (Impact × Vertrouwen) / Inspanning voordat je implementeert; focus alleen op items die waarschijnlijk p95+ of doorvoer betekenisvol zullen verplaatsen. F) Minimale diffs: Eén prestatie hefboom per wijziging. Geen niet-gerelateerde refactors. Voeg rollback-instructies toe als er enig risico bestaat. G) Regresie-guardrails: Voeg benchmarkdrempels of monitoring hooks toe om toekomstige regressies te voorkomen. Gebruik ultrathink. --- Je kunt dat eenmaal uitvoeren in Claude Code met Opus 4.5 en eenmaal in Codex met GPT 5.2 Codex (ik begon alleen met Hoog omdat Extra Hoog gewoon te langzaam voor me is, tenzij ik op het punt sta naar bed te gaan). Nadat ze klaar zijn, geef ze elk ongeveer 5 snelle rondes van dit: "Geweldig. Kijk alles nog eens goed na op voor eventuele duidelijke overzichten of omissies of fouten, conceptuele fouten, blunders, enz. Gebruik ultrathink" Laat ze dan de outputs opslaan zoals dit: "OK, sla dat allemaal op als PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md" "OK, sla dat allemaal op als PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md" Dan in Claude Code, doe: "Vergelijk wat je deed met PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md en neem de beste elementen daarvan en verwerk ze in je plan om een hybride beste van beide werelden superieur plan te krijgen door je oorspronkelijke planbestand ter plaatse te bewerken." Dan dit: Herlees AGENTS dot md zodat het nog vers in je geheugen zit. Lees nu ALLES van PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md. Controleer dan 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? We willen een uitgebreide en gedetailleerde set beads voor dit alles 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 terug hoeven te verwijzen naar het oorspronkelijke markdown plan document. Reflecteert het nauwkeurig ALLES van het markdown planbestand op een uitgebreide manier? Als wijzigingen gerechtvaardigd zijn, herzie dan de beads of maak nieuwe of sluit ongeldige of niet-toepasbare. Het is veel gemakkelijker en sneller om in "planruimte" te opereren voordat we deze dingen gaan implementeren! OVERSIMPLIFICEER DE DINGEN NIET! VERLIES GEEN ENKELE FUNCTIE OF FUNCTIONALITEIT! Zorg er ook voor dat we als onderdeel van deze beads, uitgebreide eenheidstests en e2e-testscripts met geweldige, gedetailleerde logging opnemen zodat we zeker kunnen zijn dat alles perfect werkt na implementatie. Vergeet niet om ALLEEN de `bd` tool te gebruiken om de beads te maken en te wijzigen en om de afhankelijkheden aan beads toe te voegen." Dan een paar rondes van: "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 "planruimte" te opereren voordat we deze dingen gaan implementeren! OVERSIMPLIFICEER DE DINGEN NIET! VERLIES GEEN ENKELE FUNCTIE 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 zeker kunnen zijn dat alles perfect werkt na implementatie. Gebruik ultrathink." Laat dan de zwerm los om het allemaal te implementeren. Maak je dan klaar voor RONDE 2.