Jeg tror AI endrer mer enn hvor raskt vi skriver kode. Den endrer også økonomien i alt limarbeidet rundt verktøyene våre. Et konkret eksempel er sikkerhetsskanning i CI/CD. Tidligere var det ofte fristende å velge den enkleste veien: bruke plattformens ferdige byggesteiner, ferdige actions eller ferdige pipeline-komponenter. Ikke nødvendigvis fordi det var den beste arkitekturen, men fordi alternativet kostet for mye tid å bygge og teste.
Nylig jobbet jeg med et oppsett for OWASP-relevant sikkerhetsskanning i Bitbucket. Målet var ikke bare å få skanningen til å kjøre. Målet var å gjøre løsningen mest mulig plattformuavhengig.
I praksis betyr det:
- skannelogikken skal bo i repositoryet
- pipelinen skal være et tynt orkestreringslag
- det skal være mulig å teste det samme lokalt som i CI
- ekstra installasjon og eksperimentering skal ikke forurense utviklingsmiljøet
Det høres kanskje trivielt ut, men det er nettopp her mange team tidligere har endt opp med sterk avhengighet til én CI/CD-plattform.
Hva var problemet?
Hvis man vil kjøre sikkerhetsskanning i en pipeline, finnes det ofte to veier:
- Bruk en plattformspesifikk integrasjon
- Bygg logikken selv med skript og verktøy du kontrollerer
Den første varianten er raskest å komme i gang med. Den andre varianten er ofte bedre på lang sikt, men har tradisjonelt kostet mer. Du må selv håndtere installasjon, miljøvariabler, rapportfiler, exit codes, lokal testing og drift av små detaljer som ellers er skjult bak en ferdig komponent. Det er nettopp denne kostnaden AI begynner å spise opp.
Hva ble løsningen?
I stedet for å legge skannelogikken inn i selve Bitbucket-pipelinen, ble den flyttet ned i egne skript.
Konseptuelt ser det slik ut:
Poenget er enkelt:
- Bitbucket eier ikke skannelogikken
- Docker Compose eier ikke skannelogikken
- Skriptene eier skannelogikken
Det gjør at samme oppførsel kan brukes både lokalt og i CI.
Et mer konkret eksempel
I stedet for å gjøre pipelinen tung og full av spesiallogikk, kan pipeline-steget være relativt tynt:
bash cli/scripts/run-scan.sh findsecbugs
[...]
bash cli/scripts/run-scan.sh osv
Det interessante her er ansvarsdelingen. I praksis det eneste pipeline gjør er å kjøre scriptet og publisere rapportene. Resten ligger i repositoryet.
Hvorfor Docker Compose fortsatt er viktig
Selv om pipelinen kaller skriptene direkte, er Docker Compose fortsatt svært nyttig som lokal harness.
Da kan man teste skanneoppsettet uten å:
- installere ekstra verktøy permanent på vertsmaskinen
- risikere å forurense eget utviklingsmiljø
- pushe små pipeline-endringer bare for å se om noe virker
Lokalt kan man tenke omtrent slik:
docker compose -f cli/docker-compose.yml run --rm findsecbugs
docker compose -f cli/docker-compose.yml run --rm osv-scan
Det gir et kontrollert miljø for prøving og feiling. Hvis noe går galt, kastes containeren. Hvis noe må endres, bygges den opp igjen.
Dette er også et nyttig sikkerhetsnett når man bruker AI-assistenter. Hvis arbeidsregelen er at AI kun får teste gjennom en isolert harness, reduseres risikoen for at den gjør uønskede endringer direkte i utviklingsmiljøet.
Hvorfor dette er lettere nå enn før
Det avgjørende poenget for meg er ikke at dette er mulig. Det har det egentlig alltid vært. Det nye er at det er blitt billigere å gjøre det skikkelig.
Tidligere var slike oppsett ofte i kategorien: «Ja, dette hadde vært ryddigere, men det tar for lang tid.»
Nå er vi nærmere: «Dette er ryddigere, og AI gjør det raskt nok til at det faktisk er verdt det.»
AI hjelper ikke bare med å skrive applikasjonskode. Den hjelper også med:
- skript
- konfigurasjon
- feilsøking
- små integrasjonslag
- iterasjon på tekniske detaljer
Det gjør at oppgaver som før var for små til å få prioritet, eller for kjedelige til å bli gjort ordentlig, faktisk kan løses på en mer robust måte.
En enkel illustrasjon av flyten
Det er dette som gir verdi:
- én logikk
- to kjøremiljøer
- mindre duplisering
- mindre plattformbinding
Det større poenget
For meg peker dette på noe større enn bare OWASP-skanning; Verdien av innebygde plattformbyggesteiner er i ferd med å falle.
Det som tidligere var en viktig del av forskjellen mellom én CI/CD-plattform og en annen, er ikke lenger en like sterk differensiator som før. Hvis AI reduserer kostnaden ved å bygge det som mangler selv, blir den strategiske verdien av ferdige plattformkomponenter mindre.
Det gjelder sannsynligvis ikke bare CI/CD.
Det kan også gjelde andre tradisjonelle programvareverktøy. Når AI gjør det billigere å lage avanserte interne verktøy, kan flere team velge å bygge det de faktisk trenger, i stedet for å tilpasse seg begrensningene i standardprodukter.
Men det kommer med en viktig forutsetning. Du må fortsatt vite hva du vil bygge. AI reduserer implementasjonskostnaden, men erstatter ikke arkitektonisk klarhet, teknisk dømmekraft eller evnen til å definere det riktige problemet.
Det er kanskje den viktigste lærdommen: AI gjør ikke nødvendigvis standardverktøy irrelevante. Men den flytter grensen for når det er verdt å bygge noe bedre selv.





