@rmehta The following gaps in Frappe Framework for agentic development have crystallized for me, over the past years:
-
An agent works best if it can read and update docs along with the code. Docs should serve three audiences—AI agents, human developers, and end users on the site—with distinct layers for each (e.g. agent context like
AGENTS.md, developer reference next to code, user-facing help served from the site). Today there is no single convention: patterns are ad hoc (www/markdown,config/docs.py,pyproject.tomlURLs,AGENTS.md), so agents don’t know where to look. Nor are docs served from the site in a unified, searchable way. We need a standardized layout next to code and a built-in site route that indexes and serves the user-facing layer per tenant. Start with app-global docs (same content on every site running the app), but design the layout and serving layer so site-specific overrides can be added later. Sync means docs live in git next to code and are picked up automatically on deploy/bench migrate—no separate CMS or manual copy step. -
Agents often run into problems running Frappe tests. Integration tests depend on exact DB state and are hard to set up. Frappe v16+ added
bench run-tests --test-category unitandUnitTestCase/IntegrationTestCase, but agents don’t know about it yet, and most tests in the ecosystem are still written as integration tests. We should migrate tests to unit tests where possible and provide a simple, well-documented default command for running unit tests only—optimized for minimal setup (works on a fresh disposable site without manual config) and fast feedback (single app or changed file). Support two tiers: no-site tests with mocked Frappe context for pure logic, and site-backed unit tests for Frappe-specific code (permissions, hooks, DocType lifecycle). Frappe should set conventions and ship example migrations; apps adopt incrementally. -
The standard way of editing DocTypes was human changes via the Desk UI. This is inconvenient for LLMs, even with vision. Since DocTypes are themselves documents (meta), we need a generic CLI for CRUD on any DocType/record—not a DocType-specific tool. That covers schema changes, Custom Fields, and other setup records through one interface. Proposed shape: pipe JSON on stdin, print the final document on stdout, support
--dry-run:echo '{"new": "data"}' | bench doc create DocType --dry-run bench doc read DocType DocName echo '{"modified": "data"}' | bench doc update DocType DocName --dry-run bench doc delete DocType DocName --dry-runOn success (non-dry-run), write to the DB only—use the existing export/sync workflow separately (
export-doc,bench migrate). All operations require--site(fall back tocurrent_sitewhen set, as with other bench commands).
These three gaps are equally important; no single one blocks the others.
Regarding the review bottleneck, Greptile (referral link) is working well for us. They support cross-repository context, produce low-noise reviews that catch the worst mistakes, and have a free for open-source plan.
