Vibe‑kodning i skala: risker, skuld, komplexitet, övermod

Vad “vibe‑kodning” betyder när du skalar

“Vibe‑kodning” är intuition‑först, tempo‑först‑kodning: du följer momentum, fattar snabba beslut och fortsätter leverera utan att stanna upp för att formalisera varje krav, kantfall eller designval. Det bygger ofta på en mix av personlig erfarenhet, copy‑paste‑mönster, lättviktig testning och en optimism i stil med “vi städar upp senare”.

Den här approachen kan vara genuint användbar när du utforskar idéer, validerar en prototyp eller försöker hitta produkt‑marknadspassning. Nyckeln är att koden ses som ett medel för snabb inlärning — inte som ett långsiktigt kontrakt.

Varför det förändras när teamet och kodbasen växer

I liten skala håller samma person (eller ett litet team) mest kontext i huvudet. När något går sönder är det oftast uppenbart var man ska titta. När du skalar blir kontexten distribuerad: nya utvecklare ansluter, system multipliceras och kodens “oskrivna regler” slutar vara delad kunskap.

Då slutar vibe‑kodning vara bara en personlig stil och blir ett organisatoriskt beteende. Kostnaden för odokumenterade beslut stiger, snabba fixes blir beroenden och genvägar kopieras eftersom de verkar fungera.

De tre riskerna vi återkommer till

När kodbasen växer dyker tre felmoder upp upprepade gånger:

• Teknisk skuld som tyst växer: små hacks härdar till permanent struktur.
• Dold komplexitet och överraskande beroenden: förändringar på ett ställe bryter något annat på sätt ingen förutspådde.
• Övermod som ett team‑beteende: att leverera snabbt börjar kännas som bevis på att systemet är sunt.

Detta är inte emot hastighet. Målet är att behålla momentumets fördelar samtidigt som man lägger in skydd så produkten kan skala utan att varje release blir ett spel på tur.

Varför det känns snabbt (och varför det kan vilseleda)

Vibe‑kodning känns snabbt eftersom den optimerar för flow: du fattar beslut snabbt, minimerar ceremoni och följer intuition i stället för checklistor. Det kan skapa verkligt momentum — särskilt när du börjar från noll och varje commit synligt förändrar produkten.

Kortfristiga vinster är verkliga

När målet är att lära, inte perfektion, kan vibe‑kodning vara en superkraft. Du levererar grova prototyper, utforskar idéer och håller kreativiteten hög. Team får ofta:

• Snabba prototyper som billigt validerar (eller dödar) en idé
• Snabb användarfeedback eftersom det finns något att prova
• En känsla av framsteg som håller alla engagerade

Den hastigheten är verkligen användbar när osäkerheten är hög och kostnaden för att ha fel måste hållas låg.

Tidiga framgångar kan dölja svaga grunder

Den missvisande delen är att tidig mjukvara är förlåtande. Med en liten kodbas, en utvecklare och låg trafik visar många problem sig inte än. Saknade tester biter inte ännu. Otydliga namn är fortfarande “i ditt huvud”. En genvägs‑konfiguration fungerar eftersom inget annat beror på den.

Men de där grunderna gjuts medan du rör dig snabbt. Senare, när du lägger till funktioner, onboardar nya kollegor eller integrerar tredjepartstjänster, blir samma genvägar friktion — och det “snabba” tillvägagångssättet ger långsammare resultat.

Fällan “det fungerade en gång”

Ett vanligt mönster är: något fungerar en gång, så teamet antar att det fortsätter fungera. Så blir engångslösningar copy‑pasteade mönster, och smarta hacks blir tyst “så gör vi”. Hastighet blir en vana, och vanan blir kultur.

Där det verkligen passar

Vibe‑kodning glänser för spikes, prototyper och kortlivade experiment — platser där lärande betyder mer än underhållbarhet. Felet är att låta ett experiment bli produkten utan en medveten övergång till ingenjörspraxis som stödjer skalning.

