Softverski timovi traže od umjetne inteligencije da piše više koda, objasni nepoznate repozitorije, generira testove i ubrza rutinski rad. To može biti korisno. No istodobno otkriva surovu istinu: sustav umjetne inteligencije uči iz strukture, jezika i odluka koje već postoje u kodnoj bazi. Ako je vaš proizvod labirint dupliciranih pravila, neobjašnjenih iznimaka i krhkih granica vlasništva, brže generiranje koda možda će samo pomoći da labirint raste.

Preuzimanje odgovornosti za vlastiti kod nije odbacivanje umjetne inteligencije. To je disciplina koja pomoć umjetne inteligencije čini sigurnijom i vrijednijom. Cilj je graditi softver koji ljudi mogu razumjeti, mijenjati i kojem mogu vjerovati — te kojim umjetna inteligencija može pomoći kretati se bez pretvaranja svakog zahtjeva u rizičnu igru pogađanja.

Umjetna inteligencija pojačava sustav koji već imate

Asistent umjetne inteligencije često može izraditi uvjerljivu implementaciju na temelju upita i nekoliko obližnjih datoteka. Uvjerljivo nije isto što i ispravno. Možda ne zna koje je poslovno pravilo namjerno, koja je apstrakcija zastarjela ili koja naizgled suvišna provjera štiti važan tijek rada korisnika.

Ta je razlika najvažnija u zrelim proizvodima. Težak posao rijetko je pisanje nove funkcije. On se sastoji od pronalaženja stvarnog izvora istine, razumijevanja kompromisa iza postojećeg ponašanja i unošenja male promjene bez narušavanja drugog dijela sustava.

Čista arhitektura ne znači maksimalnu apstrakciju ni savršeno ujednačenu kodnu bazu. Ona znači da su važne odluke vidljive. Razvojni inženjer — ili razvojni inženjer uz pomoć umjetne inteligencije — trebao bi moći brzo odgovoriti na osnovna pitanja: Gdje se nalazi ovo pravilo? Tko je za njega odgovoran? Što o njemu ovisi? Kako znamo da je promjena sigurna?

Učinite vlasništvo vidljivim u kodu

O vlasništvu se često raspravlja kao o organizacijskom konceptu: jedan tim je odgovoran za naplatu, drugi za identitet, a treći za mobilnu aplikaciju. To je korisno, ali nepotpuno. Vlasništvo nad kodom također mora biti čitljivo unutar repozitorija.

Razmotrite pravilo poput „pretplata se može otkazati samo ako nema nepodmirenog računa”. Ako se to pravilo pojavljuje u API kontroleru, pozadinskom radniku, web-klijentu i okidaču baze podataka, nitko za njega nije istinski odgovoran. Alat umjetne inteligencije kojem se zatraži dodavanje puta za otkazivanje može kopirati jednu od tih verzija i stvoriti petu.

Zdraviji dizajn određuje jednu autoritativnu domensku operaciju i omogućuje drugim slojevima da je pozivaju. API može provjeriti zahtjev i prevesti pogreške u odgovor. Radnik može zakazati posao. Korisničko sučelje može prikazati ishod. No poslovna odluka pripada jasno imenovanom, testiranom mjestu.

Upotrebljavajte granice koje odražavaju stvarne koncepte proizvoda

Dobre granice obično slijede jezik poslovanja, a ne tehničke trendove. „Narudžbe”, „ovlaštenja”, „radni prostori” i „obavijesti” jasnija su uporišta od generičke mape pod nazivom utils ili sveobuhvatnog servisnog sloja.

• Držite ključna poslovna pravila blizu koncepta proizvoda kojim upravljaju.
• Operacijama dajte nazive koji opisuju namjeru, poput cancelSubscription umjesto updateStatus.
• Neka ovisnosti teku prema stabilnim pravilima, a ne prema mehanizmima isporuke poput HTTP obrađivača ili komponenti korisničkog sučelja.
• Dokumentirajte neočite ograničenja uz kod i testove koji ih provode.

Ovo nije samo pitanje stila. Recenzentima daje način za procjenu generiranog koda. Umjesto da pitaju izgleda li zakrpa razumno, mogu pitati poštuje li granicu i smješta li odluku na pravo mjesto.

Pišite za sljedeću promjenu, a ne za trenutačnu demonstraciju

Umjetna inteligencija može učiniti primamljivim optimiziranje za trenutačni rezultat. Razvojni inženjer može zatražiti komponentu, krajnju točku, migraciju ili skup testova te brzo dobiti početnu točku. Izazov za vodstvo jest osigurati da brzina služi proizvodu, umjesto da prikriva neriješen rad na dizajnu.

