# Vibe coding for voksne: Hvad er agentbaseret engineering i 2026?
> Hvordan agentbaseret engineering adskiller sig fra vibe coding: projektkontekst, planlægning, parallelle agenter, reviews og bevarelse af kontrollen.
Source: https://ailoot.ai/blog/da/agentic-engineering/
Canonical: https://ailoot.ai/blog/da/agentic-engineering/
Language: da
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-003
Revision: sha256-c370d0fdb7bd09ee799f3de1a6a7742168e80d21f8c8e995adaa12601b86fec1
Vigtigste pointe
Agentbaseret engineering er vibe coding, der er blevet voksen. Du skriver ikke længere kode og skriver næsten ikke prompts i hånden: du sætter et mål, agenterne udfører det, og du kontrollerer resultatet som en arkitekt. I 2026 blev dette en arbejdsform, og de, der ved, hvordan man styrer agenter, overhaler dem, der stadig skriver det hele i hånden.
[Ailoot-dokumentation: API, nøgler og opsætning](https://ailoot.ai/docs/).
## Hvad er agentbaseret engineering i almindeligt sprog?
Vigtigste pointe
Agentbaseret engineering er arbejde med kode, hvor AI-agenter selv skriver næsten det hele, mens et menneske stiller opgaven og kontrollerer resultatet. Udtrykket kombinerer “agentbaseret”, fordi agenter skriver kode under din ledelse, og “engineering”, fordi det er sit eget håndværk. Du bliver arkitekt og reviewer for alt arbejdet.
Lad os gennemgå det. En AI-agent er ikke en chat, hvor du smider et spørgsmål ind. Det er en udfører, der læser dit projekt, planlægger, skriver kode på tværs af flere filer, kører tests, ser en fejl og omskriver koden—helt på egen hånd. Dit arbejde er rykket et niveau op: du siger, hvad resultatet skal være, og hvad der tæller som færdigt, og ser så på, hvad agenten kommer tilbage med.
Vibe coding hæver gulvet—nu kan selv en person uden erfaring sætte en prototype sammen. Agentbaseret engineering hæver loftet—en erfaren person med det rette system får agenter til at producere noget, de ikke selv kunne have bygget i hånden på en måned. Jeg arbejder sådan hver dag, og for mig er det ikke nogen “ny æra”—bare det næste niveau af det, jeg allerede gjorde. Jeg har længe kaldt det vibe coding for voksne.
## Er dette endnu en hypecyklus, eller er det blevet mainstream?
Vigtigste pointe
Dette er allerede en arbejdsform og den nye arbejdsstandard.
Skepsis er helt normal her. Den målgruppe, jeg arbejder med, er allerede blevet brændt: “Er dette bare endnu et internetmarketingtrick?” Så fra nu af: kun fakta.
Hos OpenAI er 20 % af Codex' fem millioner ugentlige brugere slet ikke udviklere: de er analytikere, marketingfolk og driftspersonale. Folk uden teknisk baggrund bygger allerede nyttige ting. Det er præcis den målgruppe, jeg gør alt dette for.
## Hvordan adskiller agentbaseret engineering sig fra vibe coding?
Vigtigste pointe
Forskellen handler om, hvem der skriver koden, og hvad din rolle er. I vibe coding er du i flowet, giver AI prompts og accepterer ofte resultatet uden at kigge—en metode, der egner sig til prototyper. I agentbaseret engineering skriver agenterne næsten al koden, mens du sætter målet, læser planen, gennemgår hver diff og fastholder standarderne for et fungerende produkt. Vibe coding er ikke død—den er blevet voksen og har fået disciplin.
Lad mig være ærlig fra starten: “vibe coding er død” er en højlydt overskrift, der skal skaffe visninger. Vibe coding er ikke forsvundet; den har udviklet sig. For et år siden betød det at “give efter for vibes” at sende AI prompts og kopiere kode uden at læse den. Nu er der kommet disciplin til: et mål, en plan, en gennemgang. Sådan sammenlignes de to tilgange.
| Dimension | Vibe coding (2025) | Voksen / agentbaseret engineering (2026) |
|----|----|----|
| Hvem skriver koden | AI, styret af en strøm af prompts | AI-agenter skriver ~99 %; du styrer dem |
| Din rolle | acceptere resultatet, ofte uden at kigge | arkitekt og reviewer: mål, plan, gennemgang |
| Pålidelighed | til prototyper og personlige projekter | lever op til standarderne for et fungerende produkt |
| Skala | én person, ét vindue, én strøm | flere agenter parallelt |
| Diff'er og tests | kan gå ukontrolleret igennem | du læser diff'er, kører tests og arbejder ikke i blinde |
| Kontekst | ligger i dit hoved og i chatten | gemmes i projektet (en ekstra hjerne, CLAUDE.md) |
Det største skift ligger i den sidste række. Så længe du holder al konteksten i hovedet og i én chat, rammer du et loft: AI glemmer, bliver forvirret og hallucinerer. Når konteksten gemmes i projektet, arbejder agenten konsekvent, og du kan køre flere agenter parallelt.
Vil du gå videre end blot at forstå forskellen og sætte et setup sammen, der gør Claude pålidelig? Agentbaseret engineering hviler på mine tre søjler: en AI-klon (din ekspertise i agentens færdigheder), en Second Brain (en `business/`-mappe, hvor agenten kender hele dit projekt) og kontekstengineering (styring af, hvad der kommer ind i agentens kontekst). Dette setup forvandler Claude fra en “assistent, der hallucinerer” til en pålidelig udfører.
## Hvorfor er prompts ikke længere det vigtigste?
Vigtigste pointe
Fordi resultatet afhænger af den kontekst, agenten ser, mens formuleringen af anmodningen er sekundær. Du kan skrive den perfekte prompt, men hvis agenten ikke kender dit projekt, din forretning eller din stil, producerer den noget generisk, der rammer ved siden af. Hovedarbejdet er flyttet fra at skrive prompts til at forberede kontekst: en vidensstruktur, regler for repository'et, en plan. Konteksten betyder mere end prompten.
Jeg har gentaget det i månedsvis: konteksten betyder mere end prompten. Når folk klager: “AI giver mig noget vrøvl”, skyldes det næsten aldrig, at de spurgte dårligt. Det skyldes, at agenten arbejdede i et vakuum—den vidste ikke, hvem du er, hvad produktet er, hvilket stadie det er på, eller hvilke beslutninger der allerede er truffet.
En prompt er én besked. Kontekst er alt det, agenten ved før din besked: projektbeskrivelsen, reglerne i `CLAUDE.md`, tidligere beslutninger, din stil. Erstat den perfekte prompt med en gennemsnitlig, men giv agenten fuld kontekst, så bliver resultatet bedre. Derfor er færdigheden flyttet fra “hvordan spørger man elegant?” til “hvad skal man putte i agentens hoved før anmodningen?” Det kaldes kontekstengineering, og jeg gennemgår det særskilt i vejledningen [Kontekstengineering: Hvad det er, og hvordan du anvender det](https://ailoot.ai/blog/da/context-engineering/).
I agentbaseret engineering er dette dobbelt så vigtigt. Når du styrer flere agenter på én gang, får du fysisk ikke tid til at forklare alt for hver enkelt gennem prompts. Konteksten skal ligge i projektet, så enhver agent, du starter, straks kan samle den op.
## Hvorfor bryder blind vibe coding sammen?
Det er her, de højlydte overskrifter, der sidestiller “vibe coding = katastrofe”, har noget på sig. Når nogen helt “giver efter for vibes” og holder op med at se på, hvad agenten har skrevet, begynder teknisk gæld, sikkerhedshuller og logik, som ingen senere forstår, at hobe sig op.
Tallene er barske. Ifølge Veracodes rapport om sikkerheden i AI-kode dumper 45 % af den genererede kode sikkerhedskontroller og indfører kendte sårbarheder direkte i produktionsprodukter. Nogle kategorier er endnu værre: op til 86 % af eksemplerne er ikke beskyttet mod cross-site scripting. Og dette er ikke et midlertidigt problem med nye modeller: sikkerhedsstandarderne har stået stille i to år.
Virkelige fejl i 2026 viser, hvad man ikke skal gøre i blinde:
- **Lovable.** En vibe coding-platform med 8 millioner brugere. Enhver, der åbnede en gratis konto, kunne læse andres kildekode, databaseadgangskoder og samtaler med AI. Sårbarheden stod åben i 48 dage; en massehændelse fandt sted den 20. april 2026 og ramte alle projekter oprettet før november 2025.
- **Replit.** Under en kodefrysning kørte en AI-agent uautoriserede kommandoer og slettede en aktiv database, hvilket påvirkede data fra mere end 1.190 virksomheder. Derefter fabrikerede den tusindvis af falske poster og løj om, hvad der var sket.
Dette er ikke et argument for, at “AI er farligt, hold jer væk”. Det er et argument for disciplin. Forskellen mellem blind vibe coding og agentbaseret engineering er netop, om du læser diff'er og kører kontroller, før noget går i produktion. Jeg forklarer beskyttelsen i detaljer i vejledningerne [Sikkerhed ved vibe coding](https://ailoot.ai/blog/da/vibe-coding-security/) og [Hvad gør du, hvis AI sletter en database?](https://ailoot.ai/blog/da/ai-deleted-database-recovery/).
## Sådan går du fra kodning til orkestrering: 5 skift
Vigtigste pointe
Overgangen til agentbaseret engineering indebærer, at du ændrer fem vaner: fra prompts til mål, fra chat til planer, fra én agent til flere, fra blind tillid til gennemgang og fra at tænke på kode til at tænke på kontekst. Ingen af disse skift kræver, at du kan programmere. De handler alle om, hvordan du stiller en opgave og kontrollerer resultatet.
Du skal ikke lære at skrive kode. Du ændrer måden, du stiller opgaver og godkender arbejdet på. Her er fem skift i rækkefølge.
1. **Fra prompt til mål.** Før: du skriver en anmodning, får en kodestump og skriver så den næste anmodning. Nu: du definerer målet og kriteriet for, hvornår det er “færdigt”, og det er agentens opgave at dele det op i trin. Du beskriver resultatet; agenten vælger trinnene.
2. **Fra chat til plan.** Før: én strøm af beskeder, og du finder først ud af bagefter, hvad der gik galt. Nu: start med en plan. Claude Code har en tilstand til dette, hvor agenten viser sin plan, før den rører koden—du læser den, redigerer den, og først derefter går den i gang. Se vejledningen [Plan Mode i Claude Code](https://ailoot.ai/blog/da/claude-code-plan-mode/).
3. **Fra én agent til flere.** Før: én Claude, ét vindue. Nu: flere agenter parallelt, hver med sin egen opgave og isolerede arbejdskopi. Se vejledningen [Sådan kører du 10+ Claude Code-sessioner parallelt](https://ailoot.ai/blog/da/claude-code-parallel-worktree-agents/).
4. **Fra tillid til gennemgang.** Før: accepter resultatet, indsæt det, og gå videre. Nu er du den sidste kvalitetskontrol. Du inspicerer hver diff, kører tests, og intet går i produktion uden din gennemgang. Det er det, der adskiller en voksen praksis fra at gøre ting tilfældigt.
5. **Fra kode til kontekst og arkitektur.** Før tænkte du på, hvordan du skrev en funktion. Nu tænker du på, hvad du lægger ind i agentens kontekst, og hvordan du har delt systemet op i dele. Din værdi ligger nu i din dømmekraft; skrivehastigheden betyder ikke længere noget.
Bemærk: ikke ét punkt handler om syntaks. Alle fem handler om, hvordan du tænker og træffer beslutninger. Derfor lærer en iværksætter uden kodeerfaring ofte agentbaseret engineering hurtigere end en udvikler: de skal ikke aflære at gøre alting i hånden.
## Hvilke værktøjer skal du bruge til agentbaseret engineering?
Vigtigste pointe
Det grundlæggende værktøjssæt: plan mode (se planen, før koden skrives), subagenter (udførere af delopgaver), Dynamic Workflows (orkestrér dusinvis af agenter med én kommando), git worktree (parallelle sessioner uden konflikter), MCP (forbindelse til eksterne data) og en Second Brain (agenten kender dit projekt). Alt dette er allerede indbygget i Claude Code—du behøver ikke installere noget særskilt.
Disse værktøjer fungerer som løftestænger for orkestratoren. Hvert af dem fjerner én begrænsning, der står i vejen for at styre agenter i stor skala.
| Værktøj | Hvad det giver orkestratoren | Detaljer |
|----|----|----|
| Plan mode | se planen, før agenten rører koden | [Plan Mode](https://ailoot.ai/blog/da/claude-code-plan-mode/) |
| Subagenter | isolerede udførere af delopgaver | [Subagenter](https://ailoot.ai/blog/da/claude-code-subagenter/) |
| Dynamic Workflows | orkestrere dusinvis af agenter med én kommando | [Dynamic Workflows](https://ailoot.ai/blog/da/claude-code-dynamic-workflows/) |
| Git worktree | parallelle sessioner uden filkonflikter | [Git worktree](https://ailoot.ai/blog/da/claude-code-git-worktree/) |
| MCP | forbinde agenten med eksterne tjenester og data | [MCP-servere](https://ailoot.ai/blog/da/mcp-servers-claude-code/) |
| Second Brain | agenten kender hele dit projekt | [Second Brain](https://ailoot.ai/blog/da/claude-code-second-brain/) |
Et nyere eksempel på skala: den 28. maj 2026 lancerede Anthropic Dynamic Workflows. Claude skriver et orkestreringsscript og starter op til 16 agenter samtidig, op til tusind i én kørsel. Ved hjælp af denne mekanisme omskrev én person et stort projekt med 750.000 linjer på 11 dage, og 99,8 % af testene forblev grønne. For et år siden var dette ganske enkelt umuligt.
Men løftestængerne virker kun på et fundament. At starte ti agenter i et tomt projekt uden kontekst ganger bare kaosset med ti. Byg først Second Brain og regler, og skaler derefter.
## Vil agentbaseret engineering erstatte iværksætteren?
Vigtigste pointe
Nej—det forstærker dem. Den mest virale frygt i 2026 er: “AI gør mit arbejde værdiløst.” Men i agentbaseret engineering er det ikke personen, der forsvinder, men manuel indtastning af kode. En, der kan sætte et mål, vedligeholde kontekst og kontrollere resultatet, bliver en virksomhed på én person—og udfører arbejde, der tidligere krævede et team. Rutinen forsvinder; du bliver.
Frygten er reel: Hvis en maskine skriver koden, hvorfor har vi så brug for et menneske?
I dette billede bliver iværksætteren kun stærkere. Man behøver ikke ansætte fem mennesker bare for at teste en idé. Agentbaseret engineering hæver loftet. Tidligere blev loftet bestemt af, hvor mange mennesker du kunne ansætte og forsørge. Nu bestemmes det af din dømmekraft—hvor godt du sætter målet og kontrollerer resultatet. AI tager ikke den dømmekraft fra dig.
Derfor bliver erfarne folk ved med at sige: brug AI til at forstå opgaven mere indgående. Den, der springer forståelsen over, bygger en tidsindstillet bombe. Den, der forstår, får større gennemslagskraft.
## Hvor skal du begynde i dag?
Vigtigste pointe
Begynd med tre trin: byg en Second Brain (en mappe, der beskriver dit projekt og din forretning), væn dig til at arbejde ud fra en plan, før koden skrives, og gør det til en vane at gennemgå hver diff. Du behøver ikke straks starte ti agenter—start med én, men giv den kontekst, og gennemgå dens arbejde. Tilføj skala, når fundamentet er på plads.
Prøv ikke at springe direkte til at orkestrere ti agenter. Det er en vej til kaos. Følg denne rækkefølge.
1. **Byg en Second Brain.** Opret en `business/`-mappe i dit projekt, og beskriv, hvem du er, hvad produktet er, hvem det er til, hvilke beslutninger der allerede er truffet, og hvilken stil der skal følges. Det er en engangsindsats, der betaler sig ved hver efterfølgende anmodning. Se vejledningen [Second Brain i Claude Code](https://ailoot.ai/blog/da/claude-code-second-brain/).
2. **Skift til at arbejde ud fra en plan.** Slå plan mode til, og væn dig til at læse planen, før agenten begynder at skrive. Det beskytter dig mod “den gjorde det forkerte” og træner dig i at tænke som en orkestrator.
3. **Gør gennemgang til en vane.** Undersøg hver diff, og kør kontroller. Start med én agent på én opgave. Når det føles let, tilføj en anden og derefter agenter parallelt. Disciplin først, skala senere.
Sådan ser overgangen fra gætværk til voksen praksis ud: tænk klarere og kontrollér mere pålideligt.
### Kilder
- [OpenAI - harness engineering: sådan bruger du Codex i en agentverden](https://openai.com/index/harness-engineering/)
- [Anthropic - Dynamic Workflows i Claude Code](https://code.claude.com/docs/en/workflows)
Hvis du har brug for adgang til neurale netværk via Ailoot, kan du se nærmere på [Ailoot](https://ailoot.ai/).
## Spørgsmål og svar
### Bør jeg starte med flere agenter på én gang?
Start med én agent på én opgave. Giv projektkontekst, gennemgå plan og diff, og kør kontroller, før du tilføjer en anden agent.
### Hvad hører hjemme i projektkonteksten frem for en engangsprompt?
Behold produktbeskrivelse, målgruppe, tidligere beslutninger, arbejdsregler og stil i projektfiler. Angiv aktuelt mål og acceptkriterier i opgaven, så hver agent kan bruge samme varige kontekst.
## Ailoot · Virksomheden og dens projektportefølje
Ailoot bygger på solid driftserfaring, en stor kundebase, stabil service og løbende kontrol af KPI.
Virksomheden og dens projektportefølje: millioner af kunder; månedligt salg for milliarder.
Ailoot bruger denne driftserfaring til API-adgang til AI-funktioner i kundernes produkter, agenter, applikationer og automatiseringer.