Većini softverskih organizacija ne nedostaje kôd. Nedostaje im kontekst koji objašnjava zašto kôd postoji, koja su pravila nepregovaračka i što se mora dogoditi kada stvarnost postane neuredna. Ta je razlika iznimno važna pri uvođenju umjetne inteligencije u proizvodni ili inženjerski tijek rada.

Sustav umjetne inteligencije može generirati funkcije, pozivati alate, sažimati tikete i predlagati promjene. No ako poslovna logika nije izričito definirana i dostupna, on uči iz najmanje pouzdanog dostupnog artefakta: raspršenih pojedinosti implementacije. Rezultat može djelovati kompetentno u demonstraciji, a pritom tiho kršiti pravila koja omogućuju funkcioniranje poslovanja.

Praktični cilj nije „naučiti model svemu”. Cilj je projektirati softver tako da se važne odluke izražavaju u oblicima koje i ljudi i sustavi umjetne inteligencije mogu pronaći, protumačiti, testirati i sigurno koristiti.

Poslovna logika više je od putanja koda

Poslovna logika obuhvaća politike i ograničenja koja određuju što sustav smije raditi. Pravilo otpreme, prag odobrenja, iznimka u određivanju cijena, provjera prava, politika zadržavanja podataka ili tijek povrata novca poslovna su logika čak i kada su trenutačno skriveni unutar kontrolera, okidača baze podataka, proračunske tablice ili nečijeg sjećanja.

Umjetna inteligencija ima poteškoća kada su ta pravila implicitna. Razmotrite agenta kojem je zadano dodavanje radnje „otkaži pretplatu”. Možda će pronaći shemu tablice i integraciju API-ja za naplatu, a zatim izraditi kôd koji pretplatu označava kao otkazanu. No stvarni postupak može zahtijevati zadržavanje pristupa do kraja plaćenog razdoblja, blokiranje otkazivanja tijekom spora, obavještavanje vlasnika računa i bilježenje događaja usklađenosti.

Nijedan od tih zahtjeva nije očit iz stupca nazvanog status.

Učinite odluke čitljivima i lokalnima

Prvi arhitektonski potez jest smjestiti odluke ondje gdje se mogu razumjeti. To ne zahtijeva veliki mehanizam pravila za svaku aplikaciju. Zahtijeva odupiranje navici raspodjele jedne politike kroz uvjete korisničkog sučelja, API rukovatelje, pozadinske poslove i ad hoc upite.

Korisni je obrazac dodijeliti imenovanoj domenskoj operaciji odgovornost za poslovnu odluku. Umjesto da mnogim pozivateljima dopustite izravnu izmjenu zapisa, pružite operaciju koja prihvaća relevantne činjenice i vraća izričit rezultat.

type CancellationDecision =
  | { allowed: true; accessEndsAt: Date }
  | { allowed: false; reason: "active_dispute" | "missing_permission" };

function decideCancellation(input: {
  hasPermission: boolean;
  hasActiveDispute: boolean;
  paidThrough: Date;
}): CancellationDecision {
  if (!input.hasPermission) {
    return { allowed: false, reason: "missing_permission" };
  }

  if (input.hasActiveDispute) {
    return { allowed: false, reason: "active_dispute" };
  }

  return { allowed: true, accessEndsAt: input.paidThrough };
}

To nije samo čišći kôd. Time se stvara stabilna jedinica značenja. Programer je može pregledati, test je može izvršiti, dokumentacija može upućivati na nju, a pomoćnik za programiranje temeljen na umjetnoj inteligenciji može je koristiti umjesto da rekonstruira politiku iz fragmenata.

Odvojite politiku, orkestraciju i nuspojave

Razvoj potpomognut umjetnom inteligencijom postaje mnogo sigurniji kada sustav razlikuje tri područja:

• Politika: što je dopušteno, potrebno ili zabranjeno.
• Orkestracija: uređeni tijek rada koji primjenjuje odluku.
• Nuspojave: zapisi u bazu podataka, e-poruke, plaćanja, poruke i pozivi vanjskih API-ja.

U primjeru pretplate odluka o otkazivanju jest politika. Ažuriranje pretplate, zakazivanje isteka pristupa, bilježenje revizijskog događaja i obavještavanje naplate jesu orkestracija i nuspojave. Miješanje svega toga u jednu veliku krajnju točku otežava osobi ili modelu utvrditi što mora ostati istinito.

