It starts with a simple question about a single Terraform variable. Soon, you're chasing configurations across dozens of browser tabs and scattered IDE folders, desperately trying to understand the reality of your infrastructure. You are flying blind in the 'Multi-Repo Verse,' and just when you think you've found a lifeline, you realize your AI copilot is confidently feeding you the wrong information.
Making Invisible Infrastructure Visible series introduction
This post is Part 1 of the "Making Invisible Infrastructure Visible" series. Over the next four posts, I will explore the complexity of managing large single or multi-repo Terraform coded infrastructure, the limitations of current tooling, and how I built Infra-Graph, a local-first, AI-powered mapping tool, to bridge the gap between static code and its hidden semantic meaning. If you manage Terraform across multiple repositories, this series is for you.
Navigating the Fog of Code
We’ve all been there. You open your IDE to make what should be a straightforward change: perhaps adjusting an ingress rule on an AWS Security Group. But in modern infrastructure, nothing exists in isolation.
You find the resource block, but the security group ID is passed as a variable. You follow the variable to a terraform.tfvars file, only to realize the actual value is sourced from a remote state data block defined in an entirely different repository. This is the reality of the "Multi-Repo Verse." It’s an architectural pattern designed to enforce boundaries, but the operational reality is a labyrinth.
Within ten minutes, your screen is an overwhelming mosaic of browser tabs, GitHub search results, and overlapping VS Code workspaces. This phenomenon isn't just "context switching", it's Tab Fatigue. It’s the mental exhaustion of trying to hold an entire, fragmented infrastructure state in your short-term memory. And beneath that exhaustion lies a deeper professional anxiety: the fear of the "Butterfly Effect."
Every time you type terraform apply, you brace yourself. If I change this output here, what downstream service in another repository am I going to break? The check-in culture has given us version control, but it has hidden the semantic reality of our infrastructure behind walls of distributed text files. You are an architect, expected to design resilient systems, but on a daily basis, you are flying blind.
So, you do what any modern developer does: you reach for an AI copilot. You paste snippets of your .tf files into the prompt, or maybe you even rely on an advanced copilot with repository-wide visibility, asking, "Is it safe to remove port 80?"
The AI responds immediately, with perfect grammar and absolute confidence. It explains why the change is safe, analyzing the code it has access to. For a brief second, you feel relief.
Then comes the Reality Check.
You realize the AI didn't, couldn't, know about the undocumented legacy load balancer defined in a separate AWS account's repository that relies on that exact port. The AI wasn't helping; it was hallucinating. It was telling you a beautiful, dangerous lie because it lacked the one thing that matters in infrastructure: grounded truth.
LLMs are powerful reasoning engines, but when fed fragmented text files, they are just creative guessers.
"They understand syntax, but they don't understand meaning."
They don't know that an open port implicitly connects two disparate resources.
That was the turning point. I realized that if I wanted to stop flying blind, and if I wanted to actually harness AI without the risk of taking down production, I didn't need a better prompt. I needed a better map. I needed a way to ground the AI, and myself, in the actual reality of the infrastructure.
In short, I needed a semantic map. In the next post, I will show you exactly what that map looks like and why it changes everything.
Next up in Part 2: how I mapped the terraform infrastructure territory, or so I thought...
Top comments (0)