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.
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?