# FAQ — ModelHike

**Isn't this just spec-driven development?**
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.

**Why not use AI to generate the implementation directly?**
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.

**Isn't source code already the source of truth?**
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.

**How is ModelHike different from UML and Model Driven Architecture?**
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.

**How is ModelHike different from a business rules engine?**
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.

**Does ModelHike replace application programming?**
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.

**Can I write custom algorithms?**
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.

**How much of the application can it model?**
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.

**Can it guarantee correctness?**
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.

**Does deterministic compilation eliminate code review?**
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.

**What happens if the model is wrong?**
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.

**Can I modify the generated code?**
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.

**Can I switch implementation frameworks?**
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.

**What frameworks are supported today?**
`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.

**How does ModelHike work with AI agents?**
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.

**Is ModelHike open source?**
Yes — MIT licensed, developed in the open on GitHub.

**What is Model-Native Development?**
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.

**When is a separate Source Model not worthwhile?**
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.

**What's in it for the business?**
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.

**What's next for ModelHike?**
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.