---
title: "Vi bygger nu på tre månader det som tog oss tre år. Det är där den svåra delen börjar. | Guardian360"
description: "På tre månader byggde en handfull personer om vår Lighthouse-plattform med mer ny funktionalitet än vi tidigare levererade på tre år. AI tog bort vår äldsta begränsning och blottlade en ny: när det inte längre är ont om byggande, är det implementeringen som är flaskhalsen."
url: https://guardian360.net/sv/blog/we-now-build-in-three-months-what-took-us-three-years/
locale: en
source: guardian360.net
---
[← Alla inlägg](https://guardian360.net/sv/blog/)

Opinion

# Vi bygger nu på tre månader det som tog oss tre år. Det är där den svåra delen börjar.

Av Jan Martijn Broekhof · 12 oktober 2026

Något har förändrats i vårt utvecklingsteam i år, och jag håller fortfarande på att vänja mig vid det. Under de senaste tre månaderna har en handfull personer på Guardian360 byggt om vår Lighthouse-plattform och utökat den med mer ny funktionalitet än vi tidigare levererade på drygt tre år. Vi anställde inte ett större team och vi hittade ingen större budget. AI-assisterad mjukvaruutveckling tog helt enkelt bort den begränsning som format varje beslut vi någonsin tagit i en roadmap: en brist på människor och verktyg.

Det låter som goda nyheter, och det är det till största delen. Men det har blottlagt en ny begränsning, och den finns inte där jag förväntade mig att hitta den. När det inte längre är ont om byggande, är det implementeringen som blir flaskhalsen. Våra partner, de managed service providers (MSP) som levererar vår cybersäkerhetsplattform till sina kunder, kan inte ta emot ny funktionalitet i den takt vi nu kan producera den. Och två ytterligare frågor håller mig sysselsatt. Är mjukvara som byggs så här snabbt verkligen säker? Och skulle mer funktionalitet kunna urholka den enkelhet som alltid skilt oss från mängden?

## Vad förändras när byggandet inte längre är flaskhalsen?

Under större delen av Guardian360:s historia var vår roadmap en lista över saker vi ville bygga, rangordnade efter vad vi hade råd att bygga. Partner efterfrågade vissa funktioner i åratal, och många av dem fick vänta.

I dag arbetar våra utvecklare tillsammans med AI för kodgenerering, testning och dokumentation. Vi började med Claude, Anthropics modell, och flyttar i allt högre grad det arbetet till Hermes. Hermes är inte en modell utan ett lager som vi byggt själva. Det använder öppna stora språkmodeller för att driva det vi kallar en företagshjärna, och det möjliggör de AI-agenter som hjälper oss med ett brett spektrum av uppgifter. Hermes, och de öppna modeller det använder, körs i vårt eget servercluster i Nederländerna, och det är lika mycket en principfråga som en praktisk fråga. Claude har aldrig haft tillgång till kunddata på vår plattform, eftersom våra partneravtal inte tillåter att den datan lämnar EU. Att flytta mer av vårt arbete till infrastruktur vi själva kontrollerar följer samma logik.

Vi är långt ifrån ovanliga. Enligt Veracodes 2026 GenAI Code Security Report genererar AI nu ungefär hälften av all kod som committas. Frågan är inte längre om mjukvaruteam använder AI, utan vad som händer sedan.

## Är mjukvara byggd med AI verkligen säker?

Detta är den oro jag tar på störst allvar, och jag misstänker att det är den första frågan många läsare kommer att ställa. Forskningen ger föga anledning till lugn. Veracode fann att ungefär 44 procent av uppgifterna för AI-kodgenerering införde en riskfylld sårbarhet, med en genomsnittlig andel godkända säkerhetstester på 56 procent, knappt förändrat från 55 procent i deras första rapport. IOActives studie från april 2026 analyserade nästan 20 000 kodexempel och fann att 31,6 procent av de AI-genererade exemplen var fullt exploaterbara; ingen modell producerade helt säker utdata.

Det som oroar mig ännu mer är glappet mellan uppfattning och verklighet. Cloud Security Alliance rapporterar att över 75 procent av utvecklarna i en undersökning trodde att AI-genererad kod är säkrare än kod skriven av människor, medan 56 procent medgav att den ofta inför säkerhetsproblem. Snabbhet känns som kompetens. Det är det inte.

IOActives slutsats är att organisationer måste behandla AI-utdata som obetrodd indata och tillämpa obligatorisk säkerhetsgranskning före driftsättning. Det är precis så vi arbetar: AI får skriva koden, men varje förändring granskas av en person som förstår den innan den når produktion. Vi går nu ett steg längre genom att vända vår egen AI-pentestning mot oss själva, inklusive crystal box-analys av vår egen källkod, där testagenterna har full tillgång till koden. Vi kör den analysen med flera olika modeller, så att de blinda fläckarna hos en modell är mindre sannolika att gå obemärkta förbi.

Samma princip präglar den AI-pentestning vi tar till våra partner, där AI:n utför testet och partnerns konsult signerar det. Utvecklare tycks dela denna instinkt. I Stack Overflows Developer Survey 2026 sa nästan hälften av respondenterna att de litar på AI-utdata när de kan verifiera det, medan endast 6,6 procent skulle lita på AI med ett viktigt beslut.

## Varför betyder fler funktioner inte automatiskt mer värde?

Den andra oron är mindre teknisk men lika verklig. No Jitter beskrev nyligen en “feature flood” i kommunikationsmjukvara, där leverantörer släpper hundratals nya funktioner varje år medan användningen släpar efter. Pendos benchmarks tyder på att omkring 80 procent av de byggda funktionerna aldrig uppnår meningsfull användning, och att 6,4 procent av funktionerna genererar 80 procent av alla klick. Det mönstret existerade långt före AI. AI gör det bara billigare att upprepa.

Guardian360 har alltid försökt erbjuda en plattform som en MSP kan förklara för en styrelseledamot på några minuter. Varje funktion vi lägger till gör det svårare. Kostnaden för att bygga en funktion har kollapsat; kostnaden för att förstå den har det inte.

Våra partner bär redan på gott om komplexitet. Forskning av CRN, publicerad av säkerhetsleverantören Coro, fann att MSP hanterar mellan 6 och 20 eller fler leverantörer för att leverera säkerhetstjänster, betygsätter integrationen mellan de verktygen till bara 6,2 av 10, och att endast 7 procent är nöjda med avkastningen på sina säkerhetsverktyg. Det sista de behöver från oss är ännu ett lager av komplexitet, hur välment det än är.

## Vart har flaskhalsen flyttat?

Googles DORA-forskning erbjuder ett användbart perspektiv. Deras rapport från 2025 fann, för första gången, ett positivt samband mellan AI-användning och leveransgenomströmning, men AI-användning korrelerade fortfarande med lägre leveransstabilitet: fler förändringsfel, mer omarbete och längre återhämtning. DORA drog också slutsatsen att AI tenderar att spegla och förstärka befintliga organisatoriska egenskaper, på gott och ont.

Jag skulle vilja utvidga den observationen bortom utvecklingsteamet. En funktion skapar värde först när en partner förstår den, konfigurerar den, förklarar den för en kund och bygger en tjänst kring den. Den kedjan löper i mänsklig hastighet. AI accelererar den första länken och lämnar resten orörd, vilket innebär att kön helt enkelt flyttar nedströms, till våra partner och deras kunder.

Stack Overflows undersökning pekar i samma riktning: människor litar på det de kan verifiera. En partner som aldrig sett en funktion fungera kan inte verifiera den, kan inte förklara den och kommer inte att sälja den.

## Borde vi helt enkelt sakta ner?

Vissa partner skulle hävda precis det: stanna upp ett tag, stabilisera, låt oss komma ikapp. Det är ett rimligt argument och jag håller delvis med. En leverantör som släpper funktioner snabbare än dess kanal kan följa optimerar för sin egen tillfredsställelse, inte för sina partner.

Ändå skulle en konstlad inbromsning slösa bort en möjlighet som små europeiska leverantörer sällan får. Svaret, tror jag, är disciplin snarare än bromsning. Det innebär att besluta vad man inte ska leverera, att behandla enkelhet som ett designkrav snarare än en eftertanke, och att involvera partner innan en funktion är färdig snarare än efteråt.

En del av den disciplinen är inbyggd i själva plattformen. Vi inför workspaces: i stället för att presentera varje funktion på en skärm grupperar vi funktionalitet efter uppgift, så att en partner bara ser det som det aktuella arbetet kräver. Det AI-drivna gränssnittet tar detta vidare. Sidor, rapporter och navigering blir definitioner i stället för kod, och en agent bygger den vy en användare efterfrågar inom ramen för sin roll. Detta är inte längre ett koncept. Vi kommer att visa det i drift den 3 november, och vi vill ha ärlig återkoppling från våra partner om huruvida det faktiskt hjälper dem.

Det finns ett andra sätt att hålla komplexiteten nere: låt plattformen göra mer av arbetet. I dag berättar Lighthouse vad som skulle kunna förbättras. I framtiden kommer den också att åtgärda det, där partnern och dess kund tillåter det. Varje uppgift plattformen tar över är en uppgift en partner inte längre behöver lära sig, förklara eller planera in.

## Varför vi öppnar dörrarna till kontrollrummet

Guardian360:s logotyp innehåller en fyr, och metaforen har aldrig känts mer träffande. En fyr är bara användbar om dess ljus når stranden. Vi kan bygga världens starkaste ljus, men det är våra partner som bär det till sina kunder.

Därför är vi värd för [“En vy från kontrollrummet”](https://guardian360.net/sv/a-view-from-the-control-room/) tisdagen den 3 november 2026, klockan 09:30 till 13:00 på Van der Valk Hotel i Woerden. Vi kommer att visa vad vi har byggt, körandes live snarare än på slides, och ge en första inblick i vad Guardian360 levererar 2027. Deltagandet är kostnadsfritt, det finns plats för omkring 50 gäster, och anmälan är öppen till 30 oktober. Mer än demonstrationerna värdesätter jag samtalet. Jag hör hellre den 3 november att något är för komplext än upptäcker det i användningssiffror ett år senare.

## Så, vad är din begränsning nu?

Om byggandet inte längre är din begränsning heller, och för många MSP är det ögonblicket närmare än det verkar, vad är det då? För oss är svaret tydligt. När det inte längre är ont om byggande, är det implementeringen som är flaskhalsen. Det är där den svåra delen börjar, och det är ett arbete vi bara kan göra tillsammans med våra partner.

## Källor

- 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