„AI ne smanjuje posao; premješta ga sa pisanja na pregled.“

Standardi koji obaraju build

Nismo postali brži zbog AI-ja. Postali smo brži jer su pravila provođena, a to je ono što je učinilo generisani kod jeftinim za prihvatanje.

Kontaktirajte nas

Tehničko vodstvo · američki marketplace za usluge kamionima · tim od 12 · 2026, četvrta godina istog angažmana

~50%

veća propusnost tima, po ciklusu tiketa

severiteta, po fazi

200

linija — granica po komponenti

Ukratko

Do 2026. tim je svakodnevno koristio Claude Code — komponente, testovi, integracije — a dizajn je bio povezan sa Figmom. Propusnost je porasla oko 50% po ciklusu tiketa, a testovi su prestali da se pišu rukom.

Zanimljiv dio je ono što je moralo postojati prije toga. AI ne smanjuje posao; premješta ga sa pisanja na pregled. Ako je pregled mjesto gdje već imate zastoj, generisanje više koda stvari čini gorim, ne boljim.

Zato su pravila došla prva. Inženjerski standardi napisani kao izvršne provjere, provođeni prije commita i ponovo u CI-ju, sa različitim setom po repozitoriju — jer jedan set za backend i biblioteku komponenti je ili previše labav za jedno ili previše strog za drugo.

Problem

Konvencija bez vlasnika je preporuka. Traje dok neko ima vremena za pažljiv pregled, a prestaje prve sedmice kad nema. Na sistemu od devetnaest repozitorija i četiri developera, „dogovorili smo se da radimo ovako“ ima poluživot od jednog kvartala.

Ograničenje

Dodavanje AI-ja to pogoršava: generisani kod dolazi brže nego što ga čovjek može pažljivo pročitati, pa standard koji je već bio mekan postaje dekorativan. Zahtjev zato nije bio „koristi AI dobro“, nego: učiniti standard mehaničkim, da prihvatanje koda košta manje od pisanja.

Šta smo uradili

Pravila kao kod, ne kao dokumentacija
Standardi koje smo provodili: nema any, sa propisanim načinom deklarisanja tipova; komponenta ne smije preći 200 linija; svaki API poziv mora imati tip zahtjeva i tip odgovora. Napisano kao provjere, ne kao vodič za stil.
Provjere, ne vodič za stil
Različit set po repozitoriju
Web aplikacija, backend i biblioteka komponenti imali su svoj set. To je važnije nego što zvuči: jedan set pravila za backend i dizajn sistem je ili dovoljno dopustljiv da bude bezvrijedan za jedno, ili dovoljno strog da se rutinski obilazi u drugom. Odluka šta je gdje važno je pitanje vođenja, ne konfiguracije.
Tri seta, tri repozitorija
Tri severiteta, po fazi
Isto pravilo ponašalo se drugačije zavisno od toga gdje ste. To je dio koji bismo preporučili svakome: većina timova izabere jedan severitet i dobije jedan od dva ishoda — previše strogo pa se ljudi bore sa alatima ili ih ugase, ili previše meko pa pravilo tiho prestane postojati.
Prisutno svuda, blokira gdje je jeftino
I tek onda AI
Sa provjerama na mjestu, Claude Code je ušao u svakodnevnu upotrebu za komponente, testove i integracije, a dizajn je povezan sa Figmom. Red je cijeli argument: generisani kod je jeftin samo ako je njegovo prihvatanje jeftino, a prihvatanje je jeftino samo ako nešto drugo osim čovjeka provjerava dosadnu polovinu.
Red je argument

ISTO PRAVILO, TRI FAZE

Tokom razvoja — upozorenje

Kaže vam bez prekidanja posla. Formatiranje i linting idu u hook jer su brzi i lokalni; tipovi i testovi u CI jer su spori i konačni.

Eskalacija po fazi znači da je pravilo prisutno cijelim putem, a blokira samo tamo gdje je blokiranje jeftino.

Rezultat

Propusnost tima veća oko 50%, mjereno po ciklusu tiketa
Testovi su prestali da se pišu rukom — što je važno jer su testovi prvo što se ispusti pod pritiskom roka
Standardi provođeni identično bez obzira na to ko pregleda, i da li iko pregleda

Najvrijednije pravilo, gledano unazad, bila je granica veličine komponente. Ne pravila o tipovima, ne API ugovori — granica od 200 linija. To je ono koje se isplaćuje godinama a ne sedmicama, jer prisiljava dekompoziciju u trenutku kad nešto počne da se širi, dok je razdvajanje još lahko.

Šta bismo uradili drugačije

Brojka od 50% je procjena iz ciklusa tiketa, ne kontrolisano mjerenje — i tako je treba tretirati.

Za oprez ima dobar razlog. METR je u julu 2025. proveo randomizovano kontrolisano istraživanje sa 16 iskusnih developera na 246 stvarnih zadataka u repozitorijima u kojima rade godinama. Developeri su predvidjeli da će ih AI učiniti 24% bržim. Nakon toga su prijavili da su 20% brži. Mjereno, bili su 19% sporiji.

+24%

predviđeno

+20%

samoprijavljeno

−19%

izmjereno

Razlika između percipiranog i stvarnog bila je 39 procentnih poena. METR je od tada revidirao dizajn studije i rezultat tretira kao istorijski, dijelom jer je u nastavku mnogo developera odbilo učestvovati ako moraju raditi bez AI-ja.

Naša postavka se od njihove razlikuje na načine koji vjerovatno znače — tim a ne pojedinci, proizvod u aktivnom razvoju a ne kod poznat pet godina, pravila provođena automatski a ne AI korišten ad hoc u editoru, i alati iz 2026. a ne s početka 2025. To su razlozi da mislimo da je naša brojka stvarna. Nisu dokaz da jeste.

Šta bismo uradili drugačije: izmjerili bismo vrijeme ciklusa kako treba. Tri mjeseca prije, tri mjeseca poslije, iz podataka koje smo već imali. Bili su dostupni, a mi smo procijenili.

Srodno

Pet problema i sistem koji ih rješavaIsta ideja dovedena dalje: ~2.450 linija provjera.Postali smo 50% brži — i zašto u to treba sumnjatiIsti argument, napisan za blog.

Svih 18 projekata