Vibe coding: muligheder og grænser

Giv mennesker plads til at bygge

En CTO i en større virksomhed kan hjælpe flere medarbejdere med at omsætte deres viden til softwareidéer. Invitér mennesker fra økonomi, drift, salg og udvikling. Giv dem tid, syntetiske data, sandbox-API’er og støtte.

Lad medarbejderne afprøve forskellige værktøjer inden for klare rammer for installation, konti og tilladte input. Et værktøj i browseren, en kodeassistent eller en lokal agent kan hjælpe dem med at teste en idé. Valget af værktøj giver ikke tilladelse til at uploade virksomhedsoplysninger eller tilslutte et system i drift.

Beskriv en enkel vej fra en nyttig prototype til udviklings- eller platformteamet. Ophavspersonen bidrager med problemet, et eksempel på arbejdsgangen og den observerede værdi. Personen behøver ikke selv at blive tjenestens sikkerheds- og driftsteam.

Afklar, hvad du skal lære

Vibe coding begynder typisk med en beskrivelse af den software, du ønsker. Du accepterer genereret kode og bruger det synlige resultat til at styre den næste ændring. Begrebet har forskellige betydninger. I denne vejledning forstår den person, der styrer arbejdet, ikke nødvendigvis hver beslutning om implementeringen.

Metoden kan hjælpe dig med at lære. En enkel brugergrænseflade kan vise, at en godkendelsesproces har for mange trin. Et midlertidigt script kan hjælpe dig med at vurdere et filformat. En prototype giver mennesker et konkret design at diskutere. Du kan beholde denne viden, selv om du kasserer koden.

Definér først et spørgsmål med et svar, du kan observere. For eksempel: »Kan en teamleder forstå denne godkendelsesproces?« Spørgsmålet har en klar afgrænsning. En opgave om at bygge et udgiftssystem omfatter også databeskyttelse, adgangskontrol, drift og ejerskab.

Tirsdagens bankprototype

Forestil dig et fiktivt eksempel. Tirsdag bruger en kollega fra økonomiafdelingen Lovable til at bygge et dashboard med opdigtede banktransaktioner. Det grupperer udgifter og viser ubetalte fakturaer. Teamet kan nu diskutere en nyttig arbejdsgang.

Nogen foreslår at tilslutte virksomhedens bankkonto. Det ændrer konsekvenserne, selv om appen stadig kaldes en »prototype«.

Afhængigt af API’et kan læseadgang afsløre saldi, transaktionshistorik, kundenavne eller betalingsreferencer. Hvis forbindelsen også tillader betalinger, kan fejl flytte rigtige penge. Kontrollér rettighedernes faktiske omfang. En bankforbindelse omfatter ikke altid adgang til betalinger.

Demoen dokumenterer ikke, at en bruger kun kan se de konti, vedkommende har adgang til. En skjult knap håndhæver ikke en rettighed. OWASP beskriver, hvordan manglende kontrol af konti eller poster kan eksponere en anden brugers data.

For betalings-API’er betyder idempotens, at en gentaget anmodning ikke gentager den tilsigtede virkning. Stripe dokumenterer én implementering. Kontrollér den konkrete udbyders adfærd, begrænsninger og regler for gentagne forsøg. En rollback af applikationen tilbagefører ikke en betaling, som banken har behandlet.

Eksemplet dokumenterer ikke en fejl i Lovable. Lovables egen sikkerhedsvejledning kræver beskyttede secrets, kontrol på serversiden, testede datapolitikker og løbende gennemgang. Brug samme krav til dokumentation for alle byggeværktøjer, agenter og manuelt skrevne apps.

Kontrollér adgang, før du tilslutter rigtige systemer

Fortsæt med at teste arbejdsgangen med syntetiske data og sandbox-konti. Før du giver adgang til rigtige systemer, skal de ansvarlige for tjenesten, sikkerheden og platformen kontrollere applikationen og dens driftsmiljø.

Brug bankens eller udbyderens godkendte tilslutningsproces. Giv kun adgang til de nødvendige konti og rettigheder. Opbevar private adgangsoplysninger i et godkendt system til secrets, uden for prompts og browserkode. Fastlæg godkendelser og beløbsgrænser, hvor betalinger er nødvendige. Kontrollér, hvordan adgang tilbagekaldes, fejl undersøges, og mistænkelig aktivitet håndteres.

Disse beslutninger skal træffes, før fortrolige input eller rigtige adgangsoplysninger kommer ind i systemet. Det kan være for sent at vente på en formel produktionsrelease. Fortsæt med datagrænser og virksomhedens IT-infrastruktur.

Fastlæg ansvaret, før brugen vokser

Et eksperiment med opdigtede data kan være kortvarigt og have få brugere. Når andre bliver afhængige af appen, skal ansvaret for brugen være klart.

1. Udpeg den ansvarlige.
2. Beskriv de tilladte brugere og data.
3. Fastlæg, hvad der skal ske ved en fejl.
4. Opbevar kildekode og konfiguration i et repository.
5. Kontrollér, at en anden person kan undersøge og genskabe systemet.

Ikke alle scripts kræver en enterprise-platform. Et personligt formateringsværktøj uden følsomme data kræver færre kontroller end en app til betalingsgodkendelse. Vurdér konsekvenserne af en fejl. Undersøg, om du kan opdage fejlen og tilbageføre dens virkninger.

Før du udvider prototypen, skal du skelne mellem det, du lærte om problemet, og dokumentationen for implementeringen. Du kan beholde brugergrænsefladen og udskifte den interne kode. Du kan begrænse den tilsigtede brug. Du kan også beholde prototypen som et midlertidigt eksperiment.

Planlæg håndtering af sårbarheder efter demoen

En vellykket demo kan skjule en alvorlig mangel i vedligeholdelsen. Der kan komme en ny sikkerhedsadvarsel om en afhængighed, uden at din kode er ændret. En scanning ved release beskriver ét tidspunkt.

Hvis appen fortsat bruges, skal nogen løbende finde, vurdere og rette sårbarheder. Rettelsen skal nå frem til produktion og blive verificeret. En scanner uden denne proces efterlader eksponeringen uløst.

Kontrollér, hvad dit konkrete værktøj og din konfiguration tilbyder. Senere forklarer løbende håndtering af sårbarheder hele processen, herunder fejlslagne scanninger og udrullede versioner.

Gør den næste ændring let at gennemgå

Giv agenten én lille ændring med tydelige acceptkriterier. Angiv, hvilke handlinger agenten må udføre. Gennemgå den resulterende diff. Udfør kontroller, der kan afvise en forkert implementering. Behandl udrulning som en særskilt beslutning, indtil ansvaret for releasen er klart.

NIST Secure Software Development Framework beskriver bredere praksis for sikker udvikling. Brug det som reference, når du vurderer manglende kontroller. Du behøver ikke lære rammeværket udenad. Du skal finde den manglende dokumentation, før softwaren påvirker andre mennesker.