AI može izraditi uvjerljivu funkciju brže nego što većina timova može otvoriti pull request. Može objasniti okvir, sastaviti testove, refaktorirati modul i ponuditi tri pristupa problemu prije nego što ga razvojni inženjer završi opisivati. To je korisno. To je i razlog zašto se trajna prednost u razvoju softvera pomiče dalje od samog koda.

Rijetka vještina sve je više arhitektonska prosudba: odlučivanje o tome što zaslužuje postojati, gdje pripada odgovornost, koji su kompromisi prihvatljivi i kako sustav može nastaviti služiti ljudima dok se poslovanje, tim i ograničenja mijenjaju.

Kod je izraz odluka. Teži je posao donijeti ispravne odluke s nepotpunim informacijama, a zatim stvoriti uvjete u kojima ih drugi ljudi mogu dalje provoditi.

Arhitektura počinje granicom problema

Mnogi tehnički neuspjesi počinju prije implementacije. Tim dobije zahtjev poput „dodajte pretplate”, „izradite izvještavanje” ili „podržite poslovne korisnike”, a zatim ga počne dijeliti na zadatke. Rad može biti učinkovit dok temeljni problem ostaje nejasan.

Arhitekt najprije postavlja preciznija pitanja. Tko ima problem? Koje se ponašanje mora promijeniti? Što treba ostati nepromijenjeno? Koje operativne, pravne, komercijalne ili posljedice za podršku slijede? Koje bi pretpostavke mogle predloženo rješenje učiniti nevažnim?

Razmotrite zahtjev za funkcionalnost izvoza dostupnu korisnicima. Očita implementacija mogla bi biti gumb koji generira proračunsku tablicu. No korisno istraživanje moglo bi otkriti da korisnici trebaju zakazanu isporuku, da pristup podacima mora poštovati uloge računa, da veliki izvozi mogu prekoračiti vrijeme izvođenja te da podršci treba način dijagnosticiranja neuspjelih poslova. Funkcionalnost nije gumb. Ona je tijek rada s implikacijama za proizvod, sigurnost, pouzdanost i vlasništvo.

AI može predložiti obrasce implementacije za taj tijek rada. Ne može pouzdano odrediti koja su ograničenja najvažnija bez čovjeka koji razumije kontekst proizvoda i može pomiriti suprotstavljene potrebe.

Učinite kompromise vidljivima, a ne slučajnima

Arhitektura se često opisuje kao odabir „najboljeg” dizajna. U praksi je to odabir dizajna čiji kompromisi odgovaraju situaciji. Jednostavan sinkroni zahtjev može biti ispravan za interni alat s malim opsegom rada. Posao u pozadini stavljen u red može biti nužan kada je rad spor, moguće ga je ponovno pokušati izvršiti ili ovisi o nepouzdanim vanjskim sustavima. Nijedan obrazac nije univerzalno bolji.

Zadatak vodstva jest jasno imenovati kompromis. Na primjer: „Počet ćemo s jednom uslugom jer je brzina iteracije trenutačno važnija od neovisnog postavljanja. Pravila naplate izdvojit ćemo iza jasnog sučelja jer će se to područje vjerojatno mijenjati.” To budućim razvojnim inženjerima daje obrazloženje umjesto arheološke zagonetke.

Koristite odluke kao imovinu tima

Jednostavan zapis odluke može spriječiti ponavljane rasprave i smanjiti skriveno znanje. Ne treba mu formalnost. Zabilježite kontekst, odluku, razmotrene alternative i posljedice. Cilj nije dokazati da je izbor bio savršen. Cilj je omogućiti jednostavno ponovno razmatranje reverzibilnog izbora i otežati zaboravljanje skupog izbora.

• Kontekst: Što se promijenilo ili koji problem zahtijeva odluku?
• Odluka: Što će tim sada učiniti?
• Alternative: Koje su vjerodostojne opcije odbijene i zašto?
• Posljedice: Kakvu složenost, rizik, trošak ili naknadni rad ovo stvara?

Ta je navika osobito vrijedna u udaljenim timovima. Pisano obrazloženje ljudima u različitim vremenskim zonama pruža zajedničko polazište i čini neslaganje sadržajnijim od preferencije prema poznatim alatima.

Dizajnirajte za vlasništvo, a ne samo za isporuku

Funkcionalnost nije dovršena kada stigne u produkciju. Dovršena je kada je tim može razumjeti, pratiti, podržavati i sigurno mijenjati. To znači da arhitektura mora uzeti u obzir cijeli život sustava.

