Većina rasprava o razvoju uz pomoć umjetne inteligencije počinje s promptovima: kako sročiti zahtjev, koji model odabrati, koliko konteksta zalijepiti u prozor za razgovor. Promptovi su važni, ali nisu temelj. Kvaliteta izlaza AI sustava često je manje ograničena sposobnošću modela nego time pruža li mu okolni softver koherentan svijet koji može razumjeti.

Agent ne može pouzdano poboljšati bazu koda kojom se ne može kretati, koju ne može testirati ni provjeriti. Ne može donijeti sigurnu operativnu odluku kada su relevantna pravila raspršena po dokumentima, neformalnom znanju i zastarjelim nadzornim pločama. Praktični izazov nije samo dodati AI softverskom radu. Riječ je o projektiranju softvera tako da AI može sudjelovati bez stvaranja samouvjerenog, skupog izvora zabune.

AI treba razumljive sustave, a ne samo velike kontekstne prozore

Ljudski programeri iznimno dobro nadoknađuju nejasnoće. Pitaju kolegu gdje se nalazi stvarno poslovno pravilo, zaključuju konvencije iz nekoliko primjera i prepoznaju kada je skup testova obmanjujući. AI ponekad može učiniti te stvari, ali pouzdana automatizacija ne bi trebala ovisiti o tome.

Razumljivost znači da sustav izlaže dovoljno strukture da alat ili agent može točno odgovoriti na osnovna pitanja: Za što je ova usluga odgovorna? Koji su ulazi valjani? Koje se nuspojave mogu pojaviti? Kako se mjeri uspjeh? Što se nikada ne smije dogoditi?

To počinje uobičajenom inženjerskom disciplinom. Jasne granice modula, eksplicitna sučelja, stabilno imenovanje, izvršivi testovi, vidljivo ponašanje u produkciji i ažurna dokumentacija nisu posebni projekti „spremnosti za AI”. To su ista ulaganja koja ljudima olakšavaju održavanje sustava. AI samo čini cijenu njihove odsutnosti vidljivijom.

Izgradite okruženje koje agent može sigurno pregledati

Dati agentu pristup repozitoriju i zatražiti od njega da „popravi grešku” nije radni tijek. To je neograničen zahtjev s nejasnim ovlastima. Korisniji dizajn agentu daje namjerne alate, uska dopuštenja i povratne petlje.

Na primjer, agentu za održavanje koda možda će trebati da:

• pretražuje repozitorij i čita relevantne datoteke;
• pokreće usmjerene testove i statičku analizu;
• mijenja datoteke unutar odobrenog radnog prostora;
• izrađuje diff za pregled;
• stane kada testovi ne uspiju ili pretpostavke ostanu nerazriješene.

Primijetite što nedostaje: neograničen pristup produkciji, široke vjerodajnice i dopuštenje da se poslovna namjera zaključuje iz poruke o pogrešci. Sustav bi trebao učiniti sigurni put jednostavnim, a nesigurni put nedostupnim.

Dizajn alata ovdje je važan. Alat nazvan deploy skriva previše. Skup eksplicitnih operacija kao što su build_release_candidate, run_staging_smoke_tests i request_production_approval čini ovlasti vidljivima. Također poboljšava mogućnost revizije: recenzenti mogu vidjeti ne samo do kojeg je zaključka agent došao, nego i što je mogao učiniti.

Pretvorite implicitno znanje u dohvatljive dokaze

Mnogi neuspjesi AI-ja zapravo su neuspjesi upravljanja znanjem. Agent za podršku daje pogrešan odgovor jer se pravilo promijenilo u dokumentu koji nitko nije indeksirao. Agent za programiranje mijenja očitu uslugu jer se arhitektonsko obrazloženje vlasništva nalazi u staroj bilješci sa sastanka. Agent za izdavanje ponavlja neuspjelu implementaciju jer ne može razlikovati prolazni kvar ovisnosti od problema s destruktivnom migracijom.

Korisni kontekst nije hrpa datoteka. To su kurirani dokazi s vlasništvom, opsegom i svježinom. Dokumentacija bi trebala razlikovati trajna pravila od privremenih uputa. Operativne upute trebale bi navesti preduvjete, očekivane izlaze i točke eskalacije. Metapodaci usluge trebali bi identificirati vlasnike, ovisnosti, okruženja i kritične putove podataka.

Oblikujte kontekst oko odluke

Umjesto pitanja: „Koje bi informacije model trebao znati?”, pitajte: „Koji su dokazi potrebni da se ova odluka donese sigurno?” Recenzent zahtjeva za povlačenje treba programske konvencije, promijenjeni kod, relevantne testove i možda ugovor nizvodne usluge. Ne treba svaki arhivirani dokument o dizajnu.

