Najčešća greška kod uvođenja AI-ja u razvojni tim je krenuti od alata. Tim kupi pristup, nekoliko developera ubrza pojedine zadatke, a zatim nitko ne zna što je standard, što je eksperiment i gdje počinje rizik za codebase.
Bolje je krenuti od mapiranja postojećeg razvojnog procesa: gdje nastaje čekanje, gdje se ponavlja ručni rad, gdje review kasni i gdje se greške najčešće provuku. Tek nakon toga ima smisla odlučiti gdje AI ulazi u workflow.
Počnite od jednog jasno omeđenog workflowa
Prvi dobar AI workflow nije "neka alat piše featuree". Bolji kandidati su poslovi s jasnim ulazom, jasnim izlazom i jednostavnom provjerom kvalitete: priprema specifikacije, review edge caseova, generiranje test matrice ili objašnjenje dijela codebasea novom članu tima.
Dobar pilot ima
- jedan jasno definiran zadatak
- poznate podatke i ograničen pristup
- pravila za review i jasnu odgovornost
- mjeru uspjeha: manje čekanja, bolji testovi ili manje reworka
Guardraili su dio procesa, ne dodatak na kraju
AI alat za pisanje koda ne bi smio zaobilaziti pravila koja već vrijede za ljude. Ako se promjena inače reviewa, testira i dokumentira, isto vrijedi i kada je dio koda nastao uz Claude Code, Codex ili drugi alat. Razlika je u tome što granice treba zapisati eksplicitnije.
Što definirati
- koje repozitorije i podatke alat smije vidjeti
- koje promjene moraju proći ljudski review prije commita
- kada se koristi read-only subagent za provjeru
- što se mora testirati prije mergea
Što izbjeći
- nejasno pravilo da "developer procijeni sam"
- slanje osjetljivih podataka bez pregleda
- promjene koje je generirao AI, bez specifikacije
- mjerenje samo broja napisanih linija koda
Mjerite utjecaj na isporuku, a ne osjećaj brzine
AI često stvara osjećaj brzine jer se prvi draft pojavi brzo. Ali stvarna vrijednost se vidi kasnije: je li review kraći, ima li manje povratnih izmjena, jesu li testovi bolji i može li netko drugi za tri mjeseca preuzeti i održavati taj kod.
Zato uvođenje AI-ja treba vezati uz inženjersku produktivnost i kvalitetu isporuke, a ne uz apstraktni cilj "koristimo AI". Ako alat ne poboljšava stvarni workflow, nisu problem developeri nego izbor use casea.
Zaključak
Odgovorno uvođenje AI-ja nije sporo. Sporo je uvoditi alat bez pravila, pa kasnije popravljati sigurnosne rupe, loš kod i izgubljeno povjerenje tima. Krenite od jednog jasno omeđenog workflowa, postavite guardraile, mjerite učinak i širite tek ono što se pokazalo korisnim.
Za timove koji žele strukturiran početak, AI consulting najviše vrijedi kada poveže alat, proces i jasnu odgovornost u jedan održiv način rada.
Josip Budalić
HOTFIX tim
Josip vodi HOTFIX d.o.o. i radi na software arhitekturi, AI-assisted development workflowima, modernizaciji codebasea i praktičnoj isporuci softwarea.