Miha Zidar: Pametnejši razvoj v dobi umetne inteligence

Jure Čuhalev je govoril z Miho Zidarjem (Fencer) o tem, kako se
spreminjata 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 ter
zanesljiv 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 o
MTTR, 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 avtomatskih
performanč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 prej
prenaš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 to
stabilnost, ljudje dobijo zaupanje, in šele takrat gredo DORA metrike gor same od sebe.