Ovaj pristup smanjuje šum i stvara bolje ponašanje pri neuspjehu. Kada potrebni dokazi nisu dostupni, agent bi to trebao reći i zatražiti ih, a ne popuniti prazninu uvjerljivim proznim tekstom.

Neka provjera bude dio radnog tijeka

Rad koji generira AI treba smatrati prijedlogom dok ne prođe neovisne provjere. Najjači obrazac nije „generiraj, pa vjeruj”, nego „generiraj, pregledaj, provjeri i zabilježi”.

Za promjene koda provjera može uključivati formatiranje, provjere tipova, jedinične testove, integracijske testove, sigurnosna skeniranja i ljudski pregled razmjeran riziku. Za odgovore namijenjene korisnicima može uključivati dohvaćanje pravila, citiranje mjerodavnog izvora i prag pouzdanosti koji neizvjesne slučajeve usmjerava osobi.

Ključno je da provjera mora testirati rezultat, a ne samo potvrditi da je agent dovršio niz koraka. Agent koji prijavi „implementacija je uspjela” nakon primanja uspješnog API odgovora možda je ipak implementirao pogrešnu verziju, nije prošao zdravstvene provjere ili je ostavio zastavicu značajke onemogućenom.

task: update_dependency
success_conditions:
  - lockfile_changed
  - focused_tests_pass
  - vulnerability_scan_completed
stop_conditions:
  - major_version_change
  - failing_integration_test
  - license_policy_uncertain
required_output:
  - summary
  - diff
  - test_results
  - unresolved_risks

Ova vrsta strukturirane definicije zadatka ne čini agenta inteligentnim. Ona njegovu ulogu čini provjerljivom. Također ljudima daje sažet način za pregled jesu li se automatizirani procesi ponašali unutar svojih namjeravanih granica.

Planirajte ponavljanja, nejasnoće i djelomične neuspjehe

Stvarni softverski rad pun je putanja neuspjeha. Mrežni poziv istekne. Test je nestabilan. Migraciju sheme sigurno je ponoviti samo prije određene točke. Vanjski sustav prihvati zahtjev, ali odgađa rezultat. AI radni tijek mora biti eksplicitan u vezi s tim stanjima.

Ponavljanja bi trebala biti ograničena i, gdje je moguće, idempotentna. Prije ponavljanja operacije radni tijek treba način za utvrđivanje je li prethodni pokušaj dovršen. Za radnje s nuspojavama trajni identifikator operacije i provjera statusa često su vredniji od još jednog optimističnog zahtjeva.

Nejasnoća zaslužuje jednaku pozornost. Ako agent naiđe na dvije uvjerljive definicije „aktivnog kupca”, ne bi trebao odabrati onu koja zadatak čini lakšim. Trebao bi istaknuti sukob, navesti konkurentske ulaze i predati odluku. Eskalacija nije neuspjeh automatizacije; ona je ispravan ishod kada su ovlasti ili dokazi nedostatni.

Koristite AI za poboljšanje sustava koji ga sadrži

Najtrajnija vrijednost često dolazi od korištenja AI-ja za otkrivanje mjesta na kojima je softver teško razumjeti. Ponovljeni zahtjevi za istim objašnjenjem repozitorija mogu ukazivati na nedostatak arhitektonske dokumentacije. Česte pogreške agenta oko radnog tijeka mogu otkriti nejasno sučelje. Obrasci ručnog pregleda mogu ukazivati na nedostatak automatizirane provjere.

Timovi bi trebali bilježiti te signale bez pretvaranja svake interakcije u nadzor. Pregledajte uzorak neuspjeha i predaja. Zapitajte se je li problem bio rezoniranje modela, neadekvatan kontekst, slab ugovor alata ili nejasno poslovno pravilo. Zatim poboljšajte najmanji sloj koji rješava uzrok.

Takav način razmišljanja izbjegava čestu zamku: opetovano mijenjanje prompta kada je stvarni nedostatak u okolnom sustavu. Bolji promptovi mogu poboljšati komunikaciju. Bolja arhitektura poboljšava pouzdanost svakog prompta koji slijedi.

Stvarna promjena je prijelaz s odgovora na odgovorno djelovanje

AI će i dalje ubrzavati izradu nacrta, pretraživanje, programiranje i sažimanje. No organizacije koje ostvare trajnu prednost bit će one koje osmisle rad tako da se predložene radnje mogu razumjeti, ograničiti, provjeriti i po potrebi poništiti.

Promptovi otvaraju razgovor. Arhitektura određuje hoće li taj razgovor postati pouzdan rad. Kada softver ima jasne granice, upotrebljive dokaze, sigurne alate i smislene provjere, AI postaje manje poput nepredvidivog proročišta, a više poput sposobnog sudionika u inženjerskom sustavu izgrađenom za suočavanje sa stvarnošću.