Risk #1: Teknisk skuld som tyst växer

Teknisk skuld är kostnaden “vi fixar senare” som du tar när du väljer den snabbaste vägen över den tydligaste, säkraste. I vibe‑kodning ser det ofta ut som att leverera en funktion med minimala tester, oklara namn eller en snabb patch som funkar för den nuvarande demon men inte är byggd för nästa tre anrop.

Hur skuld ser ut i riktig kod

Några konkreta exempel:

• Genvägar i logik: duplicera samma validering på tre ställen istället för att centralisera den
• Saknade tester: inga automatiska kontroller för kantfall, felhantering eller behörigheter
• Otydlig kod: “magiska” variabler, vaga funktionsnamn och kommentarer som “TODO: cleanup” som aldrig tas om hand
• Hårdkodade regler: priströsklar, feature‑flaggor eller regionsregler inbakade direkt i koden
• Röriga datamodeller: fält tillagda ad hoc (“temp2”, “status_v3”), inkonsekventa enum eller blandade betydelser i en kolumn

Varför små genvägar multipliceras

En enstaka genväg kan vara okej för en person i en fil. I skala sprider den sig: flera team kopierar mönster som verkar fungera, tjänster integrerar med antaganden som aldrig dokumenterats, och samma “snabbfix” implementeras på lite olika sätt. Resultatet är inte en stor krasch — det är tusen små mismatchar.

Kostnadskurvan: det blir dyrt snabbt

Skuld förändrar arbetets form. Enkla ändringar tar längre tid eftersom ingenjörer måste reda ut sidoeffekter, lägga till tester i efterhand och återskapa odokumenterade beslut. Buggar blir vanligare och svårare att reproducera. Onboarding bromsas eftersom nya kollegor inte kan skilja det avsiktliga från det oavsiktliga.

Skuld är osynlig — tills den inte är det

Teknisk skuld gömmer sig ofta i “fungerande” system. Den syns när du försöker göra en stor förändring: en redesign, ett krav på efterlevnad, en prestandalyft eller en ny integration. Då kräver de tysta genvägar betalning, vanligtvis med ränta.

Risk #2: Dold komplexitet och överraskande beroenden

Vibe‑kodning tenderar att optimera för “det fungerar på min maskin”-farten. I liten skala kommer du ofta undan med det. I skala gömmer sig komplexitet i mellanrummen mellan moduler: integrationer, kantfall och den verkliga vägen data tar genom systemet.

Var komplexiteten faktiskt bor

De flesta överraskningar kommer inte från funktionen du ändrade — de kommer från vad den funktionen rör vid.

Integrationer lägger till osynliga regler: API‑quirks, retries, rate limits, partiella fel och “lyckade” svar som ändå betyder “något gick fel”. Kantfall samlas i produktionsdata: saknade fält, oväntade format, händelser i fel ordning eller gamla poster skapade innan en valideringsregel fanns.

Dataflöden är den ultimata komplexitetsmultiplikatorn. En liten ändring i hur du skriver ett fält kan bryta ett downstream‑jobb, en analytics‑dashboard eller en billing‑export som förutsätter den gamla innebörden.

Okända beroenden (det som ingen minns)

Dold koppling visar sig som:

• Moduler som delar en databas‑tabell (eller bara en kolumn) utan tydligt kontrakt
• Delade konfigar och feature‑flaggor återanvända för orelaterat beteende
• “Utility”‑bibliotek som tyst blir en sopkorg använd överallt

När dessa beroenden inte är explicita kan du inte resonera om påverkan — bara upptäcka den i efterhand.

Produktgappet (vad det verkar göra vs vad det gör)

En ändring kan se korrekt ut i ett lokalt test men bete sig annorlunda under verklig samtidighet, retries, caching eller multi‑tenant‑data.

