Därför misslyckas AI med infrastrukturbeslut (och vad du bör göra åt det)

Alla har hört det: låt AI:n skriva koden. Och visst, för vanlig applogik funkar det ofta bra. Route handlers, databasanrop och hjälpklasser är områden där stora språkmodeller verkligen levererar. Men det finns en blind fläck som sällan diskuteras.

Så fort du ger AI:n en Terraform-fil går det snett.

Infrastrukturens kontextproblem

AI-modeller hanterar syntax utan problem. De kan generera giltig HCL hela dagen. Felet ligger inte i koden – utan i resonemanget bakom den.

Ta ett vanligt scenario: du ber AI:n lägga till en ny event i ditt meddelandesystem. Kanske ett order-created-event som ska skickas via SNS och hamna i en SQS-kö. Modellen spottar ut:

• SNS topic
• SQS-kö med dead-letter queue
• Prenumeration på topic
• IAM-policy för tjänsten som publicerar

Ser rätt ut? Problemet är att alla värden och begränsningar i konfigurationen är rena gissningar. Ska visibility timeout vara 60 eller 600 sekunder? Ska IAM-policyn peka på en specifik bucket eller använda wildcards? Hur länge ska meddelanden sparas?

Modellen väljer värden som "verkar rimliga" utifrån träningsdata – utan att veta något om er last, era rutiner eller incidenten förra kvartalet där en felaktig replay window ställde till det.

Granskningen blir tyngre, inte lättare

Det som verkligen gör ont är att kodgranskningen inte minskar. Den växer.

Att läsa igenom applogik är oftast hanterbart. Du kollar logik, testar kantfall och kanske tittar på säkerhet. Men när infrastrukturen genereras automatiskt blir granskningen en helt annan sak. Nu måste någon jämföra:

• HCL mot AWS IAM-regler
• Nya resurser mot befintlig pipeline-arkitektur
• Oskrivna teamkonventioner
• Om rätt roller ens finns i kontot

Granskaren blir en mänsklig kompilator som bär all kontext AI:n saknar. Och när något går fel – fel timeout, fel scope, fel retention – är det din pager som tjuter klockan tre på natten.

Problemet sitter i separationen

Det här är inte ett verktygsproblem. Du kan lägga på moduler, kataloger och validerare hur mycket du vill – gapet består ändå. Orsaken är arkitekturen.

Applikationskod och infrastrukturskod lever i olika repos med olika granskningscykler. AI:n fattar infrastrukturbeslut utan tillgång till den applogik som faktiskt ska använda resurserna. Kontexten som behövs finns helt enkelt inte i filen som redigeras.

Mer verktyg löser inte det.

Bättre: infrastruktur som del av kompileringen

Tänk om infrastrukturen inte var ett separat lager alls?

Istället för att skriva kod som indirekt antyder vad som behövs, deklarerar du infrastrukturen direkt i den typade applikationskoden. Ramverket tar hand om resten – provisionering, IAM-regler, dead-letter-köer och prenumerationer – baserat på vad koden faktiskt kräver.

En pub/sub-topic kan då se ut så här:

export const orderCreated = new Topic<OrderCreatedEvent>("order-created", {
  deliveryGuarantee: "at-least-once",
});

Ingen separat HCL-fil. Ingen manuell IAM-granskning. Inga gissade timeout-värden. Ramverket vet exakt vad topicet behöver eftersom det ser hur koden använder det. De riskfyllda besluten flyttas från "något AI:n gissade sig fram till" till "något ramverket beräknade deterministiskt utifrån typer."

Din PR blir ett enda TypeScript-diff i stället för kod plus femtio rader Terraform plus policyer som någon måste dubbelkolla.

Därför spelar det roll för "vibe coding"

Det är därför "vibe coding" av infrastruktur kräver en annan arkitektur än vanlig applikationskod. Du kan tryggt låta AI:n hantera applogik när koden är typad, testad och isolerad. Men infrastrukturbeslut kräver sammanhang som finns någon annanstans i systemet.

Lösningen är inte bättre prompts eller smartare verktyg. Det är att ta bort gränsen mellan applikation och infrastruktur helt. När ramverket genererar infrastrukturen från applikationskoden istället för bredvid den, flyttas de farliga besluten bort från både AI-agenter och sömnlösa kodgranskare.

Då kan du faktiskt vibe codea infrastruktur med gott samvete.