Softver rijetko zakaže zato što tim nije mogao izraditi značajku. Zakaže kada promjena naiđe na stvarnost: neočekivani unos, spora ovisnost, užurbano izdanje, nejasno upozorenje ili popravak koji rješava jučerašnji incident, a stvara sutrašnji. Agenti umjetne inteligencije mogu pomoći u tom razmaku — ne kao autonomni heroji, već kao sposobni partneri koji inženjerski rad čine promišljenijim, uočljivijim i otpornijim.

Korisno pitanje nije može li agent generirati kod. Mnogi mogu. Vrjednije pitanje je: može li pomoći timu da ranije uoči rizik, smanji ponavljajuću istragu i očuva ispravnu inženjersku prosudbu kada su sustavi pod pritiskom?

Otpornost je radna praksa

Otporan softver nastavlja pružati prihvatljivu uslugu kada se dijelovi okruženja ponašaju loše. To uključuje neispravno oblikovane zahtjeve, iscrpljene resurse, djelomične prekide rada, pogreške pri implementaciji i kvarove trećih strana. Uključuje i ljudsku stranu operacija: mogu li ljudi razumjeti što se dogodilo i sigurno reagirati.

Agent umjetne inteligencije može podržati taj rad tijekom cijelog životnog ciklusa isporuke. Može sažeti promjene u ponašanju zahtjeva za spajanje, predložiti nedostajuće rubne slučajeve, pomoći u tumačenju zapisnika tijekom incidenta ili pretvoriti grubu operativnu uputu u jasniji slijed provjera. To su vrijedni zadaci jer smanjuju kognitivno opterećenje bez potrebe da agent donese konačnu odluku o produkciji.

Ta je razlika važna. Otporan sustav ne bi trebao ovisiti o tome je li agent umjetne inteligencije u pravu. Umjesto toga, tim bi trebao osmisliti tijek rada tako da se izlaz agenta može pregledati, da ima jasne granice i da ga je lako odbaciti.

Koristite agente za proširenje inženjerske perspektive

Većina nedostataka nije skrivena na očitom putu. Nova krajnja točka može savršeno raditi s valjanim podacima, a pritom se loše ponašati kada naknadna usluga istekne zbog prekoračenja vremena. Ponovni pokušaj može poboljšati prolazne kvarove, a istodobno pojačati opterećenje tijekom prekida rada. Agent je osobito koristan kada ga se zatraži da promjenu ispita kroz nekoliko izričitih perspektiva, umjesto da ga se jednostavno pita: „Je li ovaj kod dobar?”

Pretvorite neodređene zahtjeve za pregled u konkretne upite

Dajte agentu promjenu, relevantna ograničenja i usko definiran zadatak. Na primjer, zatražite da utvrdi načine kvara povezane s idempotentnošću, prekoračenjima vremena, autorizacijom, dosljednošću podataka ili vidljivošću sustava. Zahtijevajte da razlikuje dokaze od nagađanja.

Review this payment-status handler for resilience concerns.

Focus on:
- duplicate requests and idempotency
- dependency timeouts and retry behavior
- error responses that may expose sensitive details
- logs, metrics, and traces needed for diagnosis

For each concern, cite the relevant code path and label it as
confirmed, likely, or needs human verification.

Ova struktura vodi do boljeg razgovora tijekom pregleda. Agent ne proglašava dizajn sigurnim; on pomaže recenzentu postaviti preciznija pitanja. Inženjer i dalje provjerava odnosi li se predložena zabrinutost na stvarnu arhitekturu i poslovna pravila.

Učinite ponašanje pri kvaru izričitim u kodu

Agenti su često učinkoviti u pronalaženju praznina između implementacije za sretan put i njezina operativnog ugovora. Razmotrite uslugu koja poziva vanjskog pružatelja. Pozivajući kod treba prekoračenje vremena, pažljivo ograničene ponovne pokušaje i smislen odgovor pri kvaru. Također treba odluku o tome što se događa kada je ishod neizvjestan.

async function fetchProfile(client, userId) {
  try {
    return await client.getProfile(userId, { timeoutMs: 1500 });
  } catch (error) {
    if (error.code === "TIMEOUT") {
      throw new ServiceUnavailableError("Profile service timed out");
    }
    throw error;
  }
}

