Three boundaries around AI code.

Isolate. Guide. Enforce.

A policy document does not govern an agent turn. Constraining code authoring under standardised delivery has three practical parts, and all three appear where work happens.

• Isolate. Isolated workspaces: non-production environments for people and agents, with no live credentials and scoped filesystem, tool and network grants while an idea is still changing.
• Guide. Shared engineering standards: one versioned rulebook of architecture, layout, idioms and templates for people and agents, carried in editor configuration, agent instructions and pipeline checks.
• Enforce. Compiler-enforced standards: architectural and safety rules — no panics or unwrap, no direct network or filesystem calls — fail at compile time, before a human opens a pull request, alongside protected publication and pipeline gates.

Reviewers focus on design and trade-offs — not policing mechanical rules. Guidance is shared; non-negotiable rules are enforced. A coding worker can use a grant; it cannot infer, create or widen one.

The coding worker and the delivered application are separate trust boundaries. Authoring controls bound what the worker may read, write, execute or publish while creating the change. The WebAssembly runtime bounds what the resulting application may touch when it runs. Authority granted in one boundary confers nothing in the other.

Automate verification and deployment

Agent-written unit tests often repeat the agent’s own bugs. When AI generates code at scale, verification cannot rely on happy-path unit tests alone — pipelines must replay behaviour against the spec, gate the supply chain and automate deployment:

1. Hermetic behavioural replay. Deterministic scenarios against scripted doubles, with no live network or external state, alongside unit, integration and end-to-end tests.
2. Supply-chain and secret gates. Vetted dependencies, vulnerability scans and secret hygiene that block hallucinated packages and credential leaks.
3. Automated review and deployment. AI review agents and deterministic gates run before human sign-off, then deploy one immutable artifact with its verification evidence.

Every system still needs environments, infrastructure, testing, security checks, deployment and observability. Recreating these foundations slows the first release and creates another unique platform the organisation must maintain.

Propellerhead applies reusable assets around a Wasm-shaped solution, including:

• Terraform modules and compositions for AWS or Azure;
• GitHub Actions workflows for build, test, security checks and deployment;
• environment configuration and promotion patterns;
• observability defaults and operational checks;
• artefact creation and release conventions;
• local backends for fast development and selected production backends for deployment.

These are Propellerhead delivery assets, not features of the runtime. They are adapted to the client’s security, networking, data, governance and operating requirements.

Verification and release are different decisions

A verified revision means the declared build and verification checks passed. Released means an accountable owner accepted the timing, exposure and operational consequence.

A reusable path helps teams:

1. Seal reviewed intent as a versioned revision.
2. Build and verify the integrated result in bounded waves.
3. Produce versioned, traceable artefacts.
4. Create or update infrastructure through reviewed code.
5. Deploy consistently across environments.
6. Release under controlled exposure where the product requires it.
7. Observe the result and retain a recovery path.

The exact controls remain proportionate to the system. A dependable path should be easy to use frequently, not impressive but too expensive to operate.

Prompts are not specifications

Prompts disappear after a turn and leave agents to guess. Specifications persist in the repository as the contract both people and agents build against.

Our spec-driven development engine sits around coding agents rather than competing with them. Coding agents tend to smooth over ambiguity with plausible-looking code, which short-circuits the conversations a team actually needed to have. The delivery engine forces that ambiguity into the open so people can resolve it — and if the code disagrees with the specification, the code is repaired or regenerated.

Every change runs the agentic development loop:

Specify. The engine extracts typed claims from intent, documentation, tests and, where it exists, legacy source code, retaining their source. Configured authority decides which evidence wins; equal authority remains a visible conflict, and an unresolved fact stays explicitly unknown rather than becoming a plausible guess. The model helps synthesise a candidate; typed gates hold it to the evidence.

Review and seal. A person resolves conflicts and seals the specification as a content-addressed revision in the repository: spec.md for requirements and scenarios, and design.md for architecture and decisions. Any specification change re-enters this human review gate.

Plan. Bounded units of work are derived from the sealed specification and ordered by dependency. The plan can be discarded and generated again.

Build. Each slice is handed the exact specification and plan entry it needs and built in an isolated working copy. Changes are integrated under explicit merge rules and the combined result is verified against the specification through replay gates before the revision label advances. A later run can resume from the last verified wave.

