AI može u nekoliko sekundi izraditi uvjerljiv plan implementacije, uredan opis pull requesta i prvu verziju koda. To mijenja tempo rada na softveru, ali ne mijenja središnju odgovornost inženjerskog tima: odlučiti što bi trebalo postojati, zašto bi trebalo postojati i hoće li ostati korisno nakon objave.

Rizik nije u tome što timovi koriste AI. Rizik je u tome da se uvjerljiva skica tretira kao gotova odluka. Skica može izgledati dovršeno, a istodobno sadržavati neprovjerene pretpostavke o korisnicima, arhitekturi, sigurnosti, operativnim troškovima ili nezgodnoj stvarnosti sljedećeg zahtjeva za izmjenu.

Odgovornost počinje tamo gdje generiranje završava.

Brzina je vrijedna; prosudba je posao

Generirano rješenje može savršeno riješiti navedeni problem, a ipak biti pogrešan izbor za proizvod. Razmotrite zahtjev za gumb „izvezi sve”. Skica izrađena uz pomoć AI-ja mogla bi brzo dodati krajnju točku, pozadinski zadatak i poveznicu za preuzimanje. Inženjerski posao nije završen kada ta putanja radi lokalno.

Netko i dalje mora pitati uključuje li „sve” osjetljiva polja, trebaju li veliki izvozi isteći, kako korisnik saznaje da je postupak dovršen, što se događa kada zadatak ne uspije na pola puta i odgovara li značajka stvarnoj potrebi korisnika. Možda je bolji proizvod filtrirano izvješće, zakazana isporuka ili mali skup polja koji podržava ponavljajući tijek rada.

Ova pitanja nisu odgode nametnute isporuci. Ona jesu isporuka. Pretvaraju rezultat u proizvod kojem se može vjerovati.

Odgovornost ima nekoliko slojeva

Dobri timovi čine odgovornost vidljivom duž cijelog puta od ideje do rada u produkciji. Nijedna osoba ne mora nositi svaki detalj, ali tim mora osigurati da svaki detalj ima vlasnika.

• Odgovornost za problem: Može li tim objasniti problem korisnika, željeni ishod i granice zahtjeva?
• Tehnička odgovornost: Uklapa li se implementacija u postojeći sustav, uključujući modele podataka, ovisnosti, mogućnost praćenja i ponašanje pri neuspjehu?
• Odgovornost za kvalitetu: Jesu li s odgovarajućom razinom pažnje razmotreni uobičajeni slučajevi, rubni slučajevi, pristupačnost, performanse i sigurnost?
• Operativna odgovornost: Može li tim otkriti problem, razumjeti ga, sigurno se oporaviti i podržati korisnike nakon objave?
• Odgovornost za učenje: Hoće li povratne informacije iz produkcije promijeniti sljedeću odluku tima, umjesto da nestanu u nepročitanoj nadzornoj ploči ili bilješci s retrospektive?

AI može ubrzati rad unutar svakog sloja. Može sažeti zapisnike, predložiti testove, objasniti nepoznati kod i generirati alternative. Ali ne može preuzeti odgovornost za incident u produkciji niti riješiti neslaganje oko kompromisa za proizvod. To ostaju ljudske obveze.

Preispitajte pretpostavke, ne samo sintaksu

Tradicionalni pregled koda često se usredotočuje na ispravnost, čitljivost i dosljednost. To je i dalje važno, osobito kada generirani kod stiže dovoljno brzo da stvori veći red za pregled. No pregled usmjeren na odgovornost također ispituje pretpostavke ugrađene u izmjenu.

Korisna rasprava tijekom pregleda može postaviti pitanja: Koje ponašanje korisnika čini ovo potrebnim? Što je namjerno izvan opsega? Na koju se postojeću konvenciju oslanjamo? Što bi moglo poći po zlu nakon implementacije? Kako bismo to znali? Koji je najjednostavniji način da promijenimo smjer?

Ta su pitanja osobito vrijedna za izmjene generirane AI-jem jer uglađen jezik može sakriti nesigurno zaključivanje. Detaljno objašnjenje nije dokaz. Prolazni paket testova nije dokaz da postoje pravi testovi. Čista apstrakcija nije dokaz da je apstrakcija potrebna.

