Softver se više ne procjenjuje samo prema onome što radi danas. Sve se više procjenjuje i prema tome mogu li ga ljudi i sustavi umjetne inteligencije razumjeti, mijenjati, testirati, održavati i učiti iz njega sutra.

To mijenja pitanje vodstva. „Možemo li ovo isporučiti?” i dalje je važno, ali više nije dovoljno. Tehnički lideri moraju se pitati i: Čemu ovaj sustav uči sljedeću osobu — ili sljedeći inteligentni alat — koji se s njime susretne?

AI može brzo generirati kod, sažimati repozitorije, predlagati testove i pomagati u istraživanju incidenata. Ipak, njegova korisnost ovisi o kvaliteti okruženja koje mu je dano. Razgranata baza koda s dvosmislenim nazivima, skrivenim poslovnim pravilima, zastarjelom dokumentacijom i nepouzdanim testovima ne postaje jasna samo zato što je AI usmjeren na nju. Postaje lakše stvarati uvjerljive pogreške većom brzinom.

Softver je okruženje za učenje

Svaki je proizvod skup nagomilanih odluka. Neke su odluke eksplicitne: API ugovor, model domene, tijek rada za implementaciju. Druge su tiho ugrađene u uvjetne izraze, stupce baze podataka, Slack poruke i sjećanje osobe koja je napravila posljednji hitni popravak.

Kada je važno znanje raspršeno ili implicitno, organizacija ga stalno iznova plaća. Novim programerima treba više vremena da počnu doprinositi. Udaljeni članovi tima oklijevaju prije mijenjanja nepoznatog koda. Recenzije postaju ovisne o nekolicini dugogodišnjih zaposlenika. AI pomoćnici dobivaju nepotpun kontekst i vraćaju prijedloge koji izgledaju uglađeno, ali promašuju stvarna ograničenja.

Dobra arhitektura olakšava otkrivanje znanja. Ljudima i alatima daje korisne granice: gdje pravilo pripada, koja komponenta posjeduje odluku, što funkcija jamči i kako sustav dokazuje da to obećanje ostaje istinito.

Ovo nije argument za dokumentacijski teatar ili pretjeranu apstrakciju. Ovo je argument za to da se smisleni dijelovi sustava učine čitljivima.

Učinite vlasništvo vidljivim

Dvosmisleno vlasništvo jedan je od najbržih načina stvaranja softvera koji nitko ne može s pouzdanjem unaprijediti. Usluga može imati nominalni tim, ali ako nitko ne može reći tko je odgovoran za njezinu pouzdanost, plan razvoja, kvalitetu podataka i sučelja, odgovornost postaje reaktivna.

Vidljivo vlasništvo poboljšava isporuku jer nejasna pitanja pretvara u izravne puteve. Također daje radu uz pomoć AI-ja sigurniji operativni model. Inženjer koji koristi plan migracije generiran AI-jem trebao bi znati tko može potvrditi pretpostavke o podacima. Predložena promjena API-ja trebala bi imati jasnog vlasnika koji razumije očekivanja kompatibilnosti.

Definirajte vlasništvo na razini odluka

Timovi često dodjeljuju vlasništvo samo na razini repozitorija ili usluge. To je korisno, ali nepotpuno. Teški kvarovi obično se pojavljuju na granicama: pravilima identiteta, statusima naplate, pravilima zadržavanja, postavkama obavijesti i tijekovima rada među uslugama.

• Odredite tim ili ulogu odgovornu za svaku kritičnu domenu.
• Zabilježite izvor istine za važne podatke i poslovna pravila.
• Navedite koja su sučelja javna, interna, stabilna ili eksperimentalna.
• Jasno odredite puteve eskalacije za produkcijske incidente i rizične promjene.

Vlasništvo ne bi trebalo stvarati čuvare koji usporavaju svaku promjenu. Njegova je svrha omogućiti informiranu suradnju. Sustav s dobro utvrđenim vlasništvom lakše je razvijati jer suradnici znaju gdje potražiti kontekst i tko može osporiti nesigurnu pretpostavku.

Koristite granice koje objašnjavaju proizvod

O tehničkoj se arhitekturi često raspravlja u terminima usluga, okvira i dijagrama. Oni su važni, ali snažnije je pitanje odražava li struktura stvarne koncepte proizvoda.

Razmotrite internetsko tržište. „Narudžba”, „plaćanje”, „povrat novca” i „isporuka” nisu samo tablice ili krajnje točke. To su poslovni koncepti s različitim životnim ciklusima, pravilima i načinima kvara. Ako ih baza koda sažme u generički modul transakcija, može izgledati sažeto, a istodobno postati teža za razumijevanje.

Jasne granice domene pomažu ljudima razumjeti zašto kod postoji. Također ograničavaju promjene generirane AI-jem. Pomoćnik može biti korisniji kada se od njega traži da izmijeni modul pravila povrata novca s fokusiranim testovima nego kada se od njega traži da u monolitnoj aplikaciji pronađe svako mjesto gdje bi status plaćanja mogao biti važan.

Praktične granice ne zahtijevaju opsežan program mikroservisa. Modularni monolit može biti izvrstan kada moduli imaju jasne odgovornosti, ograničene ovisnosti i namjerna sučelja. Ključ nije u broju jedinica koje se mogu implementirati. Ključ je u tome olakšava li struktura pronalaženje i zaštitu logike proizvoda.

