We built an AI that scaffolds on our own framework instead of raw code — was that a mistake?
We've been building kumiko-studio — an AI layer that generates features specifically for our own SaaS framework (Kumiko), not generic code.
The idea: instead of teaching a general AI your patterns every session, you adopt an opinionated framework once, and the AI already knows all the conventions — auth, multi-tenancy, billing, notifications, all wired up consistently.
The upside is real: no "how do I structure this?" sessions, no inconsistent patterns across features, generated code drops straight into the project.
The downside: you're locked into the framework's opinions. If the framework has a bad abstraction, the AI doubles down on it. And onboarding someone who doesn't know the framework first is harder.
Curious if others have gone this route — AI prompted specifically for your own stack — or if you think general AI + good AGENTS.md is the better long-term bet.
I like the “opinionated framework once, AI already knows the conventions” direction. The tradeoff I would watch is not only lock-in, but observability: once the AI is generating whole features, you want to know which parts of the workflow were cheap/repeatable and which parts required a stronger model, retries, or human review.
In practice, framework-specific generation probably makes model routing more important, not less. Boilerplate scaffolding can use a cheaper/fast path, while schema changes, billing logic, auth, or migration code may deserve a deeper model and stricter traceability.
That is the angle we keep building around with Tokens Forge: AI-powered products need access to multiple models, but also a ledger that explains which workflow, route, model, fallback, and balance bucket paid for each run. Otherwise it is hard to tell whether the framework is compounding efficiency or just hiding API spend behind faster generation.
Both points land. On "do opinions compound" — yes, that's exactly the bet. And the evolution concern is real, but in practice the AI reads the actual codebase each time, so when we refactor a pattern it just picks it up. No AGENTS.md drift.
On the small-team tradeoff: the one-time onboarding friction is front-loaded now because the framework is documented. After that, new features aren't "teach the AI your patterns" — they're just "describe what you need." The framework handles the architectural decisions.
I don't think the question is whether it's more opinionated—it's whether the opinion compounds. If the framework consistently removes repetitive architectural decisions, that seems like a feature rather than a limitation. The harder part is making sure those opinions can evolve as the framework matures.
This is exactly the right tradeoff for a small team shipping consistently. The consistency win you're describing - no "how do I structure this?" debates, code dropping in ready to wire - that's the compounding advantage. The onboarding cost is real but it's a one-time friction vs ongoing velocity tax. I'm curious: as you evolve Kumiko's opinions, how do you handle migrations? Does the AI-generated code become harder to refactor if it makes assumptions that get deprecated?