Default-on agentic coding er en ændring af jeres release pipeline – ikke en feature toggle

Der er en særlig type risiko, der først dukker op, når noget bliver standard. Ikke fordi capability’en er ny, men fordi organisationen holder op med at lægge mærke til den.

Det er derfor “agentic coding” bliver mest kritisk i det øjeblik, det stopper med at være et værktøj, du vælger – og bliver en mode, du arver. Når et system kan planlægge arbejde, skrive kode, køre tests og tage handlinger med mindre menneskelig oversight, har du ikke bare øget udviklingshastigheden. Du har ændret, hvordan software ender i production.

Og ændringer i release pipeline har en pris. Betaler du den ikke på forhånd, betaler du den under incidents.

Det konkrete trigger her er, at Anthropic gør Claude Code’s auto mode default-on. “Snart kræver endnu mindre menneskelig oversight” lyder som en produktivitetsnyhed. I praksis er det en governance-nyhed.

Default-on agentic coding er ikke “mere autocomplete”. Det er en ny aktør i jeres delivery-system. Behandl det, som du ville behandle en ny CI runner, en ny deploy-controller eller en ny måde at køre database migrations på. Ellers har du kun flyttet incidents til venstre – og skaleret dem.

Den skjulte ændring: I delegerer autoritet, ikke opgaver

De fleste teams tænker agentic coding som delegation af arbejde. Skriv et modul. Refaktorér en service. Tilføj tests. Opdatér dokumentation. Den framing føles tryg, fordi et menneske stadig “godkender” pull requesten.

Auto mode ændrer formen på den tryghed. Workflowet skifter fra “jeg bad den om kode” til “den tog en række handlinger i et miljø og endte med en tilstand”. Enheden er ikke længere et kodeudsnit. Det er en kæde af beslutninger.

Når du ser det sådan, bliver kerne-spørgsmålet enkelt: Hvilken autoritet gav du lige – og hvordan begrænser du den?

• Autoritet til at bruge penge: tokens, compute, API-kald, third-party tools.
• Autoritet til at ændre: filer, dependencies, konfigurationer, infrastructure-as-code.
• Autoritet til at afsløre: prompts og context, som kan indeholde secrets eller kundedata.
• Autoritet til at merge: evnen til at lande ændringer så hurtigt, at review bliver ceremonielt.

Hvis I ikke definerer det eksplicit, bliver default “hvad end værktøjet kan”. Det er ikke en policy. Det er ønsketænkning.

Default-on bør udløse samme checklist som en ny deploy-mekanisme

Når en virksomhed ændrer sin release pipeline, siger ingen seriøse: “lad os bare se, hvordan det går.” Man sætter budgets. Man lægger gates ind. Man logger provenance. Man designer rollback.

Agentic coding fortjener samme behandling, fordi failure modes ligner delivery-fejl. Output kan være korrekt og stadig skadeligt, fordi skaden ofte ligger i det, der ændrer sig rundt om koden: permissions, dependencies, configs og datahåndtering.

Her er den praktiske checklist, jeg ville kræve på plads, før “default-on” er tilladt ud over en lille, opt-in gruppe.

1) Budget controls der kan håndhæves – ikke bare er høflige

Agentic workflows gør variabel omkostning til et produkt af autonomi. En normal developersession har friktion. En agent-loop kan køre i timevis, kalde tools igen og igen og udforske brede løsningsrum.

Sæt budgets på tre niveauer:

• Per bruger per dag: stop utilsigtet runaway-forbrug.
• Per repo per uge: tving prioritering og gør spend synligt for code owners.
• Per workflow-run: begræns blast radius fra én fejlbehæftet loop.

Beslut derefter, hvad der sker, når budgettet rammes. Ikke en Slack-besked. Et håndhævet stop – eller et fallback til non-agentic mode.

2) Policy gates der forstår intent – ikke kun syntaks

Jeres eksisterende CI gates er bygget til deterministiske artifacts. Lint. Unit tests. Static analysis. De er nødvendige, men ikke tilstrækkelige, fordi agentic systemer kan ændre karakteren af change set’et.

Tilføj gates, der fokuserer på intent og scope:

• Scope gate: blokér ændringer, der rører sensitive directories (auth, billing, crypto, infra), medmindre de er eksplicit godkendt.
• Dependency gate: kræv review ved nye packages, nye container images og version-bumps ud over patch.
• Data gate: forhindre kopiering af produktionsdata ind i workspaces, prompts eller test fixtures.
• Secrets gate: stop ethvert workflow, der læser env vars eller key stores, medmindre det er et sanktioneret step med auditeret tooling.