AI‑stött kod kan bidra: genererade abstraktioner som döljer sidoeffekter, inkonsekventa mönster som komplicerar framtida redigeringar eller något olika felhanteringsstilar som skapar konstiga felmoder.

En enkel berättelse

En utvecklare byter “bara” namn på ett statusvärde för att bli tydligare. UI:t fungerar fortfarande. Men en webhook‑konsument filtrerar på det gamla statuset, en nattlig sync hoppar över poster och finansrapporter tappar intäkter en dag. Inget “kraschar” — det fungerar bara tyst felaktigt, överallt.

Risk #3: Övermod blir ett team‑beteende

Övermod i vibe‑kodning är inte bara “vara självsäker”. Det är att lita på intuition framför bevis i takt med att insatserna ökar — att skicka eftersom det känns rätt, inte eftersom det verifierats.

Tidiga vinster gör detta frestande. En snabb prototyp fungerar, kunder reagerar, mätetal stiger och teamet lär sig en farlig läxa: granskningar, tester och designtänk är “valfritt”. När du rör dig snabbt börjar allt som bromsar se ut som byråkrati — även när det är det enda som hindrar en framtida brand.

Hur tidiga framgångar blir till hoppad disciplin

Vibe‑kodning börjar ofta med verkligt momentum: färre möten, färre docs, snabbare commits. Problemet är vanan det formar:

• Pull‑requests blir stämplar (“ser bra ut, skicka”)
• Tester skjuts upp (“vi lägger till täckning senare”)
• Arkitekturval sker i någons huvud, inte i delad kontext

Det fungerar med en person och en liten kodbas. Det spricker när flera personer behöver ändra samma system säkert.

“Hjälte‑kodning” skalar inte

Övermod ger ofta hjältemönster: en person som levererar stora ändringar sent på kvällen, räddar releaser och blir den inofficiella ägaren av allt. Det känns produktivt — tills den personen är på semester, slutar eller helt enkelt bränner ut sig.

Beslutsrisk: tidslinjer blir optimistiska, migrationer ignoreras

När självförtroendet ökar blir uppskattningar kortare och risker diskonteras. Migrationer, refaktorer och dataskiften behandlas som enkla omskrivningar snarare än koordinerade projekt. Då gör team löften om lanseringsdatum som antar att allt går smidigt.

Hur det sprider sig kulturellt

Om snabbhet belönas mer än lärande kopierar teamet beteendet. Folk slutar be om bevis, slutar dela osäkerhet och slutar lyfta orosmoment. En sund ingenjörsprocess handlar inte om att röra sig långsamt — utan om att skapa bevis innan produkten tvingar fram dem.

Kvalitet och tillförlitlighet driver bort när kodbasen växer

Vibe‑kodning kan kännas som ständig framåtrörelse — tills kodbasen når en storlek där små ändringar får oväntade följder. Då faller inte kvalitet ihop på en gång. Den driver. Tillförlitlighet blir “mestadels okej”, sedan “ibland konstigt” och till sist “vi vågar inte deploya på fredagar”.

Typiska felmoder du börjar se

När ytan växer är de vanligaste felen inte dramatiska — de är högljudda:

• Regressioner: en fix i ett område bryter tyst ett annat flöde.
• Flaky beteende: samma åtgärd fungerar ibland, ibland inte (ofta pga timing, caching, race‑conditions eller inkonsekventa dataantaganden).
• Inkonsekvent UX: liknande skärmar beter sig olika för att mönster inte standardiserats (valideringsregler, felstater, loading‑indikatorer, tomma tillstånd).

Varför manuell testning slutar funka

Manuell testning skalar dåligt med releasefrekvens. När du släpper oftare finns mindre tid för noggrann kontroll, och “testa allt snabbt” blir sampling. Det skapar blindzoner, särskilt i kantfall och tvärfunktionella interaktioner. Med tiden börjar team lita på användarrapporter som detektering — vilket är dyrt, långsamt och skadar förtroendet.

Kvalitetssignaler som degraderas (och hur det syns)

