LLM-Assisted Development in Framework M

Viewed 37

The rapid evolution of Business M is powered by our "LLM-first" design philosophy. Framework M is built to be intrinsically understandable by AI agents, enabling a new paradigm of high-confidence development.

Here is exactly how Business M is built:

1. Automated Machine Knowledge (corpus.jsonl)

With every update, our GitLab CI automatically generates structured documentation and a comprehensive corpus.jsonl. This live ground-truth is published directly to:
👉 https://www.frameworkm.dev/machine/corpus.jsonl

2. Feeding the Agent

When building a new feature, you simply feed this corpus to your AI agent. Because the corpus contains the entire framework's schema and patterns, the agent doesn't need to guess—it already knows the "M way" of doing things.

3. Intelligent Scaffolding with the m Command

The m CLI tool is used for all scaffolding. The agent uses the corpus to make precise decisions, such as selecting the exact FieldType for a DocType based on existing patterns in the ecosystem.

  • m command scaffolds the DocType definition.
  • It automatically creates the Controller and Test files.

4. TDD-First Development

This is the core of our methodology:

  1. LLM Generates Tests: Based on the DocType spec, the agent writes the comprehensive test suite first. Define your expectations before writing any implementation.
  2. LLM Implements Code: The agent then generates the service and controller code specifically to pass those tests.
  3. Incremental TDD: Add features one small, verified step at a time, entirely driven by LLM iteration.

This structured, machine-readable approach is how we maintain clean architectural boundaries and massive scale while moving at lightning speed.

2 Answers

Hello @revant

Can you explain a bit more how your structure your LLM workflow. How do you use/structure corpus.jsonl and how do you feed it back for your feature development?

How is your testing stack used?

To answer your question on the "how?"; we treat the LLM as a highly capable but strictly governed collaborator. The workflow moves from abstract design to concrete, test-driven implementation in four distinct phases:


1. Design & RFC (The "Discuss" Phase)

Before a single line of code is written, I feed the corpus.jsonl to the LLM to provide context on existing DocTypes and patterns.

  • The Rule: "Discuss only." No code generation yet.
  • The Output: A Markdown-based RFC or "Phase Checklist." This ensures the LLM understands the architectural boundaries of Framework M before it gets "creative."

2. The Granular TODO (The "Spec" Phase)

I ask the LLM to transform the RFC into a hyper-specific TODO list. To make this work for both agents and humans, I enforce these strict rules:

  • TDD First: Write the test before the code. m test must verify the failure first. Check existing TODOs; they always have tests mentioned before implementation.
  • Absolute Paths: No ambiguity. Every file mentioned includes the full workspace path (e.g., apps/base/models/doctype_name/controller.py).
  • Implementation Blocks: I ask the LLM to describe the expected implementation logic in detail within the TODO item so it doesn't "hallucinate" a different path later.
  • Human-Readable: The TODO must be clear enough for a human to follow manually if needed.

3. Human Gatekeeping (The "Decision" Phase)

The TODO is placed into a GitLab MR or Issue description. This is where the CONTRIBUTING.md rules kick in.

  • The Golden Rule: LLM asks, Human decides. * Validation: I review the TODO list to ensure it aligns with the roadmap. Once I approve, the execution starts.

4. Iterative Execution & Scaffolding

Whether using an Agent (automated) or a standard LLM (copy-paste), the process is the same:

  1. Scaffold: Use the m CLI to generate the DocType and boilerplate.
  2. Test: Implement the failing test defined in Step 2.
  3. Code: Implement the logic until m test, m lint, m typecheck, and m security pass.
  4. Commit: Generate a Conventional Commit that passes gitlint and follows the scopes defined in release-config.json.

Why this works

By using corpus.jsonl, we eliminate the Context Gap. The LLM knows the FieldTypes, the Controller hooks, and the Service patterns because it’s reading the live DNA of the framework, not just generic Python best practices.

You can see our pending implementation plans here: Framework M Milestones. These are the actual implementation TODOs generated using this process.

How this boosts Application Developers

The real power of corpus.jsonl isn't just for building the framework—it’s a high-speed rail for context for anyone building on top of it.

Business M backend phases are already seeing a massive boost from this; our Finance backend with high-throughput bookkeeping is ready. Once we have these patterns in place for the frontend, we expect the same exponential boost in development speed there as well.

Related