Review și deploy
Trei trepte, PR-uri mici, deploy făcut de Feature Lead
Opt zile de așteptare
Cel mai lung blocaj din Q3 SOLO a fost de opt zile lucrătoare. Nu a fost un bug. A fost un PR care aștepta o pereche de ochi. Omul care l-a scris a trecut pe altceva. Contextul s-a pierdut. Când review-ul a venit, a venit cu întrebări la care răspunsul era deja uitat.
Faros, pe 10.000 de programatori care lucrează cu agenți AI: +21% taskuri, +98% PR-uri, +91% timp de review. Swarmia: dimensiunea mediană a unui PR s-a dublat între Q1 2025 și Q1 2026. Mai mult cod, mai mare, același număr de oameni care îl citesc. Dacă nu schimbăm review-ul, restul procesului nu contează.
Cele trei trepte
Treapta 1 — agentul
Prima trecere o face un agent: SuperBoris la Bono. Se uită la stil, erori simple, respectarea regulilor din CLAUDE.md, contractele de API, multi-tenancy, securitate de bază. Raportează. Nu modifică. Feature Lead-ul rezolvă ce raportează agentul înainte să ceară review unui om.
Treapta 2 — un coleg mid
Al doilea mid, numit la Tasks, citește PR-ul. Se uită la logica de business, la contextul proiectului, la ce nu poate vedea agentul: e ce scrie în Specify? Cazurile limită sunt tratate? Aprobă sau cere modificări. Aceasta e treapta care crește oamenii. Un mid care face review altuia învață mai mult decât unul care primește review de la Prodi.
Treapta 3 — Prodi, doar pe arhitectură
Prodi intră numai când PR-ul atinge arhitectura: model de date, integrare nouă, contract de API, decizie care va costa scump de schimbat. Nu intră pe fiecare PR. Când intră, întreabă. Nu rescrie.
Dacă Prodi a rescris, notăm. „PR-uri aprobate fără modificări de la Prodi" e o cifră lunară cu țintă de peste 70% în trei luni.
Regulile de PR
- Sub 200 de linii. Un PR de 50 de fișiere se sparge înainte de a fi trimis. Stacked PRs când un task e mai mare.
- Un PR, un task. Titlul PR-ului e numele taskului din SuperBono.
- Review-ul e taskul cu prioritatea cea mai mare pentru cel căruia i se cere. Prima reacție în sub 24 de ore.
- Dacă reviewer-ul nu poate, spune în aceeași zi cine preia.
- Descrierea PR-ului spune ce s-a verificat, nu ce s-a scris. Criteriul de verificare din task, bifat.
- Un PR deschis de peste 24 de ore fără reacție apare automat pe lista de luni.
Checklist complet: F6 · Checklist PR.
Review ca școală
Prodi întreabă, nu corectează. „De ce ai ales aici o tranzacție?" în loc de „pune tranzacție aici". Răspunsul mid-ului intră în thread. Agentul propune din thread un rând pentru CLAUDE.md sau un ADR. Prodi confirmă. Așa cunoașterea iese din capul lui Prodi și intră în fișier.
Lunar, rolul de reviewer principal se rotește între cei patru mid. Cine e reviewer principal luna asta face treapta 2 pe toate PR-urile echipei, nu doar pe proiectul lui.
Deploy
Deploy-ul e automatizat. Îl face Feature Lead-ul. Obiectivul lui Prodi în Q4 nu e să dea deploy mai repede, ci ca în două luni 100% din deploy-uri să fie făcute de altcineva.
Până când automatizarea e gata, deploy-ul e un task cu ore în lista proiectului, cu responsabil un mid, cu Prodi alături. Rolul de „responsabil deploy" se rotește lunar, ca și cel de reviewer principal.
După release, Feature Lead-ul urmărește 30 de zile. Orele de rework în aceste 30 de zile sunt o cifră a proiectului. Intră în „Calitatea soluției".
Termenul se mută înainte
Când Feature Lead-ul vede că nu ajunge la dată, mută data înainte de a trece de ea, cu motiv scris în Predictibilitate. În Q3 SOLO un singur om a făcut asta în tot trimestrul. E singurul comportament pe care îl sărbătorim explicit la retrospectivă: cine a mutat înainte, cu motiv, a făcut ce trebuie. Predictibilitatea numără „livrat la data asumată sau mutată înainte de termen cu motiv". Cine mută după întârziere nu intră.
Bug-uri: cinci zile
Nu avem backlog de bug-uri. Un bug se rezolvă sau se închide în cinci zile lucrătoare. Miercurea de calitate, la două săptămâni, e ziua în care se închide tot ce a rămas.
The Bono Way · v0.1 · 9 septembrie 2026 · pregătit de Claude pentru Bogdan; capitolele se rescriu de owner-ii lor. Sursa: repo „Bono Waiy", Markdown.