Det AI inte kan ta ansvar för

AI kan skriva din deployment-pipeline på några sekunder.

Men den kan inte förklara, klockan två på natten, varför plattformen ligger nere.

Det är det ingen pratar om. AI har inte tagit bort människorna från DevOps – den har tagit bort spårbarheten. Förut, när en utvecklare skrev ett dåligt skript för hand, gick det att spåra vem som gjort vad: en kodgranskning, en Slack-tråd man kunde bläddra tillbaka i.

När AI genererar pipelinen kan till och med ett starkt team hamna i ett märkligt läge: alla granskade den, alla litade på processen – och ändå faller ägarskapet för just det beslutet mellan stolarna. Inte för att någon slarvade, utan för att verktygen förändrades snabbare än de arbetssätt som är byggda för att fördela ansvar. 

Ärligt talat: om en deployment tar ner produktionen kan du inte sätta en AI-modell på en handlingsplan för att förbättra prestationen. Du kan inte ha det svåra samtalet med en språkmodell. Ansvaret måste ligga hos någon med en puls.

Och det är egentligen risken med AI i infrastrukturen. Det är inte att verktygen är opålitliga. Det är att de är flytande och opålitliga på samma gång, vilket är betydligt farligare än ett system som flaggar "jag är inte helt säker på det här."

De bästa DevOps- och DevSecOps-ingenjörerna hittar inte problem genom att läsa varenda loggrad. De känner på magkänsla att något är fel med en deploy – en känsla som byggts upp genom åratal av att se system krascha på konstiga, oglamorösa sätt. AI har ingen erfarenhet av det. Den har aldrig blivit väckt av ett panikartat samtal klockan två på natten

Så nej, AI har inte gjort dessa roller mindre viktiga.

Den har gjort on-call-ingenjören till sista utposten mot beslut som systemet tog, men som ingen människa faktiskt tog.

Om ditt team skalar snabbt och lutar sig hårdare mot AI för att röra sig fortare, kan det vara värt att fråga: vem äger egentligen deploymenten när något går fel? Om svaret inte är uppenbart, hör av dig