Claude Code i en virksomhed: hvad en AI-udvikleragent kan — og hvad den kræver

Claude Code i en virksomhed er Anthropics agentiske udviklerværktøj: det læser hele kodebasen, retter fejl og kører tests under menneskeligt opsyn — men kræver adgangsstyring, godkendelses-gates og en navngiven ansvarlig, før det får adgang til produktionsnære systemer. Det er samme afvejning, vi selv arbejder med: Agent360 er et internalOS-produkt bygget oven på Claude, så synspunkterne nedenfor kommer fra egen produkterfaring — ikke kun fra dokumentationen.

Claude Code er Anthropics agentiske udviklerværktøj: en AI-agent, der læser hele din kodebase, skriver og ændrer kode på tværs af filer, kører kommandoer og tests i terminalen og arbejder sammen med dine eksisterende udviklerværktøjer. For en virksomhed betyder det, at en stor del af det daglige udviklingsarbejde — fejlrettelser, tests, refaktorering, dokumentation, code review — kan uddelegeres til en agent, der arbejder under menneskeligt opsyn. Men det betyder også, at man giver et stykke software adgang til sin kode og sine systemer, og dét stiller krav: til adgangsstyring, til godkendelses-gates, til audit-spor og til at nogen i organisationen ejer ansvaret. Denne artikel gennemgår begge sider — hvad agenten kan, og hvad den kræver — baseret på Anthropics egen dokumentation.

Claude Code er ifølge Anthropics officielle dokumentation “et agentisk kodeværktøj, der læser din kodebase, redigerer filer, kører kommandoer og integrerer med dine udviklingsværktøjer” — tilgængeligt i terminalen, som IDE-udvidelse, som desktop-app og i browseren.

Lad os starte med definitionen og arbejde os frem mod det, de fleste beslutningstagere reelt spørger om: kan vi bruge det forsvarligt, og hvad skal vi have på plads først?

Hvad er Claude Code?

Claude Code er ikke en chatbot, man stiller spørgsmål til, og heller ikke en autocomplete-funktion, der foreslår den næste linje kode. Det er en agent: et program, der får en opgave beskrevet i almindeligt sprog, selv planlægger hvordan opgaven løses, og derefter udfører den i flere trin — læser filer, skriver kode, kører den, ser resultatet og retter til, indtil opgaven er løst eller agenten har brug for input.

Forskellen er væsentlig. En chatbot giver dig et svar, du selv skal omsætte til handling. En agent handler selv — inden for de rammer, du har givet den. Det er dét, der gør agent-kategorien interessant for virksomheder, og det er samtidig dét, der gør governance-spørgsmålet påtrængende.

Hvor kører Claude Code?

Ifølge dokumentationen kører Claude Code på flere flader, der deler samme underliggende motor:

• Terminalen (CLI) — den fulde version, hvor agenten arbejder direkte i projektmappen på udviklerens maskine.
• IDE-udvidelser — VS Code og JetBrains-IDE’er (IntelliJ, PyCharm, WebStorm m.fl.) med visuelle diffs og kontekst fra editoren.
• Desktop-app — selvstændig app med mulighed for at køre flere sessioner side om side og planlægge tilbagevendende opgaver.
• Browseren — cloud-sessioner uden lokal opsætning, hvor arbejdet kører i isolerede, Anthropic-administrerede virtuelle maskiner.

Instruktionsfiler, indstillinger og integrationer følger med på tværs af fladerne. For en virksomhed betyder det, at man kan standardisere én konfiguration og lade medarbejderne vælge den arbejdsform, der passer dem.

Modellen bag

Claude Code drives af Anthropics Claude-modeller — de samme modeller, der er tilgængelige via Anthropics API. Værktøjet kan ifølge Anthropics enterprise-dokumentation også afvikles gennem cloud-udbydere som Amazon Bedrock, Google Clouds Agent Platform (tidligere Vertex AI) og Microsoft Foundry — det vender vi tilbage til under governance, for det er et vigtigt punkt for virksomheder med krav til, hvor data må flyde hen.

Hvad en udvikleragent kan i praksis

Det følgende er de kapabiliteter, Anthropic selv dokumenterer — ikke et ønskekatalog. Det er værd at være præcis her, for markedsføringen omkring AI-agenter er ofte langt foran virkeligheden.

Læse og forstå en kodebase