Code is disposable. Specifications are durable. Code is generated from the spec; the sealed specification is what you keep. Regenerate the plan or rebuild the code — spec.md and design.md preserve what the system must do and how it is designed. The verified label records repository state. It does not decide that an organisation should deploy or release it.

Zero trust for generated code

The business problem should be distinctive. The technology underneath it usually should not.

We built the runtime — Rust, on Wasmtime — so our engineers could stop selecting stacks. Instead of repeatedly choosing frameworks, importing provider SDKs and wiring infrastructure into application code, they wrote business behaviour against WASI-shaped capabilities: HTTP, messaging, key-value and blob storage, SQL and identity.

The same choice matters even more when agents write the code. As Anthropic’s Julian Schrittwieser notes, Rust’s type system and safety checks act like an expert code reviewer in the agent loop — rejecting invalid edits at compile time before a human ever sees them. And because the runtime handles the bridging to infrastructure and external resources, Wasm guests contain only business logic: a much simpler class of code to generate, with far fewer ways to get it wrong.

Containers give every dependency ambient access to network sockets, files and secrets. Application behaviour on our runtime runs in sandboxed WASI guest components inside the Wasmtime sandbox, starting with zero authority and using only the capabilities the host links. Guests request typed capabilities without embedding a concrete infrastructure client; the host supplies the backend, credentials, deployment configuration and policy.

This is constraint as leverage:

• No ambient authority. A guest component has no ambient filesystem, network, process or environment access. Generated code and its dependencies can act only through capabilities linked by the host.
• Typed, narrow interfaces. Capabilities are contracts, not conventions. A component either satisfies the interface or does not compile. That proves interface compatibility, not behavioural correctness.
• Business logic, not plumbing. The host owns clients, connection pools, retries, auth and SDK wiring. Agents generate pure domain behaviour against narrow capability traits rather than infrastructure glue code — requiring far fewer tokens and allowing smaller, less expensive models than building a full service from scratch.
• Inspectable grants. The linked capabilities are enumerable. Their concrete backend reach still depends on host credentials, configuration and infrastructure policy, which remain part of the review boundary.

With the platform safe by construction, agents work within known bounds while engineers focus on the product.

Next: local, open-weight models on a narrower target

Frontier models are needed to invent architecture — when an agent has to choose libraries, invent project structure and hold an entire codebase in context — not to fill in pre-scaffolded, compiler-checked slices. Our target build adapter removes that structural work before the model turn begins: it scaffolds the crate, module layout, typed routes, message consumers and scenario test skeletons from the sealed specification, then asks the model only to fill the behavioural markers and pass cargo clippy, cargo test and the wasm32-wasip2 compiler check.

Today, that narrow target already cuts token spend and lets smaller, less expensive commercial models handle implementation slices. In early proof-of-concept runs, the same scaffold-and-verify loop also builds working WebAssembly guest slices using an untuned open-weight model (qwen3-coder-next). Our current roadmap focus is hardening local, open-weight small language model support so sensitive systems can be built and verified on client-hosted hardware without depending on a cloud model API.

Fix the system, not the output

In an internal October 2026 evaluation, we recovered a specification from an anonymised real-time rail service, rebuilt it as a WASI component and held it to the fixed 22-case replay suite used for its hand-written counterpart.

An early generated build passed 0 of 22 cases. We did not rescue it with hand edits. Each defect changed the checks, guidance, extraction or tooling inherited by later builds. The latest build passes 21 of 22 cases, including all 12 recorded production-message cases. One case remains open and reported.

This is an internal evaluation of the delivery system, not a general performance claim. The useful result is that a failure becomes a reusable system capability rather than a one-off correction hidden in generated output.

Infrastructure portability

Write code once against capability contracts; bind them to local, cloud or on-premise services at deploy time. Each environment supplies a reviewed runtime recipe — the runtime, the capability bindings, identity and policy, configuration and observability — in the same shape: in-memory and local services for a local trial, managed services in the cloud, approved internal services on-premise. Where the runtime has a conforming backend, the host can substitute it without changing or recompiling guest application logic.

That allows a team to:

• develop and test against lightweight local implementations;
• deploy the same guest against selected production services;
• keep endpoints and credentials out of application code;
• exercise application behaviour through different backend implementations;
• change a supported backend with less application-code churn; and
• preserve more choice over cost, residency and providers.

Portability changes architecture conversations now. Teams can define the capability the product needs before choosing the service that supplies it.

