"Mine favorittoppgaver," av Jeffrey Emanuel Prompt 4: Den storhjernede optimalisatoren "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. Deretter, når du har gjort en ekstremt grundig og grundig jobb med alt dette og dypt forstått hele det eksisterende systemet og hva det gjør, dets formål, hvordan det implementeres og hvordan alle delene henger sammen, trenger jeg at du undersøker, studerer og grubler over disse spørsmålene i forhold til dette prosjektet: Er det noen andre grove ineffektiviteter i kjernesystemet? Steder i kodebasen hvor: 1) endringer faktisk ville flytte nåla når det gjelder total latens/respons og gjennomstrømning; 2) og hvor endringene våre ville være beviselig isomorfe når det gjelder funksjonalitet, slik at vi ville vite med sikkerhet at det ikke ville endre de resulterende utdataene gitt de samme inputene (for tilnærmede numeriske metoder kan du tolke "det samme" som "innenfor epsilonavstand"; 3) hvor du har klart syn på en åpenbart bedre tilnærming når det gjelder algoritmer eller datastrukturer (merk at du for dette kan inkludere i dine vurderinger mindre kjente datastrukturer og mer esoteriske/sofistikerte/matematiske algoritmer, samt måter å omformulere problemet/problemene slik at et annet paradigme blir eksponert, som konveks optimaliseringsteori eller dynamiske programmeringsteknikker). Merk også at hvis det finnes godt skrevne tredjepartsbiblioteker du kjenner til som vil fungere bra, kan vi inkludere dem i prosjektet). Bruk ultratenkning.»

