The Code plugin proposes changes, verifies that contracts are preserved, cascades to affected callers, runs tests, and ships to git — with a human in the loop at every consequential step.
Most AI coding tools produce suggestions. You accept, reject, edit. The tool has no memory of what it suggested before, no understanding of what other code depends on the function it just rewrote, and no mechanism to ensure the change follows your codebase's conventions.
Code is different. Every proposed change goes through a governed workflow: propose → verify contract → classify impact → cascade to callers → run tests → ship to git. Each step is a discrete, auditable action. Each consequential action requires approval — automated for low-risk changes, human for breaking ones.
Code reads everything from the Grokers knowledge graph. It knows the preconditions and postconditions of every function. It knows which conventions govern how new code should be written. It knows which callers would be affected by a change. It doesn't re-derive any of this — Grokers already did the work.
Code clones the repository into an isolated ZFS dataset — a private, writable copy of the filesystem. All changes happen here. The original is untouched until you explicitly approve a push.
The AI reads the target function's source, its Grokers-derived contract (preconditions, postconditions, side effects, invariants), the applicable conventions from the knowledge graph, and the change description. It produces a structured rewrite: new source, new docstring, change notes. Conventions marked stale are skipped — they may no longer be accurate.
The new source is analyzed against the old contract. The change is classified as A, B, or C. Class A and B changes are auto-approved. Class C requires a human.
For breaking changes, Code walks every caller in the graph. Each is classified: does it still work under the new contract? Callers that need changes get their own sub-workloads spawned recursively, bounded by a depth limit.
The workspace's test suite runs against the modified code. Results are stored as a Code/testRun stream. Failures are surfaced as findings.
On sprint completion, changes are committed and pushed to a new branch on the source repository. The branch name, commit message, and changelog are generated from the sprint's modification log.
The most important question about any code change is: does it break existing callers? Code classifies every proposed change into one of three categories, with a conservative bias — when uncertain, assume breaking.
Equivalent behavior, possibly different wording. Auto-approved, no caller notification needed.
Relaxed preconditions or strengthened postconditions. Existing callers still work. Auto-approved.
Strengthened preconditions or weakened postconditions. Some callers may break. Human approval required, ripple pass triggered.
Class A and B rewrites are approved automatically by a judgment — a small piece of code that runs in the Safebox governance sandbox and votes on behalf of the community. Class C changes pause for human review before any caller modification begins.
When a function's contract changes incompatibly, something has to update its callers. Code does this systematically, not by guessing which files might be affected.
The cascade is bounded by a recursion depth limit and runs in parallel where the dependency graph allows it. Callers that are classified as still working under the new contract are left untouched — no unnecessary changes.
Developers subscribed to a symbol stream receive a notification when a breaking change reaches their code. They can review, approve, or intervene before the sub-workload runs. This uses Qbix's standard subscription cascade — no separate notification system.
Every sprint runs in a ZFS clone — a copy-on-write snapshot of the repository filesystem. Creating it takes milliseconds and uses no extra disk space until files are modified. The original repository dataset is never touched.
Multiple sprints on the same repo can run simultaneously because each has its own isolated clone. They don't interfere with each other or with developers working directly on the codebase.
When a sprint ends — successfully or not — the ZFS clone is destroyed automatically. No leftover branches, no orphaned files, no cleanup burden.
The snapshot captures the repo at a specific moment. The sprint analyzes and modifies a consistent state, even if other developers are committing to the source repo in parallel.
Successful sprints are projected to a git branch on the source repository's remote. The branch name and commit message are generated from the sprint's change log. You review a normal PR.
Before writing any new code, the Code plugin fetches the applicable conventions from Grokers. These are the recipes Grokers derived from analyzing your codebase — where files go, what constructors must return, which lifecycle hooks fire in which order, what patterns to avoid.
When a trigger function changes (the function a convention describes), Grokers automatically marks that convention stale. Code skips stale conventions rather than inject potentially outdated recipes. The next time Grokers re-analyzes the changed function, it derives a fresh convention. This means AI-generated code tracks the actual state of your codebase, not a snapshot from when Grokers first ran.
Code introduces exactly four stream types, two capabilities, and twelve tools. Everything else — workflow execution, action governance, notifications, access control, billing — comes from the underlying Safebox and Qbix platforms.
Code doesn't index codebases. That's Grokers. It doesn't provide the workflow primitive. That's Safebox. It doesn't talk to users. That's Safebots. Each layer does one thing well, and they compose.
The result is that a change which seems simple — "rename this method" — correctly triggers contract verification, caller classification, test execution, and git projection, all with the right approvals at each step. And a change which seems complex — "refactor this function and update all its callers" — runs the same pipeline, just with more sub-workloads spawned in parallel.