Kvalitetsdrift är mätbar även om den känns subjektiv:

• Bugbacklog växer snabbare än den krymper
• Upprepade incidenter med liknande rotorsaker
• Hotfix‑kultur: frekventa “små nöduppdateringar” efter releaser
• Högre supportvolym för “det brukade funka”-ärenden

Vad “klart” bör betyda i skala

I skala kan “klart” inte betyda “det fungerar på min maskin”. En rimlig definition inkluderar:

• Automatiska tester för kritiska vägar (och fixes inkluderar regressions‑tester)
• Grundläggande dokumentation för icke‑uppenbart beteende och beslut
• Observabilitet: loggar/metriker kring nyckelåtgärder och felpunkter

Hastighet utan kvalitet blir långsammare senare — för varje ny ändring kostar det mer att verifiera, debugga och förklara.

Säkerhet, integritet och compliance‑risker

Hastighet är en fördel — tills den hoppar över de “tråkiga” stegen som förhindrar intrång. Vibe‑kodning optimerar ofta för synlig framsteg (nya skärmar, endpoints, snabba integrationer) vilket kan kringgå hotmodellering, grundläggande säkerhetsgranskning och till och med enkla frågor som: vad kan gå fel om denna input är illvillig eller detta konto äventyras?

Vanliga luckor som syns senare

Några återkommande mönster när team rör sig snabbt utan skydd:

• Hemligheter i koden: API‑nycklar, databaspwd och tokens committade till repo, inklistrade i ärenden eller inbakade i frontend‑kod.
• Saknad inputvalidering: endpoints som accepterar okontrollerade IDs, filuppladdningar eller “free‑form” JSON som senare blir injektions‑ eller exponeringväg.
• Otrygga behörigheter: tjänster som körs med vida molnroller, delade adminkonton eller “temporär” åtkomst som blir permanent.

Dessa luckor kan ligga tysta tills kodbasen är så stor att ingen minns varför en genväg fanns.

Integritets‑ och compliance‑risk: risken multipliceras med användardata

När du sparar användardata — e‑post, betalmetadata, plats, hälsouppgifter eller beteendeanalys — är du ansvarig för hur det samlas, lagras och delas. Snabb iteration kan leda till:

• att samla in mer data än nödvändigt (svårare att motivera och skydda),
• oklara retention‑policys (“vi rensar senare”),
• oavsiktlig exponering via loggar, exporter eller för brett scope:ade interna dashboards.

Om ni omfattas av GDPR/CCPA, SOC 2, HIPAA eller branschkrav är “vi visste inte” ingen försvar.

Supply‑chain‑risk från snabba dependency‑lägg

Att lägga till bibliotek snabbt — särskilt auth, crypto, analytics eller build‑verktyg — kan introducera sårbarheter, oönskad telemetri eller inkompatibla licenser. Utan granskning kan en enda dependency vidga attackytan dramatiskt.

Säkra standarder som bevarar momentum

Använd automation och lättviktiga grindar istället för att hoppas folk ska komma ihåg:

• Automatisk scanning: secret scanning, dependency/vuln‑scanning och SAST i CI.
• Least‑privilege som standard för molnroller, servicekonton och produktionsdata.
• Granskningsgrindar för känsliga områden (auth, betalningar, PII, behörigheter, kryptering) med en kort checklista och obligatoriska granskare.

Görs väl bevarar dessa skydd hastigheten samtidigt som de förhindrar irreversibel säkerhetsskuld.

Drift: när produktion blir verklighetskontrollen

Vibe‑kodning “fungerar” ofta där den skapades: en utvecklares laptop med cachade creds, seedad data och en förlåtande runtime. Produktion tar bort de kuddarna. “Det fungerar på min maskin” blir dyrt när varje mismatch blir misslyckade deploys, partiella outage eller kundsynliga buggar som inte går att reproducera snabbt.

Det saknade lagret: observabilitet

