minimum viable constraints

A mental model I'm exploring: MVC, not the one you know, but Minimum Viable Constraints

• MVP asks: what's the least product that still delivers value?
• MVC asks: what's the least restriction that enables emergence but keeps things coherent?

As LLMs commoditize solutions, workflows become disposable. The platform supporting those workflows becomes the product. Our goal becomes density of reliable paths that enables any customer use case (is this the last use case?)

This is an emergence problem. LLMs lower the barrier from idea to execution, and people start combining tools in ways nobody planned for. By definition, you can’t design for emergence, but you can design a system where emergence thrives.

Which raises a real engineering challenge: if your system supports emergence, it also has to handle the outcomes. Not all outcomes will be good. So the question becomes: what's the minimum set of constraints that keeps things working without killing the flexibility that makes the platform valuable?

MVP strips features to find the core product. MVC strips rules to find the minimum structure that prevents chaos while still letting the system surprise you. One is a product question. The other is a platform question. I think we're moving into the second one.

Product R&D still matters! You have to solve real problems to learn what the platform needs to support. But increasingly that R&D is what builds the platform. The FDE role is a good example: you embed with customers, solve their specific problem, extract the pattern, and that pattern becomes a new reliable path in the platform. The solution is scaffolding. The platform is what stays.