Vibe coding: lietojums un ierobežojumi

Dodiet cilvēkiem iespēju veidot

Uzņēmuma CTO var palīdzēt vairāk cilvēkiem pārvērst savas zināšanas programmatūras idejās. Aiciniet cilvēkus no finanšu, operatīvās darbības, pārdošanas un inženierijas komandām. Dodiet viņiem laiku, sintētiskus datus, testa vides API un atbalstu.

Ļaujiet ideju izpētei izmantot dažādus rīkus, skaidri nosakot instalēšanas, kontu un atļauto ievaddatu robežas. Pārlūkā pieejams lietotņu veidotājs, programmēšanas asistents vai lokāls aģents var palīdzēt pārbaudīt ideju. Rīka izvēle nedod atļauju augšupielādēt uzņēmuma informāciju vai pieslēgt darbojošos sistēmu.

Publicējiet vienkāršu kārtību, kā noderīgu prototipu nodot inženierijas vai platformas komandai. Veidotājs sniedz problēmas aprakstu, darbplūsmas piemēru un novēroto vērtību. Viņam nav jākļūst par pakalpojuma drošības un ekspluatācijas komandu.

Nosakiet, kas jānoskaidro

Vibe coding parasti sākas ar vēlamās programmatūras aprakstu. Jūs pieņemat ģenerēto kodu un pēc redzamā rezultāta nosakāt nākamās izmaiņas. Terminam ir dažādas nozīmes. Šajā ceļvedī cilvēks, kurš vada darbu, ne vienmēr izprot katru īstenošanas lēmumu.

Šī metode var palīdzēt mācīties. Vienkārša saskarne var parādīt, ka apstiprināšanas procesā ir pārāk daudz soļu. Pagaidu skripts var palīdzēt novērtēt faila formātu. Prototips dod cilvēkiem konkrētu risinājumu apspriešanai. Šīs zināšanas varat saglabāt arī tad, ja kodu izmetat.

Vispirms formulējiet jautājumu ar novērojamu atbildi. Piemēram: „Vai komandas vadītājs var saprast šo apstiprināšanas procesu?“ Šim jautājumam ir skaidrs tvērums. Pieprasījums izveidot izdevumu sistēmu ietver arī datu aizsardzību, piekļuves kontroli, ekspluatāciju un atbildību.

Otrdienas bankas prototips

Aplūkojiet izdomātu piemēru. Otrdien finanšu kolēģis ar Lovable izveido paneli no izdomātiem bankas darījumiem. Tas grupē izdevumus un rāda neapmaksātus rēķinus. Tagad komanda var apspriest noderīgu darbplūsmu.

Kāds ierosina pieslēgt uzņēmuma bankas kontu. Tas maina iespējamās sekas, pat ja lietotne joprojām ir apzīmēta kā „prototips“.

Atkarībā no API lasīšanas piekļuve var atklāt atlikumus, darījumu vēsturi, klientu vārdus un nosaukumus vai maksājumu atsauces. Ja savienojums atļauj arī maksājumus, kļūdas var pārvietot īstu naudu. Pārbaudiet faktisko tiesību tvērumu; bankas savienojums ne vienmēr ietver maksājumu piekļuvi.

Demonstrācija nepierāda, ka lietotājs var redzēt tikai kontus, kuriem viņam ir tiesības piekļūt. Paslēpta poga neīsteno tiesību pārbaudi. OWASP apraksta, kā trūkstošas konta vai ieraksta pārbaudes var atklāt cita lietotāja datus.

Maksājumu API gadījumā idempotence nozīmē, ka atkārtots pieprasījums neatkārto paredzēto iedarbību. Stripe dokumentē vienu īstenojumu. Pārbaudiet faktiskā pakalpojuma sniedzēja darbību, ierobežojumus un atkārtotu mēģinājumu noteikumus. Lietotnes atgriešana iepriekšējā versijā neatceļ bankas apstrādātu maksājumu.

Šis piemērs nav pierādījums Lovable defektam. Paša Lovable drošības norādes prasa aizsargāt slepenos datus, veikt servera puses pārbaudes, pārbaudīt datu politikas un turpināt pārskatīšanu. Piemērojiet tādu pašu pierādījumu standartu jebkuram veidotājam, aģentam vai manuāli rakstītai lietotnei.

