Vibe to Live: från AI-genererad kod till säker produktion

AI-genererad kod kan köras säkert i produktion när den passerar en granskningskedja: automatisk scanning, en SBOM över beroenden, spårbarhet på varje ändring och mänskligt godkännande av det med hög påverkan.

Det är det “Vibe to Live” betyder. Vibe är hastigheten: att låta en AI-modell bygga något ur en beskrivning på naturligt språk, ofta på timmar. Live är vad produktionen och lagen kräver: granskning, dokumentation och kontroll. Bryggan mellan de två är inte att förbjuda AI-koden, och inte att lita på den. Det är att lägga in kontrollerna som gör att kod ingen läst rad för rad ändå går att stå för.

Den här guiden förklarar vad vibe coding är, varför AI-kod i produktion blivit en styrningsfråga 2026, hur granskningskedjan ser ut, och var den passar respektive inte passar.

Varför det spelar roll

AI skriver nu nästan hälften av all företagskod. Det är inte en prognos utan ett uppmätt läge. En undersökning från Salt Security i maj 2026 byggde på 100 IT-säkerhetsledare i Storbritannien och USA. Den fann att 67 procent säger att AI-kodassistenter är brett antagna. 9 av 10 säkerhetsledare är samtidigt oroade över riskerna i den koden (Salt Security, AI Coding Assistants and the New Security Challenge, 2026-06-02). Frågan har flyttat. Den är inte längre om AI kan skriva kod, utan hur man släpper igenom kod ingen människa fullt ut läst, till produktion, lagligt.

Själva begreppet har redan hunnit bli passé. Vibe coding myntades i februari 2025 av Andrej Karpathy. Ett år senare kallade han det föråldrat och förde fram mer disciplinerad agentic engineering i stället. Hypen gick alltså över. Men praktiken blev kvar: koden genereras fortfarande av AI, i allt större andel, och den ska fortfarande någonstans. Den intressanta historien 2026 är inte att låta modellen bygga. Det är vad som händer mellan bygget och produktionen.

Risken är mätt, inte anekdotisk. Opseras benchmark från januari 2026, byggd på data från 250 000 utvecklare över fler än 60 organisationer, visar att AI-genererad kod inför 15–18 procent fler säkerhetssårbarheter än kod skriven enbart av människor (Opsera, AI Coding Impact 2026 Benchmark Report, 2026-01-29). En oberoende studie från AppSec Santa testade 534 kodsnuttar över sex stora språkmodeller mot OWASP Top 10 och fann att 25,1 procent, ungefär var fjärde snutt, innehöll en bekräftad säkerhetssårbarhet (AppSec Santa, AI Code Security Study: 6 LLMs vs OWASP Top 10, 2026). Och problemet når redan produktion: enligt Aikido Security har 69 procent av organisationerna upptäckt sårbarheter som AI-genererad kod infört i deras egna system, och 1 av 5 rapporterar en allvarlig incident som följd (Aikido Security, State of AI in Security & Development 2026).

Samtidigt biter lagstiftningen. Cybersäkerhetslagen, det svenska genomförandet av NIS2, gäller sedan 15 januari 2026 och kräver systematisk riskhantering och tydligt ledningsansvar (MSB, Det här är cybersäkerhetslagen / NIS2-direktivet, hämtad 2026-06-04). Cyber Resilience Act inför rapporteringsskyldigheter från 11 september 2026 och kräver SBOM samt security-by-design över hela livscykeln (Europeiska kommissionen, Cyber Resilience Act, hämtad 2026-06-04). EU AI Act aktiverar sin huvudregim för högrisk och transparenskraven i artikel 50 den 2 augusti 2026 (Europeiska kommissionen, Regulatory framework on AI, hämtad 2026-06-04). En organisation som låter AI bygga i produktion utan spårbarhet rör sig därmed mot konkreta lagkrav, inte mot en framtida möjlighet.

Hur det fungerar

