AI er allerede i editoren. Beslutningsgangen halter – og det kan mærkes i driften, når tempoet stiger før kontrollerne.
Kort triage for ledere: Hvor går data hen, hvad går i produktion hurtigst, og hvor øges ændringsfrekvensen markant? Svarene afgør, hvem der bør trykke godkend i jeres organisation de næste måneder.
Hvad er der sket
Generativ AI er blevet en del af daglig udvikling. Unite.ai beskriver brug til API‑generering, testskrivning og scaffolding samt rapporterede produktivitetsgevinster (kilde: Unite.ai). Gevinsterne er leverandør‑ og brancheopgivelser; uafhængige, metodisk beskrevne målinger mangler i kilden.
IBM forklarer, at moderne code‑LLMs foreslår kode i realtid, oversætter mellem sprog, moderniserer legacy, hjælper med debugging og peger på potentielle sårbarheder (kilde: IBM Think). Det sænker barrieren for at prøve nye biblioteker og mønstre – ændringstakten stiger.
Konsekvensen i praksis: værktøjer glider ind i hverdagen via udviklernes flow, før klassiske indkøb‑ og sikkerhedsprocesser når at blinke grønt. Spørgsmålet er derfor, hvem der sætter rammerne – og hvornår.
Hvem træffer beslutningen nu
Magten flytter mod engineering. Unite.ai peger på, at teams vælger hurtigere end procurement og security kan nå at godkende. Tre modeller går igen: developer‑drevet, fødereret governance og centraliseret kontrol.
Developer‑drevet: Teams vælger og bærer ansvaret. Hurtigt, stærkt ejerskab. Men praksis bliver uens, og skygge‑indkøb trives.
Fødereret governance: En central ramme sætter hegnspæle, domæneteams vælger indenfor. Kræver minimumskrav, standardiserede CI/CD‑hooks og fælles risikosprog. Ofte mest realistisk over ca. 100 udviklere.
Centraliseret kontrol: En platformenhed udvælger og drifter værktøjer. Konsistens og revision er lettere. Udviklere kan dog omgå med lokale klienter og browser‑plugins, så man ender med både central løsning og uofficielle alternativer. Dyr blanding.
Sikkerhed og tillid til AI genereret kode
Kernen er tillid: Kan man regne med AI‑kode, og hvor gemmer sårbarhederne sig? Unite.ai beskriver, at diskussionen netop drejer sig om sikkerhed og kvalitet (kilde: Unite.ai). Modeller kan foreslå solide mønstre, men også gentage fejl fra træningsdata.
IBM skriver, at værktøjer i stigende grad hjælper med at finde potentielle sårbarheder og forbedre læsbarhed og performance. Betoning på potentielle. Klassiske værn som SAST, DAST og dependency‑scanning er fortsat nødvendige – og oftere – når ændringerne kommer hurtigere.
Licens og ophavsret er en blind vinkel i kilderne. IBM beskriver træning på store open‑source‑korpusser, men ingen af kilderne dokumenterer klare retningslinjer for, hvornår genereret kode kan udløse licenskrav eller attribution. Tag det som en risiko, indtil juridisk vurdering foreligger – og byg licens‑scanning ind i pipelinen.
Hvilke praktiske krav stiller det til drift og CI/CD
Når AI flytter ind i editoren, skal pipeline følge med. Ellers flytter risikoen ind i produktionen. Snillds manual brief anbefaler AI‑kontrolpunkter i CI/CD, løbende performance‑måling og tydelige POC‑faser før bred udrulning. Det er interne råd, ikke uafhængig forskning, men de adresserer hullet mellem teori og drift.
Tre lag af beskyttelse: ved pull request, i build og i drift. Ved PR bør kode mærkes, hvis dele er AI‑genereret, så reviewers ved, hvad de kigger efter. Et konkret eksempel: Et PR‑template med en afkrydsning “Indeholder AI‑genererede ændringer” og et felt “Kort prompt/kontekst brugt”, så konteksten kan vurderes. I build: SAST, licens‑scanning og secrets‑detektion som standard. I drift: følg fejlrate, MTTR og ændringsfrekvens særskilt for AI‑assisterede commits.
Data governance: Prompt‑biblioteker, snippets og systeminstruktioner er blevet organisationsdata. Behandl dem som kode – versionér, styr rettigheder, og behold revisionsspor. Det virker småt, men det er ofte her, reproducerbarheden knækker.
Regulering og leverandøransvar
ArtificialIntelligence‑News rapporterer, at OpenAI tilpasser sikkerheds‑ og transparenspraksisser til EU AI Acts GPAI Code of Practice, inklusiv pre‑release testing, system cards og eksterne red‑teaming‑netværk (kilde). Det signalerer modenhed og vilje til dokumentation.
Dokumentation er dog ikke lig med compliance. Artiklen beskriver processer, ikke uafhængige audits af dækningsgrad eller effekt. Hvad mangler ofte i et svagt system card? Trusselsmodel, eval‑data og metoder, kendte failure modes samt konkrete afhjælpninger. Bed om netop det – og om scope‑grænserne for testene.
Praktisk for vendor due diligence: Bed om indsigt i testplaner, brugte testdata og deres begrænsninger, red‑teaming‑rapporter, kendte issues og afhjælpninger. Brug materialet som input, ikke facit.
Tre konkrete scenarier for danske organisationer
Hurtig adopterende scaleup: Beslutningsmagt hos VP Engineering med fødereret governance. Krav: PR‑mærkning af AI‑kode, obligatorisk SAST og licens‑scanning, centralt prompt‑repo med kodeejere. Tradeoff: maksimal fart, men uens kvalitet mellem teams. Aftal en kvartalsvis screening på MTTR, bug‑rate og rework.
Konservativ offentlig institution: Læg valget centralt hos en platformenhed med CISO‑vetoret for datatilgang. Krav: leverandørdokumentation med system cards, beskrivelser af pre‑release tests og bevis for ekstern red‑teaming. Kodeside: DAST i pre‑prod, SBOM ved hvert release, isolation af AI‑trafik og ingen brug af borger‑/kundedata i prompts før DPIA er godkendt. Tradeoff: lavere hastighed, lettere revision.
Mellemstor virksomhed med blandet legacy‑stack: Fødereret model med standardiserede CI/CD‑hooks. Krav: ens toolchain til scanning på tværs af Java, .NET og Node, central policy for afhængigheder og en udpeget AI‑champion i hvert team. Brug AI til modernisering af legacy‑moduler, men kræv ekstra review ved automatiseret oversættelse af hele filer. Tradeoff: balance mellem fart og kontrol; risiko for policy‑drift uden løbende ajourføring.
Hvad betyder det for workflows i praksis
Code review ændrer karakter. Kig målrettet efter fejltyper LLMs ofte snubler over: inputvalidering, fejlpropagering, tidzoner og I/O‑kanter. En kort tjekliste løfter bunden. To spørgsmål, der gør ondt godt: “Er input sanitiseret?” og “Er fejltyper konsistente?”
Branch‑strategi og release‑cadence presses. Hurtigere generering presser main. Feature flags og progressive delivery bliver nødvendig buffer, når forslaget ikke er fuldt afprøvet i alle hjørner.
Dokumentationen flytter også. Prompts, systeminstruktioner og værktøjsindstillinger er udviklingsartefakter. Uden dem kan man ikke reproducere en genereret modulændring et halvt år senere. Skriv dem ned. Kort er fint – bare nok til at forstå valgene.
Praktiske råd Snilld
Følgende er interne råd fra Snillds manual brief. Brug dem som afsæt – mål og justér lokalt.
- Start med en afgrænset POC og baselines for lead time, bug‑rate og MTTR. Mål 30/90 dage før/efter POC for samme komponent. Hvis MTTR stiger over 25 % eller bug‑rate pr. KLOC stiger over 20 % efter 30 dage, sæt rollout på pause og kør ekstra review.
- Workshops om reviewer‑praksis og prompt‑hygiejne. Indfør en fælles PR‑tjekliste på én side, så den bliver brugt – ikke gemt.
- CI/CD‑kontrolpunkter: SAST (obligatorisk), DAST hvor relevant, dependency‑ og licens‑scanning, secrets‑detektion samt SBOM ved hvert release. IBM nævner sårbarhedsidentifikation i værktøjer; brug det som supplement, ikke erstatning.
- Mærkning og sporbarhed: Lad udvikleren sætte PR‑label “AI‑assisted” og angive kort prompt/kontekst. CI tilføjer et commit‑tag (fx ai:yes) og gemmer prompt‑uddrag i et versionsstyret repo eller som build‑artifact. Minimum: værktøjsnavn, versionsnummer, dato.
- Performance‑metrikker pr. team: bug‑rate efter release, MTTR, rework‑andele på AI‑genereret kode, lead time. Brug simple thresholds for eskalation (fx rework >15 % af AI‑commits over 2 sprints → ekstra review og prompt‑træning).
- Vendor due diligence: Bed om system cards, testplaner, beskrivelser af anvendte testdata og deres begrænsninger, red‑teaming‑rapporter samt proces for incident response. Kilde: ArtificialIntelligence‑News om OpenAI‑praksisser.
- Data‑ og adgangspolitik: Afklar om prompts og kode sendes ud af huset, logging og retention, samt mulighed for lokalt isoleret drift. Dokumentér beslutningen i repoets SECURITY.md.
Modargumenter og usikkerheder
Nogle vil sige, at gevinsten er tydelig og ikke kræver så meget styring. Unite.ai beskriver rapporterede gevinster, men uden uafhængige målinger. Det afviser ikke effekten – det er en påmindelse om at teste lokalt. Tallene kan falde, når kompleksitet og drift presser løsningen.
Andre peger på, at leverandørers dokumentation bør være nok. ArtificialIntelligence‑News beskriver OpenAIs tilpasning til GPAI‑koden med system cards og red‑teaming. Uden tredjepartsaudit kender man ikke dybden af testene. Brug materialet som start, ikke slut.
Licens og attribution er fortsat uklart i kilderne. IBM beskriver træningskorpusser, men ingen leverer en klar juridisk ramme for, hvornår genereret kode udløser licenskrav. Indtil praksis er tydeligere: behold licens‑scanning og juridisk vurdering som standard.
Hvem bør have mandatet
Er tempoet højt og risici moderate, peger pilen mod engineering i en fødereret ramme: centralt vedligeholdt CI/CD‑standard, minimumskrav og ret til at eksperimentere i isolerede sandkasser. Er data følsomme, eller systemerne kritiske, har central styring forrang – også hvis farten falder.
Det afgørende er sporbarhed: Hvem godkendte værktøjet, hvilke kontroller var aktive, og hvad viser driftsdata tre måneder efter? Uden den fortælling bliver beslutningen tro i stedet for evidens.
Afslutning
AI ændrer ikke kun koden – den ændrer beslutningsgangen. Så, helt konkret: Hvem sætter politikken, hvor ligger minimumskravene, og hvordan måler I, om gevinsten holder efter første release? Svaret skal kunne læses i jeres pipeline og i jeres tal. Ikke i en powerpoint.