När snabbhet prioriteras framför struktur hoppar team ofta över rören som förklarar vad systemet gör.

Dåliga loggar betyder att du inte kan svara på “vad hände?” efter ett fel.

Inga metriker betyder att du inte ser prestanda försämras gradvis förrän en gräns överskrids.

Inga traces betyder att du inte ser var tiden spenderas över tjänster, köer eller tredjeparts‑API:er.

Svag felrapportering betyder att undantag samlas i mörkret och verkliga incidenter blir gissningsarbete.

Operativ skuld visar sig som bräcklig leverans

Operativ skuld är gapet mellan “appen körs” och “appen kan driftas säkert.” Det ser ofta ut som sköra deployer, miljöspecifika fixes, oklara rollback‑steg och dolda manuella åtgärder (“kör det här skriptet efter deploy”, “starta om den workern om den stannar”). Runbooks finns inte eller är inaktuella och ägs av “den som senast rörde det”.

Symptom du märker först

Vanliga tecken på att produktion blir din flaskhals:

• Incidenthantering tar längre tid eftersom ingen ser rotorsaken
• Ägarskap är oklart: larm går men inget team känner ansvar
• Larm är högljudda eller meningslösa, så folk börjar ignorera dem
• Deploys kräver tribal knowledge och “rör inte på fredagar”-regler

Små vanor som förhindrar kaos

Börja tidigt med lättviktiga drift‑rutiner: en enkelsidig runbook per service, några dashboards kopplade till användarpåverkan, automatisk felrapportering och korta postmortems som ger en eller två konkreta åtgärder. Det är inte “extra process” — det är hur du behåller hastighet utan att göra produktion till ditt obetalda QA‑team.

Team‑ och processbrott vid skala

Vibe‑kodning kan kännas kollaborativt tidigt eftersom alla “bara levererar”. Men när teamet växer blir kodbasen det delade gränssnittet mellan människor — och inkonsekvens blir friktion.

Stildrift saktar ned samarbetet

När varje feature följer olika mönster (mappstruktur, namngivning, felhantering, state‑management, API‑anrop) spenderar ingenjörer mer tid på att översätta än att bygga. Granskningar blir debatter om smak snarare än korrekthet, och små ändringar tar längre tid eftersom ingen är säker vilket mönster som är “rätt” här.

Resultatet är inte bara långsammare leverans — det är ojämn kvalitet. Vissa delar är vältestade och läsbara, andra är bräckliga. Team börjar dirigera arbete till “den som kan den delen”, vilket skapar flaskhalsar.

Onboarding blir gissningslek

Nya ingenjörer behöver förutsägbarhet: var affärslogiken bor, hur data flyter, hur man lägger till en endpoint, var validering placeras och vilka tester som ska skrivas. I en vibe‑kodad kodbas varierar de svaren per feature.

Det ökar onboardingkostnaderna på två sätt:

• Nyanställda behöver mer tid från seniora utvecklare.
• De gör “rimliga” ändringar på fel ställe, vilket skapar regressioner eller duplikatlogik.

Koordinationskostnader syns som dubbletter och konflikter

När flera jobbar parallellt skapar inkonsekventa antaganden omarbete:

• Två utvecklare bygger liknande utilities för att ingen hittar den befintliga
• Features krockar eftersom en modul tyst beror på en annan moduls sidoeffekter
• Merge‑konflikter ökar eftersom delade filer blir dumpningsplatser

Så småningom saktar teamet ner inte för att kodning är svår, utan för att koordinering är svår.

Besluts‑skuld ersätter arkitektur

När du hoppar över explicita val — gränser, ägarskap, API‑kontrakt, “så gör vi X” — ackumulerar du besluts‑skuld. Varje framtida förändring öppnar gamla frågor igen. Utan tydliga sömmar vågar ingen refaktorisera och allt blir sammankopplat.

Enkla alignments‑verktyg som bevarar hastighet