Timovi bi trebali slobodno tražiti manju izmjenu. Najbolji odgovor na širok upit često nije široka implementacija. Može biti uski eksperiment s jasnim signalom uspjeha, izričitom granicom uvođenja i točkom odlučivanja nakon stvarne upotrebe.

Učinite provjeru konkretnom

„Molim vas, testirajte ovo” previše je neodređeno da bi stvorilo povjerenje. Definirajte što provjera znači za konkretnu izmjenu. Za novu postavku računa to može uključivati dozvole, validaciju, ponašanje pri reviziji, pristupačnost u pregledniku i ono što se događa kada ovisna usluga nije dostupna. Za migraciju baze podataka to može uključivati redoslijed implementacije, ponašanje pri popunjavanju podataka, ograničenja vraćanja na prethodno stanje i utjecaj zajedničkog rada starih i novih verzija aplikacije.

Generirani testovi korisna su polazna točka, ali tim bi prije njihova prihvaćanja ipak trebao prepoznati važna ponašanja. U suprotnom testovi mogu samo potvrditi da se implementacija ponaša točno onako kako je napisana.

Udaljenim timovima potrebna je pisana odgovornost

U distribuiranim timovima odgovornost ne može ovisiti o tome da se slučajno čuje rasprava ili prepozna tko je obično na mreži. AI to čini hitnijim jer smanjuje prepreke pri stvaranju artefakata, a povećava broj odluka skrivenih iza njih.

Pomaže jednostavan pisani zapis: kratka izjava o problemu, odabrani pristup, značajne odbačene alternative, bilješke o uvođenju i osoba ili skupina odgovorna za daljnje praćenje. To nije birokracija radi same sebe. Kolegama u drugim vremenskim zonama daje dovoljno konteksta da konstruktivno preispitaju odluku i sigurno upravljaju rezultatom.

Dobra dokumentacija također je alat za razvoj karijere. Programeri napreduju kada mogu pokazati ne samo da su implementirali značajku, nego i da su razumjeli kompromise, koordinirali objavu i unaprijedili sustav nakon promatranja njegove upotrebe. Sposobnost da se zaključivanje učini razumljivim oblik je tehničkog vodstva.

Zaštitite održivu isporuku

Brže izrađivanje nacrta može stvoriti očekivanje da se svaki zahtjev treba kretati brže. To je upravljački problem, a ne inženjerska neizbježnost. Ako AI štedi vrijeme na rutinskom radu, timovi dio tog vremena mogu utrošiti na bolje otkrivanje potreba, pouzdanije testiranje, jasnija sučelja i smanjenje nakupljene složenosti.

Bez tog izbora brzina samo povećava protok sve dok pregled, podrška i dežurstva ne postanu nova uska grla. Rezultat je poznat obrazac: više izmjena, manje razumijevanja i rastući osjećaj da nitko ne može sigurno dirati sustav.

Održivi timovi postavljaju drugačije očekivanje. Koriste automatizaciju za uklanjanje ponavljanja, a ljudsku pažnju čuvaju za nejasnoću i posljedice. Uspjeh mjere korisnim ishodima i sustavima koji se mogu održavati, a ne koliĉinom generiranog koda.

Tim i dalje ostaje proizvod

AI nacrti postajat će sposobniji. To inženjersku prosudbu čini vidljivijom, a ne manje vidljivom. Razlika nije u tome tko može najbrže generirati najdulju implementaciju. Razlika je u tome tko može nepotpune zahtjeve pretvoriti u jasne odluke, pažljivo isporučiti izmjene i nastaviti učiti kada stvarnost uzvrati odgovor.

Tim koji preuzima odgovornost za svoj rad ne odbacuje pomoć. Koristi pomoć s namjerom. Postavlja bolja pitanja prije izgradnje, provjerava ono što je važno prije objave i ostaje odgovoran nakon spajanja. Tako softver ostaje koristan dugo nakon što se nacrt zaboravi.