Questions engineers actually ask.

Same intent, different implementation. It shares the idea of defining requirements before implementation. Specifications can already be formal or executable. ModelHike's distinction is a typed, versioned Source Model with tooling for validation, inspection, dependency analysis, and blueprint-based generation. The model stays useful after the first generation.

For behavior outside the model's coverage, you should; AI is excellent at exploration and judgment. But settled decisions — API structure, DTOs, persistence wiring, standard CRUD — don't benefit from being re-derived probabilistically each run. ModelHike splits the work: AI helps define the model; the compiler applies rules it already knows.

Yes, for what the implementation actually does. But understanding one business decision may require tracing several files and framework conventions. A Source Model makes supported definitions explicit and reviewable alongside the code, not a replacement for checking it.

It builds on model-driven ideas rather than claiming to have invented them. Its approach is a Markdown-inspired text language, versioned in your repository, with CLI/MCP tooling and framework-specific blueprints. The important tradeoff is scope: model what becomes clearer, and leave implementation complexity in code.

Rules engines evaluate or execute specific kinds of rules at runtime. ModelHike models broader application structure — entities, relationships, APIs, supported behavior — and compiles it into application source code. It's a generator of applications, not a runtime evaluator of rules.

No. Domain algorithms, infrastructure details, and implementation-specific techniques stay in ordinary code — that's the design, not a gap. Model what benefits from explicit semantics; code what's better expressed imperatively.

Yes. Use conventional code for algorithms and behavior outside blueprint coverage. The DSL also supports method declarations and logic blocks; whether those become executable implementation depends on the target blueprint.

Application structure and supported behavior: containers, modules, entities, properties, references, methods, and API declarations. Coverage depends on the model features and the target blueprint; anything unsupported stays in code.

No. Typed models reduce ambiguity for supported concepts, and validation catches structural and semantic errors early — but nothing makes an incorrect specification correct. Tests and review remain essential.

No. Review the modeled decision, inspect the generated implementation, and test its behavior. Established blueprints can make repetitive changes easier to inspect; determinism alone does not prove correctness or reduce review effort.

Validation catches some structural and semantic errors. A valid model can still describe the wrong application, and generation will not correct that. Review the model and test the resulting software.

Yes. No code cage: it's conventional source you can inspect, test, and customize. Direct edits aren't guaranteed to survive regeneration. Preserve recurring changes through the model or blueprint where supported; AI can assist that work, but reconciliation is not automatic.

That's the architecture's purpose: models are separate from blueprints, and two blueprints exist today. Frameworks have different capabilities; a model preserves supported application definitions — it doesn't eliminate migration work.

api-nestjs-monorepo (NestJS + TypeScript: REST APIs, CQRS, MongoDB) and api-springboot-monorepo (Spring Boot 3.x + Java: GraphQL, reactive WebFlux, MongoDB). The DSL is target-agnostic; new blueprints are folders of templates.

Via an MCP server over stdio and a JSON-native Smart CLI. Agents draft models, then validate → diagnose → fix → explain autonomously with structured diagnostics; humans step in to approve. Twelve MCP tools cover the loop: validate, generate, dry-run, inline-generate, explain, inspect, what-depends-on, list-types, fix, preflight, list-blueprints, dsl-schema-in-markdown.

Yes — MIT licensed, developed in the open on GitHub.

Treating the application model as a first-class engineering artifact across the lifecycle: typed, versioned, machine-readable, and used for validation, inspection, impact analysis, and generation — not a planning document discarded when coding starts.

Throwaway prototypes, single-endpoint utilities, unexplored domains in heavy flux, and apps whose complexity is purely algorithmic gain little from a modeling layer. The model earns its keep when structure, relationships, and change over time dominate — as in real business applications.

Business knowledge in versioned, reviewable artifacts instead of buried in implementation. Review business-level changes without reading every diff. Automate repeatable structure through blueprints. Reuse proven patterns. Keep the option to change implementation technology. No ROI claims — the value is safer, more understandable change.

Richer outcome and constraint modeling: describing what the business promises — a payment authorized, a refund within limits — without prescribing every algorithm. This is the direction of the project, not a shipped feature.