Când haosul devine metodă: AI și GitHub pentru gestionarea unui proiect pe care nimeni nu voia să-l atingă

Mă sună un client. Voce tensionată, cuvinte măsurate.

“Ivan, avem o problemă. De fapt, avem problema.”

Cunosc tonul ăsta. E tonul celui care a încercat deja să rezolve lucrurile intern, a eșuat, și acum caută pe cineva care să-i spună adevărul fără ocolișuri.

Problema este un software de gestiune — nu un site web, nu o aplicație — un sistem critic pe care rulează procese de business importante. Are câțiva ani. A crescut repede, cum se întâmplă întotdeauna când business-ul aleargă mai repede decât arhitectura. Și acum s-a acumulat totul: bug-uri deschise pe care nimeni nu le închide, cereri de evoluție pe care nimeni nu le planifică, dezvoltatori care lucrează pe versiuni diferite ale codului fără să știe ce face celălalt.

Scenariul clasic care, în cuvinte, “funcționează”. Dar pe dinăuntru e un câmp minat.

🧠 Prima întâlnire: a înțelege ce nu funcționează cu adevărat #

Când intru într-un proiect ca acesta, nu mă uit mai întâi la cod.
Mă uit la oameni. Mă uit cum comunică. Mă uit unde se pierd informațiile.

Echipa era formată din patru dezvoltatori buni. Serioși. Competenți.
Dar lucrau așa:

• codul stătea într-un folder partajat în rețea
• modificările erau comunicate prin email sau într-un tabel Excel
• bug-urile erau raportate verbal, pe chat, prin tichete — fără un criteriu unic
• nimeni nu știa cu certitudine care era versiunea “bună” a software-ului

Și știi ce se întâmplă în situațiile astea?
Fiecare are dreptate din punctul lui de vedere. Dar proiectul, în ansamblu, e scăpat de sub control.

Problema nu e tehnică. E organizatorică.
Și aici se schimbă totul.

📌 Propunerea: GitHub ca coloană vertebrală a proiectului #

Primul lucru pe care l-am pus pe masă a fost clar, direct, fără fasoane:

Adoptăm GitHub. Tot codul trece pe acolo. Fără excepții.

Nu e o chestie de modă. Nu e pentru că “fac toți așa”.
E pentru că GitHub rezolvă, cu instrumente concrete, probleme pe care niciun tabel Excel nu le va putea gestiona vreodată:

• Versionare reală: fiecare modificare e urmărită, comentată, reversibilă
• Branch-uri și Pull Request-uri : fiecare dezvoltator lucrează pe copia lui, apoi propune modificările echipei — nu suprascrie munca celorlalți
• Issue tracker integrat: bug-urile și cererile de evoluție trăiesc în același loc cu codul
• Istoric complet: cine a făcut ce, când, de ce

Am văzut fața dezvoltatorului senior. Un amestec de curiozitate și neîncredere.
“Dar noi am făcut mereu așa.”

I-am răspuns calm: “Știu. Și rezultatul e motivul pentru care sunt aici.”

N-am spus-o ca să provoc. Am spus-o pentru că e adevărul.
Iar adevărul, când e spus în modul potrivit, nu jignește. Eliberează.

🔬 Al doilea pas: AI ca accelerator, nu ca înlocuitor #

Odată definit fluxul de lucru pe GitHub — branch-uri, review, merge controlate — am făcut a doua propunere.

“Integrăm inteligența artificială în procesul de rezolvare a bug-urilor.”

Liniște.

Înțeleg reacția. Când spui “AI” într-o cameră plină de dezvoltatori, jumătate se gândesc la ChatGPT care generează cod la întâmplare, cealaltă jumătate crede că le spui că locul lor de muncă nu mai e necesar.

Niciuna dintre cele două.

Ce am propus e foarte diferit:

• Când un dezvoltator preia un bug, înainte de a scrie o linie de cod, folosește AI-ul pentru a analiza contextul
• AI-ul citește codul implicat, logurile, descrierea problemei
• Propune ipoteze. Nu soluții definitive — ipoteze argumentate
• Dezvoltatorul evaluează, verifică, și apoi implementează

AI-ul nu înlocuiește programatorul.
AI-ul îi economisește primele două ore de analiză — alea în care citești cod scris de altcineva, încercând să înțelegi ce naiba se întâmplă.

Iar cele două ore, înmulțite cu fiecare bug, cu fiecare dezvoltator, cu fiecare săptămână, devin un număr care schimbă calculele proiectului.

📊 Numerele pe care le-am pus pe masă #

N-am vândut vise. Am prezentat estimări conservative.

