Preskoči na sadržaj

AI-assisted kodiranju trebaju manje petlje

Beleške iz saveta Matta Pococka o ograničenjima konteksta, vertikalnim slice-ovima, TDD-u i tome gde je ljudska procena i dalje bitna.

  • ai-tools
  • workflow
  • engineering

Izvor: video Matta Pococka (YouTube).

Što više koristim AI coding agente, jedna stvar postaje sve očiglednija: alat vredi samo onoliko koliko vredi workflow oko njega.

Saveti Matta Pococka o AI-assisted kodiranju su korisni jer izbegavaju lenju verziju ove priče. Ne svodi se na “piši bolje promptove” ili “uzmi veći model”. Poenta je mnogo praktičnija: drži model unutar malog, dobro definisanog problema sa brzim feedback-om, a ljudsku procenu koristi tamo gde je i dalje bitna.

Ostani u pametnoj zoni

Veliki context window-i su korisni, ali nisu magija.

Model može da reklamira 200k tokena, 1M tokena, ili više. To ne znači da razgovor ostaje podjednako oštar dok se kontekst puni. Što više tokena dodaš, model mora da prati više veza. Na kraju ulazi u ono što Matt zove “dumb zone”: mesto gde i dalje zvuči samouvereno, ali počinje da donosi lošije odluke.

Praktično pravilo je jednostavno. Drži zadatke dovoljno male da stanu u pametnu zonu modela. U praksi to znači da aktivni kontekst držiš svežim, fokusiranim i po pravilu znatno ispod 100k tokena.

Kompakcija pomaže, ali nije isto što i čist reset. Nekad je ispravan potez da potpuno obrišeš kontekst i kreneš ispočetka iz osnovnog stanja. Analogija sa Mementom je gruba, ali tačna: oštećeno pamćenje čini da loše odluke deluju koherentno.

Pusti da te izroštilja pre koda

Čista specs-to-code verzija vibe codinga zvuči elegantno, a u praksi obično propadne.

Obećanje je zavodljivo: izmeniš spec fajl, predaš ga agentu i pustiš sistem da kompajlira softver iz zahteva. Problem je što gubiš kontrolu nad codebase-om. Prestaješ da dizajniraš stvar i počinješ da review-uješ šta god je model usput zaključio.

Bolji obrazac je da nateraš agenta da te intervjuiše pre nego što napiše kod.

Koristi “grill me” prompt. Neka postavlja jedno po jedno pitanje. Nateraj ga da razjasni proizvod, arhitekturu, edge case-ove, ograničenja, data model, očekivanja od UI-ja i failure mode-ove pre nego što pipne repozitorijum.

Evo kako da instaliraš i koristiš “grill me” skill:

npx skills@latest add mattpocock/skills

Taj proces je sporiji na početku, ali stvara zajedničku sliku. Agent više ne nagađa iz mutnog spec-a. Pomaže ti da maglovitu nameru pretvoriš u dizajn koji stvarno možeš da pregledaš.

Gradi vertikalne slice-ove, ne horizontalne faze

Agenti prirodno naginju ka horizontalnim planovima implementacije.

Prvo hoće da naprave sve šeme. Pa sve API rute. Pa ceo UI. Izgleda organizovano, ali odlaže integrisani feedback do samog kraja, a baš tada greške postaju skupe.

Vertikalni slice-ovi rade bolje.

Vertikalni slice, ili tracer bullet, seče kroz ceo stack. Jedan issue može da obuhvati oblik podataka, servisnu logiku i najmanji koristan UI za jedno jedino ponašanje. Ne mora da bude kompletan. Mora da dokaže da slojevi rade zajedno.

Ovo je bitno jer je AI agentima feedback potreban koliko i ljudima. Vertikalni slice ti daje nešto stvarno što možeš da pokreneš, pregledaš i ispraviš. Horizontalna faza ti daje gomilu delova i mnogo odloženog rizika.

Biraj Kanban umesto sekvencijalnih planova

Dugi sekvencijalni planovi serijalizuju posao.

Samo jedan agent realno može da prati “faza jedan, pa faza dva, pa faza tri” a da ne zgazi ostatak plana. To je loš oblik za paralelno izvršavanje.

Bolja struktura je Kanban tabla nezavisnih issue-a sa eksplicitnim blokirajućim vezama. Ako zadatak C zavisi od zadataka A i B, reci to direktno. Tretiraj posao kao usmereni aciklični graf, a ne kao dugačku checklistu.

To ti daje dve prednosti. Prvo, prave zavisnosti postaju vidljive. Drugo, više agenata može istovremeno da radi na zadacima koji se ne blokiraju.

Tabla je bitna jer razdvaja planiranje od raspoređivanja. I dalje možeš da imaš pravac proizvoda, ali izvršavanje postaje skup malih, nezavisno proverljivih jedinica.

Neka AFK coding zasluži pravo na postojanje

Planiranje treba da ostane interaktivno. Implementacija ponekad može da postane AFK posao.

Ta podela radi samo ako codebase ima jake feedback petlje. Bez testova, type check-ova, lintinga, smoke testova i jasnih signala greške, agent koji kodira sam samo proizvodi tekst u mraku.

TDD je jedan od najboljih načina da se petlja zategne.

Nateraj agenta da prvo napiše test koji pada. Onda neka implementira najmanju izmenu koja prolazi. Pa pokreni provere. Test nije puka ceremonija. Daje agentu metu, a tebi dokaz da ponašanje postoji.

AFK coding nije magična autonomija. To je automatizacija unutar sistema koji može brzo da odbije loš rad.

Dizajniraj duboke module u kojima agent radi

Đubre od codebase-a pravi đubre od agenata.

Codebase pun sitnih, jako spregnutih fajlova je težak za navigaciju ljudima, a modelima još teži. Agent mora da juri veze kroz ceo graf, da drži previše lokalnih konvencija u memoriji i da nagađa koji detalj je bitan.

Duboki moduli su bolji.

Dubok modul ima mali, stabilan javni interfejs i iza njega krije mnogo internog ponašanja. Taj oblik čoveku daje korisnu površinu za dizajn, a agentu omeđenu unutrašnjost u kojoj radi.

Tu ljudski inženjer treba da potroši ukus i procenu. Dizajniraj interfejse. Odluči gde su granice modula. Učini eksterno ponašanje dosadnim i stabilnim. Onda delegiraj implementaciju unutar te kutije.

Nemoj da automatizuješ ukus

Poslednja lekcija je najmanje zgodna: ljudski review je i dalje bitan.

AI može da generiše kod, testove, dokumentaciju, scaffolding, migracije i review komentare. Može da se kreće brzo kad je zadatak dobro oblikovan. Ali manuelni QA i code review su mesta gde ukus ulazi u sistem.

Tu primećuješ da li interakcija deluje kako treba, da li apstrakciju vredi zadržati, da li kod samo prolazi provere ili stvarno pripada codebase-u.

Cilj nije da se inženjer izbaci iz petlje. Cilj je da se inženjer pomeri na delove petlje sa najvećom polugom: dizajniranje posla, ograničavanje agenta, čitanje izlaza i odlučivanje šta je dovoljno dobro da ostane.

AI-assisted kodiranje najbolje radi kad manje liči na slepo generisanje, a više na disciplinovan inženjering sa bržim motorom za izvršavanje.