Hvis du har læst min tekst om formal specs som incident-værktøj, er det samme filosofi: Du tilføjer ikke proces for skønhed. Du tilføjer den der, hvor tvetydighed bliver til outages, leaks eller dyre fejlregninger.

3) Provenance der holder til en incident review

Når noget går i stykker, spørger I: “hvorfor gjorde vi det her?” Hvis svaret er “agenten besluttede det”, er I allerede bagud. Ikke fordi AI ikke kan være nyttig, men fordi I ikke kan lære uden traceability.

I har brug for provenance, der binder sammen:

• Prompt og context: hvilke instruktioner og hvilke inputs der blev brugt.
• Tool calls: hvilke kommandoer der kørte, hvilke API’er der blev ramt, hvilke filer der blev læst.
• Artifacts: diffs, testresultater, build outputs og deploy-metadata.
• Menneskelige godkendelser: hvem godkendte hvad, på hvilket tidspunkt i kæden.

Gem det som build logs. Uforanderligt nok til at kunne stoles på – og tilgængeligt nok til at kunne debugges.

4) En rollback-plan og en kill switch, I har øvet

Rollback er ikke en knap. Det er en capability. Hvis en agent kan shippe flere ændringer hurtigere, vil I oftere opleve “korrekt kode, forkert system”. Det betyder, at rollback skal være billig og rutine.

• Hurtige revert-paths: feature flags, sikre deploy-defaults, migrations der kan rulles tilbage.
• Agent kill switch: én kontrol til at slå auto mode fra på tværs af organisationen – eller per repo – uden at vente på, at hvert team selv følger op.
• Freeze modes: mulighed for at låse sensitive områder til human-only changes under incidents eller audits.

Det hænger sammen med et bredere mønster, jeg har skrevet om i owning more of the stack. Hver ny capability er også nye måder at fejle på. Autonomi multiplicerer det, medmindre I designer til at stoppe fejl tidligt.

En erfaring fra virkeligheden: hastighed uden en control plane skaber “stille” kvalitetsgæld

Jeg har set en QA-funktion gå fra at være en gate til sidst til at være en design-constraint fra starten, da release-frekvensen steg, og forbundne produkter begyndte at shippe softwareopdateringer som et urværk. De teams, der forblev sunde, var ikke dem med de mest talentfulde mennesker. Det var dem, der gjorde change traceable, afgrænset og reversibelt.

Agentic coding presser i samme retning. Hvis I læner jer op ad hero reviewers, taber I. Review skalerer dårligt. Control skalerer godt.

Den praktiske konsekvens er ukomfortabel: I kan ikke “købe” agentic produktivitet med seats alene. I skal finansiere systemet omkring. Hvis I ikke gør det, leverer tool’et stadig output, men organisationen betaler prisen som incident-belastning, rework og en gradvis mistillid til automation.

Sådan ruller I det ud i dette kvartal uden at gøre jeres repos til et casino

Hvis du har ansvar for software delivery, kan du behandle default-on som en staged release – ikke en preference-setting.

1. Definér tiers af autonomi: suggest-only, PR-author, tool-caller i sandbox, tool-caller i shared env. Bind hvert niveau til eksplicitte controls.
2. Vælg to repos: ét med lav risiko og ét med høj læringsværdi. Undgå den centrale revenue path i starten, men gem jer ikke i toy projects.
3. Instrumentér før I skalerer: token spend, time-to-merge, rollback-rate, incident count og “mennesketid per shipped change”.
4. Tilføj gates der, hvor incidents er dyre: auth, billing, infra, data exports. I behøver ikke at “boil the ocean”.
5. Øv kill switch: kør en drill. Sørg for, at det faktisk stopper workflows at disable auto mode – og at det ikke knækker builds.

Hvis du vil have den supplerende vinkel, er min tidligere tekst Build on the Stack You Have samme rollout-logik anvendt på AI bredere: compounding gains kommer fra kontrolleret adoption – ikke entusiastisk sprawl.

Min holdning: default-on autonomi er fint – men kun for teams, der kan bevise control

Auto mode som default bliver normalt. Spørgsmålet er, om det bliver normalt på en måde, der gør jeres systemer mere robuste – eller normalt på en måde, der bare accelererer unowned change.

Hvis I behandler agentic coding som en release pipeline-ændring, ender I med bedre logs, klarere policies og reversibility, som I burde have bygget alligevel. Hvis I behandler det som en developer preference, skalerer I præcis de problemer, I allerede har: uklart ejerskab, svage gates og incident reviews, der ender i skuldertræk.

I behøver ikke at sætte farten ned. I skal gøre autonomi forståelig, afgrænset og stoppelig.