Jure Čuhalev je govoril z Miho Zidarjem (Fencer) o tem, kako sespreminjata razvoj in način dela z uporabo umetne inteligence in agentov. Odprla sta vprašanja kot so - kaj so agent harnessi oziroma, kot je predlagal Miha, ogrodja, znotraj katerih agent lahko dela? Kako se spreminja vloga in pomen CI/CD? Zakaj in kako so feature togglei izjemno pomembni za hiter terzanesljiv razvoj. Kako zagotoviti zaupanje in varnostne mreže? Kako navigirati čez izzive, ki jih tovrstne oblike razvoja prinesejo in kako biti boljši razvijalec? Miha je zgodbo začel pri zgodovini metodologij. Ker je bil razvijalski čas nekoč izjemno drag, smo okoli razvijalcev gradili ograje - od waterfalla do kasnejših "agilnih" pristopov, ki so cikel skrajšali s šestih mesecev na šest tednov, a so ostali projektno usmerjeni. Število napak na tisoč vrstic kode se kljub temu ni bistveno spremenilo. Zato je boljši pristop od preprečevanja napak omejevanje njihovega dometa: majhni koščki, pogosto v produkcijo. Poanta pogostih deployev ni število, ampak to, da te ni strah poslati kode v produkcijo takrat, ko ti to ustreza - tudi če je to enkrat na teden. In o tem ne sme odločati nekdo drug: če je koda šla čez CI, odloča razvijalec oziroma ekipa. Govorila sta tudi o DORA metrikah in o merjenju ter organizaciji dela dobrih ekip, pri čemer je Miha opozoril, da gre za korelacijo in ne vzročnost - deset deployev na dan samo po sebi ne pomeni dobrega in varnega produkta. Razmišljal je tudi o Swiss cheese modelu, kjer ima vsaka plast varovanja svoje luknje, in oMTTR, ki bi moral biti klik na gumb in ne paničen popravek kode - če moraš za popravek v produkciji pisati kodo, si nekje prej že zgrešil. Precej časa sta namenila drugi plati varoval: varovalo, ki mu ne moreš zaupati, je slabše od nobenega, ker mu ljudje zaupajo bolj, kot bi smeli. Miha je opisal primer avtomatskihperformančnih testov, ki so javljali petodstotne degradacije ob petdesetodstotnem šumu, kar je demonstriral tako, da je iste rezultate "izboljševal" in "kvaril" brez enega samega commita.Enako velja za flaky teste, ki jih ekipa začne ignorirati, in za feature toggle, ki jih Miha priporoča kot največji učinek za najmanj truda, a s pomembnim opozorilom - vsak dodaten toggle je dodatna kompleksnost in kombinacija, ki je nihče ne testira, zato jih je treba čim prej pobrisati. Alternativa je ločen deploy na stranko, kjer je domet napake odstotek prometa.Dotaknila sta se tudi vidljivosti v produkciji in vloge QA ekip, ki lahko razvijalce naredijo manj previdne. Pri agentih se po Mihovem mnenju ponavlja ista zgodba, le da agent nima spomina - ima kontekst, ki ne sme biti prevelik, in se z vsako posodobitvijo modela na novo uči. Znanje, ki se je prejprenašalo med ljudmi v firmi, je zato treba zakodirati v sistem, tako da junior, nov senior z drugačnimi navadami ali agent vsi zadenejo iste dogovorjene standarde. Ko sistem dobi tostabilnost, ljudje dobijo zaupanje, in šele takrat gredo DORA metrike gor same od sebe. Hvala za pozornost in družbo! Se vidimo na našem Discordu - discord.com/invite/xV2Xc4VX9W ✌️
