Why I built Forge

Most web frameworks are built for one audience: the developer writing the code. Forge is built for four.

The developer writing the code. The AI assistant helping build it. The human visiting the resulting site. And the AI agent consuming its content.

Coming back in the age of AI

I came back to web development after years in IT project management. The tooling had changed beyond recognition — npm, Webpack, Vite, Tailwind, React, Next.js. Each one solving a real problem. Each one adding a new layer that requires its own expertise to manage, its own configuration to maintain, and its own failure modes to debug.

I wanted to build a site. I ended up managing a build pipeline.

But something else had changed too. AI assistants had arrived. And the first thing I noticed was that AI is only as good as what it can understand. A codebase with six layers of abstraction, implicit conventions, and scattered configuration is as opaque to an AI assistant as it is to a new developer joining the project.

If you are building software that AI will help you maintain — and you are, whether you planned to or not — then predictability, clarity, and documentation are not nice-to-haves. They are the foundation.

The problem with complexity

A deep dependency stack does not just slow you down. It introduces gaps.

Cross-site request forgery protection wired in the wrong order. Security headers applied inconsistently. Session handling that works in development and breaks in production behind a reverse proxy. Middleware that conflicts with middleware from a different package. None of these are exotic problems. They are the ordinary tax of assembling a framework from parts.

Every layer you add is another layer your AI assistant has to reason about, another layer where a subtle mistake can be silent for weeks, and another layer that a new developer — human or AI — has to learn before they can contribute safely.

What Forge does instead

Forge ships the security fundamentals correctly, once.

CSRF protection, secure cookies, HTTPS redirect, security headers, rate limiting, role-based access control — these are not plugins to configure. They are part of the framework, designed to work together, documented in one place, and testable as a unit.

Content lifecycle — Draft, Scheduled, Published, Archived — is enforced by the framework, not by the developer remembering to add a status check. Non-published content never leaks to public endpoints, sitemaps, feeds, or AI indexes. This is not configurable. That is the point.

Roles compose with lifecycle naturally. A Guest sees only Published content. An Author sees their own drafts. An Editor sees everything. You declare this once on the module. Forge enforces it everywhere.

Built to be maintained by AI

Forge's API naming, file structure, and architecture documentation are designed with AI code generation in mind. Not as a marketing claim — as a design constraint.

Every exported symbol has a godoc comment. Every architectural decision is recorded in DECISIONS.md with rationale and consequences. The dependency graph has no cycles. The file structure is flat and predictable. There are no magic conventions — only explicit configuration.

When you ask Copilot or Claude to add a feature to a Forge application, it produces idiomatic code on the first try. Not because the AI is clever, but because the framework is unambiguous.

This is what readable code means in 2026: readable by humans, and readable by the AI that will help you maintain it.

What this site is

forge-cms.dev is built with Forge itself. Every page you read was created via the Forge content API. Every link is tracked. Every post has a canonical URL, an Open Graph tag, and an AIDoc endpoint at /devlog/{slug}/aidoc.

It is the proof that the framework works — and that the AI that helped build it understood what it was building.