Why Every Platform Team Shouldn't Build Their AI Standards From Scratch

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3897065) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Luigi Di Fraia Posted on Apr 28 Why Every Platform Team Shouldn't Build Their AI Standards From Scratch #agents #ai #automation #devops This is Part 0 of a series on building agentic AI workflows for platform engineering. Part 1 jumped straight into the practical how-to: your first steering file, the workspace structure, getting started with Terraform. This article takes a step back to ask a broader question: why is every team building this from scratch? Something odd is happening across the industry right now. Thousands of platform engineering teams are independently discovering the same thing: AI coding assistants are competent at the language level but ignorant at the team level. They know Terraform syntax but not your Terraform conventions. They know Kubernetes but not your Kubernetes workflow. They'll generate a perfectly valid IAM policy using jsonencode() when your team exclusively uses data.aws_iam_policy_document. They'll suggest kubectl apply when your team is GitOps-first and everything goes through ArgoCD. The fix is straightforward. You encode your standards into files that AI agents read automatically: steering files, skills, agent definitions, so every conversation starts with your team's conventions already loaded. I'll cover the mechanics in detail later in this series. But here's the question nobody seems to be asking: why is every team writing these from scratch? The Terraform Module Problem, Again We've been here before. Before the Terraform Registry existed, every team wrote their own VPC module. Most of them were 80% identical: the same subnets, the same route tables, the same NAT gateway pattern, with 20% of team-specific customisation on top. The Terraform Registry didn't eliminate custom modules. It eliminated the redundant 80%. Teams could start from a community module and customise the rest. AI workspace configurations have the same problem today. Every platform team that adopts agentic AI tooling starts from zero: "Always use data.aws_iam_policy_document", discovered independently by every AWS/Terraform team "Conventional commits with semantic release", written into a steering file by every team that uses them "No 0.0.0.0/0 ingress unless documented", encoded as a rule by every security-conscious team "Pin provider versions, pin Terraform versions", rediscovered after the first breaking upgrade This is collective knowledge being individually rediscovered. It's wasteful, and it's solvable. A Layered Model for Shared Standards The solution looks like what already works for linting, CI templates, and infrastructure modules: composable, shareable, layered configuration. Layer 1: Industry baseline. Universal best practices that are true regardless of your organisation. AWS Well-Architected principles as steering rules. CIS Benchmarks as security baselines. Terraform style conventions. Git hygiene. These should be published, versioned, and consumable, not rediscovered by every team. Layer 2: Organisation standards. Your company's specific opinions layered on top: naming conventions, tagging standards, provider version pins, CI template references, security baselines. Shared across teams within the…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.