D1 opened this series with four audiences: browser, API client, AI agent reading, AI agent operating. It is a reasonable thing to hear and wonder: does designing for AI agents compromise the experience for developers? Extra abstraction, extra configuration, extra layers?
It does not. That is what this post is about.
Forge does not have a developer mode and an AI mode. There is no toggle, no special API surface, no separate subsystem for agent use. The same architecture serves all four audiences -- and the reason it works is that explicit, typed, and self-describing are not AI features. They are good software principles. Forge applies them consistently, and it turns out AI agents value exactly the same things experienced developers do.
Four examples.
1. Struct tags as single source of truth
The developer writes one struct:
type Post struct {
forge.Node
Title string `forge:"required,min=3" forge_description:"The headline of the post"`
Excerpt string `forge:"required" forge_description:"1-2 sentences for the list and meta description"`
Body string `forge:"required" forge_format:"markdown"`
}From this single definition, Forge derives: field validation, database column mapping, MCP tool schema, and the field descriptions the agent reads when it calls create_post. No separate schema file. No documentation to write and keep in sync with the implementation.
The developer benefits because there is one place to change when requirements change. The agent benefits because the tool schema is self-describing without anyone having written documentation specifically for it. Same struct. Same tags. Both benefit from the same decision.
2. Fail-fast and predictability
Forge validates configuration at startup and stops if anything is wrong. /_health is available when mounted, returning framework version and status. The binary does not start in a broken state and fail later when a request hits the misconfigured path.
For a developer, this means: you know immediately whether the instance is correctly configured. No silent failures, no debugging an issue that was visible at boot.
For an agent, the same guarantee applies. It is either calling a correctly configured, running system -- or it is not calling anything. No half-working states, no ambiguous responses to handle. The predictability that experienced developers appreciate is the same predictability that makes an agent's operations reliable.
3. Content lifecycle enforcement
The developer writes no draft-leak prevention code. No status filter on every query, no conditional check before serving a response. The framework enforces the lifecycle -- Draft, Scheduled, Published, Archived -- at the architectural level. Anything outside Published returns 404.
The agent cannot leak drafts regardless of what it is instructed to do. Not because of a prompt constraint that can be overridden, but because the enforcement is in the framework, not in the application layer. The same guarantee that removes cognitive overhead for the developer removes the possibility of agent error for the operator.
4. Go doc comments as API documentation
Forge's exported types, methods, and functions are documented with thorough Go doc comments. This is the primary documentation format -- not a separate wiki, not a docs site that can drift from the implementation.
A developer using GitHub Copilot or Claude Code gets accurate, contextual completions directly in the editor. The doc comments are the source -- no separate manual to look up, no risk of the documentation describing an older API.
An AI assistant helping build a Forge application reads the same doc comments. pkg.go.dev exposes them browsably. godoc generates them locally. There is no separate "AI-friendly documentation" -- all documentation is human-readable and machine-readable simultaneously, because it is Go.
This extends the self-describing principle from runtime (tool schemas, .aidoc, /_health) to the development layer itself. Forge describes itself at every level: for the browser, for the operating agent, and for the developer and AI assistant building with it.
Why it works
D1 introduced four audiences. D7 showed reading and operations as complementary layers -- what the agent can read, what it can act on. D9 is the answer to the question underneath all of it: why does one architecture serve all four?
Because the qualities that make software good for developers -- explicit contracts, typed interfaces, single sources of truth, predictable failure -- are the same qualities that make software reliable for automated systems. The goals were never in tension. Forge applied the same principles consistently, and agents benefit for the same reason developers do.