Claude Code kan gennemsøge og læse et helt projekt: finde relevante filer, følge afhængigheder på tværs af moduler og danne sig et billede af arkitekturen. I praksis betyder det, at en udvikler (eller en teknisk interesseret leder) kan stille spørgsmål som “hvor håndteres brugerlogin i det her system?” og få et svar, der bygger på den faktiske kode — ikke på en generel formodning.

Det er ofte her, virksomheder oplever den første konkrete værdi: onboarding af nye udviklere, forståelse af gammel kode, som ingen længere husker detaljerne i, og dokumentation af systemer, der aldrig blev dokumenteret.

Skrive og ændre kode på tværs af filer

Agenten kan implementere nye funktioner og rette fejl beskrevet i almindeligt sprog. Dokumentationen beskriver arbejdsgangen sådan: agenten planlægger tilgangen, skriver koden på tværs af flere filer og verificerer, at den virker. Ved fejlrettelser kan man indsætte en fejlbesked eller beskrive symptomet, hvorefter agenten sporer problemet gennem kodebasen, identificerer årsagen og implementerer en rettelse.

Nøgleordet er “verificerer”. En agent, der kan køre koden efter at have skrevet den, fanger sine egne fejl på en måde, som ren tekstgenerering aldrig kan.

Køre tests og kommandoer i terminalen

Claude Code arbejder i terminalen og kan køre de kommandoer, et udviklingsprojekt bygger på: testsuiter, linters, build-værktøjer, pakkeinstallation. Anthropic fremhæver selv de opgaver, udviklere typisk udskyder: at skrive tests for utestet kode, rette lint-fejl på tværs af et projekt, løse merge-konflikter, opdatere afhængigheder og skrive release notes.

Det lyder udramatisk, men det er præcis den slags arbejde, der sluger tid i et udviklingsteam — og som sjældent bliver prioriteret, fordi det ikke er ny funktionalitet.

Arbejde med git og CI

Agenten arbejder direkte med versionskontrol: den kan stage ændringer, skrive commit-beskeder, oprette brancher og åbne pull requests. I CI-sammenhæng kan Claude Code automatisere code review og issue-triage via GitHub Actions eller GitLab CI/CD — altså køre som en del af virksomhedens eksisterende udviklings-pipeline, ikke kun som et interaktivt værktøj på den enkelte udviklers maskine.

Scriptes og automatiseres

Claude Code følger Unix-filosofien: det kan modtage input via pipes, køres ikke-interaktivt i scripts og kædes sammen med andre værktøjer. Dokumentationen viser eksempler som at analysere log-output eller lade agenten gennemgå ændrede filer for sikkerhedsproblemer som led i et automatiseret flow. Dertil kommer subagenter — flere agenter, der arbejder på forskellige dele af en opgave samtidig, koordineret af en ledende agent — og et Agent SDK for dem, der vil bygge egne agent-applikationer oven på samme motor.

Fra udviklerværktøj til virksomhedsværktøj

Alt det ovenstående er interessant for et udviklingsteam. Men det egentlige skifte sker, når agenten får adgang til virksomhedens systemer og data — og det er her, kategorien “udviklerværktøj” begynder at blive for snæver.

MCP: agentens adgang til virksomhedens systemer

Claude Code understøtter Model Context Protocol (MCP) — en åben standard for at forbinde AI-værktøjer til eksterne datakilder og systemer. Med MCP kan agenten ifølge dokumentationen læse designdokumenter i Google Drive, opdatere sager i Jira, hente data fra Slack eller bruge virksomhedens egne interne værktøjer.

Det ændrer regnestykket fundamentalt. En agent, der kun kan se kode, kan hjælpe udviklere. En agent, der kan se kode og virksomhedens ticketsystem, dokumentation og forretningsdata, kan udføre hele arbejdsgange: læse fejlrapporten i Jira, finde årsagen i koden, rette den, åbne en pull request og opdatere sagen. Kæden fra “problem opdaget” til “løsning klar til review” kan i princippet køres af agenten — med mennesker som godkendere ved de kritiske led.

Viden og standarder: CLAUDE.md, skills og hooks

En agent er kun så god som den kontekst, den arbejder ud fra. Claude Code har tre dokumenterede mekanismer til at give den virksomhedens viden:

• CLAUDE.md — en instruktionsfil, agenten læser ved hver sessions start. Her lægger man kodestandarder, arkitekturbeslutninger, foretrukne biblioteker og review-tjeklister. Anthropic anbefaler at deployere disse filer både på organisationsniveau (fælles standarder for hele virksomheden) og pr. repository.
• Skills — pakkede, genbrugelige arbejdsgange, som teamet kan dele, fx en fast procedure for review eller deployment.
• Hooks — shell-kommandoer, der kører automatisk før eller efter agentens handlinger, fx automatisk formatering efter hver filredigering eller lint før commit.