Ovaj je primjer namjerno nepotpun. Pripada li ovdje ponovni pokušaj ovisi o pružatelju, operaciji, obrascima prometa i tome je li ponavljanje sigurno. Agent može predložiti pitanja poput „Je li ovaj zahtjev idempotentan?” ili „Pokušava li klijent već ponovno?” Ta pitanja sprječavaju čestu pogrešku: dodavanje drugog sloja ponovnog pokušaja bez spoznaje da jedan već postoji.

Koristite agente za izradu nacrta testova za ove slučajeve, ali pobrinite se da tvrdnje budu smislene. Test prekoračenja vremena trebao bi provjeriti ponašanje o kojem ovise korisnici i uzvodni pozivatelji, a ne samo da se dogodila iznimka. Test dvostrukog zahtjeva trebao bi potvrditi da se stanje ne mijenja dvaput. Test pričuvnog rješenja trebao bi potvrditi da se zastarjelim ili degradiranim podacima jasno upravlja.

Poboljšajte operacije bez automatiziranja odgovornosti

Tijekom incidenta najteži je dio često sastaviti pouzdanu sliku iz upozorenja, nadzornih ploča, povijesti implementacija, zapisnika i nedavnih promjena. Agent umjetne inteligencije može sažeti te ulaze, grupirati slične pogreške, predložiti vremensku crtu i utvrditi sustave koji prvo zaslužuju pregled.

To može uštedjeti dragocjene minute, osobito kada su dokazi šumoviti. No odgovor na incident također je područje u kojem pouzdanje može biti opasno. Agent može stvoriti uvjerljivu priču iz nepotpunih signala. Njegov sažetak tretirajte kao pomoć pri istrazi, a ne kao voditelja incidenta.

• Neka dokazi budu vidljivi. Zatražite od agenta da svaki zaključak poveže s retkom zapisnika, promjenom metrike, razlikom u konfiguraciji ili činjenicom koju je pružio čovjek i koja ga podupire.
• Odvojite opažanje od preporuke. „Stopa pogrešaka povećala se nakon implementacije” razlikuje se od „Odmah vratite prethodnu verziju.”
• Očuvajte granice odobravanja. Radnje poput promjena u produkciji, upotrebe vjerodajnica, komunikacije s korisnicima i popravka podataka trebale bi zahtijevati izričito ljudsko odobrenje.
• Zabilježite ishod. Nakon incidenta, potvrđena saznanja pretvorite u testove, upozorenja, poboljšanja operativnih uputa ili stavke zaostataka.

Izgradite pouzdane tijekove rada s agentima

Agent postaje pouzdaniji kada je njegovo okruženje namjerno ograničeno. Dajte mu pristup samo za čitanje kada pregledava ili istražuje. Omogućite samo dokumentaciju, područja repozitorija i alate potrebne za zadatak. Zahtijevajte strukturirani izlaz kada će naknadna automatizacija koristiti njegov rezultat. Najvažnije, nepovratne radnje odvojite od analize.

Praktičan tijek rada mogao bi agentu omogućiti pregled razlike implementacije i izradu kontrolnog popisa rizika. Razvojni inženjer pregledava taj popis, odabire eventualne promjene i pokreće uobičajeni postupak testiranja i implementacije. Agent zatim može sažeti dobiveni izlaz testiranja, ali ne može redefinirati što znači „prošlo”.

Ovaj pristup također pomaže timovima naučiti gdje agenti donose stvarnu vrijednost. Ako se isti nalaz pregleda ponavlja, poboljšajte statičke provjere, predloške testova ili konvencije usluga. Najbolji ishod nije agent koji zauvijek hvata isti problem; to je sustav u kojem je taj problem teže stvoriti.

Odaberite partnerstvo umjesto predstave

Agenti umjetne inteligencije mogu učiniti rad na softveru bržim, ali sama brzina nije otpornost. Otpornost proizlazi iz jasnih ugovora, ograničenih načina kvara, dobre vidljivosti, uvježbanog odgovora i inženjera koji razumiju kompromise koje čine.

Dobro upotrijebljen, agent jača te navike. Timovima daje još jedan par očiju, ubrzava rutinsku analizu i olakšava ponovnu upotrebu operativnog znanja. Neoprezno upotrijebljen, može dodati uglađenu neizvjesnost već složenim sustavima.

Trajan put je jednostavan: agentima dodijelite posao koji se može provjeriti, ljude zadržite odgovornima za odluke s posljedicama i svaku potvrđenu lekciju pretvorite u snažniju inženjersku praksu. Tako umjetna inteligencija postaje istinski partner u izradi softvera koji preživljava stvarni svijet.