AI može generirati uvjerljivu funkciju na temelju upita. To nije isto što i razumjeti softver kojem se pridružuje.

Najteži dio pozadinskog inženjerstva nikada nije bio brzo pisanje koda. To je očuvanje namjere preko granica: API ugovora, ograničenja baze podataka, pravila ponovnog pokušaja, okruženja za implementaciju i neprivlačnog pravila da neuspjelo plaćanje ne smije postati dva plaćanja. Ako se od AI asistenta očekuje da radi trajne promjene, treba mu pristup toj namjeri u oblicima koje može pregledati i o kojima može zaključivati.

Upit je samo ulaz. Sustav je kontekst.

Softver je više od svojih izvornih datoteka

Tipična PHP usluga može iz kontrolera izgledati jednostavno: validirati zahtjev, pozvati uslugu, spremiti zapis, vratiti JSON. No smisleno ponašanje može biti raspodijeljeno među migracijama baze podataka, radnicima reda čekanja, konfiguracijom okruženja, Docker definicijama, pravilima obrnutog proxyja, postavkama nadzora i API ugovorima trećih strana.

Razmotrite krajnju točku za stvaranje narudžbe. Lokalno uvjerljiva implementacija mogla bi umetnuti redak narudžbe i staviti e-poruku potvrde u red čekanja. Implementacija svjesna sustava postavlja korisnija pitanja: Je li zahtjev idempotentan? Rezervira li se zaliha prije potvrde transakcije? Može li objava u red čekanja ne uspjeti nakon upisa u bazu podataka? Šalje li ponovni pokušaj još jednu e-poruku? Koje su vrijednosti statusa valjane i gdje se provode?

Na ta pitanja nije moguće pouzdano odgovoriti općenitim upitom kao što je “dodaj stvaranje narudžbe”. Ona ovise o artefaktima koji arhitekturu čine razumljivom.

Učinite ugovore vidljivima

Najvrjedniji kontekst obično nije više proze. To je eksplicitan ugovor blizu koda koji ga implementira. OpenAPI opisi, JSON sheme, tipizirani DTO-ovi, migracije baze podataka i integracijski testovi otkrivaju različite dijelove istine sustava.

Na primjer, kontroler ne bi smio prešutno odlučivati što znači status narudžbe. To pravilo pripada granici domene, dosljedno predstavljenoj u validaciji, pohrani i odgovorima.

enum OrderStatus: string
{
    case Pending = 'pending';
    case Paid = 'paid';
    case Cancelled = 'cancelled';
}

Ova mala definicija ne rješava poslovni tijek rada, ali uklanja dvosmislenost. AI koji je čita može vidjeti dopuštene vrijednosti umjesto da izmisli stanje processing zato što zvuči razumno. Isto načelo primjenjuje se na odgovore o pogreškama, formate paginacije, pravila autorizacije i terete webhookova.

Korisni ugovori trebali bi biti izvršivi gdje je to moguće. Dokumentirana krajnja točka je korisna; dokumentirana krajnja točka potkrijepljena testovima mnogo je pouzdanija. Kada se dokumentacija i ponašanje ne slažu, paket testova trebao bi taj nesklad učiniti vidljivim, umjesto da dopusti da postane plemensko znanje.

Dizajnirajte granice koje otkrivaju namjeru

AI bolje funkcionira u sustavima s jasnim spojevima jer i ljudi u njima bolje rade. Kontroler koji pristupa nekoliko tablica, oblikuje vanjski zahtjev, primjenjuje pravila određivanja cijena i šalje posao ostavlja previše ponašanja implicitnim. Razdvajanje tih odgovornosti stvara mjesta na kojima se namjera može imenovati i testirati.

• Kontroleri prevode HTTP pitanja u zahtjeve aplikacije.
• Aplikacijske usluge koordiniraju slučaj upotrebe i njegovu granicu transakcije.
• Kod domene upravlja poslovnim pravilima i prijelazima stanja.
• Adapteri izoliraju baze podataka, redove čekanja, pružatelje plaćanja i drugu infrastrukturu.

Ovo nije argument za ceremonijalne slojeve oko svakog CRUD zaslona. Ispravna količina strukture jest ona koja sprječava da važne odluke procure posvuda. Jednostavno administrativno pretraživanje može biti sasvim u redu kao izravan upit. Naplata plaćanja, dodjela zaliha i dozvole računa zaslužuju snažnije granice jer pogreške imaju šire posljedice.

Dajte operacijama nazive, a ne samo implementacije

Metoda nazvana capturePayment() prenosi više od generičke save(). Ona sugerira nepovratnu vanjsku radnju, koja bi trebala odmah potaknuti pitanja o idempotentnosti, vremenskim ograničenjima i zapisima revizije.

Nazivi postaju osobito važni kod ponovnih pokušaja. Mrežni kvarovi su normalni, a operacija koja se može ponoviti mora biti dizajnirana tako da je njezino ponavljanje sigurno ili da se može prepoznatljivo odbiti. Ključ idempotentnosti često je dio ugovora, a ne opcionalna optimizacija.

