Development Environments and Mobility
Part 3 of The AI-Assisted Software Engineering Workflow.
Development Environments and Mobility
Current Default: Local Execution
Local development remains the best fit because it provides:
- Docker CLI and the complete development toolchain
- Straightforward inspection of changes
- Direct access to local services and resources
- Easier testing and integration
Cloud Environment Findings
Codex cloud environments: setup friction is too high for the current workflow.
Claude cloud environments: marginally better because containers can resume, but missing tools and awkward local inspection reduce their value.
The current conclusion is not that cloud execution is unusable, but that vendor-controlled cloud workspaces do not yet fit a heavily tooled local workflow.
Bring-Your-Own Portable Environment
The more promising experiment is a project-owned development container:
- A common base image contains shared tools and interfaces.
- A project image layers dependencies and project-specific services.
- Source may be mounted or baked into selected images.
- Existing container hosting can provide a remote, reproducible workspace.
Open design questions include:
- Baked source versus mounted source
- Git and credential handling
- Secrets management
- Docker access from the development container
- Remote editor experience
- Propagating base-image updates
- Persistence and backup of in-progress work
Multi-Machine Synchronization
Dropbox currently transports unfinished work between machines without requiring a WIP commit for every handoff. Git remains authoritative version control.
This is convenient but requires discipline:
- Do not edit the same workspace concurrently on multiple machines.
- Wait for synchronization before changing machines.
- Treat conflicts and partial synchronization as operational risks.
- Continue using commits for durable, meaningful history.
A future improvement is an automatic handoff snapshot: save, optionally validate, create a recoverable checkpoint, and synchronize or push to a temporary branch.
Distributed Execution
Remote-capable tools allow one machine to run planning or analysis while another handles interactive implementation and review. This can separate contexts and overlap long-running work, but it is an optional organizational technique rather than a fundamental capability multiplier.