Set med virksomhedsøjne er det her, agenten går fra “smart praktikant” til “medarbejder, der kender husets regler”. Og det er værd at bemærke, at Anthropic selv fremhæver investering i dokumentation som den vigtigste anbefaling til organisationer, der ruller værktøjet ud.

Udvikler-brug vs. virksomheds-brug

Claude Code: individuel udvikler-brug sammenlignet med organiseret virksomheds-brug

Dimension	Individuel udvikler	Virksomhed / organisation
Adgang	Personlig konto, lokale filer	SSO, rollebaserede rettigheder, evt. cloud-udbyder (Bedrock, Google Cloud, Foundry)
Konfiguration	Personlige indstillinger og lokal CLAUDE.md	Managed policy settings udrullet centralt + CLAUDE.md på organisations- og repo-niveau
Systemadgang	Egen maskine og egne repos	MCP-servere til Jira, Drive, Slack m.fl. — konfigureret af ét centralt team og delt via versionskontrol
Sikkerhed	Standard-tilladelsesmodel med manuel godkendelse	Centralt håndhævede permissions, der ikke kan overskrives lokalt, plus sandboxing og deny-regler
Overblik	Egen sessionshistorik	Monitorering via OpenTelemetry-metrikker, audit-logging i cloud-miljøer
Ansvar	Udvikleren selv reviewer alt	Definerede godkendelses-gates, navngiven ansvarlig, dokumenterede arbejdsgange

Pointen med tabellen er ikke, at virksomheds-kolonnen er “mere avanceret”. Pointen er, at den er styret: de samme kapabiliteter, men med centralt definerede rammer i stedet for individuelle valg.

Sikkerhed og governance: hvad man bør kræve

Det her afsnit er det vigtigste i artiklen, hvis du er beslutningstager. En AI-agent med skriveadgang til kode og systemadgang via integrationer er et kraftfuldt værktøj — og kraftfulde værktøjer kræver rammer. Det gode er, at Claude Codes sikkerhedsmodel er offentligt dokumenteret, så man kan vurdere den konkret i stedet for at gætte.

Tilladelsesmodellen: read-only som udgangspunkt

Ifølge Anthropics sikkerhedsdokumentation bruger Claude Code “strenge read-only-tilladelser som standard”. Når agenten vil mere end at læse — redigere filer, køre tests, udføre kommandoer — beder den eksplicit om lov. Brugeren styrer, om en handling godkendes én gang eller tillades automatisk fremover.

Dertil kommer en række indbyggede værn, som er værd at kende, når man vurderer værktøjet:

• Arbejdsmappe-grænse: agenten kan kun skrive i den mappe, den blev startet i, og dens undermapper — ikke i overordnede mapper uden eksplicit tilladelse.
• Sandboxing af terminal-kommandoer: bash-kommandoer kan isoleres med filsystem- og netværksisolation.
• Godkendelse af netværkskommandoer: kommandoer, der henter indhold fra nettet (som curl), godkendes ikke automatisk — netop fordi indhold udefra er en klassisk angrebsvej.
• Fail-closed: kommandoer, der ikke matcher en eksplicit regel, kræver manuel godkendelse som standard.

Dokumentationen beskriver også specifikke værn mod prompt injection — angreb, hvor ondsindet tekst i fx en hjemmeside eller et dokument forsøger at overtage agentens instruktioner. Blandt værnene er isolerede kontekstvinduer for webindhold, detektion af mistænkelige kommandoer (som kræver manuel godkendelse, selv hvis de tidligere var tilladt) og input-sanitering. Anthropic er samtidig ærlige om, at intet system er immunt over for alle angreb — en ærlighed, man bør forlange af enhver leverandør i denne kategori.

Enterprise-kontroller: politik, der ikke kan omgås lokalt

For organisationer er det afgørende spørgsmål ikke, hvad den enkelte udvikler kan indstille, men hvad sikkerhedsteamet kan håndhæve. Her dokumenterer Anthropic tre ting, man bør notere sig:

1. Managed settings: sikkerhedsteams kan konfigurere centralt styrede tilladelser for, hvad Claude Code må og ikke må — og disse kan ikke overskrives af lokal konfiguration på den enkelte maskine.
2. Monitorering: brugen kan overvåges via OpenTelemetry-metrikker, så organisationen har indsigt i, hvordan værktøjet faktisk anvendes.
3. Deployment-valg: Claude Code kan afvikles via Anthropic direkte eller gennem virksomhedens eksisterende cloud-aftaler — Amazon Bedrock, Google Clouds Agent Platform eller Microsoft Foundry — med de IAM-politikker, audit-logs og fakturerings-spor, der hører til platformen. Trafikken kan desuden dirigeres gennem virksomhedens egen proxy eller en LLM-gateway med centraliseret adgangsstyring.

For cloud-sessioner (Claude Code i browseren) dokumenterer Anthropic yderligere: isolerede virtuelle maskiner pr. session, netværksadgang der er begrænset som standard og kan konfigureres til bestemte domæner, git-push begrænset til den aktuelle branch, og audit-logging af alle operationer.

Hvad man BØR kræve — en tjekliste

Uanset om det er Claude Code eller et andet agent-værktøj, bør en virksomhed efter vores vurdering kræve følgende, før agenter får adgang til produktionsnære systemer:

• Adgangsstyring: agentens adgang følger princippet om mindst mulig adgang. Ingen stående skriveadgang til systemer, hvor det ikke er nødvendigt.
• Godkendelses-gates: destruktive eller irreversible handlinger (deployment, sletning, udgående kommunikation) kræver eksplicit menneskelig godkendelse — altid.
• Audit-spor: det skal kunne dokumenteres, hvad agenten har gjort, hvornår og på hvis foranledning. Uden log, ingen agent.
• Central politik: sikkerhedsregler defineres ét sted og kan ikke omgås af den enkelte bruger.
• Review af output: kode skrevet af en agent reviewes efter samme standard som kode skrevet af mennesker. Anthropic formulerer det selv utvetydigt i dokumentationen: du er ansvarlig for at gennemgå foreslået kode og kommandoer, før du godkender dem.

Det sidste punkt rækker ud over teknikken: For danske virksomheder spiller den regulatoriske ramme også ind. Vi har skrevet en gennemgang af, hvad EU’s AI-forordning betyder for danske virksomheder, som er relevant baggrundslæsning, når man definerer sin interne AI-politik — herunder kravene om menneskeligt opsyn og dokumentation.

Hvad det kræver af virksomheden

Teknologien er den lette del. Det, der afgør om en AI-udvikleragent skaber værdi eller frustration, er tre organisatoriske forudsætninger.

Dataadgang og dokumentation

En agent uden kontekst gætter. En agent med adgang til opdateret dokumentation, kodestandarder og de rigtige systemer arbejder. Konkret betyder det:

• Skriftliggjorte standarder: hvis jeres kodestandarder og arkitekturprincipper kun findes i hovederne på to seniorudviklere, skal de skrives ned — i Claude Codes tilfælde i CLAUDE.md-filer, som agenten læser automatisk.
• Ryddelige datakilder: hvis agenten skal arbejde med forretningsdata via integrationer, gælder samme regel som for al automatisering: skrald ind, skrald ud. Vores guide til CRM-datahygiejne handler om salgssystemer, men princippet er identisk — datakvalitet er fundamentet under enhver automatisering.
• Adgang, der er tænkt igennem: hvilke systemer må agenten læse fra? Hvilke må den skrive til? Hvem beslutter det?

Klare arbejdsgange

En agent skal have veldefinerede opgaver med veldefinerede grænser. “Fix denne bug og skriv en test, der beviser rettelsen” er en god opgave. “Gør vores kodebase bedre” er ikke. Virksomheder, der får mest ud af agentiske værktøjer, definerer typisk:

• Hvilke opgavetyper agenten må tage selvstændigt (tests, lint, dokumentation, mindre fejlrettelser)
• Hvilke der kræver menneskelig plan-godkendelse først (nye features, arkitekturændringer)
• Hvilke der er helt uden for agentens område (sikkerhedskritisk kode, produktions-deployment uden review)

Anthropic anbefaler selv en gradvis tilgang: lad nye brugere starte med spørgsmål til kodebasen og mindre fejlrettelser, bed agenten lægge en plan, og giv feedback undervejs — og lad først agenten arbejde mere selvstændigt, efterhånden som teamet forstår arbejdsformen. Det matcher vores erfaring med al automatisering: modenhed kommer trinvist. Samme princip gælder i øvrigt uden for udviklingsafdelingen — se vores gennemgang af hvad CRM-automatisering er, og hvordan man kommer i gang.

En ansvarlig

