Development Environments, Compute, and Composable Infrastructure

3. Enduring Principle

Treat the environment as a versioned execution dependency

A Development Environment Contract should identify:

• repository set, baseline commits, checkout layout, and writable paths;
• operating system, architecture, image, language runtimes, package managers, compilers, browsers, and tool versions;
• build, test, lint, migration, startup, readiness, and cleanup commands;
• required local and shared services, endpoints, test data, and feature flags;
• human, service, worker, and repository identities;
• secret references and credential-minting policy;
• filesystem, process, network, egress, and resource boundaries;
• preview ports, URLs, access policy, and evidence capture;
• cache inputs and invalidation rules;
• lifecycle, timeout, suspend, teardown, and orphan-recovery behavior; and
• environment attestation and qualification evidence.

The Execution Manifest binds an exact environment version to an Attempt. A floating “latest” image or mutable workstation state prevents meaningful reproduction.

Separate environment orchestration from compute allocation

The compute provider exposes allocation, start, stop, snapshot, measure, and termination. The environment provisioner makes that resource useful for a specific software system. Keeping the boundary explicit permits managed compute, bring-your-own compute, or an internal fleet without rewriting factory authority.

Choose persistence deliberately

Ephemeral environments are created from a declared state and destroyed after work. They reduce drift and cross-run contamination but incur cold-start, clone, dependency, and authentication cost.

Persistent environments retain checkouts, caches, and credentials across runs. They start faster and require drift detection, cleanup, credential rotation, capacity reservation, and stronger reconciliation.

The pets-versus-cattle analogy describes operational replaceability. A replaceable worker can be rebuilt from automation; a pet requires individual repair. Small teams may begin with a few persistent workers, but should still automate bootstrap and prove that a replacement can be created from declared state.

Make startup and preview part of the product contract

Measure queue wait, allocation, checkout, dependency restore, service startup, readiness, and first useful tool call separately. Use golden images, content addressed caches, partial clones, warm pools, and preflight only when their invalidation rules are explicit.

For user-facing software, a reviewable preview is part of the result. It should have a stable Attempt identity, authenticated access, bounded lifetime, environment and commit labels, health state, logs, and deterministic teardown. A preview URL is not evidence of correctness; it is an interface through which humans and validators can gather evidence.

Design the worker fleet as a production service

Fleet controls include:

• typed queues and priority classes;
• concurrency and tenant quotas;
• admission based on required architecture, tools, network, and capacity;
• autoscaling and warm-capacity policy;
• backpressure and load shedding;
• lease, heartbeat, fencing, cancellation, and drain;
• timeout budgets and classified retry;
• exponential backoff with jitter for transient dependencies;
• circuit breakers and provider failover;
• dead-letter or quarantine handling for poison work;
• capacity, cost, utilization, and orphan accounting; and
• service-level objectives for readiness, dispatch, teardown, and recovery.

Backoff and retry do not authorize another external effect. Idempotency and reconciliation remain required whenever allocation, publication, or teardown may have succeeded before the response was lost.

Compose the stack one layer at a time

Evaluate build, buy, or bring-your-own choices independently:

For enterprise use, compare identity federation, tenant isolation, data residency, private networking, egress controls, key management, audit retention, quotas, chargeback, support, and exit procedures. For open-source or open-core components, also examine license, release cadence, maintainer health, dependency provenance, vulnerability response, upgrade compatibility, and the ability to operate without a hosted control service.

8. Notes and lessons learned

• A sandbox can be safe and unusable; a development environment can be usable and unsafe. The factory needs both properties.
• Cold-start time is a product metric because it directly affects validated lead time and human trust.
• Bring-your-own compute does not remove integration responsibility; it changes who owns the resource boundary.
• A preview is a temporary review surface, not an acceptance decision.

9. Interview and discussion questions

1. How does a development environment differ from a sandbox and from compute?
2. When should agent workers be persistent instead of ephemeral?
3. Which environment fields must be frozen for reproducibility?
4. How would you connect a remote worker to shared internal services safely?
5. What does an enterprise build-versus-buy review need beyond price?
6. Which fleet signals should pause autonomous execution?