I choose what matters.
Intent, constraints, tradeoffs, acceptance of risk, and approval at decision gates. I want to understand and defend the architecture—not just receive a finished branch.
HOW I BUILD AI-NATIVE ENGINEERING / 001
Build the system around the code.
AI-native engineering, to me, is designing the human, agent, repository, and test system so useful software can be built reliably. I define the intent and make the consequential decisions. Agents help investigate and execute. Checks turn claims into evidence.
THE OPERATING LOOP / V0.1
THE QUESTIONWhat proves
this works?
01 / INTENT02 / DESIGN03 / AGENTS04 / PROOF05 / LEARNthis works?
THE THESIS 002
The human catches wrong.
The system catches broken.
More generated code is not the goal. The goal is a process that makes better decisions, keeps work reviewable, and exposes uncertainty before it becomes a production problem.
I want to be deeply involved in planning—choosing between real alternatives, understanding the architecture, and being able to defend each decision later. Execution can be shared; accountability cannot.
THE MODEL 003 / FIVE LAYERS
Five questions before “ship it.”
Open a layer to see the question I ask, the artifact it produces, and the boundary it adds.
01Product intentWhat problem are we solving, and what would success mean?
I start with users, constraints, existing solutions, and a measurable promise. One North Star and a few supporting metrics should tell me whether the product works and whether it is worth operating. Targets need evidence; when the evidence is missing, research comes before a PRD.
02System designWhat are the boundaries, interfaces, and tradeoffs?
I review high-level design—containers, trust boundaries, invariants, and scale—and low-level design—data relationships, APIs, components, state ownership, and key sequences. For an existing codebase, I also want a change plan: affected files, compatibility, tests, security, and rollout risk.
03Agent orchestrationWho owns which work, with what context and permissions?
The supervisor can do the work itself or dispatch a job when it is one phase, has isolated file ownership, and can run independently. Each skill declares one output. A task names its Owns: paths and Done-when command, so an agent receives an explicit contract.
04VerificationWhat evidence proves the implementation is correct?
Acceptance criteria precede implementation. The kit specifies a scope guard, a single make check command, security review, and a read-only verifier that does not grade a worker's self-report. Human approval gates decide whether the product and design are right; automated quality gates look for broken work.
05System improvementWhen work fails, which part of the system should change?
A failure can belong to the brief, the design, the context, the tools, or the checks. I log the symptom, owning layer, proposed fix, and guard that would catch a recurrence. Changes to the factory itself get their own review rather than being slipped into a project run.
FROM IDEA TO EVIDENCE 004
A project run, not a prompt.
The kit has more phases than this view. These are the decisions a visitor should understand first.
- 01 / DISCOVER
Frame the problem
Brief, evidence, users, market, and metrics.
sharpen-brief → gather-evidence - 02 / DEFINE
Agree on intent
Write the PRD. Stop for a human decision at G1.
write-prd → G1 - 03 / DESIGN
Make tradeoffs
Review HLD, LLD, interfaces, and task slices.
design-hld → design-lld → G4 - 04 / BUILD
Give work a boundary
Implement scoped tasks with acceptance checks already defined.
define-acceptance → implement-task - 05 / VERIFY
Inspect evidence
Run checks, read the diff, use independent review.
make check → verifier → G5 - 06 / LEARN
Close the loop
Ship, record the outcome, and route meaningful failures.
ship-milestone → route-failure
G1–G5 are human approval gates in the kit's documented workflow. The shorter Fix and Standard tracks avoid running every phase for every change.
DECISIONS AS ARTIFACTS 004A
I want a record of why.
At a design gate, I compare options and make the call. The decision journal records the choice after that human answer, alongside the alternative I rejected, the cost I accepted, and the condition that would make me revisit it. That record lets me explain the architecture months later.
See the decision-journal templateDECISION RECORD / WHAT I NEED TO KNOW
01 / OPTIONSWhat did we consider?
02 / REASONWhy this choice here?
03 / COSTWhat did we accept?
04 / REVERSIBILITYWhen would we revisit it?
DIVISION OF WORK 005
Clear ownership makes speed useful.
Agents do bounded work.
Research, draft designs, write code, run tests, and prepare evidence within explicit output and file boundaries. The supervisor checks dispatched work against the task contract.
Tools make claims testable.
Scope guards, acceptance tests, make check, secret scanning, and independent review catch errors that a convincing summary could hide.
A skill's instruction to stop is useful, but it is not enforcement by itself. My kit treats code-level checks and repository permissions as the stronger boundary.
A REAL REVISION 006 / CERBO
A missed signal changed the process.
On a Cerbo project, the early planning flow reached for success targets without enough market evidence. It had also missed partner stack information that should have informed the technical choice. Those gaps were process failures, so I traced them back to the brief and evidence phases.
Read F3 and F4 in the public logTHE GAP
Technical delivery was easier to describe than business value or fit with the partner's environment.
THE CHANGE
The kit now asks for a North Star, supporting metrics, and partner evidence. The market-research addition is recorded as a proposed change in the public findings log.
THE GUARD
Phase checks look for metric and partner evidence; the research step should surface missing assumptions before a PRD locks them in.
STILL TESTING THE SYSTEM 007
The hard part is knowing when less is enough.
When is the full process too much?
A small fix should not require a product ceremony. The kit has Fix, Standard, and Full tracks; I keep questioning whether each gate earns its cost.
Can I defend the choice?
A design is only useful if I can explain the rejected alternative, the accepted cost, and what would make me revisit it.
What is actually proven?
A green check proves a defined condition passed. It does not, by itself, prove customers need the product or that the metric is worth optimizing.
OPEN THE SOURCE 008
See the rules, not just the diagram.
Software Factory Kit is public and evolving. These are the documents behind this page.