Pretvorite testove u izvršivo objašnjenje

Testovi se često smatraju zaštitom pri izdanju. Oni su također među najboljim objašnjenjima koja sustav može ponuditi. Fokusirani test pokazuje što je važno, uvjete koji pokreću određeno ponašanje i ishod koji poslovanje očekuje.

Na primjer, nejasan naziv testa poput should work correctly gotovo da ne pruža smjernice. Test nazvan refund_is_rejected_after_the_settlement_window_closes odmah prenosi pravilo proizvoda. Tijelo testa tada može učiniti pravilo konkretnim bez potrebe da čitatelj to zaključuje iz pojedinosti implementacije.

Takva je jasnoća važna pri pregledavanju promjena uz pomoć AI-ja. Generirani kod može zadovoljiti površinski test, a pritom kršiti nenavedeno pravilo. Dobro imenovani testovi usmjereni na scenarije otežavaju previd skrivenih očekivanja.

Dajte prednost pouzdanosti pred pukom pokrivenošću

Velik broj pokrivenosti nije isto što i pouzdano ponašanje. Testovi pružaju veću vrijednost kada štite smislene odluke i vjerojatne putove kvara.

• Testirajte pravila domene i rubne slučajeve koji bi naštetili korisnicima ili operacijama.
• Provjeravajte ugovore između komponenti i usluga.
• Uključite ponašanje pri kvaru, vremenska ograničenja, ponovne pokušaje i scenarije djelomičnog uspjeha tamo gdje su važni.
• Neka testovi budu dovoljno čitljivi da služe kao primjeri budućim suradnicima.

Kada je promjena rizična, postavite jednostavno pitanje: ako se ovo ponašanje pokvari sljedeći tjedan, bi li postojeći testovi objasnili što je pošlo po zlu? Ako ne bi, nedostajući test možda je vredniji od još jednog prečaca u implementaciji.

Dokumentacija bi trebala smanjiti trošak donošenja odluka

Dokumentacija ne uspijeva kada pokušava ispričati sve. Uspijeva kada odgovara na pitanja koja bi inače zahtijevala prekid rada, istraživanje ili nagađanje.

Korisna arhitektonska bilješka mogla bi objasniti zašto je tijek rada asinkron, što se događa kada nizvodni pružatelj usluga nije dostupan, koji su podaci mjerodavni i kako programer može potvrditi lokalnu promjenu. To je daleko vrednije od dijagrama koji navodi svaku internu klasu.

Za udaljene timove pisani je kontekst posebno važan. Vremenske zone i raspoređeni rasporedi čine neformalni prijenos znanja nepouzdanim. Sažet zapis odluke može spriječiti ponavljajuću raspravu. Pouzdan priručnik za postupanje može smanjiti stres tijekom incidenta. Jasan vodič za uvođenje može pomoći novom članu tima da postane produktivan bez tretiranja kolega kao tražilice.

AI ne zamjenjuje ovu disciplinu. On je pojačava. Dobar pisani kontekst daje AI pomoćniku bolji materijal za sažimanje, povezivanje i primjenu. Loš kontekst samo mu daje više dvosmislenosti koju može uvjerljivo reproducirati.

Dizajnirajte sustave isporuke za sigurno učenje

Održiva isporuka nije uklanjanje rizika. Riječ je o tome da rizik bude vidljiv, ograničen i popravljiv. Timovima su potrebne kratke povratne sprege, ali brzina bez vidljivosti jednostavno je odgođena neizvjesnost.

Zdrav put isporuke omogućuje razumijevanje što se promijenilo, potvrdu očekivanog ponašanja, promatranje rezultata i promjenu smjera kada je to potrebno. To načelo vrijedi bez obzira na to jesu li promjene napisane u potpunosti ručno ili izrađene uz pomoć AI-ja.

1. Neka promjene budu dovoljno male za pregled i dijagnosticiranje.
2. Koristite automatizirane provjere koje odražavaju stvarne brige o kvaliteti, a ne samo pravila oblikovanja.
3. Implementirajte u fazama kada to učinak zahtijeva.
4. Nakon izdanja pratite relevantne signale proizvoda i operacija.
5. Neka postupci vraćanja na prethodno stanje i ublažavanja problema budu uobičajeni, a ne herojski.

AI može pomoći u pripremi bilješki o izdanju, prepoznavanju pogođenih putova koda ili izradi nacrta testnih slučajeva. Odgovorni tim i dalje mora definirati zaštitne ograde. Alati mogu ubrzati odluku; ne mogu preuzeti odgovornost za njezine posljedice.

Prilika za vodstvo

Najvrjedniji tehnički lideri neće biti oni koji jednostavno najranije usvoje AI. Bit će to oni koji izgrade organizacije u kojima se AI može promišljeno koristiti: sustave s jasnim konceptima, eksplicitnim vlasništvom, pouzdanim testovima, dostupnim odlukama i praksama isporuke koje podržavaju oporavak.

Takav rad poboljšava više od rezultata AI-ja. Programere čini učinkovitijima, udaljenu suradnju mirnijom, a proizvode lakšima za razvoj kako se potrebe korisnika mijenjaju.

Na kraju, softver iz kojeg AI može učiti također je softver iz kojeg ljudi mogu učiti. Gradite za to zajedničko razumijevanje i baza koda postat će više od zapisa isporučenih značajki. Postat će trajna imovina koja pomaže da se sljedeća dobra odluka donese brže.