If you’ve poked around enough GitHub orgs or inherited enough infrastructure, you’ve probably noticed the same thing I have. There’s no single “right” way to do Infrastructure-as-Code (IaC). Best practices exist, but in the real world they tend to blur into a spectrum. You’ll find everything from beautifully organized setups to scripts held together with comments and good intentions. Each of these approaches reflects hard-won lessons—how teams navigate compliance needs, move fast without breaking things, or deal with whatever org chart they’re living under.
Over time, I started naming the patterns I kept running into. Giving things a name makes it easier to talk about them, both with teammates and with AI agents. When you name a pattern, you don’t have to re-explain the trade-offs every time. You can say “Forked Helm Chart” and people understand what you’re optimizing for. You don’t need a ten-slide deck.
Some patterns show up over and over again. Forked Helm Chart, for example, is a favorite in highly regulated environments. It gives you an auditable, stable base, but you’re on the hook for handling upgrades manually. Kustomize Base + Overlay keeps everything in plain YAML and is great for patching different environments without dealing with templating logic. GitOps Monorepo gives you a single place to understand the entire fleet, which makes onboarding easier. Of course, once that repo hits a certain size, it starts to slow you down.
There are plenty more worth knowing: Helm Umbrella Charts, Polyrepo setups, Argo App-of-Apps, Programmatic IaC with tools like Pulumi or CDK, Micro-Stacks that isolate each component, packaging infrastructure with Kubernetes Operators, and Crossplane Composition that abstracts cloud resources through CRDs. If nothing else, consider this a field guide you can pass along to a new teammate—or to whatever AI agent joins your team next quarter.
Each of these patterns is a balancing act. Forking a chart gives you stability but slows down upgrades. Using a polyrepo lets you assign fine-grained access controls, but you lose the convenience of atomic pull requests. Writing your IaC in a real programming language gives you reusable modules, but it’s no longer just YAML that everyone can follow. Once you start recognizing these trade-offs, you can often see where a codebase is going to get brittle—before it becomes a late-night incident.
And that brings us to where things are headed. AI is already moving beyond just making suggestions. We’re starting to see agents that open pull requests, refactor entire environments, or even manage deploys. In that world, unclear folder structures or vague naming conventions become real blockers. It’s not just about human readability anymore. A consistent layout, good metadata, and a clear naming scheme become tools that machines use to make safe decisions. Whether to fork a chart or just bump a version number can hinge on something as simple as a well-named directory.
The teams that start building with this mindset today will have a real edge. When automation is smart enough to do real work, your infrastructure needs to be legible not just to other engineers, but to the systems that will help you run it. That’s how you get to a world where your infrastructure fixes itself at 2am and nobody needs to do archaeology the next morning.
