Waarom AI tekortschiet bij infrastructuurkeuzes (en hoe je dat oplost)

Je hebt het vast al gehoord: laat AI je code schrijven. Voor applicatielogica werkt dat verrassend goed. Route handlers, queries en helper-functies zijn precies het soort werk waar taalmodellen in uitblinken. Maar er is één gebied waar ze structureel de mist in gaan.

Zodra je een AI een Terraform-bestand laat aanpassen, klopt er niets meer.

De context ontbreekt

AI kan prima geldige HCL schrijven. Dat is niet het probleem. Het probleem is dat het model geen idee heeft waarom bepaalde keuzes gemaakt worden.

Stel je vraagt een agent om een nieuw event toe te voegen aan je messaging-systeem. De output ziet er netjes uit: een SNS-topic, een SQS-queue met dead-letter queue, de juiste IAM-regels. Maar de concrete waarden — visibility timeout, message retention, scope van de policies — zijn puur geraden. Het model heeft geen zicht op je workload, incidentgeschiedenis of interne afspraken.

Review wordt zwaarder, niet lichter

Ironisch genoeg verdwijnt de reviewdruk niet. Die wordt juist groter. Bij applicatiecode controleer je logica en edge cases. Bij infrastructuur moet je ook nog controleren of de voorgestelde resources passen binnen bestaande pipelines, of IAM-beleid niet te breed is, en of teamconventies worden gevolgd die nergens zijn vastgelegd.

De reviewer wordt een menselijke compiler. En als er iets misgaat — een verkeerde timeout, een te brede policy — gaat ’s nachts de pager af.

Applicatie en infrastructuur leven gescheiden

De kern van het probleem is architecturaal. Applicatiecode en infrastructuurcode staan in verschillende repositories met eigen reviewcycli. De AI neemt infrastructuur-beslissingen zonder toegang tot de applicatielogica die die infrastructuur moet ondersteunen.

Extra modules of validators lossen dat niet op. Die voegen alleen meer lagen toe aan een gebroken systeem.

Infrastructuur als compile-time concern

Wat als infrastructuur geen apart iets meer is?

Stel dat je in je getypeerde applicatiecode direct aangeeft wat er nodig is. Een framework vertaalt dat automatisch naar de juiste resources, policies en queues. In plaats van losse Terraform-bestanden schrijf je iets als:

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

Het framework ziet exact hoe het topic wordt gebruikt en berekent de juiste configuratie. Geen handmatige IAM-controle meer. Geen losse HCL-diff in je PR.

Wat dit betekent voor vibe coding

Vibe coding werkt alleen als de code typed, getest en geïsoleerd is. Bij infrastructuur is dat zelden het geval, omdat de benodigde context elders ligt. De oplossing is niet een betere prompt, maar het weghalen van de scheiding tussen applicatie en infrastructuur. Pas als je framework infrastructuur compileert op basis van je applicatiecode, kun je die beslissingen met vertrouwen aan AI overlaten.