Vibe to Live är en granskningskedja mellan prototypen och produktionen. Den lägger kontrollerna i pipelinen i stället för att hoppas att en utvecklare läser allt. Fem led bär den.

1. Spårbarhet på ursprunget. Varje ändring kopplas till vem eller vad som genererade den, vilken prompt och vilken modell. Det är grunden för att kunna granska i efterhand och för att uppfylla dokumentationskraven i CRA och cybersäkerhetslagen.
2. Automatisk scanning. SAST (statisk analys av koden) och DAST (dynamisk analys av det körande systemet) söker kända sårbarhetsmönster innan koden byggs. Det fångar den repetitiva delen som ingen människa hinner läsa sig igenom.
3. SBOM över beroenden. En programvarustycklista (SBOM) listar varje bibliotek och version som ingår, så att kända CVE:er kan matchas automatiskt. CRA kräver en SBOM i maskinläsbart format i den tekniska dokumentationen.
4. Mänsklig granskning där det räknas. En människa godkänner kod som påverkar känsliga flöden, höga behörigheter eller persondata. Inte varje rad, utan det med hög påverkan.
5. Loggning och kontinuerlig övervakning. Vad som hämtas, byggs och körs loggas, så att en incident kan rekonstrueras inom de frister CRA sätter: 24 timmars tidig varning, 72 timmars full notifiering, 14 dygns slutrapport.

Den viktiga insikten är var den mänskliga insatsen ska ligga. När AI genererar hälften av koden blir manuell radgranskning både ogörlig och fel prioriterad. ProjectDiscoverys rapport från april 2026 byggde på 200 säkerhetspraktiker i Nordamerika och Västeuropa. Alla tillfrågade rapporterar ökad leverans. Men säkerhetsteamen lägger nu mer tid på att validera fynd än på att åtgärda sårbarheter (ProjectDiscovery, 2026 AI Coding Impact Report, 2026-04-22). Automatisera det repetitiva. Spara människan för det som spelar roll.

OWASP är tydligt på en punkt som ofta missförstås: en språkmodell kan inte själv vara en säkerhetsgräns. I OWASP Top 10 for LLM Applications 2025 slås fast att systemprompter inte är säkerhetskontroller, eftersom modellen är stokastisk och inte går att granska som en deterministisk gräns (OWASP GenAI Security Project, OWASP Top 10 for LLM Applications 2025). Säkerheten ligger i pipelinen runt modellen, inte i modellen.

Varje led i kedjan svarar mot ett konkret krav. Spårbarheten och loggningen är vad cybersäkerhetslagens dokumentation och CRA:s rapporteringsfrister förutsätter. SBOM:en är ett uttryckligt krav i CRA:s tekniska dokumentation, i maskinläsbart format. Den mänskliga grinden är vad EU AI Act kallar mänsklig tillsyn för system som faller inom högrisk. Vanlig kodassistans hamnar normalt utanför AI Act:s högriskkategori, men telemetri till chefs- och produktivitetsdashboards kan dra in en del användning i regelverket. Poängen är inte att memorera paragrafer. Den är att bygga kedjan en gång och låta den uppfylla flera regelverk samtidigt.

När det passar

Vibe to Live passar när hastigheten i AI-genererad utveckling ska behållas men koden ska nå en miljö med riktiga krav.

• Prototyp som ska bli produkt. När en idé byggd snabbt med AI visat sig bära och nu ska driftas på riktiga användare och riktig data.
• Reglerad eller säkerhetskänslig verksamhet. När CRA, NIS2 eller EU AI Act gäller och spårbarhet, SBOM och riskhantering är krav, inte önskemål.
• Hög leveranstakt med litet säkerhetsteam. När utvecklingen accelererat med AI och granskningen måste skalas med automatik i stället för fler manuella ögon.
• Data som ska stanna i Sverige eller EU. När känslig information inte får lämna er miljö och ni behöver kontroll över både kod och var den körs.

När det inte passar

