Workstream 1
Feature Compiler
LLMs are fast, but they are not naturally trustworthy architects.
Feature Compiler is the part of Kanbien that turns a feature request into small backend capabilities with enough structure around each slice to make implementation reviewable, testable, and safe to mount or discard.
The Problem
The problem with going straight from prompt to code
When an LLM is asked to build a backend feature directly, it can produce convincing code while missing the decisions that make software production-ready: authorization, lifecycle rules, persistence boundaries, API contracts, audit behavior, test coverage, documentation, and compatibility.
The result may look fast at first, but the risk moves downstream into review, debugging, drift, and rework.
The Bet
The harness matters more than the prompt
The bet behind Feature Compiler is that AI-assisted delivery becomes useful when the work is broken into smaller, explicit capabilities before implementation begins.
A capability is one focused piece of functionality that performs one job well: create a user, update a user, delete a user, list users, export records, or run a specific background process.
What It Does
What Feature Compiler does
- Turns vague feature requests into thin backend capability slices.
- Forces architecture, authorization, lifecycle, persistence, API, testing, and documentation decisions into view.
- Creates a build path that can be reviewed before code is written.
- Keeps each slice isolated enough to mount, verify, revise, or discard.
- Produces evidence that a human can inspect.
Why It Matters
What this makes possible
The goal is not to generate more code. The goal is to reduce the time between understanding a requirement and safely proving a production-grade backend slice.
- A backend capability can be planned, built, tested, and documented quickly.
- Review becomes easier because the slice has a defined boundary.
- Drift is reduced because implementation follows a structured artifact chain.
- Failed or rejected work can be discarded without contaminating the repo.
- Stakeholders get evidence, not just promises.
Flow
A public version of the pipeline
Step 01
The request becomes a decision-ready brief
A stakeholder should not need to describe tables, routes, or architecture. They should be able to explain what they want, who it is for, what must never happen, who should have access, and what a safe outcome looks like. Kanbien turns that into a brief the build harness can use without pretending the missing details are already settled.
Stakeholder says
"Let customers invite team members."
Kanbien captures
- Who is inviting whom?
- What happens if the email is already used?
- Who can invite admins?
- What must be approved before sending?
Step 02
The feature is broken into single-objective capabilities
A feature is too large and ambiguous to build reliably in one pass. The Kanbien capability matrix breaks it into smaller actions that each do one thing well, then defines the myriad rules around that action that engineers would ordinarily need to build it properly: who may use it, what valid input looks like, how it should be built, what errors should say, how your website or app can consume it, documentation, testing requirements, logging and monitoring rules, and many more.
Step 03
The hidden architecture questions are forced into view
This is where the system stops letting the model hand-wave. The blueprint makes backend decisions reviewable before code exists: route shape, persistence, lifecycle, authorization, compatibility, tests, and documentation.
Blueprint must answer
- API shape and route behavior
- Persistence and lifecycle states
- Authorization and tenant boundaries
- Required tests, docs, and proof
Step 04
The build work gets rails
The capability is turned into task packets with allowed write areas, expected proof, and stop conditions. That means the model is not free to sprawl across the repo just because it can.
Step 05
The slice can be mounted or removed cleanly
The point is not just speed. The point is reversibility. A capability lands as a bounded slice with feature-local code, tests, contracts, and docs so it can be reviewed without contaminating unrelated work.
Mounted slice
- feature/invitations/domain
- feature/invitations/transport
- tests/invitations
- docs/api-contracts
Step 06
Done means evidenced, not generated
A generated backend feature is not trusted because it exists. It is trusted only after behavior, API shape, tests, documentation, and artifact alignment can be inspected against the original slice.
Ready only when
- Pass API behavior exercised
- Pass Validation errors proven
- Pass Docs and Postman ready
- Pass Artifact sweep clean
Evidence
Evidence in the repo
The public evidence is the shape of the harness: capability matrices, implementation blueprints, task breakdowns, API contract expectations, Postman proof, feature manifests, and test obligations.
- Capability matrix: records what the capability must decide.
- Implementation blueprint: turns the capability into a build plan.
- Task breakdown: isolates the delivery work.
- API and Postman proof: makes the behavior testable.
- Artifact sweep: checks docs and repo truth do not drift.
Boundary
What I am not publishing
The public version explains the purpose, shape, and evidence of Feature Compiler. The detailed prompts, internal routing logic, scoring rules, schemas, and execution workflow are intentionally private.