Ce face un document bun pentru un plan de remarcare pentru un proiect de dezvoltare software? Care este diferența dintre un plan bun și unul grozav? Tot vorbesc la nesfârșit despre cum petrec 85%+ din timpul și energia mea în fazele de planificare. Ei bine, ce presupune asta exact? Este greu de explicat în abstract; Ai nevoie de un exemplu concret care să ilustreze cu adevărat nuanțele. Așa că m-am gândit să împărtășesc un exemplu bun de azi. Aceasta răspunde și la o întrebare recentă pe care am primit-o despre abordarea mea. Oamenii par să creadă că trebuie să faci totul în proiect dintr-o singură dată. Și în abordarea mea, asta este adevărat, dar doar pentru versiunea 1! Dacă decizi că vrei să adaugi funcții noi sau să schimbi modul în care funcționează lucrurile, evident că poți face asta odată ce ai un v1 funcțional. Și modul în care faci asta este la fel cum creezi v1, creând mai întâi un plan de reducere foarte detaliat și apoi transformându-l în mărgele. Îți voi da un exemplu din Cass, programul meu Coding Agent Session Search, care este un program Rust destul de elaborat ce detectează, analizează, stochează și indexează automat toate jurnalele tale de sesiuni anterioare de la aproape orice agent de programare. Oferă sub 50ms "căutare instantanee pe măsură ce tastezi" pe toate acele jurnale și are multe alte funcții interesante. Am decis că aș dori să adaug o funcție în Cass care este similară cu una pe care o am deja în MCP Agent Mail și în beads_viewer (bv): posibilitatea de a exporta configurația ca un site static care poate fi servit folosind GitHub Pages. Puteți vedea un exemplu pentru bv chiar pentru acest proiect, care este rezultatul final al procesului de planificare pe care îl voi descrie în această postare: Această funcționalitate face foarte rapidă și ușoară generarea și implementarea site-ului exportat folosind utilitarul gh. Site-ul în sine constă de obicei într-un fișier sqlite și o mulțime de typescript și wasm care rulează complet în browser, dar cu performanțe foarte bune și funcții și stilizare plăcute, pe care le puteți observa în exemplul menționat. Acum, să partajezi mesaje MCP Agent Mail sau o grămadă de mărgele este un lucru, dar să partajezi o grămadă de jurnale de sesiuni ale agenților de codare este foarte diferit; aceste lucruri sunt adesea pline de informații sensibile, chei API, înjurături/invective (cel puțin ale mele sunt!) și alte materiale pe care cu siguranță nu ai vrea să le expui lumii. Dar GitHub Pages, oricât de plăcut ar fi, funcționează doar pentru repozitorii publice (apropo, uneltele mele suportă și Cloudflare Pages, dar GH Pages este mai bun și mai ușor pentru acest caz de utilizare). Deci, cum să gestionezi aceste probleme? Răspunsul este criptarea: utilizatorul selectează mai întâi ce agenți de codare să includă, ce foldere de proiect, perioada de timp etc., iar un pachet este generat (rețineți că acest pachet este în formatul canonic în care Cass convertește intern toate mesajele agenților de codare din formatele lor native originale), iar apoi utilizatorul oferă o parolă pentru criptarea acelui pachet. Ideea este că, deși repository-ul și pagina web sunt publice, toți, în afară de tine și de cei cărora le dai parola, vor vedea pur și simplu un câmp de parolă și nu vor putea citi niciunul dintre mesaje. Odată ce parola este introdusă, deblochează o interfață frumoasă și receptivă care îți permite să cauți ușor prin mesaje aproape la fel de rapid și eficient ca Cass. Și dacă chiar nu ai nimic de ascuns, poți lăsa parola dezactivată și să faci totul public. Oricum, aceasta este o funcție nouă extrem de complexă de adăugat din multe motive. Doar vrăjitorul de export este extrem de complex și complicat. Dar cerințele suplimentare legate de criptare și securitate fac dificil de realizat corect. Oricum, i-am cerut lui Claude Code cu Opus 4.5 să studieze mai întâi tot codul relevant din proiectul meu BV pentru implementarea acestei funcții, apoi i-am explicat cum funcționalitatea corespunzătoare din Cass ar trebui să fie diferită. Apoi mi-a creat o tăietură inițială la un plan. I-am cerut celor de la CC să verifice din nou codul bv pentru mai multe perspective și înțelegere despre cum a fost implementată funcționalitatea în bv și apoi să folosească aceste informații pentru a extinde și îmbunătăți documentul planului existent. În final, am mutat planul pe ChatGPT Pro în browser cu GPT 5.2 cu Raționament Extins, împreună cu acest preambul: "Revizuiți cu atenție întregul plan pentru mine și veniți cu cele mai bune revizuiri în termeni de arhitectură mai bună, funcții noi, funcții modificate etc., pentru a-l face mai bun, mai robust/fiabil, mai performant, mai convingător/util etc. Pentru fiecare modificare propusă, oferă-mi analiza ta detaliată și raționamentul/justificarea pentru care ar face proiectul mai bun, împreună cu schimbarea în stil git-diff față de planul original prezentat mai jos:" Apoi am lipit ieșirile în Claude Code astfel: OK, acum integrează aceste revizuiri în planul de remarcare la loc; Folosește UltraThink și fii meticulos. La final, poți să-mi spui cu ce schimbări ești pe deplin de acord, cu care ești oarecum de acord și cu care nu: "''[Text lipit #1 +995 rânduri]''' Apoi am clătit și am repetat asta de încă două ori. Acesta nu este un proces rapid: ultima recenzie, despre care puteți vedea o captură de ecran mai jos, a durat 27 de minute să fie finalizată: Puteți vedea planul final de reducere de ~3.500 de linii aici: Dar ceea ce este mai interesant este să vezi revizuirile din GitHub, unde poți vedea îmbunătățirile masive făcute de la v2 la v3 și cum aceste îmbunătățiri continuă de fapt până la final: Asta a durat în total aproximativ 3 ore. Bănuiesc că acesta este motivul pentru care majoritatea oamenilor par să nu fie dispuși să facă acest nivel de planificare. Se simte că nu faci prea multe pentru că nu se scrie cod, dar dacă faci corect și apoi pornești destui agenți în roiul tău cu Agent Mail, Beads și bv, codul va fi scris atât de ridicol de rapid încât compensează cu mult această parte lentă. Și, mai mult, codul va fi foarte bun. Revenind la poveste, eram gata să transform planul în mărgele. Am explicat deja acest proces într-o altă postare recentă, dar esența lui este să folosești acest prompt cu Claude Code: "OK, deci acum citește TOT PLAN_TO_CREATE_GH_PAGES_WEB_EXPORT_APP.md; vă rog să luați TOATE acestea și să le dezvoltați și să le folosiți pentru a crea un set cuprinzător și detaliat de mărgele pentru toate acestea, cu sarcini, subsarcini și structură de dependență suprapuse, cu comentarii detaliate astfel încât totul să fie complet auto-conținut și auto-documentat (inclusiv fundalul relevant, raționamentul/justificarea, considerațiile etc. – orice ne-am dori ca "sinele nostru viitor" să știe despre scopurile, intențiile și procesul de gândire și cum acestea servesc scopurile generale ale proiectul. Mărgelele ar trebui să fie atât de detaliate încât să nu fie nevoie să consultăm înapoi documentul original al planului de reducere. Amintește-ți să folosești DOAR instrumentul 'bd' pentru a crea și modifica mărgelele și a adăuga dependențele. Folosește ultrathink." Apoi am făcut rundă după rundă din acest prompt de follow-up în Claude Code: "Recitește AGENTS dot md ca să fie încă proaspăt în mintea ta. Apoi citește TOT PLAN_TO_CREATE_GH_PAGES_WEB_EXPORT_APP.md. Folosește ultrathink. 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 mărgelelor, includem teste unitare cuprinzătoare și scripturi de testare e2e, cu jurnale detaliate și excelente, ca să fim siguri că totul funcționează perfect după implementare. Este esențial ca TOTUL din planul de reducere să fie integrat în mărgele, astfel încât să nu fie nevoie să ne întoarcem la planul de reducere și să nu pierdem niciun context important, idei sau perspective despre noile funcționalități planificate și motivele pentru care le facem." După aproximativ 8 sau 9 cartușe, ajunge în sfârșit la o stare stabilă. Apoi am făcut ca Codex cu GPT 5.2 să facă o ultimă rundă folosind același prompt. Rezultatul final poate fi văzut la linkul împărtășit mai sus. Și asta, prieteni, arată un plan bun. Și, de asemenea, cum arată un set bun de mărgele bazat pe un plan. Aceste mărgele sunt atât de lustruite și detaliate încât poți elibera mecanic un roi mare de agenți pentru a le implementa folosind Agent Mail, Beads și BV, și va ieși aproape perfect, fără prea multă bătaie de cap. Sunt prea obosit să încep munca de implementare în seara asta, dar o voi face mâine și apoi voi prezenta noua funcție, pe care cred că utilizatorii Cass o să o aprecieze foarte mult.

Î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. Acum, poți încă să obții mult mai mult timp combinând idei inteligente din Gemini3 în aplicația web cu Deep Think activat, sau din Grok4 Heavy, sau Opus 4.5 în aplicația web, dar tot vrei să folosești GPT Pro pe web ca arbitru final al ceea ce să preiei de la fiecare model și cum să-l integrezi cel mai bine. Și pentru că această postare ar putea fi și mai comic de lungă, vă las cu promptul meu pentru a integra aceste planuri concurente într-un singur plan canonic de reducere "cel mai bun dintre toate lumile": "Am rugat 3 LLM-uri concurente să facă exact același lucru și au venit cu planuri destul de diferite, pe care le puteți citi mai jos. Vreau să analizezi FOARTE atent planurile lor cu mintea deschisă și să fii sincer intelectual despre ce au făcut mai bine decât planul tău. Apoi vreau să vii cu cele mai bune revizuiri posibile ale planului tău (ar trebui pur și simplu să actualizezi documentul existent pentru planul original împreună cu revizuirile) care să îmbine artistic și abil "cele mai bune lumi" pentru a crea o versiune hibridă adevărată, supremă, superioară a planului care să atingă cel mai bine obiectivele noastre declarate și să funcționeze cel mai bine în practica reală pentru a rezolva problemele cu care ne confruntăm și obiectivele noastre generale asigurând în același timp succesul extrem al întreprinderii cât mai bine posibil; Ar trebui să-mi oferi o serie completă de modificări în stil git-diff față de planul tău original pentru a-l transforma într-un plan nou, îmbunătățit, mult mai lung și detaliat, care integrează cele mai bune planuri cu fiecare idee bună inclusă (nu trebuie să menționezi ce idei au venit din ce modele în planul îmbunătățit revizuit final): " (La naiba, încă un prompt pentru distracție; Folosesc această variantă pentru a îmbunătăți iterativ un plan de reducere existent): "Revizuiți cu atenție întregul plan pentru mine și veniți cu cele mai bune revizuiri în termeni de arhitectură mai bună, funcții noi, funcții modificate etc., pentru a-l face mai bun, mai robust/fiabil, mai performant, mai convingător/util etc. Pentru fiecare modificare propusă, oferă-mi analiza ta detaliată și raționamentul/justificarea pentru care ar face proiectul mai bun, împreună cu schimbarea în stil git-diff față de planul original prezentat mai jos:"

Niveluri de implicare satanică aici... 𖤐⁶⁶⁶𓃶