Vibe coding: primjena i ograničenja

Dajte ljudima prostor za izradu softvera

CTO u velikoj organizaciji može pomoći većem broju ljudi da svoje znanje pretvore u ideje za softver. Pozovite ljude iz finansija, operacija, prodaje i inženjeringa. Dajte im vrijeme, sintetičke podatke, sandbox API-je i podršku.

Dopustite ljudima da koriste različite alate za istraživanje, uz jasne granice za instalaciju, račune i dozvoljene ulazne podatke. Alat za izradu aplikacija u pregledniku, asistent za kodiranje ili lokalni agent može im pomoći da testiraju ideju. Izbor alata ne daje dozvolu za učitavanje podataka kompanije ili povezivanje stvarnog sistema.

Objavite jednostavan postupak za predaju korisnog prototipa inženjerskom ili platformskom timu. Autor prototipa opisuje problem, primjer radnog toka i uočenu vrijednost. Ne mora postati tim za sigurnost i operativni rad usluge.

Utvrdite šta trebate naučiti

Vibe coding obično počinje opisom softvera koji želite. Prihvatate generisani kod i vidljivim rezultatom usmjeravate sljedeću promjenu. Izraz 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. Jednostavan interfejs može pokazati da postupak odobravanja ima previše koraka. Privremena skripta može pomoći u procjeni formata fajla. Prototip daje ljudima konkretan dizajn o kojem mogu razgovarati. To znanje možete zadržati i kada odbacite kod.

Prvo postavite pitanje s odgovorom koji možete uočiti. Naprimjer: „Može li voditelj tima razumjeti ovaj postupak odobravanja?“ Ovo pitanje ima jasan opseg. Zahtjev za izradu sistema za troškove obuhvata i zaštitu podataka, kontrolu pristupa, operativni rad i odgovornost.

Bankarski prototip napravljen u utorak

Razmotrite izmišljeni primjer. U utorak kolega iz finansija koristi Lovable da napravi kontrolnu ploču na osnovu izmišljenih bankarskih transakcija. Ona grupiše potrošnju i prikazuje neplaćene fakture. Tim sada može razgovarati o korisnom radnom toku.

Neko predlaže povezivanje bankovnog računa kompanije. To mijenja posljedice, čak i ako aplikacija i dalje nosi oznaku „prototip“.

Pristup za čitanje može otkriti stanje računa, historiju transakcija, imena klijenata ili reference plaćanja, zavisno od API-ja. Ako veza dozvoljava i plaćanja, greške mogu prenijeti stvarni novac. Potvrdite stvarni opseg dozvola; bankarska veza ne uključuje uvijek pristup plaćanjima.

Demonstracija ne potvrđuje da korisnik može vidjeti samo račune za koje ima ovlaštenje. Skriveno dugme ne provodi ograničenje dozvole. OWASP opisuje kako izostanak provjera 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 dokumentuje jednu implementaciju. Provjerite ponašanje, ograničenja i pravila ponovnih pokušaja stvarnog pružaoca usluge. Vraćanje aplikacije na prethodnu verziju ne poništava plaćanje koje je banka obradila.

Ovaj primjer nije dokaz nedostatka u alatu Lovable. Lovableove vlastite sigurnosne smjernice traže zaštićene tajne, provjere na serveru, testirane politike podataka i stalni pregled. Primijenite isti standard dokaza na svaki alat za izradu aplikacija, agenta ili ručno napisanu aplikaciju.

Provjerite pristup prije povezivanja stvarnih sistema

Nastavite testirati radni tok sa sintetičkim podacima i sandbox računima. Prije pristupa stvarnim sistemima, neka odgovorni za uslugu, sigurnost i platformu provjere aplikaciju i njeno radno okruženje.

Koristite postupak povezivanja koji je odobrila banka ili pružalac usluge. Dodijelite pristup samo potrebnim računima i samo potrebne dozvole. Čuvajte privatne pristupne podatke u odobrenom spremištu tajni, izvan promptova i koda preglednika. Odredite odobrenja i ograničenja plaćanja tamo gdje su plaćanja potrebna. Provjerite kako opozvati pristup, istražiti neuspjehe i odgovoriti na sumnjivu aktivnost.

Ove odluke moraju prethoditi unošenju povjerljivih podataka ili pristupnih podataka za stvarne sisteme. Čekanje formalnog produkcijskog izdanja može biti prekasno. Nastavite s granicama podataka i infrastrukturom velikih organizacija.

Odredite odgovornosti prije širenja upotrebe

Eksperiment s izmišljenim podacima može kratko trajati i imati malo korisnika. Kada drugi ljudi zavise od aplikacije, odredite odgovornosti za njenu upotrebu.

1. Navedite odgovornu osobu.
2. Utvrdite dozvoljene korisnike i podatke.
3. Odredite odgovor na neuspjeh.
4. Čuvajte izvorni kod i konfiguraciju u repozitoriju.
5. Provjerite da druga osoba može pregledati i reproducirati sistem.

Ne treba svakoj skripti korporativna platforma. Lični alat za formatiranje bez osjetljivih podataka treba manje kontrola od aplikacije za odobravanje plaćanja. Procijenite posljedice greške. Provjerite možete li grešku otkriti i poništiti njene učinke.

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

Planirajte rad na ranjivostima nakon demonstracije

Uspješna demonstracija može sakriti ozbiljan nedostatak u održavanju. Za zavisnost se može pojaviti novo upozorenje o ranjivosti bez ikakve promjene vašeg koda. Skeniranje pri izdavanju opisuje jedan trenutak.

Ako aplikacija ostane u upotrebi, neko mora nastaviti pronalaziti, procjenjivati i ispravljati ranjivosti. Ispravka mora stići u produkciju i proći provjeru. Skener bez ovog postupka odgovora ostavlja izloženost neriješenom.

Provjerite šta pružaju vaš stvarni alat i konfiguracija. Kasnije, stalno upravljanje ranjivostima objašnjava cijeli proces, uključujući neuspjela skeniranja i raspoređene verzije.

Neka sljedeću promjenu bude lako pregledati

Dajte agentu jednu malu promjenu s izričitim kriterijima prihvatanja. Navedite koje radnje agent može poduzeti. Pregledajte nastalu razliku u kodu. Izvršite provjere koje mogu odbiti pogrešnu implementaciju. Zadržite raspoređivanje kao posebnu odluku dok odgovornosti za izdavanje ne budu jasne.

NIST Secure Software Development Framework opisuje šire prakse sigurnog razvoja. Koristite ga kao referencu pri procjeni kontrola koje nedostaju. Ne morate zapamtiti okvir. Trebate utvrditi koji dokazi nedostaju prije nego što softver počne utjecati na druge ljude.