AI može izraditi zaslon, komponentu ili uvjerljiv plan implementacije u nekoliko sekundi. To je korisno. Također je lako zamijeniti brzinu za napredak proizvoda.

Softver koji je najvažniji rijetko je definiran svojom prvom verzijom. Svoju vrijednost stječe odlukama koje povezuju potrebe korisnika, poslovna ograničenja, operativnu stvarnost i dugoročno vlasništvo. Upiti mogu ubrzati dijelove tog rada, ali ne mogu ukloniti potrebu za njim.

Izazov za vodstvo nije oblikovati rad prema onome što AI može generirati. Radi se o oblikovanju softvera oko stvari koje organizacija mora napraviti ispravno — i o tome da ih je nemoguće zanemariti.

Započnite s problemom koji ima jasne granice

„Izradite nadzornu ploču” poziv je na stvaranje privlačne neodređenosti. Koristan problem proizvoda ima jasne granice: određenog korisnika, situaciju, cijenu neuspjeha i signal da se ishod poboljšao.

Razmotrite razliku između ova dva zahtjeva:

• „Izradite nadzornu ploču za izvješćivanje za korisnike.”
• „Pomozite administratorima računa da pronađu neuspjele uvoze podataka prije roka za tjedno izvješćivanje, jasno objasnite neuspjeh i omogućite siguran ponovni pokušaj bez kontaktiranja podrške.”

Druga izjava stvara pritisak na dizajn. Postavlja pitanja o dozvolama, ponašanju pri ponovnom pokušaju, porukama o pogreškama, povijesti revizija, svježini podataka i tijekovima rada podrške. Ta pitanja su mjesto gdje počinje produktno razmišljanje. Također otkrivaju gdje su generirano sučelje ili primjer koda samo polazišna točka.

Prije razgovora o implementaciji, timovi bi trebali moći opisati problem jednostavnim jezikom. Ako to ne mogu, AI će neizvjesnost često učiniti uglađenijom umjesto da je ukloni.

Učinite vlasništvo vidljivim u dizajnu

Softver postaje krhak kada je funkcionalnost „gotova”, ali nitko ne preuzima odgovornost za njezino ponašanje nakon objave. To je osobito često kada se isporuka mjeri spojenim pull requestovima ili dovršenim zadacima umjesto trajnom korisnošću.

Vlasništvo treba osmisliti kao dio proizvoda i procesa isporuke. Za svaku značajnu mogućnost razjasnite tko je odgovoran za:

• ishod za korisnika i poslovnu odluku koja stoji iza njega;
• očekivanja u pogledu pouzdanosti, sigurnosti i performansi;
• operativni odgovor kada dođe do neuspjeha;
• dokumentaciju koja korisnicima i članovima tima pomaže razumjeti funkcionalnost;
• odluku o njezinu poboljšanju, pojednostavnjenju ili povlačenju.

To ne znači pripisivati krivnju jednoj osobi. Znači osigurati da odgovornost ne nestane između proizvoda, dizajna, inženjerstva, podrške i operacija.

AI može izraditi nacrte testova, sažeti incidente i predložiti dokumentaciju. Ne može preuzeti odgovornost. Tim koji zna tko je vlasnik usluge, korisničkog putovanja ili tehničke odluke učinkovitije će koristiti te alate jer postoji krug ljudske prosudbe oko rezultata.

Ugradite ograničenja u sustav, a ne samo u upit

Upiti najbolje funkcioniraju kada djeluju unutar dobrih ograničenja. Isto vrijedi za programere. Snažno inženjersko okruženje čini siguran put koji se može održavati najlakšim putem.

Na primjer, ako tim očekuje da svaka promjena API-ja uključuje provjere autorizacije, mogućnost promatranja sustava i testove ponašanja pri neuspjehu, ta bi se očekivanja trebala pojavljivati u predlošcima, praksama pregleda koda, automatiziranim provjerama i konvencijama za usluge. Ne bi smjela ovisiti o tome hoće li se netko sjetiti zatražiti ih od asistenta.

Korisna ograničenja su konkretna:

• Definirajte jasne granice između usluga i vlasništva nad njihovim podacima.
• Učinite implementaciju, vraćanje na prethodnu verziju i onemogućavanje funkcionalnosti rutinskim, a ne herojskim postupcima.
• Bilježite smislene zapisnike i metrike prije nego što incident nametne tu potrebu.
• Koristite kontrolne popise za pregled za pitanja koja je lako previdjeti, poput kontrole pristupa, sigurnosti migracije i ponašanja u degradiranom stanju.
• Neka arhitektonske odluke budu lako dostupne, uključujući kompromise koji su do njih doveli.

