Agentic engineering: varför mid-market i DACH har fastnat på steg ett

Vad är agentic engineering, och hur skiljer det sig från vibe coding?

Agentic engineering är en definierad utvecklingslivscykel i flera steg, driven av AI-agenter mot en befintlig produkt, med integrationer, riktig data, säkerhetsspärrar och tester. Vibe coding är snabb prototypning för icke-programmerare från ett blankt blad. Samma underliggande modeller. Helt olika discipliner.

Sammanblandningen av de två gör verklig skada. Team testar vibe coding på en tjugo år gammal kodbas, ser det gå sönder och drar slutsatsen att AI inte är moget. Verktyget var aldrig byggt för det jobbet.

En användbar tumregel: bygg din frontend i Lovable och koppla den till Shopifys kärna via API:et. Det är rätt arbetsfördelning. Vibe coding för ytan, agentic engineering för systemet under.

Varför medelstora bolag i DACH har fastnat på steg ett

Ursäkterna är förutsägbara. Vi är speciella. Vår kodbas är för komplex. Jag testade en gång och det funkade inte.

Den ärliga versionen ser annorlunda ut. Teamet är rädda att tappa kontrollen, rädda att agenten ska göra jobbet bättre än de gjorde, rädda för att behöva lära sig ett nytt verktyg från noll. Det är inte tekniska problem. Det är ledarskapsproblem.

Vi bygger benchmarkstudien AI Monitor 2026 tillsammans med ETH Zürich och universitetet i St. Gallen just för att "vi jobbar med AI" inte är en mognadsnivå. Bland medelstora bolag i DACH är mönstret detsamma: AI-mognad följer ledarskap och kultur, inte regelverk.

Varför flyttade flaskhalsen från utveckling till ledarskap?

I två decennier var utvecklingsteamet begränsningen i varje mjukvarubolag. Inte längre. När transformationen väl är klar är din enda verkliga gräns din tokenbudget. Innan den är klar är begränsningen ledarskap och product management.

Utvecklare är riskaverta av goda skäl. De har fått skulden för förseningar och underskattad komplexitet i åratal. Be dem bygga en funktion på vanligt sätt och de kan estimera den: en sprint, två veckor. Be dem bygga den med agenter och de kan inte ge dig den siffran, för de vet ännu inte hur agenten beter sig. Så de faller tillbaka på verktygen de litar på.

Det enda som bryter det mönstret är en vd eller R&D-chef som uttryckligen säger: det är okej att testa och okej att misslyckas, så länge man lär sig något. Utan det mandatet uppifrån händer ingenting.

Hur får du in agentic engineering i CFO:ns resultaträkning?

Två case, och en CFO känner igen båda. Kostnadscaset: samma output med färre personer, eller dubbel output med samma headcount, efter en transformationsperiod. Överlevnadscaset: börsnoterade mjukvarubolag byggda på ett enda smalt use case har straffats med värderingstapp i spannet 40 till 50 procent, för att de saknar svar på hur värde ser ut i en agentisk framtid.

Överlevnadscaset är det starkare. Det flyttar kostnaden från "innovationsbudget" till "att finnas kvar".

När vi skalade Aioma till 30 personer på sex månader var matematiken enkel: varje ny utvecklare var en linjär kostnad. Med en agentisk stack böjer sig den linjen. Det är den delen CFO:n faktiskt bryr sig om.

Bygget i tre steg efter att ledningen är ombord

När ledningen väl är ombord börjar det riktiga arbetet. Tre steg innan du sätter en enda agent i drift.

Extrahera kunskapen. Din produkt har vuxit i decennier. AI är redan bra på att läsa allt: koden, varje beroende, dokumentationen, Slack-historiken, Jira- och supportärendena. En del kunskap finns bara i seniora utvecklares huvuden, så låt dem prata igenom systemet, transkribera det och mata in det. Resultatet är en strukturerad kontexthubb, och den måste växa kontinuerligt. Utan den är agenten en briljant junior med minnesförlust varje morgon.

Kartlägg säkerhetsrisken. Angripare har också AI. Nya modeller blir bra på att hitta zero-day-sårbarheter som aldrig upptäckts tidigare. Innan du låter agenter ändra något vill du ha en tydlig säkerhetsöversikt, så att du vet vad som ska fixas först.

Bygg testsviten. Femtio enhetstester med fem procents täckning räcker inte. Du behöver en heltäckande end-to-end-svit, helst tusentals scenarier baserade på riktig användningsdata, kanske en digital tvilling av systemet. Agenter ändrar mycket, snabbt. Testerna är det som talar om att allt fortfarande fungerar.

Först efter de tre stegen sätter du din första agent i drift, och du börjar sekventiellt: en modul, ett API, en frontend. Inte överallt på en gång.

