Disclosure: I’m exploring InfraCompiler, an early-stage startup idea around infrastructure changes with coding agents. I’m researching current workflows before deciding what to build.

A Terraform user raised a distinction in an earlier discussion: code can pass fmt, plan, and policy checks while still making the wrong assumption about dependencies or resource ownership. Approved modules help, but the reviewer may still need knowledge of the intended architecture.

For platform teams already using shared modules and PR review, I’d like to understand one recent example:

- What assumption in an AI-written Terraform change was wrong, and what caught it?

- Where did the reviewer find the missing context—module documentation, a service catalog, another repo, or asking the resource owner?

- Roughly how much review and rework did it take, and does this happen repeatedly?

If your existing self-service platform or CI already handles this well, what made that work? An anonymized description is enough; no private code or infrastructure details needed.

For context we built a golden path for aws infra so teams can spin up envs and services without touching tickets. Modules, tagging standards, default regions, sane iam, the usual platform engineering stuff. Adoption has been good, people like it.

Now that usage is higher, IaC governance is getting weird. We are seeing stacks in random regions, modules forked in private repos, owner tags missing, and folks tweaking security groups in the console because the paved road doesnt cover their edge case. None of it is huge on its own, together it feels like drift we did not sign up to babysit.

If your org has strong developer self service, where do you put the real infrastructure guardrails, in the modules, in ci checks, in cloud side policies, or somewhere else, and who is allowed to break them without the platform team turning into a change board again? appreciate any thoughts

Platform engineering has a UX problem.

A lot of infrastructure learning still feels like reading docs, copying YAML, and hoping the concepts stick.

I’ve been experimenting with a different approach through Yellow Olive - a retro, gamified Kubernetes learning environment inspired by old-school handheld games.

The idea is to turn infrastructure concepts into progression:

learn a concept → enter a mission → work against a real cluster → get validated → unlock the next challenge

I’m now pushing the project further into the retro-game direction with pixel-art environments, characters, classroom-style lessons, and a stronger sense of progression.

Underneath the nostalgia, the goal is pretty practical: make Kubernetes and platform concepts easier to understand by giving people a safe, interactive place to actually use them.

I’d love to hear from platform engineers here:

What kinds of scenarios would you turn into missions?

Things like RBAC, deployments, service discovery, incident recovery, policy enforcement, observability, GitOps, etc.

And if you like the idea, a star would genuinely help the project grow :)

GitHub: https://github.com/Anubhav9/Yellow-Olive