Granskningskedjan är inte gratis, och den är inte alltid rätt avvägning.

• Engångsprototyp som aldrig ska driftas. Ska koden bara visa en idé internt och sedan kastas, tillför en full pipeline mest friktion. Bygg snabbt, men släpp den aldrig till produktion.
• När teamet saknar förmåga att granska det scannern flaggar. Verktygen hittar fynd, men någon måste kunna bedöma dem. Utan den kompetensen blir scanningen en lista ingen agerar på. Då är första steget att bygga förmågan, inte pipelinen.
• När kraven på latens eller kostnad är extrema. Varje granskningssteg kostar tid i bygget. För system där varje sekund i pipelinen är kritisk måste avvägningen göras medvetet, inte slentrianmässigt.
• När ni saknar mandat att stoppa en leverans. En grind som aldrig får säga nej är ingen grind. Om en deadline alltid trumfar granskningen ger kedjan falsk trygghet. Då är problemet styrning, inte teknik.

Skillnaden mellan vibe coding och Vibe to Live är alltså inte hastighet mot långsamhet. Det är prototyp mot produktion: vad ni vill kunna stå för när koden möter riktiga användare och riktiga lagkrav.

Konkret exempel

En svensk verksamhet låter sitt team bygga en intern handläggartjänst med AI-assisterad utveckling. På några dagar finns en fungerande prototyp. Den läser data, svarar handläggare och sparar tid. Frågan blir: kan den gå i produktion?

Med en vibe-coding-prototyp rakt till live skulle organisationen släppa kod ingen läst, mot persondata, i en verksamhet som omfattas av cybersäkerhetslagen sedan 15 januari 2026. En sårbarhet i ett AI-genererat beroende skulle kunna nå produktion oupptäckt. Statistiken säger att risken är reell: var fjärde AI-genererad kodsnutt kan bära en sårbarhet.

Med Vibe to Live passerar samma kod kedjan. Varje ändring kopplas till sin prompt och modell. SAST och DAST scannar bygget. En SBOM listar alla beroenden och matchar dem mot kända CVE:er. En människa granskar det som rör persondata och behörigheter, och godkänner. Loggningen gör att en framtida incident kan rapporteras inom CRA:s frister. Prototypen behåller sin hastighet, men det som når produktion är granskat, dokumenterat och spårbart.

Den här typen av leverans bygger vi under ett certifierat AI-ledningssystem (ISO 42001-certifierad, av DNV Business Assurance) och på infrastruktur i Sverige eller EU. Det är så hastighet och kontroll kan samexistera: er AI, er data, er frihet.

Effekten av kedjan är att sårbarheter fångas i pipelinen, före produktion, i stället för att upptäckas i drift, och att ledtiden från prototyp till granskad produktion blir spårbar i stället för att hoppas på. Resultatet är kod som går att stå för: scannad, dokumenterad och godkänd där det räknas.

Vanliga missförstånd

“AI-genererad kod är osäker och hör inte hemma i produktion.” Det stämmer inte. AI-kod inför mätbart fler sårbarheter, 15–18 procent enligt Opsera, men den körs säkert när den granskas, scannas och spåras. Förbudet är inte svaret. Kontrollkedjan är.

“Vibe to Live betyder att en människa läser all kod.” Det är varken möjligt eller mest effektivt. Manuell radgranskning skalar inte när AI skriver hälften av koden. ProjectDiscovery visar att säkerhetsteam redan lägger mer tid på att validera fynd än på att åtgärda dem. Människan granskar det med hög påverkan. Resten fångar automatiken.

“En tillräckligt bra AI-modell granskar sin egen kod.” En språkmodell kan inte vara sin egen säkerhetsgräns. OWASP slår fast att modellen är stokastisk och inte går att granska som en deterministisk kontroll. Granskningen måste ligga i pipelinen runt modellen, inte i modellen själv.

Vibe coding gjorde det snabbt att bygga. Vibe to Live gör det möjligt att stå för det ni byggt.