Det är arkitekturen Simon Scheurer och jag bygger in i Teklens: en kunskapshubb som läser in GitHub, Jira, Confluence, Slack, dokumentation och vilket API som helst i en sökbar graf, med en agent-runtime förankrad i den via RAG, och use cases (arbetsflödesassistenter, SaaS-modernisering, due diligence-paket) byggda ovanpå. Poängen med diagrammet är att du inte börjar i use caset. Du börjar i hubben.

Varför agentic engineering är ett GTM-problem, inte bara ett R&D-problem

Det här är delen de flesta bolagsbyggare missar. Agentic engineering är inte bara en utvecklingshistoria. Det är en intäktshistoria.

Släpper du en version om året får du ett försök om året att hitta product-market fit i produktens agentiska lager. En konkurrent som släpper månadsvis får tolv. De itererar förbi dig tills du är irrelevant. Hela poängen med transformationen är att pressa ihop den loopen, så att du kan testa positionering och värde snabbt nog för att det ska spela roll.

Själva värdeerbjudandet måste också ändras. Kunder vill inte längre ha mjukvara där de matar in data och får en rapport tillbaka. De vill ha utfall och färdiga arbetsflöden. Det är ett ompositioneringsproblem, och ompositionering är ett GTM-jobb, inte ett utvecklingsjobb.

Den interna komprimeringen spelar också roll. När supporten skickar eskaleringar direkt till en agent, när product management prioriterar 50 punkter i stället för att sålla ner till 5, snabbas hela intäktsmotorn upp. Slimmade agentiska produktteam ändrar din unit economics, och unit economics ändrar hur du säljer. Se Revenue Systems & GTM Engineering för det längre resonemanget.

Var går agentic engineering sönder?

Tre sätt att misslyckas, i frekvensordning.

Talangbristen. Kompetensen är ny för alla, så det finns ingen djup pool att rekrytera ur. Antingen tar du in någon med riktig erfarenhet, eller så accepterar du en lång intern inlärningskurva. Det finns ingen genväg.

Fantasin om en enda prompt. "Claude code, fixa det" på en kodbas med tjugo miljoner rader kommer att misslyckas, och teamet kommer att skylla på tekniken i stället för på upplägget. Förväntan måste vara en process i flera steg med iteration, inte ett magiskt kommando.

Fällan "kan jag inte bara köpa det". Det vanligaste misslyckandet jag ser: bolag som vill köpa agentic engineering som en licens och sedan glömma bort det. Så fungerar det inte. Det tränas, det köps inte. Daglig förbättring, som en teammedlem.

Skiftet i huvudet, från vd och nedåt

Sluta skruva fast AI på din produkt som en lista med use cases. Bygg operativsystemet under: kontext, säkerhet, tester. Släpp sedan loss agenterna.

Skiftet går från vd:n som behöver lära sig vibe coding, via R&D-chefen som behöver bli övertygad om att det fungerar, ner till utvecklaren som tar till sig nya verktyg och accepterar daglig förändring. Finns inte det skiftet, misslyckas det.

Tåget har lämnat stationen. Bussen går fortfarande.

Vill du ha veckoversionen av det här? Prenumerera på nyhetsbrevet The Science of GTM för genomgången av hur produkt, GTM och AI fungerar som ett system. Eller ställ dig på väntelistan till AI GTM Lab-kohorten om du vill ha playbooken live.

FAQ

Vad är agentic engineering?

Agentic engineering är en definierad utvecklingslivscykel i flera steg, driven av AI-agenter mot en befintlig produkt, med integrationer, riktig data, säkerhetsspärrar och tester. Det skiljer sig från vibe coding, som är snabb prototypning för icke-programmerare från ett blankt blad.

Är GDPR det största hindret för AI-införande bland medelstora bolag i DACH?

Nej. Både erfarenheten från fältet och benchmarkstudien AI Monitor pekar på ledarskap, kommunikation och kultur som de främsta hindren. Regelverk är en lösbar begränsning. Det svårare problemet är att få ledningens engagemang och övervinna utvecklarnas riskaversion.

Var börjar du med agentic engineering i ett befintligt mjukvarubolag?

Steg ett är att få ledningen ombord, med budget för verktyg och coachning och uttryckligt tillstånd att misslyckas. Därefter följer utvecklingsarbetet tre steg: extrahera kodbasens kunskap till en kontexthubb, kartlägg säkerhetsrisken och bygg en heltäckande testsvit. Först då sätter du din första agent i drift, en modul i taget.

Varför spelar agentic engineering roll för go-to-market, inte bara för utveckling?

För att det ändrar releasetakt, värdeerbjudande och unit economics. Snabbare iteration låter dig testa positionering före konkurrenterna. Kundernas förväntningar skiftar från mjukvara du sköter själv till levererade utfall. Slimmade agentiska team ändrar hur du säljer.

Kan du köpa en färdig agentic engineering-lösning från hyllan?

Nej. Agentic engineering måste tränas och anpassas till din produkt, din kodbas och din process, och sedan förbättras kontinuerligt. Att behandla det som ett engångsköp är det vanligaste skälet till att transformationer misslyckas.