Înainte să arzi o mulțime de jetoane cu un roi mare de agenți pe un proiect nou, vechea maximă de tâmplărie "Măsoară de două ori, taie o dată!" merită revizuită ca "Verifică mărgelele de N ori, implementează o dată", unde N este practic cât poți suporta. Am observat că continui să obții tot mai multe îmbunătățiri, chiar dacă sunt subtile, cu cât rulezi asta la rând cu Opus 4.5 (reține că următorul prompt este folosit doar DUPĂ ce ai transformat deja planul inițial de reducere în mărgele folosind cealaltă provocare pe care am dat-o recent în postarea mea foarte lungă despre fluxurile mele de lucru): "Recitește AGENTS dot md ca să fie încă proaspăt în mintea ta. Verifică fiecare mărgea foarte atent – ești sigur că are sens? Este optim? Am putea schimba ceva pentru a face sistemul să funcționeze mai bine pentru utilizatori? Dacă da, revizuiește mărgelele. Este mult mai ușor și mai rapid să funcționăm în "spațiul planului" înainte să începem să implementăm aceste lucruri! NU SIMPLIFICA PREA MULT LUCRURILE! NU PIERDE NICIO FUNCȚIONALITATE SAU FUNCȚIONALITATE! De asemenea, asigură-te că, ca parte a acestor mărgele, includem teste unitare cuprinzătoare și scripturi de testare e2e, cu jurnale detaliate și excelente, astfel încât să fim siguri că totul funcționează perfect după implementare. Amintește-ți să folosești DOAR instrumentul 'bd' pentru a crea și modifica mărgelele și pentru a adăuga dependențele la mărgele. Folosește ultrathink." Obișnuiam să rulez asta doar o dată sau de două ori înainte să încep implementarea, dar recent am experimentat rulându-l de 6+ ori și tot făcea rafinări utile. Dacă începe să se deterioreze în ceea ce privește îmbunătățirile incrementale ale mărgelelor, ai putea încerca să începi o nouă sesiune CC, începând cu: "Mai întâi citește TOATE fișierele AGENTS dot md și README dot md cu mare atenție și înțelege TOATE pe ambele! Apoi folosește modul agent de investigație a codului pentru a înțelege pe deplin codul, arhitectura tehnică și scopul proiectului. Folosește ultrathink." Și apoi continuăm cu aceeași temă ca cea prezentată mai sus, dar precedată de: "Recent am transformat un fișier de planuri de reducere într-o grămadă de mărgele noi. Vreau să le analizezi și să le analizezi foarte atent folosind 'bd' și 'bv'." Cu cât planul tău de remarcare este mai complex și mai complex, cu atât această tehnică devine mai relevantă. Dacă ai un plan mic, trivial și un proiect foarte simplu, asta este evident exagerat. Dar în acest caz, probabil vei vedea puține câștiguri/schimbări incrementale la fiecare rundă, așa că ar trebui să fie destul de evident când e momentul să te oprești. Amintește-ți: tokenurile de planificare sunt mult mai puține și mai ieftine decât cele de implementare. Chiar și un plan de reducere foarte mare și complex este mai scurt decât câteva fișiere de cod substanțiale, ca să nu mai vorbim de un întreg proiect. Și modelele sunt mult mai inteligente când raționează despre un plan foarte detaliat și bine conturat, dar totuși suficient de mic încât să se încadreze ușor în fereastra lor de context (aceasta este cu adevărat ideea cheie din spatele concentrării mele obsesive pe planificare și de ce am petrecut 80%+ din timp pe această parte). Și dacă te bazezi pe GPT Pro cu Extended Reasoning în aplicația web pentru planificarea inițială, așa cum recomand cu tărie (adică pentru a-ți crea și îmbunătăți planul de reducere pe care în cele din urmă îl vei transforma în mărgele), practic le primești pe bază de "all-you-can-eat" cu un plan Pro, așa că profită la maximum de asta! Niciun alt model nu poate atinge Pro pe web când gestionează input care se potrivește ușor în fereastra de context. Este cu adevărat unic. ...