Zašto AI često “krpa posljedice” umjesto da riješi uzrok (i kako to kontroliram kao AI manager)
Sažetak
U stvarnom radu s AI alatima često se dogodi da AI krene rješavati simptome (posljedice), umjesto da odmah identificira uzrok i predloži najjednostavnije trajno rješenje. To se meni dogodilo na WordPress primjeru: stranica je “šetala” lijevo–desno na mobitelu, a umjesto brzog rješenja jednim klikom, dugo smo radili dijagnostiku i “krpanje” kroz CSS. Ovaj vodič pokazuje kako prepoznajem taj obrazac ponašanja AI-a, koje kontrole uvodim te kako natjeram AI da radi dokazno i da prioritizira uzrok.
Kome je ovaj vodič namijenjen
- AI managerima i voditeljima projekata koji koriste AI za tehničke i poslovne zadatke
- svima koji žele brže doći do stabilnog rješenja umjesto niza pokušaja
- korisnicima WordPressa (i općenito digitalnih alata) koji žele razumjeti “što je uzrok, a što je simptom”
Problem i simptomi
Problem: kad AI-u dam zadatak, on često krene u niz tehničkih koraka koji popravljaju simptome, ali ne dolaze brzo do uzroka. Tipični simptomi takvog AI pristupa su:
- predlaganje “patch” rješenja (npr. CSS trikovi, workaroundi) bez provjere postoji li jednostavniji i stabilniji pristup
- nedovoljno jasne kontrole (što točno dokazujemo i čime)
- gubitak vremena na iteracije koje ne mijenjaju osnovnu arhitekturu rješenja
- osjećaj da “radimo puno”, ali se ne približavamo uzroku
Cilj
Cilj mi je natjerati AI da:
- prvo utvrdi uzrok i predloži najjednostavnije trajno rješenje
- drži se dokaznog pristupa (dokaz → opseg → radnja)
- ne predlaže destruktivne ili široke promjene bez jasnog opravdanja
Okruženje / preduvjeti
- AI alat (npr. ChatGPT ili sličan) koji daje prijedloge koraka i rješenja
- zadaci iz stvarnog rada (WordPress, marketing, operativa, razvoj)
- spremnost da se uvedu “kontrolne točke” prije izvođenja radnji
Rješenje – korak po korak
1) Prvo definiram “što je uzrok”, a što “simptom”
AI često vidi simptom i odmah predlaže popravak. Ja prvo tražim da se jasno kaže:
- što je vidljivo ponašanje (simptom)
- što je vjerojatan uzrok
- što je dokaz koji taj uzrok potvrđuje ili odbacuje
Bez toga nema smisla ići dalje.
2) Uvijek tražim minimalni dokaz prije prve radnje
Prije bilo kakvog rješenja tražim bar jedan objektivan signal (dokaz), npr.:
- Network/Console output (web problemi)
- server log (404/500)
- mjerljiva provjera (scrollWidth vs clientWidth)
- točan selector / element koji uzrokuje problem
AI bez dokaza često “ispaljuje” tipična rješenja koja ponekad rade, ali mogu pojesti sate.
3) Uvijek radim “scope check”: lokalno vs globalno
Prije većih promjena provjeravam opseg:
- je li problem samo na jednoj stranici/komponenti
- ili je globalan na cijelom webu/sustavu
Ovo je presudno jer često postoji najjednostavnije rješenje koje vrijedi samo za jednu stranicu (npr. promjena templatea), umjesto globalnog “krpanja”.
4) Tražim rangirane opcije, ne “popis svega”
AI-u izričito kažem da mi da 2–3 opcije, rangirane po:
- trajnosti (rješava uzrok ili samo posljedicu)
- riziku (može li nešto pokvariti drugdje)
- vremenu provedbe (koliko traje i koliko je koraka)
- reverzibilnosti (mogu li vratiti nazad u 1 minutu)
Zatim ja biram jednu opciju i radimo samo nju.
5) “Jedan klik” rješenja stavljam u vrh prioriteta
U praksi se često dogodi da postoji rješenje koje je:
- brže
- stabilnije
- i arhitektonski ispravno
U mom konkretnom slučaju WordPress stranice “letak”, najbrže rješenje je bilo promijeniti template na “Canvas” (stranica bez headera i footera), jer je to letak/landing i nije mi trebao standardni layout.
6) Tek ako nema trajnog rješenja, idem na “patch”
Workaround (npr. CSS) prihvaćam tek ako:
- ne postoji stabilna promjena postavke ili templatea
- patch je page-scoped (ne globalan)
- postoji jasna provjera da je patch potreban
Provjera rezultata (kako znam da radi)
- problem se više ne pojavljuje na uređajima na kojima je reproduciran (npr. mobitel)
- postoji mjerljiva provjera prije/poslije (npr. nestane horizontalni scroll ili “bounce” efekt)
- rješenje je stabilno i ne uvodi nove nuspojave na drugim stranicama
- rješenje je dokumentirano (što je promijenjeno i zašto)
Najčešće greške i kako ih izbjeći
- AI odmah predlaže workaround: tražim dokaz i “scope check” prije bilo kakvog patcha.
- Preširoka rješenja: ne prihvaćam globalne promjene ako je problem lokalni.
- Previše opcija bez prioriteta: tražim rangiranje i biram jednu opciju.
- Destruktivne radnje bez potrebe: reinstall, brisanje ili velike promjene tek nakon dokaza i odobrenja.
- Nema zapisa što je učinjeno: bilježim svaki korak i rezultat provjere.
Zaključak / što sam naučio
AI može ubrzati posao, ali bez kontrole može potrošiti vrijeme na popravljanje posljedica umjesto rješavanja uzroka. Zato je uloga AI managera ključna: postaviti dokazni proces, tražiti provjere, odrediti opseg i natjerati AI da prioritizira trajna rješenja (postavke, templatei, arhitektura) prije “krpanja”. Ovaj slučaj mi je potvrdio da je najbolji rezultat kombinacija: AI kao pomoćnik + čovjek kao kontrolor metode i prioriteta.
FAQ
- Je li AI “kriv” što ide u workaround?
Ne radi se o krivnji, nego o načinu rada: AI često optimizira za “nešto što izgleda kao rješenje”, a ne za najkraći put do uzroka. Moj posao je postaviti proces. - Kako najbrže prekinuti “lutanje”?
Vratiti se na dokaz: što je uzrok, koji je test, što je opseg, koje su 2–3 rangirane opcije.
