The Engineering Workshop
How AI-native engineering runs here: a human sets the rules, agents build inside them, deterministic gates and human review stand before production, and findings feed back into the rules.
How AI-native engineering runs here: a human sets the rules, agents build inside them, deterministic gates and human review stand before production, and findings feed back into the rules.
Exhibit 10 · Leadership
A fix or a feature is caught by the deterministic gates; a risky migration is caught by human review. Either way it goes back and never ships.
A rule added from an earlier production finding catches the misread sooner, before a test would. The rules are versioned like software.
A workshop at rest. Choose the change, whether an agent misreads the spec, and whether a rule has been updated from a finding.
The human sets the architecture and the rules the agents must work inside: the shared base set, plus the boundaries for this change.
Coding agents implement a new feature at the benches, inside the rules. The work follows the spec.
The deterministic gates run and pass: build, types, tests, lint, all green.
A lead reviews the change against the architecture and the intent, and approves it. Agent-written code is held to the same bar as anyone else's.
Back to the benchskipped for this input
The agents correct the change against what caught it, and it runs the gates and review again. This time it passes. The misread never reaches production.
The change merges and ships. Production is observed: the dish watches how the running service behaves, not just whether the build was green.
An observation becomes a finding, and the finding becomes a rule back on the rack, versioned like software. The next change starts with that guard already in place.
The drafting table and the rule rack at the back are mine: I set the architecture and the rules the agents must work inside. Along the line, the agents implement the change at their benches. Nothing they write goes straight to production. Every change runs the deterministic gates, build, types, tests and lint, and then a lead reviews it. Only then does it ship, and the observatory dish keeps watching the running service after it does.
The loop closes at the back. An observation becomes a finding, and the finding becomes a rule back on the rack, versioned like software. The next change starts with that guard already in place.
This is an illustrative model of the operating model, not a view into any real repository.