Du behöver ingen tung byråkrati. Några lättviktiga “alignments‑primitiv” gör stor nytta:

• Konventioner: namngivning, mappstruktur, felhantering, logging
• Delade mallar: service/modul‑scaffolds, testsetup, PR‑checklistor
• Golden paths: en rekommenderad väg för vanligt arbete (t.ex. lägga till en API‑route, skapa ett bakgrundsjobb, introducera en ny UI‑sida)

De här verktygen minskar koordinationskostnader och gör kodbasen mer förutsägbar — så teamet kan fortsätta röra sig snabbt utan att snubbla över sig självt.

Varningssignaler: mätetal och lukter att vakta

Vibe‑kodning kan se fint ut — tills dagen den inte gör det. Tricket är att fånga skiftet från “tillfälligt stök vi städar upp” till “systematisk skuld som sprider sig.” Håll koll på både siffror och teamets beteende.

Mätbara indikatorer (siffrorna ljuger inte)

Få mätvärden rör sig först:

• Cykeltid ökar: små ändringar tar längre tid vecka för vecka, även när scope är liknande.
• Felrate ökar: fler buggar per release, fler kundrapporter eller fler hotfixes.
• Rollbackar ökar: releaser revertas oftare, eller deploys pausas för att det “känns riskabelt”.
• Incidentfrekvens/severitet växer: fler sidor, längre återställningstid, upprepade incidenter.

Kvalitativa lukter (vad folk börjar säga)

Dessa är ofta tidigare signaler än dashboards:

• “Rör inte den filen — den bryter allt.”
• “Endast Alex förstår den här delen.”
• Features släpps och skrivs om var några veckor för att den senaste versionen är svår att bygga vidare på.
• PR:er blir enorma eftersom team undviker att integrera ofta.

Tillfälligt stök vs systematisk skuld

Tillfälligt stök är avsiktligt och tidsboxat (t.ex. ett snabbt experiment med ett tydligt cleanup‑ticket och ägare). Systematisk skuld är standardbeteende: genvägar saknar plan, sprids över moduler och gör framtida ändringar långsammare.

Lätta sätt att granska verkligheten

• Skapa en enkel beroendekarta (även en diagram) för att upptäcka överraskande kopplingar.
• Följ testtäckningstrender över tid (riktning är viktigare än absoluta siffror).
• Kör snabba incidentreviews för att identifiera upprepade orsaker, inte bara engångsfixar.

Gör risk synlig

Använd ett “skuldregister” och månatliga tech‑health checks: en kort lista över största skulderna, deras påverkan, en ägare och ett mål‑datum. Synlighet förvandlar vag oro till hanterligt arbete.

Praktiska skydd som bevarar hastighet utan kaos

Snabb kodning kan förbli snabb om du definierar vad “säker hastighet” innebär. Målet är inte att bromsa folk — utan att göra den snabba vägen till den förutsägbara vägen.

Definiera ett “safe speed”‑arbetsflöde

Håll förändringar små och ägda. Föredra PR:er som gör en sak, har en tydlig granskare och kan rullas tillbaka enkelt.

En enkel regel: om en ändring inte kan förklaras i några få meningar bör den delas upp.

Lägg lättviktiga grindar före merges

Skydd fungerar bäst när de är automatiska och konsekventa:

• Kodgranskningsnormer: kräva minst en granskare utanför författaren och gör “vad kan gå sönder?” till en standardfråga.
• CI‑grindar: builds måste passera, tester körs och fel blockerar merges.
• Linting/formattering: tvinga stil med verktyg så människor inte slösar tid på tabs vs spaces.
• Dependency‑policy: dokumentera hur nya bibliotek godkänns, hur versioner uppgraderas och vem som äger kritiska beroenden.

Testlager (på platt svenska)

Tänk i lager så du inte försöker testa allt på samma sätt:

