---
title: "Vi bygger nu på tre måneder det, der før tog os tre år. Det er dér, den svære del begynder. | Guardian360"
description: "På tre måneder har en håndfuld mennesker genopbygget vores Lighthouse-platform med mere ny funktionalitet, end vi før leverede på tre år. AI fjernede vores ældste begrænsning og afslørede en ny: når det at bygge ikke længere er en knap ressource, er implementering det."
url: https://guardian360.net/da/blog/we-now-build-in-three-months-what-took-us-three-years/
locale: en
source: guardian360.net
---
[← Alle indlæg](https://guardian360.net/da/blog/)

Holdning

# Vi bygger nu på tre måneder det, der før tog os tre år. Det er dér, den svære del begynder.

Af Jan Martijn Broekhof · 12. oktober 2026

Noget har ændret sig i vores udviklingsteam i år, og jeg er stadig ved at vænne mig til det. I de seneste tre måneder har en håndfuld mennesker hos Guardian360 genopbygget vores Lighthouse-platform og udvidet den med mere ny funktionalitet, end vi tidligere leverede på over tre år. Vi hyrede ikke et større team, og vi fandt ikke et større budget. AI-assisteret softwareudvikling fjernede ganske enkelt den begrænsning, der formede hver eneste roadmap-beslutning, vi nogensinde har truffet: en mangel på mennesker og værktøjer.

Det lyder som gode nyheder, og i det store og hele er det også det. Men det har afsløret en ny begrænsning, og den ligger ikke dér, hvor jeg havde forventet at finde den. Når det at bygge ikke længere er en knap ressource, er implementering det. Vores partnere, de managed service providers (MSPs), der leverer vores cybersikkerhedsplatform til deres kunder, kan ikke optage ny funktionalitet i den hastighed, vi nu kan producere den. Og to yderligere spørgsmål holder mig beskæftiget. Er software, der bygges så hurtigt, egentlig sikker? Og kan mere funktionalitet udhule den enkelhed, der altid har adskilt os fra andre?

## Hvad ændrer sig, når det at bygge ikke længere er flaskehalsen?

I det meste af Guardian360’s historie var vores roadmap en liste over ting, vi gerne ville bygge, rangeret efter, hvad vi havde råd til at bygge. Partnere bad om bestemte funktioner i årevis, og mange af dem måtte vente.

I dag arbejder vores udviklere side om side med AI til kodegenerering, test og dokumentation. Vi startede med Claude, Anthropics model, og flytter i stigende grad det arbejde over til Hermes. Hermes er ikke en model, men et lag, vi selv har bygget. Det bruger open source-sprogmodeller til at drive det, vi kalder en virksomhedshjerne, og det faciliterer de AI-agenter, der hjælper os med en bred vifte af opgaver. Hermes, og de open source-modeller, det bruger, kører i vores egen serverklynge i Holland, og det er lige så meget et princip som et spørgsmål om praktik. Claude har aldrig haft adgang til kundedata på vores platform, fordi vores partneraftaler ikke tillader, at de data forlader EU. At flytte mere af vores arbejde til infrastruktur, vi selv kontrollerer, følger samme logik.

Vi er langtfra usædvanlige. Ifølge Veracodes 2026 GenAI Code Security Report genererer AI nu cirka halvdelen af al committet kode. Spørgsmålet er ikke længere, om softwareteams bruger AI, men hvad der sker derefter.

## Er software, der bygges med AI, egentlig sikker?

Dette er den bekymring, jeg tager mest alvorligt, og jeg formoder, at det er det første spørgsmål, mange læsere vil stille. Forskningen giver kun lidt grund til trøst. Veracode fandt, at cirka 44 procent af AI-kodegenereringsopgaver introducerede en risikabel sårbarhed, med en gennemsnitlig sikkerhedsbeståelsesrate på 56 procent, stort set uændret fra 55 procent i den første rapport. IOActives undersøgelse fra april 2026 analyserede næsten 20.000 kodeprøver og fandt, at 31,6 procent af de AI-genererede prøver var fuldt udnyttelige; ingen model producerede fuldstændig sikkert output.

Det, der bekymrer mig endnu mere, er kløften mellem opfattelse og virkelighed. Cloud Security Alliance rapporterer, at over 75 procent af udviklerne i én undersøgelse mente, at AI-genereret kode er mere sikker end menneskeskrevet kode, mens 56 procent indrømmede, at den ofte introducerer sikkerhedsproblemer. Hastighed føles som kompetence. Det er det ikke.

IOActives konklusion er, at organisationer skal behandle AI-output som utroværdigt input og håndhæve obligatorisk sikkerhedsgennemgang før udrulning. Det er præcis sådan, vi arbejder: AI må gerne skrive koden, men hver ændring gennemgås af en person, der forstår den, før den når produktion. Vi går nu et skridt videre ved at vende vores egen AI-pentest mod os selv, herunder crystal box-analyse af vores egen kildekode, hvor testagenterne har fuld adgang til koden. Vi kører den analyse med flere forskellige modeller, så den ene models blinde vinkler er mindre tilbøjelige til at blive overset.

Samme princip præger den AI-pentest, vi bringer til vores partnere, hvor AI’en udfører testen, og partnerens konsulent underskriver den. Udviklere ser ud til at dele denne instinktive tilgang. I Stack Overflows 2026 Developer Survey sagde næsten halvdelen af respondenterne, at de stoler på AI-output, når de kan verificere det, mens kun 6,6 procent ville betro AI en vigtig beslutning.

## Hvorfor betyder flere funktioner ikke automatisk mere værdi?

Den anden bekymring er mindre teknisk, men lige så reel. No Jitter beskrev for nylig en “feature flood” i kommunikationssoftware, hvor leverandører udgiver hundredvis af nye funktioner hvert år, mens anvendelsen halter bagefter. Pendos benchmarks antyder, at omkring 80 procent af de byggede funktioner aldrig opnår meningsfuld anvendelse, og at 6,4 procent af funktionerne genererer 80 procent af alle klik. Det mønster eksisterede længe før AI. AI gør det blot billigere at gentage.

Guardian360 har altid forsøgt at tilbyde en platform, som en MSP kan forklare et bestyrelsesmedlem på få minutter. Hver funktion, vi tilføjer, gør det sværere. Omkostningen ved at bygge en funktion er kollapset; omkostningen ved at forstå den er det ikke.

Vores partnere bærer allerede rigeligt med kompleksitet. Forskning fra CRN, udgivet af sikkerhedsleverandøren Coro, fandt, at MSPs håndterer mellem 6 og 20 eller flere leverandører for at levere sikkerhedstjenester, vurderer integrationen mellem disse værktøjer til blot 6,2 ud af 10, og at kun 7 procent er tilfredse med afkastet på deres sikkerhedsværktøjer. Det sidste, de har brug for fra os, er endnu et lag af kompleksitet, hvor velment det end måtte være.

## Hvor er flaskehalsen flyttet hen?

Googles DORA-forskning tilbyder et nyttigt perspektiv. Dens 2025-rapport fandt for første gang en positiv sammenhæng mellem AI-adoption og leveringsgennemstrømning, men AI-adoption korrelerede stadig med lavere leveringsstabilitet: flere ændringsfejl, mere omarbejde og længere genopretning. DORA konkluderede også, at AI har en tendens til at spejle og forstærke eksisterende organisatoriske træk, på godt og ondt.

Jeg vil udvide den observation ud over udviklingsteamet. En funktion skaber kun værdi, når en partner forstår den, konfigurerer den, forklarer den til en kunde og bygger en tjeneste op omkring den. Den kæde kører i menneskelig hastighed. AI accelererer det første led og lader resten være urørt, hvilket betyder, at køen ganske enkelt flytter nedstrøms, til vores partnere og deres kunder.

Stack Overflows undersøgelse peger i samme retning: folk stoler på det, de kan verificere. En partner, der aldrig har set en funktion virke, kan ikke verificere den, kan ikke forklare den og vil ikke sælge den.

## Bør vi simpelthen sætte farten ned?

Nogle partnere ville argumentere for netop det: stop en tid, stabiliser, lad os indhente jer. Det er et rimeligt argument, og jeg er delvist enig i det. En leverandør, der udgiver hurtigere, end dens kanal kan følge med, optimerer for sin egen tilfredshed, ikke for sine partnere.

Men at sætte farten kunstigt ned ville spilde en mulighed, som små europæiske leverandører sjældent får. Svaret er efter min overbevisning disciplin frem for opbremsning. Det betyder at beslutte, hvad man ikke skal udgive, at behandle enkelhed som et designkrav frem for en eftertanke og at involvere partnere, før en funktion er færdig, frem for bagefter.

En del af den disciplin er indbygget i selve platformen. Vi introducerer workspaces: i stedet for at præsentere hver funktion på én skærm grupperer vi funktionalitet efter opgave, så en partner kun ser det, som den aktuelle opgave kræver. Den AI-drevne brugerflade tager dette videre. Sider, rapporter og navigation bliver definitioner frem for kode, og en agent bygger den visning, en bruger beder om, inden for grænserne af vedkommendes rolle. Dette er ikke længere et koncept. Vi vil vise det virke den 3. november, og vi ønsker ærlig feedback fra vores partnere om, hvorvidt det faktisk hjælper dem.

Der er en anden måde at holde kompleksiteten nede på: lad platformen gøre mere af arbejdet. I dag fortæller Lighthouse dig, hvad der kunne forbedres. I fremtiden vil den også rette det, hvor partneren og dens kunde tillader det. Hver opgave, platformen overtager, er en opgave, en partner ikke længere skal lære, forklare eller planlægge.

## Hvorfor vi åbner dørene til kontrolrummet

Guardian360’s logo indeholder et fyrtårn, og metaforen har aldrig føltes mere rammende. Et fyrtårn er kun nyttigt, hvis dets lys når kysten. Vi kan bygge verdens klareste lys, men det er vores partnere, der bærer det ud til deres kunder.

Derfor er vi vært for [“Et kig fra kontrolrummet”](https://guardian360.net/da/a-view-from-the-control-room/) tirsdag den 3. november 2026 fra 09:30 til 13:00 på Van der Valk Hotel i Woerden. Vi vil vise, hvad vi har bygget, kørende live frem for på slides, og give et første indblik i, hvad Guardian360 leverer i 2027. Deltagelse er gratis, der er plads til omkring 50 gæster, og tilmelding er åben indtil 30. oktober. Mere end demonstrationerne værdsætter jeg samtalen. Jeg vil hellere høre den 3. november, at noget er for komplekst, end opdage det i anvendelsestal om et år.

## Så, hvad er din begrænsning nu?

Hvis det at bygge heller ikke længere er din begrænsning, og for mange MSPs er det øjeblik tættere på, end det ser ud, hvad er den så? For os er svaret klart. Når det at bygge ikke længere er en knap ressource, er implementering det. Det er dér, den svære del begynder, og det er et arbejde, vi kun kan udføre sammen med vores partnere.

## Kilder

- Veracode: 2026 GenAI Code Security Report: AI Is Writing More of Your Code but Security Hasn’t Caught Up (July 2026)
- IOActive: The Security Gap in AI-Generated Code (April 2026)
- Cloud Security Alliance: Vibe Coding Security Debt: AI-Generated Vulnerabilities at Scale (April 2026)
- IT Brief UK: Stack Overflow survey finds developers wary of AI tools (October 2026)
- Google Cloud / DORA: Announcing the 2025 DORA report: State of AI-assisted Software Development
- No Jitter: Vendors ship thousands of features, users adopt dozens (July 2026)
- Coro / CRN: Your Tool Stack Is Eating Your Margins (August 2026)
- Guardian360: A view from the control room, event 3 November 2026