Det problem, vi ikke vidste vi havde

Forestil dig det her: To pull requests glider igennem alle tests alene. Begge ændringer ser skarpe ud. Reviewere nikker godt. Så merger du dem til main – og appen krasher på en måde, ingen enkelt ændring kan forklare.

Nu forestil det sker non-stop. Ikke fordi holdet er sløjt, men fordi en udviklers AI-agent har spyttet 12 overlappende branches ud, mens et menneske stadig skriver én funktion.

Det er agent-assisteret udvikling i praksis. Og det afslører huller i workflows, der har holdt i årtier.

Lokal perfektion betyder ikke system-sammenhæng

Koden kan være fejlfri isoleret – og totalt forkert i helheden.

Tag et eksempel med web-rendering:

• Branch A skifter message-layout til nyt målesystem. Hurtigere, renere, alle tests grønne.
• Branch B booster markdown-rendering ved at udvide det gamle system. Virker som en drøm alene.
• Branch C tilføjer tests til scrolling. Alt passer.

Hver branch står stærkt. Diffen ser legitim ud. Review fanger intet galt.

Men sammen på main? To målesystemer kører parallelt. Systemet er i krig med sig selv. Fejlen dukker kun op, når du kombinerer dem mod den rigtige base-branch.

Det handler ikke om kodekvalitet. Det handler om integration.

CI/CD er ikke klar til agent-hastighed

Klassiske pipelines – inklusive merge queues – er bygget til mennesker: Flere devs, delte branches, central test, reviews når arbejdet er "godt nok".

Der er en indbygget bremse. En dev skriver feature, pusher PR, venter. Integrationstrykket sker i teamet, fanget af CI.

Agenter ignorerer det.

En dev med agent kører 5, 10 eller 20 lokale worktrees samtidigt. Nogle stablet, nogle blindgyder, nogle på forældet kodebase. Billige at lave, lette at smide, hurtigere end reviews.

Integrationstrykket sker lokalt – før det rammer remote repo.

Når GitHub CI ser det, har du brugt timer på review, rebase og mental gymnastik. Merge queue hjælper ikke – det er for sent.

Rebase er plaster, ikke strategi

"Kan agenten ikke bare rebase konflikter væk?"

Jo. Det virker delvist.

Rebase matcher tekst. Git flytter linje 42 til 49 smukt. Men Git kan ikke spotte, om ændringerne stadig giver arkitektonisk mening.

Intent-konflikter er ikke tekstkonflikter.

En branch refaktoriserer auth til OAuth2. En anden udvider legacy session-auth til en lille feature. Ingen merge-konflikter. Tests passer. Men sammen? To auth-verdener i kaos.

Rebase går igennem. Tests grønne. Kode shippes ødelagt.

Du skal have proces – ikke bare værktøjer

Forskellen er klar:

En rebasing agent er et værktøj. En workflow, der styrer parallelle agent-ændringer, er en proces.

Merge queue gør mere end vente:

• Rækkefølge: Hvilke ændringer integreres først?
• Replay-check: Test kombineret resultat mod rigtig base.
• Arkitektur-validering: Tjek om merged state holder vand – ikke kun tekst.

Til agenter skal det ske tidligere: En lokal integrationskø, der:

1. Overvåger alle aktive agent-branches.
2. Spotter overlaps og afhængigheder.
3. Foreslår sikker rækkefølge.
4. Kører kombi-tests før upstream-push.
5. Fanger arkitektur-fejl, tests misser.

Den skjulte pris for hastighed

Ingen snakker om det: Supervision skalerer ikke med fart.

Ved menneskehastighed holder én reviewer trit. Review er flow-kontrol.

Agenter producerer kortere end review – men flaskehalsen er ikke langsommere mennesker. Det er manglende integrationsstyring. Fang konflikter før human review.

Her udforsker platforme som NameOcean's Vibe Hosting nye veje. Hosting bliver del af dev-workflow. Cloud-miljøet kan matche deploy-cadence og give tidlig feedback. Forestil hosting, der spotter arkitektur-problemer lokalt – før GitHub-push. Det er cross-stack-tænkning til agent-eraen.

Hvad det betyder for din workflow

Bruger du AI-agenter (eller planlægger)? Tjek din integrationsstrategi:

1. Kan du håndtere overlappende ændringer fra én dev? Merge queue til sekventielt menneske-arbejde er sårbar.
2. Verificerer du før eller efter merge? Agent-branches kræver kø-checks.
3. Tjekker du arkitektur eller kun tekst? Tests og linting rækker ikke. Valider systemdesign i kombi.
4. Blokerer reviews? Human bottleneck betyder, du har ikke løst agent-koordinering – bare skabt kø.

God nyhed: Det kan løses. Bremse ikke agenterne. Gør integration smartere.

Dårlig nyhed: Dine værktøjer er sandsynligvis ikke optimeret. Men det gør det til en fed udfordring. Hold, der knacker lokal integration, får velocity-fordel over 2010s-merge-queue-folk.

Fremtiden handler ikke om hurtigere devs eller smartere agenter. Det handler om workflows, der styrer agent-farten.