A chatbot that emits an SPFx React snippet is not much of a product. It wraps scaffolding, produces plausible code, and leaves the hard part—whether the result actually works—to the user.
I built a small local alternative: an SPFx Factory that turns structured requirements into an official SharePoint Framework scaffold, an implementation task for Codex, and a bounded verification report.
Repository: https://github.com/vystartasv/spfx-factory
The factory boundary
The factory is deliberately local:
- Node 22 CLI
- Official
spfx createscaffolding - React
webpart-reactprojects - Codex execution only behind explicit
--execute - Verification only behind explicit
--verify - No tenant login, deployment, credentials, telemetry, browser automation, or Git operations inside generated tasks
- Static policy scanning for secrets, permissions, unsafe URLs, and unauthorized mutations
The default path is safe and boring. It validates a specification, creates the official scaffold, renders FACTORY_TASK.md, and performs policy checks. It does not silently install packages or run an agent.
Verification is the product boundary
The generated project is not accepted because an agent says “done”. The factory records separate stages:
- official scaffold
- Codex implementation
- policy scan
- dependency installation
- explicit test script
- build
- package
Missing scripts.test fails verification. Project warnings fail verification even when the command exits zero. Optional package scripts are reported as skipped instead of being silently omitted.
Verification child processes receive a Node heap override of 8 GB through NODE_OPTIONS. Existing non-heap options are preserved; the host macOS memory configuration is not changed.
Writable web parts are explicit
Read-only remains the default. Writable generation requires "mode": "writable" and explicit positive create/read/update/delete intent.
The writable policy is not “disable security checks”. It allows only narrow typed SharePoint/PnP mutation patterns while continuing to reject secrets, permission requests, unsafe URL schemes, raw HTTP mutation patterns, and other unrelated operations.
Local writable verification uses deterministic adapters. That proves CRUD logic, validation, conflict/error handling, and UI behavior in the generated project. It does not prove tenant writes, SharePoint permissions, authentication, deployment, or production behavior.
Two independent writable samples passed the final local gate:
- Request Tracker — local create/list/update/delete, optimistic conflict handling, accessible delete confirmation
- Leave Request — local submit/list/update/remove, date validation, recoverable error states
Both passed test, build, package, and policy stages with zero project warnings.
The failures were useful
The first generated samples exposed exactly why a verification layer matters:
- missing explicit test scripts
- TypeScript warnings from dynamic SCSS access
- unsupported
Array.includesunder the scaffold target -
voidand floating-promise lint failures - defensive
javascript:test literals triggering SPFx lint - a negative-path Jest test that did not match the installed Jest behavior
- dependency peer/deprecation warnings from the current SPFx scaffold
Each discovered defect became either a factory gate, a generated-task rule, or a regression test. The factory became stricter instead of hiding the failures.
What this does not claim
This is not tenant-ready automation. Local success cannot establish:
- SharePoint runtime behavior
- tenant permissions
- authentication and identity behavior
- deployment readiness
- browser accessibility in a real workbench
- production data correctness
Those require a separate human-controlled tenant validation stage.
Run it locally
npm install
npm test
npm run build
npm run check
node lib/cli.js validate --spec specs/request-tracker.json
node lib/cli.js generate \
--spec specs/request-tracker.json \
--output ./out/request-tracker \
--execute --verify
The final factory repository checks pass with 47 tests, TypeScript build, type check, and whitespace validation. The generated writable samples were verified separately and remain disposable local artifacts rather than committed tenant projects.
The useful lesson is simple: an agent producing code is easy. An agent-backed factory that refuses to call broken, unsafe, or unverifiable output complete is the actual engineering work.
Top comments (1)
Hello Glad to see you, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.
I really like the distinction between code generation and verified artifact generation. The strongest part of this architecture is making verification an explicit state transition rather than trusting an agent's completion message.
I would push this further by modeling the factory as a deterministic state machine: specification validated, scaffold generated, implementation produced, policy analyzed, dependencies resolved, tests executed, build completed, package generated, verification signed. Each transition should emit immutable structured evidence so the final report becomes an auditable artifact rather than console output.
I would also introduce capability based generation. Instead of allowing the agent to infer what it can modify, derive capabilities directly from the specification and enforce them through AST analysis and an allowlist. For example, CRUD capability should map to specific typed PnP operations, while unrelated mutations become policy violations.
Another powerful layer would be differential verification. Keep a known good scaffold baseline and compare generated changes against it using AST and dependency graph analysis. This can detect unexpected imports, permission changes, network endpoints, package additions, and API surface expansion before execution.
For production maturity, I would separate local semantic verification from tenant verification exactly as you described. That boundary makes the system much easier to reason about and dramatically reduces the blast radius of agent generated code.
This is much closer to an engineering control plane than another AI code generator. I would enjoy exchanging ideas around verified agentic development and policy driven code generation.