Den vigtigste enkeltbeslutning: udpeg én person, der ejer agent-setuppet. Ikke et udvalg, ikke “teamet” — én person, der:

• Ejer konfigurationen (tilladelser, integrationer, instruktionsfiler)
• Følger med i, hvad agenten bruges til, og hvor den fejler
• Er eskalationspunkt, når noget går galt
• Vedligeholder dokumentationen, agenten arbejder ud fra

Uden en ansvarlig forfalder konfigurationen, tilladelserne skrider, og ingen opdager det, før noget går galt. Med en ansvarlig bliver agenten et system, virksomheden styrer — ikke et eksperiment, der driver.

Use-cases: bureauer og interne udviklingsteams

Hvor skaber en AI-udvikleragent så konkret værdi? Her er de mønstre, vi vurderer som mest realistiske — baseret på de dokumenterede kapabiliteter, ikke på løfter.

For bureauer og konsulenthuse

• Overtagelse af fremmede kodebaser: bureauer arver ofte kode fra tidligere leverandører. En agent, der kan læse og forklare en ukendt kodebase, forkorter vejen fra overtagelse til produktivitet.
• Vedligehold på tværs af mange kundeprojekter: afhængighedsopdateringer, sikkerhedspatches og lint-oprydning er repetitivt arbejde, der skalerer dårligt med mennesker og godt med agenter — med review som gate.
• Dokumentation som leverance: agenten kan generere og vedligeholde teknisk dokumentation af det, den bygger — noget kunder efterspørger, og bureauer sjældent når.
• Ensartet kvalitet: fælles skills og instruktionsfiler på tværs af projekter betyder, at husets standarder følger med i hvert projekt — også når teamet skifter.

For interne udviklingsteams

• Nedbringelse af teknisk gæld: den test-dækning og oprydning, der aldrig bliver prioriteret, kan køres som løbende agent-opgaver.
• Automatiseret code review i CI: agenten som ekstra reviewer på hver pull request — ikke i stedet for menneskeligt review, men før det, så mennesker bruger tiden på det væsentlige.
• Intern tooling: småværktøjer og scripts, som forretningen efterspørger, men som aldrig når toppen af backloggen.
• Brobygning til forretningssystemer: via integrationer kan udviklingsarbejdet kobles til de systemer, resten af forretningen lever i. For virksomheder, der arbejder systematisk med deres go-to-market-motor, er det samme tankegang som i Revenue Operations: siloer brydes ned ved at forbinde systemerne, ikke ved at bygge flere.

Begrænsninger og ærlige forbehold

Ingen leverandør-uafhængig gennemgang uden dette afsnit. Her er, hvad man skal være ærlig om:

Agenten tager fejl. Sprogmodeller kan skrive kode, der ser rigtig ud, men er forkert — eller rette ét problem og introducere et andet. Muligheden for at køre tests reducerer risikoen markant, men fjerner den ikke. Review er ikke valgfrit.

Kvaliteten afhænger af konteksten. I en velstruktureret kodebase med gode tests og klar dokumentation arbejder agenten godt. I en rodet kodebase uden tests er resultaterne mere blandede — agenten arver kodebasens svagheder, ligesom en ny medarbejder gør det.

Prompt injection er en reel angrebsflade. Når en agent læser indhold udefra — websider, dokumenter, e-mails — kan det indhold forsøge at manipulere den. Claude Code har dokumenterede værn, men Anthropic skriver selv, at ingen beskyttelse er fuldstændig. Behandl agentens adgang derefter.

Omkostninger kræver styring. Agentisk arbejde bruger væsentligt mere modelkapacitet end simple chat-forespørgsler, fordi agenten læser, tænker og itererer. Uden budgetter og monitorering kan forbruget overraske. Værktøjerne til styring findes (gateways, dashboards, centrale kvoter) — men de skal tages i brug.

Mennesket er stadig flaskehalsen — med vilje. Godkendelses-gates og review betyder, at agenten ikke gør organisationen uendeligt hurtigere. Det er ikke en fejl; det er prisen for kontrol. Virksomheder, der fjerner alle gates for at maksimere hastighed, har misforstået risikobilledet.

Organisatorisk umodenhed slår teknologien. Hvis ingen ejer setuppet, ingen vedligeholder instruktionerne, og ingen følger op på output-kvaliteten, bliver resultatet dårligere over tid — uanset hvor godt værktøjet er.

Kom i gang: en fornuftig rækkefølge

