Poslovanje

Beyond AI Prompts: Engineering Products That Agents Will Seek to Build

Iznad AI upita: razvoj proizvoda koje će agenti nastojati izgraditi

AI agenti mijenjaju poznato pitanje u softveru: ne samo „Možemo li ovo izgraditi?“, nego i „Hoće li sposoban agent odlučiti izgraditi to s nama?”

To je pitanje veće od dizajna promptova. Promptovi mogu pokrenuti rad, ali proizvodi zaslužuju kontinuiranu upotrebu jasnim granicama, pouzdanim ponašanjem, korisnim podacima i sučeljima koja dobre odluke čine lakšima od loših. Ako agent može usporediti nekoliko alata, priklonit će se proizvodu koji je najlakše razumjeti, najsigurnije koristiti i najvjerojatnije će dovršiti posao bez spašavanja.

Za tehničke vođe to nije razlog za jurnjavu za novitetima. To je razlog da se trajne inženjerske discipline ponovno sagledaju kroz oštriju produktnu leću.

Agenti nagrađuju razumljive proizvode

Ljudi mogu nadoknaditi nejasnoće. Razvojni inženjer može zaključiti da polje nazvano status prihvaća samo mali skup vrijednosti. Inženjer podrške može znati da se asinkroni izvoz obično dovrši u roku od nekoliko minuta. Agentu ne bi trebala biti potrebna nijedna vrsta takvog neformalnog znanja.

Razumljivost znači da se proizvod objašnjava vlastitim dizajnom. Ulazi su dobro definirani, pogreške omogućuju poduzimanje radnji, promjene stanja su vidljive, a važne radnje imaju predvidljive ishode. Dokumentacija je važna, ali ne može nadoknaditi zbunjujući ugovor.

Razmotrite razliku između API-ja koji vraća općeniti neuspjeh i onoga koji vraća strukturirano objašnjenje:

{
  "error": {
    "code": "invalid_state_transition",
    "message": "An order in 'shipped' state cannot be cancelled.",
    "allowed_actions": ["request_return"]
  }
}

Drugi odgovor pomaže osobi, klijentskoj aplikaciji i agentu da se ispravno oporave. Smanjuje nagađanje upravo u trenutku kada je nagađanje skupo.

Ovo se načelo proteže izvan API-ja. Nadzorna ploča trebala bi učiniti vlasništvo vidljivim. Tijek rada implementacije trebao bi razlikovati neuspjelu izgradnju, blokirano odobrenje i dovršeno izdanje koje čeka provjeru. Zaslon za naplatu trebao bi jasno prikazati posljedice za cijenu prije primjene promjene.

Gradite za pouzdano dovršenje, a ne za impresivne demonstracije

Proizvod može izgledati inteligentno, a ipak biti težak za upotrebu u stvarnom radu. Test je podržava li potpun, ponovljiv ishod uz uobičajene nesavršenosti: spore ovisnosti, djelomične podatke, duplicirane zahtjeve, ograničenja dozvola i prekinute tijekove rada.

Kada dizajnirate mogućnost namijenjenu agentima, mapirajte cijeli posao, a ne samo sretan put. Ako agent stvara zapis kupca, može li otkriti mogući duplikat? Može li priložiti izvor svoje odluke? Može li sigurno ponovno pokušati nakon isteka vremena? Može li čovjek pregledati ili poništiti rezultat?

Korisni proizvodi čine ova pitanja odgovorivima unutar samog proizvoda. To obično zahtijeva nekoliko neglamuroznih temelja:

  • Stabilne identifikatore umjesto oznaka koje se mogu promijeniti.
  • Idempotentne operacije tamo gdje se očekuju ponovni pokušaji.
  • Izričite dozvole i vjerodajnice ograničenog opsega.
  • Revizijske tragove za radnje s važnim posljedicama.
  • Jasna stanja životnog ciklusa za dugotrajni rad.
  • Sigurne zadane postavke i točke potvrde za nepovratne promjene.

To nisu samo detalji implementacije. To su značajke proizvoda jer određuju mogu li korisnici s pouzdanjem delegirati smislen posao.

Dizajnirajte prijenos između autonomije i odgovornosti

Najvrjedniji tijekovi rada ne bi trebali biti potpuno autonomni. Trebali bi biti primjereno autonomni.

Agent može sastaviti bilješku o izdanju, klasificirati dolazne zahtjeve, uskladiti rutinske zapise ili pripremiti predloženu promjenu konfiguracije. No tim i dalje mora odlučiti koje radnje zahtijevaju pregled, koje se mogu nastaviti automatski i koje se nikada ne smiju dogoditi bez izravnog odobrenja.

