ADI Code is theLAB's self-hosted, browser-based coding workspace built on OpenCode. It brings a conversational coding interface together with model selection, project workspaces, and tools that can reach other machines in an authorized lab environment.
This article describes the project's design and a safe working method, not a public access endpoint or an inventory of private machines. The project showcase contains a demonstration.
From a chat window to a workspace
A coding assistant needs more than a model. It needs the correct repository, access to relevant files, a way to run checks, and a record of what it changed. ADI Code puts those operations behind a browser interface while the actual work runs on a server.
Browser -> authenticated workspace -> coding agent
-> repository files and checks
-> configured model provider
-> approved remote tools
The workspace and model runtime are separate concerns. A model may run locally or through a hosted provider; selecting a local-looking gateway does not by itself establish where inference happens. Check routing before sending private code.
A typical task
- Select the project directory and inspect its current Git status.
- Read repository instructions and find the code that actually handles the behavior.
- Give the agent a concrete outcome, relevant constraints, and a verification command.
- Review its proposed or completed diff, including dependency and configuration changes.
- Run the appropriate checks in the environment that will execute the code.
- Commit or deploy only after the authorized reviewer approves that action.
For example, "fix upload validation and run the upload tests" is more useful than "improve the backend." Define what must stay unchanged, especially persisted data and public APIs.
Reaching other machines
An orchestration tool can launch an agent on another authorized host and return status or output. This is useful when the repository, runtime, or hardware lives elsewhere. Remote execution does not make working directories, environment variables, or installed dependencies interchangeable.
Treat every remote operation as a separate boundary: verify the hostname, user, directory, and repository before editing. A successful SSH command normally exits after that command; it is not evidence that later unwrapped commands run remotely.
Delegation and review
Parallel agents work best on independent tasks with explicit file ownership. One might inspect tests while another researches an API. Two agents rewriting the same module usually create review work rather than save time.
Use Multi-Agent Coding: Delegation Without Chaos for the coordination pattern and Context Engineering for Coding Agents for choosing what each agent should see.
Security and recovery
Keep the workspace authenticated and restrict filesystem and remote-tool access. Agent-visible repositories can contain malicious instructions; they are not a substitute for the user's authorization. Do not give a coding container the Docker socket or unrestricted credentials merely for convenience.
Preserve user edits, keep a recoverable deployment artifact, and back up workspace data separately from the application image. A passing build is not proof that a deployment preserves authentication, uploads, or database state.