• Enhetstester: kontrollerar små logikbitar snabbt.
• Integrationstester: ser till att komponenter fungerar ihop (DB, köer, externa tjänster).
• End‑to‑end‑tester: simulera en verklig användarväg; håll dessa få och högt värderade.
• Kontrakts‑tester: validera handskakningen mellan tjänster eller API‑konsumenter så ändringar inte överraskar andra.

Dokumentation som skalar

Skriv mindre, men skriv rätt saker:

• ADR (arkitekturbeslutsdokument): korta noteringar om vad ni beslutade och varför.
• Mini design‑anteckningar: en sida innan större jobb för att samordna omfattning och risker.
• Runbooks: steg‑för‑steg‑guider för vanliga produktionsproblem och deploy/rollback‑procedurer.

Var AI‑verktyg passar (och var inte)

Använd AI‑assistenter för utkast: första versionen av kod, testscaffolding, refaktoringsförslag och dokumentationsutkast. Men behåll mänskligt ansvar: granskare äger mergningen, team äger beroendeval och ingen bör acceptera genererad kod de inte kan förklara.

Ett praktiskt sätt att behålla “prototyp‑fart” men minska drift‑risk är att standardisera överlämningen från chat‑byggda prototyper till underhållna system. Om du till exempel använder en vibe‑kodningsplattform som Koder.ai för att skapa webappar (React), backends (Go + PostgreSQL) eller mobilappar (Flutter) från en chattgränssnitt, behandla output som vilket annat ingenjörsartefakt som helst: exportera källan, kör den genom era vanliga CI‑grindar och kräva tester + granskning innan den når bred användning. Funktioner som snapshots/rollback och planning mode kan hjälpa dig röra dig snabbt samtidigt som ändringar blir auditerbara och reversibla.

När vibe‑kodning är okej (och när den inte är det)

Vibe‑kodning kan vara ett smart val när du vill lära snabbt, validera en idé eller få loss ett team. Den blir ett dåligt spel när snabbhet tyst ersätter tydlighet och koden behandlas som “tillräckligt bra” för långsiktig användning.

Besluts‑kriterier (snabb verklighetscheck)

Använd vibe‑kodning när de flesta av dessa är sanna:

• Risknivå: låg (ett misstag är irriterande, inte katastrofalt)
• Användarpåverkan: begränsad blast radius (en liten kohort, interna användare eller feature‑flagged)
• Datasensitivitet: ingen reglerad eller mycket känslig data
• Tids‑horisont: du kan ersätta det snart, eller du har planerat tid för att hårdlanda

Undvik det när du rör betalningar, auth, behörigheter, kärnflöden eller något du skulle skämmas att förklara under en incidentreview.

Tänk i “zoner”

• Experimentzonen: prototyper, engångsskript, demos. Vibe‑kodning passar.
• Kärnsystemzonen: intäktsvägar, kunddata, delade bibliotek. Vibe‑kodning endast för spikes — sedan refaktor.
• Reglerad zon: vård, finans, produkter med tung integritet eller revisionskrav. Kör inte vibe‑kodning i produktion här.

Ett enkelt playbook: snabbt först, sedan hårdna

1. Prototypa snabbt bakom en flagga eller i en sandbox.
2. Nämn det som prototyp (ticket‑label, README‑notering, utgångsdatum).
3. Hårdlanda innan bred adoption: lägg till tester, förenkla beroenden, dokumentera beteende och få en granskning.
4. Gradera eller ta bort: gör det underhållsbart — eller radera det.

Checklista du kan använda nästa vecka

• Finns en tydlig ägare och ett utgångsdatum för den här koden?
• Är den feature‑flagged eller säkert avgränsad?
• Finns grundläggande tester för den kritiska vägen?
• Är beroenden minimala och avsiktliga?
• Hanterar den fel och kantfall förutsägbart?

Välj ett skydd att införa först: “Ingen prototyp når 20% av användarna utan tester + granskning.” Enas om det i teamet och du behåller hastigheten utan att ärva kaos.