Vibe coding: primjene i ograničenja

Dajte ljudima prostor za razvoj

CTO u velikom poduzeću može pomoći većem broju ljudi pretvoriti svoje znanje u ideje za softver. Pozovite ljude iz financija, operacija, prodaje i inženjerstva. Osigurajte im vrijeme, sintetičke podatke, testne API-je i podršku.

Dopustite različite alate za istraživanje uz jasne granice za instalaciju, račune i dopuštene ulazne podatke. Alat za izradu aplikacija u pregledniku, asistent za programiranje ili lokalni agent može pomoći testirati ideju. Izbor alata ne daje dopuštenje za učitavanje podataka tvrtke ili povezivanje produkcijskog sustava.

Objavite jednostavan postupak kojim se koristan prototip predaje razvojnom ili platformskom timu. Njegov autor donosi problem, primjer radnog procesa i uočenu vrijednost. Ne mora postati sigurnosni i operativni tim te usluge.

Utvrdite što trebate naučiti

Vibe coding obično počinje opisom željenog softvera. Prihvaćate generirani kod i prema vidljivom rezultatu usmjeravate sljedeću promjenu. Pojam ima različita značenja. U ovom vodiču osoba koja usmjerava rad ne mora razumjeti svaku odluku o implementaciji.

Ova metoda može pomoći u učenju. Jednostavno sučelje može pokazati da postupak odobravanja ima previše koraka. Privremena skripta može pomoći procijeniti format datoteke. Prototip daje ljudima konkretan prijedlog o kojem mogu razgovarati. To znanje možete zadržati i kad odbacite kod.

Najprije definirajte pitanje s odgovorom koji možete opaziti. Primjerice: „Može li voditelj tima razumjeti ovaj postupak odobravanja?” To pitanje ima jasan opseg. Zahtjev za sustav za troškove uključuje i zaštitu podataka, kontrolu pristupa, rad sustava i odgovornosti.

Bankarski prototip napravljen u utorak

Razmotrite izmišljeni primjer. Kolega iz financija u utorak alatom Lovable izrađuje nadzornu ploču s izmišljenim bankovnim transakcijama. Ona grupira troškove i prikazuje neplaćene račune. Tim sada može razgovarati o korisnom radnom procesu.

Netko predlaže povezivanje bankovnog računa tvrtke. Time se mijenjaju posljedice, čak i ako aplikacija i dalje nosi oznaku „prototip”.

Pristup za čitanje može otkriti stanja računa, povijest transakcija, imena ili nazive klijenata ili pozive na broj, ovisno o API-ju. Ako veza dopušta i plaćanja, pogreške mogu premjestiti stvarni novac. Potvrdite stvarni opseg ovlasti; bankovna veza ne uključuje uvijek pristup plaćanjima.

Demonstracija ne potvrđuje da korisnik vidi samo račune za koje ima ovlasti. Skriveni gumb ne provodi provjeru ovlasti. OWASP opisuje kako izostanak provjere računa ili zapisa može izložiti podatke drugog korisnika.

Za API-je za plaćanje idempotentnost znači da ponovljeni zahtjev ne ponavlja namjeravani učinak. Stripe dokumentira jednu implementaciju. Provjerite ponašanje, ograničenja i pravila ponovnog pokušaja stvarnog pružatelja usluge. Vraćanje prethodne verzije aplikacije ne poništava plaćanje koje je banka obradila.

Ovaj primjer nije dokaz nedostatka alata Lovable. Sigurnosne smjernice samog Lovablea traže zaštitu tajnih podataka, provjere na poslužitelju, testirana pravila za podatke i stalne preglede. Isti standard dokaza primijenite na svaki alat za izradu, agenta ili ručno napisanu aplikaciju.

Provjerite pristup prije povezivanja stvarnih sustava

Nastavite testirati radni proces sa sintetičkim podacima i testnim računima. Prije stvarnog pristupa osobe odgovorne za uslugu, sigurnost i platformu trebaju provjeriti aplikaciju i njezino operativno okruženje.

Upotrijebite odobreni postupak povezivanja banke ili pružatelja usluge. Dodijelite samo pristup potrebnim računima i potrebne ovlasti. Privatne vjerodajnice držite u odobrenom spremištu tajnih podataka, izvan promptova i koda preglednika. Ako su plaćanja potrebna, odredite tko ih odobrava i postavite ograničenja plaćanja. Provjerite kako opozvati pristup, istražiti kvarove i reagirati na sumnjive aktivnosti.

Te odluke moraju prethoditi unosu povjerljivih podataka ili stvarnih vjerodajnica u sustav. Čekanje službenog produkcijskog izdanja može biti prekasno. Nastavite s granicama podataka i infrastrukturom poduzeća.

Definirajte odgovornosti prije širenja upotrebe

Eksperiment s izmišljenim podacima može trajati kratko i imati malo korisnika. Kad drugi ovise o aplikaciji, definirajte odgovornosti za njezinu upotrebu.

1. Navedite odgovornu osobu.
2. Utvrdite dopuštene korisnike i podatke.
3. Definirajte odgovor na kvar.
4. Držite izvorni kod i konfiguraciju u repozitoriju.
5. Provjerite može li druga osoba pregledati i reproducirati sustav.

Ne treba svaka skripta platformu za veliko poduzeće. Osobni alat za formatiranje bez osjetljivih podataka treba manje kontrola od aplikacije za odobravanje plaćanja. Procijenite posljedice pogreške. Provjerite možete li je otkriti i poništiti njezine učinke.

Prije proširenja prototipa odvojite ono što ste naučili o problemu od dokaza o implementaciji. Možete zadržati sučelje i zamijeniti unutarnji kod. Možete ograničiti namjeravanu upotrebu. Prototip možete zadržati i kao privremeni eksperiment.

Planirajte ranjivosti nakon demonstracije

Uspješna demonstracija može sakriti ozbiljan nedostatak u održavanju. Za ovisnost može biti objavljena nova sigurnosna obavijest bez ikakve promjene vašeg koda. Skeniranje pri izdavanju opisuje samo jedan trenutak.

Ako se aplikacija i dalje upotrebljava, netko mora nastaviti otkrivati, procjenjivati i ispravljati ranjivosti. Ispravak mora stići u produkciju i proći provjeru. Skener bez tog postupka reakcije ostavlja izloženost neriješenom.

Provjerite što pružaju vaš stvarni alat i konfiguracija. Kasnije kontinuirano upravljanje ranjivostima objašnjava cijeli postupak, uključujući neuspjela skeniranja i postavljene verzije.

Omogućite jednostavan pregled sljedeće promjene

Zadajte agentu jednu malu promjenu s izričitim kriterijima prihvaćanja. Navedite koje radnje smije poduzeti. Pregledajte nastali diff. Provedite provjere koje mogu odbiti pogrešnu implementaciju. Postavljanje u okruženje zadržite kao zasebnu odluku dok odgovornosti za izdavanje ne postanu jasne.

NIST Secure Software Development Framework opisuje šire postupke sigurnog razvoja. Upotrijebite ga kao referencu pri procjeni kontrola koje nedostaju. Ne trebate napamet naučiti okvir. Trebate utvrditi koji dokazi nedostaju prije nego što softver utječe na druge ljude.