About the Author
Why I Built This
Plan Forge came from frustration — my own.
I've spent my career as a software architect. First building enterprise systems, then helping teams at Microsoft build them on Azure. I know what good architecture looks like: clean layers, clear boundaries, every component with a purpose. Lasagna, not spaghetti.
When AI coding agents arrived, I was excited. Here was a tool that could generate code faster than any team I'd ever managed. But the excitement wore off fast. The agents were brilliant at greenfield work — scaffolding, boilerplate, CRUD endpoints — but they had no concept of architectural discipline. They made decisions I didn't ask for, expanded scope without warning, and produced code that compiled but couldn't be maintained.
Sound familiar? If you've hit the 80/20 wall, you know exactly what I mean.
I realized the problem wasn't the models. The models were capable. The problem was that nobody was giving them structure. No scope contracts. No validation gates. No separation between building and reviewing. We'd spent decades learning that human dev teams need guardrails, code reviews, and architectural governance — then handed AI agents a blank prompt and said "build me an app."
So I started writing those guardrails. First as instruction files I pasted into Copilot chats. Then as structured prompts. Then as a pipeline with sessions and validation gates. Then as a full framework with agents, skills, lifecycle hooks, an orchestrator, a dashboard, and cost tracking.
I built Plan Forge because I needed it. The same impulse that made me establish coding standards for human teams drove me to establish them for AI teams. The tools are different, but the principles are the same: clear scope, layered architecture, validation at boundaries, independent review, and no spaghetti code — ever.
Background
My work at Microsoft focuses on Azure enterprise architecture — helping organizations design cloud systems that scale, stay secure, and remain maintainable over years. Before that, I built distributed systems, designed multi-tenant SaaS platforms, and ran engineering teams where architecture governance was a daily concern.
That background shapes Plan Forge in specific ways:
- Stamps pattern architecture — my open-source StampsPattern project brings Azure enterprise cell isolation to infrastructure-as-code. The same boundary-thinking is in every Plan Forge scope contract.
- Multi-tenant isolation — years of building SaaS platforms taught me that "works for one tenant" is not the same as "works for all tenants." Plan Forge's multi-tenancy reviewer agent comes from real production incidents.
- Guardrails as culture — I've never seen a great team that didn't have standards. The guardrails aren't about distrust — they're about consistency. Whether your team member is a junior dev, a senior engineer, or an AI model, they all produce better work when they know the rules.
Community
Plan Forge is open source (MIT). Contributions, extensions, bug reports, and feedback are all welcome.
- GitHub: srnichols/plan-forge
- Contributing: See CONTRIBUTING.md
- Extensions: Build and publish your own domain guardrails — Chapter 11