Hey folks, been deep in the terraform weeds this week trying to wrangle a multi-account AWS setup with Terragrunt, and the age-old problem of scattered context across different ChatGPT conversations hit me *again*. I was explaining a root module's variable validation to a colleague in one chat, while debugging a weird `for_each` error with a provider quirk in another. Total context fragmentation.
So, OpenAI's new "project" feature feels like it was built for us—the infrastructure-as-code tinkerers who live in sprawling, interconnected systems. The core idea seems to be a persistent, shared context container that you can keep feeding files and conversations into. This isn't just a longer thread; it's a dedicated workspace.
Think about it like a Terraform state file for your AI interactions. Instead of:
* Losing the precise explanation of your custom module's `outputs` structure.
* Re-uploading your `variables.tf` and `main.tf` for the tenth time to ask a new question.
* Manually summarizing past solutions when a new, related error pops up days later.
You could have a "Project" for your entire `infrastructure-live` repository. You'd seed it once with your core module schemas, your Terragrunt `terragrunt.hcl` hierarchy, and key provider docs. Then, every subsequent chat—whether it's about IAM policies, S3 bucket configs, or troubleshooting a `terraform import`—draws from that shared foundation.
My immediate experimental questions are:
* How does it handle versioned files? If I update my `versions.tf` from provider `~> 4.0` to `~> 5.0`, does the project context understand the diff, or just see the new file?
* Is there a practical limit to the "active" context it can reference from the project during a single chat? Our `main.tf` files can be huge.
* Can you "tag" or structure content inside a project? For example, segmenting it into `modules/`, `envs/prod/`, `docs/` would be a game-changer.
I'm cautiously optimistic. If this works as hinted, my workflow could shift from:
```bash
# Old: Start a new chat, upload relevant .tf files, re-explain the surrounding setup.
```
To:
```bash
# New: Open the "Platform VPC Project" and just ask: "Why is this `aws_vpc_endpoint` resource causing a cycle error given the attached route tables I've shown before?"
```
The potential for maintaining continuity on complex, stateful infrastructure discussions is huge. Has anyone gotten early access to play with this? I'm particularly curious about its behavior with structured configs like HCL or YAML—does it "understand" the hierarchy better than a plain text dump?
That Terraform state file analogy is spot on. It made me think about the difference between seeding a project with static code versus feeding it ongoing operational logs.
If you're integrating this into a CI/CD pipeline, how do you handle the 'state drift' problem? The AI's context in the project could become outdated if someone merges a PR that changes a module's interface, but the project still has the old schema cached. You'd need a strategy for context refreshes, maybe triggered by a `terraform plan` diff.
Mike D.
> Think about it like a Terraform state file for your AI interactions.
That's the perfect way to frame it. Seeding a project with your entire `infrastructure-live` repo is the dream. I can see it now - you could feed it the Terragrunt `terragrunt.hcl` inheritance chain once, and then every question about why a variable isn't propagating from the root would actually have the context.
The big win for me would be for provider-specific quirks. You could dump a dozen AWS provider docs into the project once, then when you get that weird "IAM role assumption loop" error in a child account, the AI has the full backdrop instead of you pasting the same error log into a fresh, clueless chat.
But I wonder about the token cost of that initial seed. Uploading a whole monorepo's worth of HCL could get expensive fast.
Prompt engineering is the new debugging.
You're right about the token cost, but I think the bigger issue is project *invalidation*. If you seed it with a whole repo and then `git pull`, does the project know which files changed? Probably not.
We might need to treat these like Docker layers - you start with a base project (core modules, provider docs) and then apply diffs. But I don't think the API exposes that yet. So you're stuck re-uploading everything or living with stale context.
My sandbox is bigger than yours.
You're focusing on a core automation problem. If you treat the project context as static, you're just building a new kind of tech debt.
The real use case is hooking it into your pipeline. A commit hash changes, a script diffs the repo, and updates the project context via the API. Without that, the feature is useless for active development. It's another manual step to forget.
Beep boop. Show me the data.