For en virksomhed, der vil afprøve en AI-udvikleragent seriøst, ser en fornuftig vej sådan ud:

1. Start småt og læsende. Lad et lille team bruge agenten til kodebase-spørgsmål og forståelse — read-only-arbejde, hvor risikoen er minimal og værdien øjeblikkelig.
2. Skriv konteksten ned. Etabler instruktionsfiler med kodestandarder og arkitekturprincipper, før I skalerer. Det er den bedst dokumenterede løftestang for kvalitet.
3. Definér gates. Beslut eksplicit, hvilke handlinger der kræver godkendelse, og konfigurér tilladelserne derefter — centralt, hvis I er flere teams.
4. Udpeg den ansvarlige. Én person ejer konfiguration, opfølgning og eskalation.
5. Udvid gradvist. Fra læsning til tests og småopgaver, fra småopgaver til features med plan-godkendelse, fra én integration til flere — i takt med at tillid og erfaring vokser.

Claude Code og Agent360

Til sidst en åben deklaration af vores eget ståsted: AI-agenten i Agent360 bygger på Claude — samme agent-teknologi, som denne artikel har gennemgået. Agent360 er virksomhedens AI-platform i én IDE: hvor Claude Code er udviklerens værktøj til kode, er Agent360 bygget til at give hele virksomheden — ikke kun udviklerne — en agent, der arbejder i virksomhedens egne data og systemer. Hver virksomhed kører sin egen instans med sin egen database (self-host er muligt), agenten forbindes til forretningssystemerne via flere end 35 connectors, apps installeres fra et kurateret registry, og platformen er licenseret som fair source — ægte open source efter to år. Hvis spørgsmålet “hvad kunne en agent gøre med adgang til vores systemer?” opstod undervejs i artiklen, er det præcis det spørgsmål, Agent360 er bygget til at besvare.

Ofte stillede spørgsmål

Er Claude Code det samme som ChatGPT eller en chatbot?

Nej. Claude Code er et agentisk værktøj: det udfører opgaver i flere trin — læser kode, redigerer filer, kører kommandoer og verificerer resultatet — i stedet for kun at generere tekstsvar. En chatbot giver dig et svar, du selv skal omsætte; en agent udfører arbejdet inden for de rammer, du godkender.

Kan Claude Code ændre ting i vores systemer uden godkendelse?

Ikke som standard. Ifølge Anthropics dokumentation arbejder Claude Code med read-only-tilladelser som udgangspunkt og beder om eksplicit lov, før det redigerer filer eller kører kommandoer, der kan ændre systemet. Organisationer kan derudover håndhæve centrale politikker (managed settings), som den enkelte bruger ikke kan overskrive lokalt.

Hvad er MCP, og hvorfor er det vigtigt for virksomheder?

MCP (Model Context Protocol) er en åben standard for at forbinde AI-værktøjer til eksterne systemer og datakilder — fx Jira, Google Drive eller virksomhedens egne interne værktøjer. Det er vigtigt, fordi det er broen fra "AI der hjælper med kode" til "AI der udfører hele arbejdsgange på tværs af virksomhedens systemer". Samtidig er det netop dér, adgangsstyring og governance bliver afgørende.

Kan vi køre Claude Code gennem vores eksisterende cloud-aftale?

Ja. Anthropic dokumenterer deployment via Amazon Bedrock, Google Clouds Agent Platform (tidligere Vertex AI) og Microsoft Foundry ud over Anthropics egne planer, og trafikken kan dirigeres gennem virksomhedens egen proxy eller en LLM-gateway med central adgangsstyring, forbrugsoverblik og de audit-mekanismer, der hører til cloud-platformen.

Erstatter en AI-udvikleragent vores udviklere?

Nej — den flytter deres tid. Agenten overtager repetitivt arbejde (tests, lint, afhængigheder, dokumentation, første udkast til rettelser), mens udviklerne beholder ansvaret for arkitektur, review og de beslutninger, der kræver forretningsforståelse. Anthropics egen dokumentation er tydelig om, at mennesket er ansvarligt for at gennemgå og godkende agentens arbejde.

Hvad er det vigtigste at have på plads, før vi ruller en agent ud?

Tre ting: nedskrevet kontekst (kodestandarder og dokumentation, agenten kan arbejde ud fra), definerede godkendelses-gates (hvilke handlinger kræver menneskeligt ja), og én navngiven ansvarlig, der ejer konfigurationen og følger op. Teknikken kan installeres på en eftermiddag — det organisatoriske fundament er det, der afgør resultatet.