AI en Infrastructure Engineering

De vraag die hieraan verbonden is, is de voor de hand liggende: maakt dit engineering overbodig? Zodra alle context over een stack en de bijbehorende infrastructuur ergens is opgeschreven waar een agent het kan lezen, zijn wij dan aan de beurt?

Ik denk niet dat dit precies de juiste vraag is, omdat we al een versie hiervan hebben meegemaakt.

We zijn hier eerder geweest

Heeft Kubernetes Ansible gedood? In zekere zin wel. Ik heb in jaren geen Ansible-playbook meer geschreven — als je me er nu een zou geven, zou ik turen naar de modulesyntaxis alsof ik het nog nooit gezien had — niet omdat configuratiemanagement stopte met belangrijk zijn, maar omdat Kubernetes serverbeheer eenvoudig genoeg maakte dat we stopten met het bouwen van onze eigen node-images. We gebruiken gewoon wat de cloudprovider ons aanbiedt, een AWS AMI die voor ons is gebouwd, zonder vragen te stellen.

En wanneer ben ik voor het laatst via SSH inloggen op een node om iets te debuggen? Vrijwel nooit. Als een node kuren vertoont, kill ik hem en hoop ik dat de vervanging niet hetzelfde probleem heeft. De laag daarboven ging hetzelfde pad: als ik een container draai op ECS Fargate, in een Lambda, of op Cloudflare Containers, dan weet of interesseer ik me er oprecht niet om op welke node deze is geland. Maar dat betekent niet dat er niemand is die het orkestreert; het betekent dat ik nog steeds heb besloten dat deze workload een container moest zijn, welk image er draait, met wie het mag communiceren, hoe het schaalt en wat er gebeurt als het faalt.

Kubernetes en serverless containers hebben die laag van beslissingen niet verwijderd; ze hebben de eenheid van werk verplaatst van "de machine" naar "de workload", en alles onder die laag is stilzwijgend geautomatiseerd.

Niemand zou zeggen dat Kubernetes, of Fargate, of het containerplatform van Cloudflare, infrastructure engineers heeft vervangen. Elk van hen verving een specifieke laag van handmatig werk — het handmatig bouwen van images, het handmatig patchen van boxen, weten op welke node een workload landde — en de engineers bewogen elke keer mee naar de laag daarboven. Ik denk dat AI hetzelfde doet, maar dan één laag hoger.

Wat er dagelijks is veranderd

Ik gebruik Claude dagelijks om Helm-charts te genereren en Terraform-modules te schrijven. Het deel dat het daadwerkelijk uit mijn dag heeft verwijderd, is niet het denken, maar het zoekwerk. Ik lees niet langer door de changelog van de AWS-provider om uit te zoeken wat er is veranderd tussen v5 en v6; ik beschrijf wat ik wil, in welke vorm ik de module of chart wil hebben, en Claude produceert een versie ervan. Het vereist iteratie om het in de vorm te krijgen die ik daadwerkelijk zou implementeren, maar zodra het daar is, wordt het het voorbeeld voor de volgende keer — zeker met een AGENTS.md in de repo die ernaar verwijst.

Hetzelfde gebeurde een tijd geleden één niveau lager: ik schrijf niet meer handmatig ruwe Kubernetes YAML, net zoals ik geen Ansible-modules meer handmatig schrijf — daar zijn Helm-charts voor. In toenemende mate schrijf ik de Helm-chart zelf ook niet meer. Ik geef de richting van wat het moet doen, en Claude schrijft het.

Wat er niet is veranderd

Ik moet nog steeds weten hoe een goede Terraform-module of een goed gestructureerde Helm-chart eruitziet. Ik moet nog steeds in staat zijn om via SSH in te loggen op een node wanneer er echt iets misgaat en het killen van de pod geen optie is — de bovenliggende laag verwijdert de onderliggende laag niet, het verandert alleen hoe vaak je die moet aanraken.

En ik ben nog steeds degene die de uiteindelijke vorm van de zaken bepaalt: hoe de definitieve versie van een module eruitziet, wat over een jaar nog onderhoudbaar is, en hoe een chart moet worden uitgerold en geversioneerd. AI doet het tijdrovende werk. Ik geef nog steeds de richting.

De vaardigheid die je inruilt

De eerlijke afweging is dit: ik ben sneller in het bouwen en debuggen van zaken dan twee jaar geleden, maar ik ben ook zichtbaar roestiger in de fundamenten onder die snelheid. Mijn herinnering voor HCL-syntaxis is niet meer wat hij was. Vier jaar geleden schreef ik handmatig een geneste for-loop — vier niveaus diep, waarbij subnets over regio's en availability zones in een ander AWS-account werden getagd — en het kostte me ongeveer een uur om de syntaxis correct te krijgen:

locals {
  subnet_tags = merge([
    for account, regions in var.accounts : merge([
      for region, azs in regions : merge([
        for az, subnets in azs : {
          for subnet_id, tags in subnets :
          "${account}/${region}/${az}/${subnet_id}" => tags
        }
      ]...)
    ]...)
  ]...)
}

Vier merge([...]...) aanroepen gestapeld op elkaar, alleen maar om een map van een map van een map van subnets af te vlakken. Claude schrijft het equivalent nu in enkele seconden, en als je me vandaag zou vragen om dat vanaf nul te produceren, zou ik er oprecht over na moeten denken. Mijn reflexen voor het debuggen van een kapotte node via SSH zijn iets trager dan toen dat de enige manier was die ik kende. Dat is geen hypothetische kost — het is iets wat ik in real-time voel gebeuren, op dezelfde manier als veel engineers die na Kubernetes zijn ingestroomd nooit echt hebben geleerd hoe ze handmatig een server-image moesten maken, en daar prima mee zijn, omdat ze dat nooit nodig hadden.

Waar dit naartoe gaat

Waar ik minder zeker over ben, is hoe lang "ik geef nog steeds de richting" standhoudt. Op dit moment ben ik degene die de langetermijnvorm van een stack bepaalt, omdat ik de context heb en de agent dat niet heeft — althans, niet verder dan wat is opgeschreven in de AGENTS.md van een repo.

Maar dat is precies het gat dat die bedrijfbrede AI-initiatieven proberen te dichten: geef de agent de volledige context, niet alleen die van één repo. Als dat daadwerkelijk werkt, zou een agent met een echt langetermijnoverzicht van de gehele infrastructuur — niet alleen deze Terraform-module, maar elke beslissing die jarenlang in elke repo is genomen — uiteindelijk beter kunnen plannen dan ik, op dezelfde manier als ik een tool niet kan verslaan die elke changelog van elke provider die ik gebruik heeft gelezen.

Kubernetes verving infrastructure engineers niet; het verving een laag van hun werk en tilde hen één niveau omhoog. Ik denk niet dat AI engineering vervangt. Ik denk dat het nog steeds bezig is met het opeten van de laag net onder "richting geven" — en ik ben er niet volledig van overtuigd dat dat de laatste laag is die het opeet.