Vibe coding: bruk og begrensninger

Gi folk rom til å bygge

En CTO i en større virksomhet kan hjelpe flere med å omsette kunnskapen sin til programvareideer. Inviter folk fra økonomi, drift, salg og utvikling. Gi dem tid, syntetiske data, sandkasse-API-er og støtte.

La folk bruke ulike verktøy til utforskning innenfor klare grenser for installasjon, kontoer og tillatte inndata. Et nettleserbasert byggeverktøy, en kodeassistent eller en lokal agent kan hjelpe dem med å teste en idé. Valg av verktøy gir ikke tillatelse til å laste opp bedriftsinformasjon eller koble til et system i drift.

Publiser en enkel fremgangsmåte for å ta en nyttig prototype videre til utviklings- eller plattformteamet. Skaperen bidrar med problemet, et eksempel på arbeidsflyten og den observerte verdien. Vedkommende trenger ikke bli tjenestens sikkerhets- og driftsteam.

Finn ut hva du trenger å lære

Vibe coding starter vanligvis med en beskrivelse av programvaren du ønsker. Du aksepterer generert kode og bruker det synlige resultatet til å styre neste endring. Begrepet har ulike betydninger. I denne veiledningen forstår personen som styrer arbeidet, ikke nødvendigvis hver implementeringsbeslutning.

Metoden kan hjelpe deg med å lære. Et enkelt grensesnitt kan vise at en godkjenningsprosess har for mange trinn. Et midlertidig skript kan hjelpe deg med å vurdere et filformat. En prototype gir folk et konkret design å diskutere. Du kan beholde kunnskapen når du forkaster koden.

Definer først et spørsmål med et observerbart svar. For eksempel: «Kan en teamleder forstå denne godkjenningsprosessen?» Spørsmålet har et klart omfang. En forespørsel om å bygge et utgiftssystem omfatter også databeskyttelse, tilgangskontroll, drift og eierskap.

Tirsdagens bankprototype

Se for deg et fiktivt eksempel. På tirsdag bruker en kollega i økonomiavdelingen Lovable til å bygge et dashbord med oppdiktede banktransaksjoner. Det grupperer utgifter og viser ubetalte fakturaer. Teamet kan nå diskutere en nyttig arbeidsflyt.

Noen foreslår å koble til selskapets bankkonto. Det endrer konsekvensene, selv om appen fortsatt kalles en «prototype».

Lesetilgang kan avsløre saldoer, transaksjonshistorikk, kundenavn eller betalingsreferanser, avhengig av API-et. Hvis tilkoblingen også tillater betalinger, kan feil flytte reelle penger. Bekreft det faktiske omfanget av tillatelsene; en banktilkobling gir ikke alltid betalingstilgang.

Demoen dokumenterer ikke at en bruker bare kan se kontoene vedkommende har tilgang til. En skjult knapp håndhever ikke en tillatelse. OWASP beskriver hvordan manglende konto- eller postkontroller kan eksponere en annen brukers data.

For betalings-API-er betyr idempotens at en gjentatt forespørsel ikke gjentar den tilsiktede effekten. Stripe dokumenterer én implementering. Kontroller den faktiske leverandørens atferd, begrensninger og regler for nye forsøk. En rollback av applikasjonen reverserer ikke en betaling banken har behandlet.

Eksemplet dokumenterer ikke en feil i Lovable. Lovables egen sikkerhetsveiledning krever beskyttede hemmeligheter, kontroller på serversiden, testede datapolicyer og løpende gjennomgang. Bruk samme dokumentasjonskrav for alle byggeverktøy, agenter og manuelt skrevne apper.

Kontroller tilgangen før du kobler til reelle systemer

Fortsett å teste arbeidsflyten med syntetiske data og sandkassekontoer. Før reell tilgang gis, skal de ansvarlige for tjeneste, sikkerhet og plattform verifisere applikasjonen og driftsmiljøet.

Bruk bankens eller leverandørens godkjente tilkoblingsprosess. Gi bare tilgang til nødvendige kontoer og tillatelser. Oppbevar private påloggingsopplysninger i godkjent lagring for hemmeligheter, utenfor prompter og nettleserkode. Fastsett betalingsgodkjenninger og grenser der betalinger er nødvendige. Verifiser hvordan tilgang tilbakekalles, feil undersøkes og mistenkelig aktivitet håndteres.

Beslutningene må tas før fortrolige inndata eller reelle påloggingsopplysninger kommer inn i systemet. Å vente på en formell produksjonsutgivelse kan være for sent. Fortsett med datagrenser og virksomhetens infrastruktur.

Definer ansvar før du øker bruken

Et eksperiment med oppdiktede data kan ha kort levetid og få brukere. Når andre blir avhengige av appen, må ansvaret for bruken defineres.

1. Navngi eieren.
2. Identifiser tillatte brukere og data.
3. Definer responsen på en feil.
4. Bevar kildekode og konfigurasjon i et repository.
5. Verifiser at en annen person kan undersøke og gjenskape systemet.

Ikke alle skript trenger en virksomhetsplattform. Et personlig formateringsverktøy uten sensitive data trenger færre kontroller enn en app for betalingsgodkjenning. Vurder konsekvensene av en feil. Kontroller om du kan oppdage feilen og reversere virkningene.

Før du utvider prototypen, skill det du lærte om problemet, fra dokumentasjonen om implementeringen. Du kan beholde grensesnittet og erstatte den interne koden. Du kan begrense den tilsiktede bruken. Du kan også beholde prototypen som et midlertidig eksperiment.

Planlegg for sårbarheter etter demoen

En vellykket demo kan skjule en alvorlig mangel i vedlikeholdet. En avhengighet kan få en ny sårbarhetsmelding uten at koden din endres. En skanning ved utgivelse beskriver ett tidspunkt.

Hvis appen forblir i bruk, må noen fortsette å finne, vurdere og rette sårbarheter. Rettelsen må nå produksjon og bestå verifisering. En skanner uten denne responsprosessen lar eksponeringen forbli uløst.

Kontroller hva det faktiske verktøyet og konfigurasjonen gir. Senere forklarer kontinuerlig sårbarhetshåndtering hele prosessen, inkludert skanningsfeil og utrullede versjoner.

Gjør neste endring enkel å gjennomgå

Gi agenten én liten endring med tydelige akseptkriterier. Angi hvilke handlinger agenten kan utføre. Undersøk den resulterende diffen. Gjennomfør kontroller som kan avvise en feil implementering. Behold utrulling som en egen beslutning til ansvaret for utgivelsen er avklart.

NIST Secure Software Development Framework beskriver bredere praksis for sikker utvikling. Bruk det som referanse når du vurderer manglende kontroller. Du trenger ikke lære rammeverket utenat. Du må identifisere manglende dokumentasjon før programvaren påvirker andre mennesker.