Why Manifest exists

For decades we organized ourselves by layer. Front-end engineers. Back-end engineers. Infrastructure engineers. Data engineers. Each with their own languages, tools, communities, and mental models.

That specialization made sense. Building a responsive UI and tuning a database query are genuinely different skills. They still are. Specialization will always exist — someone will always care more about pixel-perfect layouts, and someone else about query plans.

But the lines are blurring. Agents don't see layers the same way humans do. An agent reading your codebase doesn't think "I'm a front-end engineer" — it reads the feature file, understands the API, writes the component, sets up the database table, and moves on. The full stack isn't a career path. It's a single context window.

In the end, we're all just engineers building applications.

The tools need to catch up to that reality.

Every framework you've used was designed by humans for humans. That's not a criticism — it was the right choice when humans were the ones writing code. But it produced a particular kind of complexity.

Middleware chains. Decorator-based dependency injection. File-system routing conventions. Auto-discovery. Lifecycle hooks. Magic methods. Convention over configuration taken so far that understanding a single request requires knowing the framework by heart.

If you're an expert in Next.js or NestJS or Rails, you navigate this fluently. You've built the mental model. You know where things happen even when the code doesn't say so.

Agents don't have that luxury. They don't have years of framework-specific intuition. And more importantly — all the code agents write needs to be explicit. An agent can't rely on "well, the framework does this behind the scenes." It reads code. If the code doesn't say it, the agent doesn't know it.

The irony: optimizing for agent comprehension produces code that's easier for humans to understand too. Explicit is just good engineering.

Manifest is a TypeScript framework that runs on Bun. That part is normal. What's different is the design constraint: every line of code must be readable by an agent that has zero framework-specific knowledge.

One feature, one file. A feature declares its route, inputs, authentication, side effects, error cases, and business logic in a single defineFeature() call. An agent reads one file and understands one complete behavior. No hunting across directories.

The framework itself is ~1,000 lines of TypeScript source code that ships inside your project — not as an npm package. When an agent needs to understand how routing works, it reads manifest/router.ts — 76 lines. When it needs to change validation, it edits manifest/validator.ts — 92 lines. There is no black box.

No dependencies. No hidden functionality. No middleware. No decorators. No dependency injection. No file-system routing. No convention-based auto-discovery. If something happens, it's because the code says so.

The whole framework fits in a single context window. An agent doesn't just use Manifest — it understands every line of it.

But let's be clear: none of this is a guarantee your project won't become a mess. Manifest can't do magic — in fact, it tries to do as little magic as possible. It gives you a clean foundation and gets out of the way. What you build on top of it is entirely up to you.

You can make it as complex as you want. You can scatter logic across files, bury intent behind abstractions, build the same tangled architecture you're used to. Manifest won't stop you. It's a foundation, not a guardrail.

What it does ask is that you change how you think about writing software. Not "learn a new framework" — the framework is 1,000 lines, you'll read it in ten minutes. The shift is in how you approach the work: writing code that's meant to be read by something other than you, declaring intent explicitly, keeping behavior visible. That's a mindset change, not a tooling change.

Most tools treat agents as a development aid — a smarter autocomplete, a code reviewer, a pair programmer. Manifest goes further. Agents aren't just part of the writing process. They're part of the entire lifecycle.

The self-healing loop is the most ambitious part. An error occurs. The agent reads MANIFEST.md to orient itself. It reads the feature file — one file, complete behavior. It diagnoses the issue, edits the code, and Bun hot-reloads the module. No deploy. No restart. The next request runs the new code.

This only works because every design decision in Manifest was made to support it. One file per feature so the agent edits one file. Declared side effects so the agent knows the blast radius. Source-code framework so the agent can fix anything. No hidden behavior so the agent's model matches reality.

Manifest is young. The core framework works — features, validation, routing, testing, CLI, frontend support, streaming. You can build real things with it today. But large parts of the vision are still ahead: database integration, authentication, the full production agent sidecar.

We're not hiding that. The roadmap is public. The framework is 1,055 lines you can read in minutes. There are no announcements about announcements.

What exists is solid. What's coming is ambitious. The gap between the two is where the experiment lives.

This is for people who want to try a different way of working with agents.

Not everyone will want this. If your team has deep Rails expertise and it serves you well, keep using Rails. If Next.js gives you what you need and you understand the trade-offs, use Next.js. We're not here to tell you your tools are wrong.

But if you've felt the friction — agents struggling with framework conventions they can't see, code scattered across files for organizational reasons that don't help the reader, abstractions that hide more than they reveal — then Manifest might be worth an afternoon.

Fork it. Read the code. See if it changes how you think about what a framework can be.