To razdvajanje agentima daje i sigurnije granice. Agentu može biti dopušteno sastaviti test politike ili predložiti promjenu orkestracije, dok produkcijske nuspojave ostaju iza pregledanih sučelja. Što je neka radnja važnija po posljedicama, to je manje prihvatljivo njezino značenje izvoditi samo iz upita na prirodnom jeziku.

Pretvorite pravila u izvršive primjere

Dokumentacija pomaže, ali je proza po svojoj naravi dvosmislena. Testovi pretvaraju ključna očekivanja u nešto što sustav može provjeriti. Za rad s umjetnom inteligencijom testovi su i mehanizam povratne informacije: pokazuju pomoćniku koje je ponašanje važno i otkrivaju uvjerljive, ali netočne izmjene.

Dajte prednost primjerima koji opisuju smislen scenarij, a ne samo pojedinosti implementacije.

it("keeps access active until the paid-through date", () => {
  const decision = decideCancellation({
    hasPermission: true,
    hasActiveDispute: false,
    paidThrough: new Date("2030-06-30T00:00:00Z")
  });

  expect(decision).toEqual({
    allowed: true,
    accessEndsAt: new Date("2030-06-30T00:00:00Z")
  });
});

Granični slučajevi zaslužuju posebnu pozornost: vremenske zone, ponovni pokušaji, dvostruki događaji, nedostajući podaci, promjene dozvola, djelomični neuspjesi i sukobljena ažuriranja. Upravo su to područja u kojima model za generiranje koda može proizvesti nešto što djeluje razumno, ali narušava operativnu stvarnost.

Dajte agentima alate, a ne široke ovlasti

Ugrađivanje poslovne logike ne znači stavljanje svakog pravila u upit. To znači izlaganje pažljivo oblikovanih mogućnosti. Agent koji treba odgovoriti može li se narudžba vratiti trebao bi pozvati operaciju za provjeru uvjeta povrata, umjesto da pregledava sirove zapise narudžbi i improvizira odgovor.

Dobre granice alata čine ulaze, izlaze, dozvole i stanja neuspjeha izričitima. Alat koji izvršava radnju s važnim posljedicama trebao bi, gdje je to praktično, omogućiti probno pokretanje ili put provjere. Primjerice, previewRefund može objasniti ispunjava li se uvjet i koji je očekivani iznos prije nego što se pokrene zasebno odobrena radnja issueRefund.

Važna je i idempotentnost. Agenti ponovno pokušavaju. Mreže otkazuju. Pozadinski radnici ponavljaju poruke. Ako operacija može uzrokovati naplatu, obavijest ili prijelaz zapisa, njezino sučelje treba navesti kako se obrađuju dvostruki zahtjevi. Pouzdana automatizacija manje ovisi o sigurnosti modela nego o ponašanju sustava kada je ta sigurnost pogrešna.

Izgradite zajedničku mapu domene

Nazivi su dio arhitekture. Ako jedna usluga nešto naziva „kupcem”, druga „računom”, a treća „organizacijom”, i ljudi i umjetna inteligencija stvarat će netočna povezivanja između pojmova. Uspostavite mali domenski rječnik i koristite ga u kôdu, API-jima, testovima i dokumentaciji.

Sažete opise držite blizu kôda za pravila koja je lako pogrešno razumjeti. Povežite politiku s njezinim testovima i s tijekom rada koji je provodi. Cilj nije iscrpna dokumentacija; cilj je smanjiti broj mjesta na kojima netko mora nagađati.

Učinite umjetnu inteligenciju sudionikom dobro oblikovanog sustava

Najjača strategija za umjetnu inteligenciju nije tražiti od modela da nadoknadi nejasan softver. Ona je unaprijediti softver dok važno znanje ne dobije svoje mjesto: imenovane operacije za odluke, testove za primjere, alate za radnje i revizijske tragove za posljedice.

Kada je poslovna logika ugrađena na ovaj način, umjetna inteligencija postaje korisnija jer ima bolje ograde kojih se može držati. Programeri dobivaju istu korist. Arhitektura koja modelu pomaže naučiti vaš sustav obično je i arhitektura koja vašem timu pomaže mijenjati ga bez gubitka razloga zbog kojih je izgrađen.