Vibe coding: användning och gränser

Ge människor utrymme att bygga

En CTO i ett företag kan hjälpa fler att omvandla sin kunskap till programvaruidéer. Bjud in människor från ekonomi, drift, försäljning och utveckling. Ge dem tid, syntetiska data, API:er i testmiljö och stöd.

Låt människor använda olika verktyg för utforskande inom tydliga gränser för installation, konton och tillåten indata. Ett webbaserat byggverktyg, en kodassistent eller en lokal agent kan hjälpa dem att testa en idé. Verktygsvalet ger inte tillstånd att ladda upp företagsinformation eller ansluta ett skarpt system.

Beskriv en enkel väg för att lämna en användbar prototyp till utvecklings- eller plattformsteamet. Skaparen bidrar med problemet, ett exempel på arbetsflödet och det observerade värdet. Personen behöver inte bli tjänstens säkerhets- och driftteam.

Bestäm vad du behöver lära dig

Vibe coding börjar vanligen med en beskrivning av programvaran du vill ha. Du accepterar genererad kod och använder det synliga resultatet för att styra nästa ändring. Begreppet har olika betydelser. I den här guiden förstår den som styr arbetet inte nödvändigtvis varje implementationsbeslut.

Metoden kan hjälpa dig att lära dig. Ett enkelt gränssnitt kan visa att en godkännandeprocess har för många steg. Ett tillfälligt skript kan hjälpa dig att bedöma ett filformat. En prototyp ger människor ett konkret förslag att diskutera. Du kan behålla kunskapen när du kastar koden.

Definiera först en fråga med ett observerbart svar. Till exempel: ”Kan en teamchef förstå den här godkännandeprocessen?” Frågan har ett tydligt omfång. En begäran om att bygga ett utgiftssystem omfattar även dataskydd, åtkomstkontroll, drift och ansvar.

Tisdagens bankprototyp

Tänk dig ett fiktivt exempel. På tisdagen använder en ekonomikollega Lovable för att bygga en dashboard med påhittade banktransaktioner. Den grupperar utgifter och visar obetalda fakturor. Teamet kan nu diskutera ett användbart arbetsflöde.

Någon föreslår att ansluta företagets bankkonto. Det förändrar konsekvenserna, även om appen fortfarande kallas ”prototyp”.

Läsåtkomst kan röja saldon, transaktionshistorik, kundnamn eller betalningsreferenser, beroende på API:t. Om anslutningen även tillåter betalningar kan fel flytta riktiga pengar. Bekräfta det faktiska behörighetsomfånget; en bankanslutning omfattar inte alltid betalningsåtkomst.

Demonstrationen visar inte att en användare endast kan se behöriga konton. En dold knapp upprätthåller ingen behörighet. OWASP beskriver hur saknade konto- eller postkontroller kan exponera en annan användares data.

För betalnings-API:er innebär idempotens att en upprepad förfrågan inte upprepar den avsedda effekten. Stripe dokumenterar en implementation. Kontrollera den faktiska leverantörens beteende, begränsningar och regler för nya försök. En återställning av appversionen återkallar inte en betalning som banken har behandlat.

Exemplet är inte belägg för ett fel i Lovable. Lovables egna säkerhetsråd kräver skyddade hemligheter, kontroller på serversidan, testade datapolicyer och löpande granskning. Ställ samma krav på underlag för alla byggverktyg, agenter och manuellt skrivna appar.

Kontrollera åtkomst innan du ansluter verkliga system

Fortsätt testa arbetsflödet med syntetiska data och testkonton. Låt tjänste-, säkerhets- och plattformsansvariga verifiera applikationen och driftmiljön före verklig åtkomst.

Använd bankens eller leverantörens godkända anslutningsflöde. Ge bara åtkomst till nödvändiga konton och behörigheter. Förvara privata autentiseringsuppgifter i godkänd hemlighetslagring, utanför promptar och webbläsarkod. Ange godkännanden och gränser när betalningar behövs. Verifiera hur åtkomst återkallas, fel undersöks och misstänkt aktivitet hanteras.

Besluten ska fattas innan konfidentiell indata eller verkliga autentiseringsuppgifter kommer in i systemet. Att vänta på en formell produktionsrelease kan vara för sent. Fortsätt med datagränser och företagets IT-infrastruktur.

Definiera ansvar innan användningen ökar

Ett experiment med påhittade data kan vara kortvarigt och ha få användare. När andra förlitar sig på appen behöver ni definiera ansvaret för användningen.

1. Utse en ansvarig.
2. Identifiera tillåtna användare och data.
3. Bestäm hur fel ska hanteras.
4. Förvara källkod och konfiguration i ett repository.
5. Verifiera att en annan person kan granska och återskapa systemet.

Alla skript behöver inte en företagsplattform. Ett personligt formateringsverktyg utan känsliga data behöver färre kontroller än en app för betalningsgodkännande. Bedöm konsekvenserna av ett fel. Kontrollera om du kan upptäcka felet och återställa dess effekter.

Innan du utökar prototypen ska du skilja lärdomarna om problemet från underlaget om implementationen. Du kan behålla gränssnittet och ersätta den interna koden. Du kan begränsa den avsedda användningen. Du kan också behålla prototypen som ett tillfälligt experiment.

Planera för sårbarheter efter demonstrationen

En lyckad demonstration kan dölja en allvarlig lucka i underhållet. Ett nytt sårbarhetsmeddelande kan gälla ett beroende utan någon ändring i din kod. En skanning vid release beskriver en tidpunkt.

Om appen fortsätter användas måste någon fortsätta hitta, bedöma och åtgärda sårbarheter. Rättningen måste nå produktion och verifieras. En skanner utan denna åtgärdsprocess lämnar exponeringen olöst.

Kontrollera vad ditt faktiska verktyg och dess konfiguration erbjuder. Senare beskriver kontinuerlig sårbarhetshantering hela processen, inklusive misslyckade skanningar och driftsatta versioner.

Gör nästa ändring lätt att granska

Ge agenten en liten ändring med uttryckliga acceptanskriterier. Ange vilka åtgärder agenten får utföra. Granska den resulterande diffen. Utför kontroller som kan underkänna en felaktig implementation. Behåll driftsättning som ett separat beslut tills releaseansvaret är tydligt.

NIST Secure Software Development Framework beskriver bredare arbetssätt för säker utveckling. Använd det som referens när du bedömer saknade kontroller. Du behöver inte memorera ramverket. Du behöver identifiera saknat underlag innan programvaran påverkar andra människor.