Echipa gestiona în medie 15-20 de bug-uri pe săptămână.
Timpul mediu de rezolvare era de aproximativ 6 ore per bug (între analiză, fix, testare, deploy).

Cu introducerea GitHub + AI în workflow, estimarea mea era:

O reducere de peste 90% din timpul total de rezolvare.
O creștere de 12 ori a capacității echipei de a închide tichete.
Fără să angajezi pe nimeni. Fără să schimbi oamenii. Schimbând metoda.

🛠️ Cum funcționează în practică #

Workflow-ul pe care l-am desenat e simplu. Intenționat simplu.

1. Bug-ul ajunge ca Issue pe GitHub
Titlu clar, descriere, etichetă de prioritate. Gata cu emailurile, gata cu chat-ul.

2. Dezvoltatorul creează un branch dedicat
fix/issue-234-eroare-calcul-tva — numele spune tot.

3. Înainte de a atinge codul, consultă AI-ul
Îi pasează codul implicat, eroarea, contextul. AI-ul returnează o analiză structurată: unde ar putea fi problema, ce fișiere sunt implicate, ce teste trebuie verificate.

4. Dezvoltatorul implementează fix-ul
Cu un avantaj enorm: știe deja unde să se uite.

5. Pull Request cu review
Un coleg revizuiește codul. Nu de formă — pentru calitate.

6. Merge în branch-ul principal
Doar după aprobare. Codul “bun” rămâne bun.

7. Issue-ul se închide automat
Trasabilitate completă. De la problemă la soluție, totul documentat.

📈 Ce s-a schimbat după trei săptămâni #

Primele zile au fost cele mai grele. Mereu așa e.
Instrumente noi, obiceiuri noi, tentația de a reveni la “cum se făcea înainte”.

Dar după trei săptămâni s-a întâmplat ceva.

Dezvoltatorul senior — cel care se uitase la mine cu neîncredere — mi-a scris:

“Ivan, ieri am rezolvat un bug care anul trecut m-a blocat două zile. Cu AI-ul mi-a luat patruzeci de minute. Nu pentru că AI-ul a scris codul. Ci pentru că mi-a arătat imediat unde era problema.”

Uite. Ăsta e punctul.
AI-ul nu scrie cod mai bun decât un dezvoltator experimentat.
AI-ul accelerează drumul dintre problemă și înțelegerea problemei.

Iar înțelegerea e mereu pasul cel mai scump.

🎯 Lecția pe care o duc acasă #

De fiecare dată când intru într-un proiect în dificultate, găsesc același tipar:

1. Oameni competenți
2. Instrumente inadecvate
3. Procese absente sau informale
4. Frustrare crescândă

Soluția nu e niciodată “lucrați mai mult”.
Soluția e lucrați diferit.

GitHub nu e un instrument pentru dezvoltatori. E un instrument pentru echipe.
AI-ul nu e o jucărie. E un multiplicator de competență.

Dar niciunul nu funcționează dacă nu e cineva care privește proiectul de sus, înțelege unde se pierd orele, și are curajul să spună: “Schimbăm.”

💬 Pentru cei care se recunosc în această poveste #

Dacă gestionezi un proiect software și te regăsești în ce am descris — codul împrăștiat, bug-urile care revin, echipa care muncește mult dar închide puțin — să știi că nu e vina oamenilor.

E vina sistemului în care lucrează.

Iar sistemul poate fi schimbat.
Trebuie schimbat.

Nu sunt necesare revoluții. Sunt necesare alegeri precise, implementate cu metodă.

Un repository partajat. Un flux de lucru clar. Un asistent inteligent care accelerează analiza.

Trei lucruri. Trei decizii.
Care transformă haosul în control.

Glosar #

Pull Request — Cerere formală de incorporare a modificărilor dintr-un branch în branch-ul principal, cu code review obligatoriu. Mecanismul care garantează că codul “bun” rămâne bun.

Version Control — Sistem care urmărește fiecare modificare a codului, menținând istoricul complet. Git este standardul; GitHub adaugă colaborare peste Git.

Issue Tracker — Sistem integrat de urmărire pentru bug-uri și cereri de funcționalități. Pe GitHub, issue-urile trăiesc în același loc cu codul, cu trasabilitate de la problemă la soluție.

Code Review — Revizuirea codului de către un coleg înainte de merge. Surprinde bug-uri, îmbunătățește calitatea și răspândește cunoașterea codebase-ului în echipă.

Branch — Linie de dezvoltare independentă care permite lucrul pe modificări izolate fără a afecta codul principal până la merge-ul aprobat.