Koristite granice odlučivanja, a ne nejasan oprez

„Zadržite čovjeka u procesu” često je previše neprecizno da bi usmjeravalo inženjerski rad. Definirajte granicu operativnim pojmovima. Na primjer, agent može automatski ažurirati nacrt članka u bazi znanja, poslati zahtjev za kupnju na odobrenje, a može mu biti zabranjeno naručivanje. Razlika je razumljiva, provjerljiva i podložna reviziji.

Dobre granice također čuvaju zamah. Ako svaka radnja zahtijeva odobrenje, ljudi postaju usko grlo, a automatizacija postaje sporiji oblik ručnog rada. Ako nijedna radnja ne zahtijeva odobrenje, organizacija preuzima rizike koje možda neće moći promatrati ili poništiti.

Pravi dizajn ljudima daje utjecaj u trenucima prosudbe, dok rutinsko izvršavanje ostaje rutinsko.

Učinite znanje o proizvodu dostupnim ondje gdje se rad odvija

Agenti su učinkoviti samo onoliko koliko je učinkovit kontekst kojim se mogu koristiti. Ipak, mnoge organizacije pohranjuju ključno znanje u raspršenim razgovorima, zastarjelim dokumentima i sjećanjima nekoliko iskusnih suradnika. To je već skupo za udaljene timove; rad uz pomoć agenata samo brže otkriva taj trošak.

Tehnički vođe mogu to poboljšati bez stvaranja dokumentacijske birokracije. Usredotočite se na informacije koje mijenjaju odluke: vlasništvo nad uslugama, granice sustava, postupke implementacije, trenutačna ograničenja, priručnike za incidente i definicije poslovnih pojmova.

Pišite ove artefakte za djelovanje. Koristan priručnik ne počinje lekcijom iz povijesti. Počinje načinom prepoznavanja problema, procjenom utjecaja, poduzimanjem sigurnog prvog koraka i eskalacijom kada je potrebna. Korisna arhitektonska bilješka identificira odgovornosti sustava, ovisnosti i ograničenja o kojima se ne pregovara.

Ta jasnoća koristi novim zaposlenicima, distribuiranim kolegama, budućim održavateljima i agentima podjednako. Zajednički je cilj smanjena ovisnost o sinkronom objašnjavanju.

Mjerite povjerenje kroz operativno ponašanje

Usvajanje nije isto što i povjerenje. Tim može isprobati agenta zato što je dostupan, a zatim se potajno prestati oslanjati na njega nakon nekoliko zbunjujućih ishoda. Vođe bi trebali pratiti signale koji otkrivaju postaje li proizvod pouzdan u svakodnevnom radu.

  • Koliko se često posao dovrši bez ručne rekonstrukcije?
  • Jesu li neuspjesi dovoljno razumljivi da se brzo riješe?
  • Mogu li korisnici pregledati što se dogodilo i zašto?
  • Znaju li ljudi kada delegirati, a kada intervenirati?
  • Čini li sustav sljedeću sigurnu radnju očitom?

Ova pitanja potiču bolje razgovore o proizvodu od uskog fokusa na opseg automatizacije. Više automatiziranih radnji nije automatski bolje. Bolji je ishod više korisnog rada dovršenog uz odgovarajuću kontrolu i manje skrivenog operativnog opterećenja.

Trajna prednost je inženjerska prosudba

Kako AI olakšava stvaranje koda, rijetka se vještina pomiče naviše. Diferencijator je sve više sposobnost oblikovanja vrijednog problema, postavljanja pouzdanih ograničenja i vođenja proizvoda od mogućnosti do trajne korisnosti.

Razvojni inženjeri u toj budućnosti ne postaju manje važni. Postaju odgovorniji za kvalitete koje softver čine vrijednim delegiranja: jasnoću, otpornost, sigurnost, reverzibilnost i empatiju prema osobi odgovornoj za rezultat.

Proizvodi koje će agenti nastojati izgraditi s nama nisu magične crne kutije. To su dobro projektirani sustavi koji namjeru čine jasnom, napredak vidljivim, a oporavak mogućim. Ugradite te kvalitete u proizvod sada i ljudi i agenti imat će bolji razlog da ga nastave birati.

Portret autora bloga

Mihajlo

Ja sam Mihajlo — programer vođen znatiželjom, disciplinom i stalnom željom da stvorim nešto smisleno. Dijelim uvide, tutorijale i besplatne usluge kako bih pomogao drugima da pojednostave svoj rad i rastu u svijetu softvera i umjetne inteligencije koji se neprestano razvija.