Za novi asinkroni proces vlasništvo uključuje više od radnika i reda. Netko mora znati kako se prikazuje neuspjeli rad, kada prestaju ponovni pokušaji, kako se sprječava dvostruka obrada, što korisnik vidi tijekom odgode i kako operater može intervenirati. Ako nijedno od tih pitanja nema odgovor, sustav je prenio složenost u budućnost.

Dobri tehnički voditelji tu budućnost čine vidljivom tijekom planiranja. Pitaju što se događa kada ovisnost nije dostupna, ulaz je neispravan, implementacija je prekinuta ili promet neočekivano poraste. To nije pesimizam. To je poštovanje prema činjenici da stvarni softver većinu svojeg života provodi izvan sretnog puta.

Ugradite opažljivost u funkcionalnost

Opažljivost treba tretirati kao infrastrukturu proizvoda, a ne kao posao čišćenja. Tim treba dovoljno signala da odgovori na praktična pitanja: Je li radnja uspjela? Koliko je trajala? Koji su račun ili zahtjev bili pogođeni? Je li ponovni pokušaj pomogao? Je li neuspjeh izoliran ili sustavan?

Točni alati se razlikuju, ali načelo ne: koristan sustav čini svoje važno ponašanje razumljivim. Zapisnici bez konteksta, metrike bez odluke koju podupiru i upozorenja bez jasnog vlasnika stvaraju buku umjesto pouzdanja.

Koristite AI kao polugu, a ne kao zamjenu za odgovornost

AI je izvrstan u ubrzavanju ograničenog rada. Može pomoći pri izradi matrice testova, sažimanju nepoznatog puta kroz kod, sastavljanju koraka migracije, usporedbi opcija implementacije ili prepoznavanju rubnih slučajeva koje vrijedi pregledati. Kada se dobro koristi, skraćuje udaljenost između ideje i konkretnog artefakta koji tim može pregledati.

Ali generirani kod nasljeđuje dvosmislenost upita i slijepe točke pregledavatelja. Tehnički uvjerljiv odgovor može prekršiti pravilo domene, izložiti podatke, stvoriti neograničen trošak ili se loše uklopiti u postojeće operativne prakse. Osoba koja spaja promjenu i dalje je odgovorna za te ishode.

Praktičan tijek rada jest dati AI-ju ograničene zadatke, a zatim pregledati njegov izlaz u odnosu na stvarni sustav:

1. Navedite namjeravano ponašanje i ograničenja o kojima nema pregovora.
2. Zatražite implementaciju ili skup alternativa.
3. Provjerite rezultat u odnosu na sučelja, pravila podataka, putove neuspjeha i uvjete implementacije.
4. Dodajte testove koji izražavaju poslovno ponašanje, a ne samo generiranu strukturu.
5. Zadržite obrazloženje ondje gdje ga sljedeći razvojni inženjer može pronaći.

Ovaj pristup štiti brzinu bez prepuštanja prosudbe drugima. Cilj nije dokazati da ljudi još uvijek mogu pisati kod. Cilj je usmjeriti ljudsku pozornost tamo gdje ima najveću polugu.

Stvorite sustave koji ljudima pomažu donositi dobre odluke

Arhitektura je također društveni dizajn. Tim s nejasnim vlasništvom, neprozirnim prioritetima i krhkim primopredajama imat će poteškoća čak i s elegantnim kodom. Nasuprot tome, tim sa zajedničkim modelom proizvoda, eksplicitnim sučeljima, konstruktivnim pregledima i upravljivom količinom rada u tijeku može postojano poboljšavati nesavršen sustav.

Tehnički voditelji na to utječu postavljanjem korisnih zadanih vrijednosti: male promjene umjesto herojskih prepisivanja, jasni kriteriji prihvaćanja umjesto podrazumijevanih očekivanja, učenje iz incidenata umjesto okrivljavanja te održiv tempo umjesto ponavljane hitnosti. Ti izbori čine isporuku predvidljivijom jer smanjuju količinu neizvjesnosti skrivene u svakodnevnom radu.

Najvrjedniji softverski stručnjaci neće biti oni koji se natječu s AI-jem u stvaranju izoliranih redaka koda. Bit će to ljudi koji nejasnoću pretvaraju u koherentan plan, povezuju tehničke izbore s ljudskim ishodima i ostavljaju iza sebe sustave koje drugi ljudi mogu sigurno razvijati.

To je posao izvan koda: ne samo izgradnja softvera koji radi, već i izgradnja prosudbe, vlasništva i zajedničkog razumijevanja koji korisnom softveru omogućuju da potraje.