Jeg inkluderte miniatyrversjonen av denne prompten her fordi serien «Mine favorittprompter» skal være kompakte, bitstore, selvstendige nuggets. Men i dag forvandlet jeg dette til et virkelig sinnssykt system. Det er ikke relevant om du lager et annet CRUD-program i React eller en TODO-liste, men hvis du gjør noe ganske komplisert i Rust eller Golang, eller noe som involverer komplekse data, er denne tilnærmingen nesten skremmende i hva den kan gjøre. Det er en prosess med to runder. Her er runde 1: --- Les først ALLE AGENTS dot md-filen og README dot md-filen supernøye og forstå ALLE av begge! Bruk deretter kodeundersøkelsesagent-modusen for å fullt ut forstå koden, den tekniske arkitekturen og formålet med prosjektet. Deretter, når du har gjort en ekstremt grundig og grundig jobb med alt dette og dypt forstått hele det eksisterende systemet og hva det gjør, dets formål, hvordan det implementeres og hvordan alle delene henger sammen, trenger jeg at du undersøker, studerer og grubler over disse spørsmålene i forhold til dette prosjektet: Er det noen andre grove ineffektiviteter i kjernesystemet? steder i kodebasen hvor 1) endringer faktisk ville flytte nålen når det gjelder total forsinkelse/respons og gjennomstrømning; 2) slik at endringene våre ville være beviselig isomorfe når det gjelder funksjonalitet, slik at vi ville vite med sikkerhet at det ikke ville endre de resulterende utgangene gitt de samme inputene; 3) hvor du har en klar visjon for en åpenbart bedre tilnærming når det gjelder algoritmer eller datastrukturer (merk at du for dette kan inkludere i dine vurderinger mindre kjente datastrukturer og mer esoteriske/sofistikerte/matematiske algoritmer, samt måter å omformulere problemet(e) slik at et annet paradigme blir avslørt, som listen vist nedenfor (Merk: Før du foreslår noen optimalisering, etabler grunnlinjemålinger (p50/p95/p99 latens, gjennomstrømning, toppminne) og fang opp CPU-/allokerings-/I/O-profiler for å identifisere faktiske hotspots): - N+1 eliminering av spørrings-/hentemønster - null-kopiering / buffer-gjenbruk / scatter-gather I/O - kostnader for serialiseringsformat (parse/kodingsoverhead) - begrensede køer + tilbaketrykk (forhindrer minneoppblåsning og haleforsinkelse) - sharding / stripete låser for å redusere konkurranse - memoisering med strategier for cache-invalidering - dynamiske programmeringsteknikker - konveks optimaliseringsteori - lat evaluering / utsatt beregning - iterator-/generatormønstre for å unngå å materialisere store samlinger - strømming/chunked prosessering for minnebegrenset arbeid - forberegnings- og oppslagstabeller - indeksbasert oppslag vs lineær skanningsgjenkjenning - binærsøk (på data og på svarrom) - topoengs- og skyvevinduteknikker - prefikssummer / kumulative aggregater - topologisk sortering og DAG-bevissthet for avhengighetsgrafer - syklusdeteksjon - union-funn for dynamisk konnektivitet - graftraversering (BFS/DFS) med tidlig avslutning - Dijkstras / A* for vektede korteste stier - prioriterte køer / heaps - prøver for prefiksoperasjoner - Bloom-filtre for probabilistisk medlemskap - intervall-/segmenttrær for range-spørringer - romlig indeksering (k-d-trær, quadtrees, R-trees) - persistente/uforanderlige datastrukturer - copy-on-write-semantikk - objekt-/tilkoblingspooling - valg av cache-utkastelsespolicy (LRU/LFU/ARC) - batchbevisst algoritmevalg - asynkron I/O-batching og koalescing - låsefrie strukturer for scenarioer med høy konkurranse - arbeidstyveri for rekursiv parallellisme - optimalisering av minneoppsett (SoA vs AoS, cache-lokalitet) - kortslutning og tidlig avslutning - strenginternering for gjentatte verdier - resonnement for amortisert analyse med hensyn til disse generelle retningslinjene der det er aktuelt: DP-anvendelighetssjekker: - Overlappende delproblemer? → memoize med stabil tilstandsnøkkel - Optimal partisjonering/batching? → prefikssummer + intervall DP - Avhengighetsgraf med gjentatt traversering? → enkeltpass-topologisk DP KONVEKSE OPTIMALISERINGSSJEKKER: - Brute-force nøyaktig tildeling/planlegging? → LP / min-kostnadsflyt med deterministisk tie-breaking - Kontinuerlig parametertilpasning med eksplisitt tap? → regulariserte minste kvadraters / QP - Stort dekomponerbart konvekst objektiv? → ADMM / proksimale metoder Merk også at hvis det finnes godt skrevne tredjepartsbiblioteker du kjenner til som fungerer bra, kan vi inkludere dem i prosjektet. METODIKKKRAV: A) Baseline først: Kjør testsuiten og en representativ arbeidsmengde; Registrer P50/P95/P99 latens, gjennomstrømning og toppminne med nøyaktige kommandoer. B) Profil før forslag: Fang CPU + allokering + I/O-profiler; Identifiser de 3–5 største hotspotene i % tid før du foreslår endringer. C) Ekvivalens-orakel: Definer eksplisitte gyldne utganger + invarianter. For store inputrom, legg til egenskapsbaserte eller metamorfe tester. D) Isomorfibevis per endring: Hver foreslått diff må inkludere en kort bevisskisse som forklarer hvorfor utganger ikke kan endres (inkludert rekkefølge, tie-breaking, flyttallsatferd og RNG-frø). E) Mulighetsmatrise: Ranger kandidater etter (Impact × Confidence) / Innsats før implementering; Fokuser kun på gjenstander som sannsynligvis vil bevege seg p95+ eller gjennomstrømning meningsfullt. F) Minimale forskjeller: Én ytelsesspak per bytte. Ingen urelaterte refaktorer. Inkluder retningslinjer for tilbakerulling hvis det foreligger noen risiko. G) Regresjonsgarantier: Legg til referansegrenser eller overvåkningskroker for å forhindre fremtidige regresjoner. Bruk ultratenkning. --- Du kan kjøre det én gang i Claude Code med Opus 4.5 og én gang i Codex med GPT 5.2 Codex (jeg begynte å bruke bare High fordi Extra High er for tregt for meg, med mindre jeg skal legge meg). Når de er ferdige, gi hver av dem omtrent 5 raske runder av denne: "Flott. Se over alt igjen for åpenbare oversikter, utelatelser eller feil, konseptuelle feil, tabber osv. Bruk ultratenkning» La dem deretter lagre utgangene slik: "OK, spar alt det der som PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md" "OK, lagre alt det der som PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md" Deretter, i Claude Code, gjør du: "Sammenlign det du gjorde med PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md og ta de beste elementene fra det og vev dem inn i planen din for å få en hybrid, best av begge verdener, overlegen plan ved å redigere den opprinnelige planfilen din." Så dette: Les AGENTS dot md på nytt så det fortsatt er ferskt i minnet. Les nå HELE PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md. Sjekk så 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? Vi ønsker et omfattende og detaljert sett med perler for alt dette, med oppgaver, deloppgaver og avhengighetsstruktur lagt over, med detaljerte kommentarer slik at hele greia er helt selvstendig og selvdokumenterende (inkludert relevant bakgrunn, begrunnelse/begrunnelse, hensyn osv. – alt vi ønsker at vårt «fremtidige jeg» skal vite om målene, intensjonene og tankegangen og hvordan det tjener prosjektets overordnede mål). Perlene bør være så detaljerte at vi aldri trenger å gå tilbake til det opprinnelige nedslagsdokumentet. Gjenspeiler den nøyaktig HELE nedslagsplanen på en omfattende måte? Hvis endringer er nødvendige, revider perlene, lag nye, eller lukk ugyldige eller ikke-anvendelige. 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." Så noen runder med: "Sjekk hver perle supernø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 beads inkluderer omfattende enhetstester og e2e-testskript med god, detaljert loggføring, slik at vi kan være sikre på at alt fungerer perfekt etter implementering. Bruk ultratenkning.» Så slipp løs svermen for å gjennomføre alt. Så gjør deg klar for RUNDE 2.