Prije prihvaćanja promjene zapitajte se koju buduću promjenu ona olakšava ili otežava. Značajka izgrađena oko jasnog modela dozvola može kasnije podržati nove uloge. Značajka izgrađena od raspršenih uvjetnih provjera može funkcionirati danas, a istodobno svaki budući zahtjev za dozvolama učiniti skupim.

Male se odluke zbrajaju. Dosljedno rukovanje pogreškama, predvidljivo imenovanje, uska sučelja i smisleni testovi smanjuju količinu konteksta potrebnu za siguran rad. To jednako koristi novim članovima tima, udaljenim kolegama i alatima umjetne inteligencije.

Testovi trebaju objasniti odluke

Skup testova jedna je od najboljih površina za učenje u repozitoriju kada izražava ponašanje, a ne trivijalnosti implementacije. Vrijedan test čini više od dokazivanja da je funkcija pozvana; pokazuje što proizvod obećava u smislenim uvjetima.

it("does not cancel a subscription with a pending invoice", async () => {
  const subscription = createSubscription({ pendingInvoice: true });

  await expect(cancelSubscription(subscription)).rejects.toThrow(
    "A subscription with a pending invoice cannot be cancelled."
  );
});

Precizan jezik i alati razlikovat će se, ali načelo ostaje: testovi trebaju otkriti razlog postojanja pravila. Asistent umjetne inteligencije tada može upotrijebiti taj dokaz pri predlaganju povezanih promjena. Ljudski recenzent može vidjeti kada generirana zakrpa slabi ugovor.

Udaljenim timovima potreban je zajednički kontekst, a ne stalni sastanci

U udaljenom timu nedokumentirani je kontekst posebno skup. Odgovor nije pretvoriti svaku odluku u sastanak. Potrebno je ostavljati trajne tragove ondje gdje ljudi rade: sažete bilješke o dizajnu, promišljene opise zahtjeva za povlačenje, rasprave o problemima i povijest predaja koja objašnjava namjeru.

Za značajne promjene kratak pisani prijedlog može spriječiti mnogo ponovljenog rada. Navedite problem, predloženu granicu, razmotrene alternative i način na koji će promjena biti potvrđena. To asinkronim članovima tima daje nešto konkretno što mogu osporiti ili poboljšati. Također stvara kontekst koji može usmjeriti budući rad uz pomoć umjetne inteligencije.

Pregled koda trebao bi štititi ovo zajedničko razumijevanje. Recenzenti ne moraju prepisivati svaki redak niti odbacivati nepoznate pristupe. Trebali bi se usredotočiti na pitanja koja alati ne mogu pouzdano riješiti sami:

• Rješava li ovo stvarni problem korisnika?
• Je li poslovno pravilo smješteno unutar odgovarajuće granice?
• Što se događa kada ovisnost zakaže ili je unos nepotpun?
• Koje se ponašanje namjerno zadržava?
• Može li drugi inženjer održavati ovo bez ponovne izgradnje skrivenog konteksta?

Upotrebljavajte umjetnu inteligenciju kao suradnika, a ne kao vlasnika

Umjetna inteligencija posebno je učinkovita kada je zadatak ograničen, a okolni sustav razumljiv. Može izraditi nacrt ponavljajućeg koda, predložiti testne slučajeve, sažeti lokalne obrasce i pomoći u istraživanju refaktoriranja. Manje je pouzdana kada se od nje traži da iz nepotpunog konteksta zaključi strategiju proizvoda, razriješi dvosmislena pravila ili donese arhitektonsku odluku s velikim utjecajem.

Praktičan tijek rada zadržava odgovornost unutar tima. Najprije definirajte željeno ponašanje. Navedite relevantna ograničenja. Zatražite malu promjenu koju je moguće pregledati. Pokrenite testove i pregledajte putanje neuspjeha. Zatim pregledajte rezultat kao da je došao od sposobnog, ali tek zaposlenog razvojnog inženjera: koristan je, brz i još uvijek treba kontekst i prosudbu.

Nikada ne dopustite da generirani kod bude izuzet od standarda koji se primjenjuju na ručno napisani kod. I dalje treba jasnog vlasnika, razumljiv dizajn, odgovarajuće testove i operativni plan.

Trajna prednost je razumljiv softver

Najvrjednija kodna baza nije ona s najviše automatizacije ili najsloženijom arhitekturom. To je ona koja može prihvatiti promjenu bez ovisnosti o nekolicini ljudi koji pamte svaku povijesnu slučajnost.

To je ono što vlasništvo stvara. Ono pretvara kod u trajnu imovinu proizvoda, čini udaljenu suradnju mirnijom, razvojnim inženjerima daje prostor za rast i omogućuje umjetnoj inteligenciji da ubrza rad bez tihog preuzimanja kontrole nad dizajnom. Gradite softver koji sljedeću osobu može naučiti što znači. Zatim se pobrinite da ta sljedeća osoba — čovjek ili stroj — ima sustav iz kojeg vrijedi učiti.