public function createOrder(CreateOrderRequest $request): Order
{
    return $this->orders->findByIdempotencyKey($request->idempotencyKey)
        ?? $this->transaction->run(
            fn () => $this->createNewOrder($request)
        );
}

Pojedinosti se razlikuju ovisno o okviru i sloju perzistencije. Važno je da baza podataka također treba provoditi pretpostavku jedinstvenosti. Provjere samo na razini aplikacije mogu se utrkivati kada dva identična zahtjeva stignu istodobno.

Postupajte s bazom podataka kao s izvorom ponašanja

Shema baze podataka često je najzanemareniji oblik dokumentacije. Ipak, ona AI-ju i sljedećem programeru govori što je sustav spreman prihvatiti. Strani ključevi izražavaju odnose. Jedinstvena ograničenja štite identitet. Stupci koji ne dopuštaju null razlikuju obvezne podatke od opcionalnih. Ograničenja provjere mogu zaštititi jednostavne invarijante kada ih baza podataka podržava.

Migracije bi trebalo pregledavati kao promjene ponašanja, a ne samo kao infrastrukturu implementacije. Dodavanje stupca koji dopušta null obično je niskorizično. Zamjena vrijednosti koju koristi indeks, popunjavanje milijuna redaka ili pooštravanje ograničenja može utjecati na zaključavanja, planove upita i mogućnosti vraćanja promjena.

Za veće promjene preferirajte slijed proširenja i sužavanja:

1. Dodajte promjenu sheme kompatibilnu unatrag.
2. Implementirajte kod koji može čitati i stare i nove reprezentacije.
3. Namjerno popunite podatke, uz praćenje napretka i obradu neuspjeha.
4. Prebacite zapisivače i čitače kada su podaci stabilni.
5. U kasnijoj implementaciji uklonite zastarjeli put.

Ovaj obrazac ljudima i AI-ju pruža sigurniji put kroz promjenu. Zamjenjuje „izmijeni sve odjednom” eksplicitnim međustanjima.

Kontekst mora uključivati operativno okruženje

Kod koji prolazi lokalno ipak može zakazati u produkciji jer je njegovo okruženje cijelo vrijeme bilo dio stvarnog programa. Docker konfiguraciju, zadane vrijednosti varijabli okruženja, provjere ispravnosti, naredbe radnika i manifeste implementacije treba održavati kao prvoklasni kod.

PHP aplikaciji mogu trebati odvojeni procesi za web zahtjeve i rad reda čekanja. Ako Docker slika dokumentira samo ulaznu točku za web, AI može dodati klasu posla koja se nikada ne obrađuje. Ako provjera ispravnosti samo potvrđuje da se PHP pokreće, može prijaviti uspjeh dok aplikacija ne može dosegnuti svoju bazu podataka.

Operativna dokumentacija trebala bi odgovoriti na konkretna pitanja: što pokreće svaki proces, koje ovisnosti moraju biti dostupne, koja je konfiguracija potrebna i kako izgleda sigurno vraćanje promjena. Držite tajne izvan primjera i repozitorija, ali učinite potrebne nazive varijabli i pravila validacije vidljivima.

Izgradite povratne sprege, a ne lažno pouzdanje

Promjene koje generira AI zaslužuju iste zaštitne mjere kao i promjene koje stvaraju ljudi: formatiranje, statičku analizu, ciljane testove, integracijske testove za važne granice i pregled prema stvarnim kriterijima prihvaćanja. Cilj nije zahtijevati iscrpno testiranje za svaku izmjenu. Cilj je postaviti najjače provjere tamo gdje promjena prelazi granicu ili može narušiti stanje.

Dobar zahtjev za spajanje daje AI-ju dovoljno povratnih informacija da se ispravi. Neuspjeli test trebao bi identificirati ugovor koji je prekršen. Test baze podataka trebao bi koristiti realistična ograničenja. Test reda čekanja trebao bi provjeriti što se događa kada je isporuka odgođena ili duplicirana. Zapisnici i metrike trebali bi sadržavati identifikatore zahtjeva ili poslova koji produkcijske kvarove čine sljedivima.

Ovdje postoji primamljiva pogreška: tretirati AI kao bržeg junior programera kojem jednostavno trebaju dulji upiti. Takvo uokvirivanje propušta priliku. Bolji je cilj izgraditi sustav u kojem je ispravan put vidljiv, ograničen i testabilan.

Arhitektura postaje upit

Najbolji softver za razvoj uz pomoć AI-ja nije softver s najduljom datotekom uputa. To je softver čija je namjera raspodijeljena kroz iskrena sučelja, ograničenja, testove, migracije i operativne postupke.

Kada se ti dijelovi slažu, AI može dati koristan doprinos jer ima nešto stvarno za razumjeti. Kada su u sukobu ili ostaju implicitni, čak i elegantan generirani kod postaje nagađanje. Izgradite sustav tako da se njegova pravila mogu otkriti, a zatim neka upit pokaže na taj sustav. Tako pomoć postaje inženjerstvo, a ne automatsko dovršavanje.