Fjorten måneder. Så længe er det siden, jeg startede med vibe coding. Og landskabet er fuldstændig forandret.
Sidste gang jeg var på Verbos—det var i august—var samtalen "hvad er det her egentlig?" Nu, i februar 2026, er feltet eksploderet. Spørgsmålet er skiftet: "Hvordan gør vi det sammen?"
Det er fjerde gang, jeg sidder i showet, og man kan føle forskel. Industrien er gået fra skepsis til adoption—en messier, mere kompleks adoption. Og den kompleksitet er hvor det rigtige arbejde begynder.
🎙️ Podcast Edition
Det her er et bonuspost (post 10) i Kapitel 9: "Build Over Buy." Fire røster, en time og elleve minutter, der diskuterer hvor team-baseret vibe coding egentlig skal hen.
2026-02-06 · 1:10:59
Fem Centrale Indsigter
1. Autonome Agenter Har Brug for Klare Begrænsninger (3:00–9:30)
OpenClaw erobrede internettet ved at gøre ting, som AI-assistenter ikke gjorde før—køre autonomt på maskiner, træffe beslutninger, operere uden konstant tilsyn. Appealen er ægte. Problemet også: en agent med tokens og internetadgang kan gøre skade hvis den ikke er ordentligt sandboxet.
Pointen er ikke at være bange for agenterne. Det er at forstå hvad "sikker autonom" egentlig betyder. Vi bevæger os hurtigt; sikkerhedsrevisioner viser at vi bevæger os for hurtigt.
2. Team Vibe Coding Kræver Forskellige Workflows (40:50–50:40)
Mega pull requesten er symptom. Det rigtige problem er at vi stadig behandler code review som et efterfølgende filter i stedet for en upfront samarbejdsform.
Forestil dig det her: Dit team sidder omkring et Kanban board. Agenter popper op og beder om hjælp. I stedet for at individuelle bidragydere tager opgaven, samler to, tre personer sig, diskuterer requirements med agenten i realtid, og bliver enige om retning før agenten producerer kode. Tests, quality gates, og digitale tvillinger validerer output. PR'en bliver en formalitet, ikke en flaskehals.
Det er den retning vi går.
3. Pull Requests Som Vi Kender dem Kan Være Forbi (48:00–53:20)
Vi reviewet ikke længere baseret på kodestørrelse. Vi reviewet baseret på adfærd. Blev knappen samme farve? Brød vi en API-kontrakt? Virker integrationen stadig?
Metriken er ikke linjer ændret—det er om tests passes og systemet opfører sig som forventet. PR-beskrivelsen skal være kort: hvad var opgaven, hvilken proces førte til designet, hvilke tests bekræfter at det virker.
4. Frontend Bevæger Sig Hurtigere End Backend—Og Det Er et Problem (42:50–47:50)
Frontend-udviklere er tættest på brugerne. De hører feedback, validerer idéer, itererer hurtigt. Backend-udviklere befinder sig længere nede i stakken og har brug for mere sikkerhed før ændringer går live.
Vibe coding forstærker denne asymmetri. Du kan generere hundrede UI-variationer. Du kan ikke generere stabile APIs lige så let. Løsningen er ikke at sætte farten ned i frontend—det er at bygge bedre interfaces (APIs, kontrakter, emulatorer) så agenter kan operere sikkert i begge lag.
5. Junior-Udviklere Er Ikke Erstattet—De Lærer Anderledes (58:30–1:04:50)
Den almindelige visdom siger at juniors er dømt. Virkeligheden er anderledes. Juniors i dag er mere komfortable med at spørge Claude eller ChatGPT end senior-ingeniører er. De lærer workflow i stedet for syntax.
Hvad skiftede for mig: Jeg holdt op med at bede juniors gravede sig ned i teknikken. Jeg startede på at bede dem forstå hvad kunder faktisk har brug for. Agenten håndterer koden. Seniors håndterer validering. Juniors håndterer requirement-oversættelse. Alle vinder.
Hvor Dette Forbinder
- Build Over Buy — Bøjningspunktet hvor du stopper med at forhandle med værktøjer og starter med at bygge dine egne.
- 10x Developers, 1000x Leverage — Hvorfor multiplikatorer betyder mere end heroisme når teams skaleres.
- Less Reading, More Building — Hvordan læringsvejen skifter når iteration er gratis.
Det her afsnit føles som en milepæl. Ikke fordi alt er løst. Fordi samtalen er modnet. Vi er forbi "er det her virkeligt?" Nu spørger vi "hvordan gør vi det ansvarligt, sammen, på stor skala?"
Det er hvor de interessante problemer ligger.
Poul