Pārbaudiet piekļuvi pirms īstu sistēmu pieslēgšanas

Turpiniet pārbaudīt darbplūsmu ar sintētiskiem datiem un testa kontiem. Pirms īstas piekļuves lūdziet par pakalpojumu, drošību un platformu atbildīgajiem pārbaudīt lietotni un tās darbības vidi.

Izmantojiet bankas vai pakalpojuma sniedzēja apstiprināto savienošanas procesu. Piešķiriet tikai nepieciešamos kontus un tiesības. Glabājiet privātos piekļuves datus apstiprinātā slepeno datu glabātuvē, ārpus uzvednēm un pārlūka koda. Ja maksājumi ir vajadzīgi, nosakiet to apstiprinājumus un limitus. Pārbaudiet, kā atsaukt piekļuvi, izmeklēt kļūmes un reaģēt uz aizdomīgu darbību.

Šie lēmumi jāpieņem, pirms sistēmā nonāk konfidenciāla ievade vai īsti piekļuves dati. Gaidīt formālu laidienu produkcijas vidē var būt par vēlu. Turpiniet ar datu robežām un uzņēmuma infrastruktūru.

Nosakiet atbildību pirms lietojuma paplašināšanas

Eksperiments ar izdomātiem datiem var būt īslaicīgs un paredzēts nelielai auditorijai. Kad citi cilvēki ir atkarīgi no lietotnes, nosakiet pienākumus, kas saistīti ar tās izmantošanu.

1. Nosauciet atbildīgo.
2. Nosakiet atļautos lietotājus un datus.
3. Apziniet, kā reaģēt uz kļūmi.
4. Glabājiet pirmkodu un konfigurāciju repozitorijā.
5. Pārbaudiet, vai cits cilvēks var pārbaudīt un reproducēt sistēmu.

Ne katram skriptam vajag uzņēmuma platformu. Personiskam formatētājam bez sensitīviem datiem vajag mazāk kontroles pasākumu nekā maksājumu apstiprināšanas lietotnei. Novērtējiet kļūdas sekas. Pārbaudiet, vai kļūdu var atklāt un novērst tās ietekmi.

Pirms prototipa paplašināšanas atdaliet to, ko uzzinājāt par problēmu, no pierādījumiem par īstenojumu. Varat saglabāt saskarni un aizstāt iekšējo kodu. Varat ierobežot paredzēto lietojumu. Varat arī paturēt prototipu kā īslaicīgu eksperimentu.

Plānojiet ievainojamību novēršanu arī pēc demonstrācijas

Veiksmīga demonstrācija var slēpt nopietnu uzturēšanas trūkumu. Par atkarību var publicēt jaunu ievainojamības paziņojumu, lai gan jūsu kods nav mainījies. Skenēšana laidiena brīdī apraksta tikai vienu laika punktu.

Ja lietotne paliek lietošanā, kādam jāturpina atrast, izvērtēt un novērst ievainojamības. Labojumam jānonāk produkcijas vidē un jāiztur pārbaude. Skeneris bez šī reaģēšanas procesa atstāj apdraudējumu nenovērstu.

Pārbaudiet, ko nodrošina faktiskais rīks un konfigurācija. Vēlāk nepārtrauktas ievainojamību pārvaldības pamācība izskaidro visu procesu, tostarp skenēšanas kļūmes un izvietotās versijas.

Padariet nākamo izmaiņu viegli pārskatāmu

Uzdodiet aģentam vienu nelielu izmaiņu ar skaidriem pieņemšanas kritērijiem. Norādiet, kādas darbības aģents drīkst veikt. Pārskatiet iegūto diff. Veiciet pārbaudes, kas var noraidīt nepareizu īstenojumu. Saglabājiet izvietošanu kā atsevišķu lēmumu, līdz atbildība par laidienu ir skaidra.

NIST Secure Software Development Framework apraksta plašākas drošas izstrādes prakses. Izmantojiet to kā atsauci, vērtējot trūkstošos kontroles pasākumus. Ietvars nav jāiegaumē. Jāatrod trūkstošie pierādījumi, pirms programmatūra ietekmē citus cilvēkus.