Te prakse ne usporavaju inovacije. One smanjuju skriveni trošak promjene. Kada AI pomaže proizvesti više koda, to smanjenje još je važnije. Brže generiranje bez snažnijih zaštitnih ograda samo povećava opseg budućeg održavanja.

Dizajnirajte za nezgodan put

Sretni put je mjesto gdje žive demonstracije. Nezgodan put je mjesto gdje se povjerenje stječe ili gubi.

Što se događa kada je pružatelj plaćanja spor, kartica preglednika osvježena usred tijeka rada, uvezena datoteka ima jedan neispravno oblikovan redak ili dva administratora naprave proturječne promjene? To nisu rubni slučajevi u omalovažavajućem smislu. To su uobičajena stanja u stvarnom sustavu.

Praktični pregled dizajna postavlja pitanja kao što su:

• Može li korisnik razumjeti što se dogodilo bez čitanja tehničkog jezika?
• Može li sigurno ponovno pokušati radnju?
• Hoće li ponovni pokušaj duplicirati podatke ili pokrenuti nepovratnu operaciju?
• Koje se stanje čuva ako ovisnost nije dostupna?
• Kako će tim znati da se neuspjeh ponavlja?

AI može predložiti rukovanje pogreškama, ali nema urođeno razumijevanje toga koji su neuspjesi skupi, štetni ili reputacijski značajni za određeno poslovanje. Taj kontekst proizlazi iz promišljene suradnje s ljudima koji su najbliži korisnicima i operacijama.

Udaljeni timovi trebaju pisanu memoriju proizvoda

Distribuirani rad čini neformalni kontekst manje pouzdanim. Odluka donesena u kratkom razgovoru može biti nevidljiva programeru koji sutra implementira promjenu, kolegi iz podrške koji sljedeći mjesec obrađuje zahtjev ili novom zaposleniku koji se pridružuje sljedećeg tromjesečja.

Pisani artefakti ne moraju postati birokracija. Kratak zapis odluke, sažeta bilješka o izdanju i opis zadatka koji objašnjava zašto je promjena važna mogu spriječiti tjedne ponovnog rada. Cilj nije iscrpna dokumentacija. Cilj je dovoljno zajedničke memorije da ljudi mogu donositi usklađene odluke bez čekanja na sastanak.

To je još jedno područje u kojem AI može pomoći s mehanikom: pretvaranjem grubih bilješki u prvi nacrt, prepoznavanjem neodgovorenih pitanja ili sažimanjem tehničke rasprave. Tim i dalje treba potvrditi rezultat i sačuvati obrazloženje koje je važno. Čist sažetak nije koristan ako tiho uklanja neslaganje koje bi trebalo utjecati na sljedeću odluku.

Koristite AI kao umnožitelj prosudbe

Najvrjednija uporaba AI-ja u radu na softveru nije zamjena za razmišljanje. Ona oslobađa pažnju za rad koji zahtijeva razmišljanje: pojašnjavanje zahtjeva, uspoređivanje alternativa, pregled rizične promjene, pojednostavljivanje prenapučenog tijeka rada ili razgovor s korisnikom.

To zahtijeva zdrav standard dokaza. Generirani kod treba pročitati, testirati i razumjeti. Generirana objašnjenja treba provjeriti u odnosu na stvarni sustav. Generirane planove treba preispitati zbog nedostajućih ovisnosti, nevaljanih pretpostavki i operativnih praznina.

Pomaže jednostavno pitanje: Bi li tim mogao s pouzdanjem održavati ovo kad bi generirani rezultat nestao sutra? Ako je odgovor ne, rezultat još nije imovina. On je samo neprovjereno ubrzanje.

Učinite softver vrijednim brige

AI će i dalje olakšavati izradu softvera. To čini razlučivanje vrjednijim, a ne manje vrijednim. Organizacije koje izgrade trajne proizvode bit će one koje brzinu pretvaraju u učenje, učenje u bolje odluke, a bolje odluke u sustave kojima ljudi mogu vjerovati.

Jasno oblikujte problem. Iskreno dodijelite vlasništvo. Ugradite zaštitne ograde u sustav isporuke. Poštujte nezgodan put. Sačuvajte obrazloženje odluka. Zatim upotrijebite AI kako biste se brže kretali unutar tog temelja.

Upiti mogu pokrenuti rad. Svrha, odgovornost i disciplinirano izvršavanje ono su što softver čini nemogućim za zanemariti.