Trust is contextual, not a maturity score

Explore, Govern, Connect and Support are situations to match, not levels to climb. The required safeguards follow what the application can reach, who depends on it and what happens when it fails. There is no virtue in moving every experiment toward business-critical operation; choose the least costly state that matches the actual consequence.

• State 0 · Explore. Local discovery: one builder, synthetic or local inputs, no shared dependence. Isolate and keep local.
• State 1 · Govern. Shared work: a named owner, an approved workspace and tools, protected changes and checks. The authoring boundary applies.
• State 2 · Connect. Live capability: an explicit purpose and owner, typed live-system contracts, host policy and operational visibility. The runtime boundary applies.
• State 3 · Support. Business dependence: durable reviewed intent, release and service ownership, recovery evidence and continuity decisions. The full delivery system applies.

Crossing one of these boundaries is a clearance, not an automatic progression. It requires a named trigger, sufficient evidence and an accountable decision-maker. Automation can produce evidence; it does not erase ownership.

The highest consequence sets the trust radius

Place the application on the same four-state scale along four dimensions:

• Reach — what it can access: a local environment, shared systems or live capabilities.
• Data — what it can read or change: synthetic data, project data, or live or regulated data.
• Dependence — who relies on it: one builder, a team, or customers and operations.
• Continuity — what must survive failure: discard it, restore it, or recover within an obligation.

Take the furthest answer, not the average. That answer sets the required state and its safeguards. Reassess whenever one of the four changes; the required state can move in either direction.

Decision rights stay explicit

• People set the outcome, source precedence, acceptance criteria and release authority.
• Models extract, propose, implement and repair. They do not make their own output authoritative.
• Deterministic controls enforce paths, grants, required evidence and checks.
• The runtime host decides which application capabilities exist and retains their credentials and infrastructure policy.
• The release and service owners accept operational consequence and remain responsible for recovery.

What we do not claim

Most tooling pages overclaim. We would rather state the boundary precisely, because the boundary is where your risk assessment actually happens.

• The runtime is not a managed platform and does not offer broad multi-cloud support out of the box. It sits inside a client-owned solution; the host backends and cloud deployment assets available are named and verified for each engagement.
• The portability promise is narrow and useful: supported host backends can change without changing or recompiling guest application logic. Data migration, provider-specific semantics, performance, cost and operational equivalence still require explicit work and verification against the target service.
• The WebAssembly sandbox does not replace infrastructure security. Credentials still need appropriate scope, network and egress policy still apply, shared backends need appropriate isolation, and every linked capability or writable mount is a real grant. Host configuration is part of the security boundary.
• The authoring boundary is only as strong as its worker sandbox, toolchain and grants. Approved adapter and toolchain code remains trusted code, and a broad grant remains broad.
• The delivery engine’s workflow is review-gated and single-node. People authorise privileged execution, publication and release. We do not claim unattended delivery.
• Model-assisted review is useful; it is not host-attested proof. Verification is described at the level actually achieved.
• Local, open-weight small-model code generation is active roadmap work, not a general production default today. While our narrow target already reduces token volume and allows smaller, cheaper commercial models in current engagements, proof-of-concept runs with untuned qwen3-coder-next show the target is narrow enough for local open-weight models, and we are working to make that path production-ready.
• The internal evaluation above is evidence about one fixed case set, not a production guarantee or a benchmark for another system.
• Terraform modules, GitHub Actions workflows and environment patterns are reusable Propellerhead delivery assets applied around a Wasm-shaped solution, not features of the runtime.

If a claim anywhere on this site ever seems larger than this list allows, the list wins.

This is the shape of software we deliver

Prototype, legacy codebase or new service — every change runs the same governed path:

• Prototype to production. Extract intent from a rapid or citizen-built prototype and rebuild it as a supported service.
• Legacy modernisation. Recover specifications from legacy code, tests and documentation and regenerate a clean implementation.
• Cloud portability. Build once against capability contracts and move across local, cloud and on-premise environments by swapping the runtime recipe.
• High-trust systems. Deliver at AI speed in regulated environments with auditable specifications, compile-time rules and a zero-trust runtime sandbox.

Readiness and advisory work may stop before implementation. When Propellerhead writes the application, it runs on our WebAssembly runtime. The business problem stays unique. The way the software runs, is tested and is released does not have to be invented again.

Explore new systems

Explore modernisation

Explore continuous improvement