Choosing an AI Coding Environment

A durable checklist for matching the task to conversational help, a cloud workspace, or local repository work.

Start with where the code lives and what the change touches. A single function explained in a chat thread, a multi-file change across branches with tests, and a local repository edited with a terminal and Git history are different jobs. They need different AI coding agent environments, even when the same assistant model answers the question.

Ethen's architecture direction describes Code as one system exposed through three levels: lightweight help in Chat, a full cloud workspace in Platform, and a local agent workspace in Desktop. That separation is a design target, not proof that every migration has shipped. It is still a useful way to choose: each level assumes a different scope for files, execution, history, and review.

This guide compares the three patterns, shows what to check before you commit to one, and names the limits visible in the inspected implementation files.

The three patterns in one picture

The architecture document lists the intended Code surfaces explicitly:

• Chat Code is lightweight conversational coding: explain a snippet, write a function, fix a bug, make a component, edit a pasted fragment.
• Platform Code is a full cloud engineering workspace: repositories, branches, agents, terminal, multi-file editing, pull requests, builds, tests, deployments, and environments.
• Desktop Code is a local coding-agent environment: local repositories, local terminal, local models, cloud models, Git, agents, file editing, and commands.

The same document states that all three should share architecture and project state where appropriate, and its ownership matrix assigns Code canonically to Platform plus Desktop, with only a lightweight version in Chat. Desktop itself is defined as Chat plus Code plus Local Models.

That framing gives you a stable decision rule:

• If the work fits in one message and leaves no repository trace, conversational help is enough.
• If the work spans files, branches, builds, or team review, you need a workspace with repository scope.
• If the work must stay on your machine or use a local runtime, you need a local environment with explicit local controls.

None of these implies automatic end-to-end delivery. The Platform list includes deployments and environments as workspace concerns, but the inspected sources do not establish an automatic pipeline from prompt to production. Treat deployment as a separate step with its own checks, regardless of which surface drafts the change.

Conversational help: when a snippet is enough

Conversational coding help answers questions about code without taking ownership of a repository. The architecture examples are deliberately small: explain this code, write a function, fix this bug, make a React component, edit this snippet.

This pattern fits when:

• You bring the context in the prompt and can judge the answer by reading it.
• The change is one function, one file section, or one concept.
• No terminal, branch, test run, or pull request is required to accept the result.
• You will paste the result into your own editor and keep responsibility for integration.

Chat is described as intentionally limited. It should remain a simple general-purpose conversational product, not absorb the full Computer product, full Research workspace, full Studio catalog, or full autonomous Founder system. The rule that one capability has one canonical owner reinforces the point: Chat can expose a simplified version of Code, but it is not the canonical home for repository work.

Practical checks before you rely on conversational help:

• [ ] Can you paste every dependency the answer needs, or does the helper need to read files you cannot see?
• [ ] Can you test the suggestion in your own toolchain after you receive it?
• [ ] If the suggestion is wrong, is the blast radius one snippet or a whole branch?
• [ ] Do you need history, attribution, or rollback beyond your chat transcript?

If any answer points outside the thread — another file, a failing test, a branch diff — move up to a workspace. Conversational help does not stop being useful; it stops being sufficient once the change has repository scope.

A durable habit: use the chat thread for learning and drafting, then re-apply the accepted change inside the environment that owns the files. That keeps the explanation where it is readable and the edit where it is reviewable.

Cloud workspace: when the work spans files and review

A cloud engineering workspace assumes the unit of work is a repository change, not a message. The Platform Code scope names the pieces: repositories, branches, agents, terminal, multi-file editing, pull requests, builds, tests, deployments, and environments.

Choose this pattern when:

• The task edits more than one file or must stay consistent across a branch.
• You need a terminal, build, or test run to validate before review.
• The change will go through a pull request or shared history.
• Teammates need to see the same files, diffs, and checks you see.

The value here is shared state and review surface. Multi-file editing without branch scope drifts quickly. A workspace that can show the diff, run the checks, and attach the result to a pull request keeps the agent's work inspectable.

What to verify in any cloud-style setup, regardless of vendor:

• [ ] Repository scope: which repositories and branches can the agent read and write?
• [ ] Execution scope: can it run shell commands, builds, and tests, and where are those runs logged?
• [ ] Change representation: does it produce diffs, checkpoints, or patches a reviewer can walk file by file?
• [ ] Identity scope: whose history does a run belong to, and what happens on sign-out or account switch?
• [ ] Deployment boundary: is deployment a manual, reviewed step, or is it conflated with drafting code?

The last two points deserve emphasis because they are easy to overlook. The inspected coding-run persistence code scopes runs to the signed-in owner, discards the previous scope on account change, and broadcasts identity changes across tabs so follower tabs fail closed. That is a local account-isolation design, not evidence of cloud sync or team backup. Do not assume that because a run survives a restart on one machine, it is visible to teammates or preserved on a server. Ask where history lives and who can read it.

Similarly, do not read the word deployments in an architecture list as a promise of hands-free release. The binding limit for this guide applies broadly: no claim of automatic end-to-end deployment is supported by the inspected sources. A workspace can prepare a change and run checks; release still needs its own approvals, environments, and rollback plan.

Local repository work: when the machine matters

Local repository work keeps files, execution, and optionally the model runtime on your own machine. The Desktop Code scope names local repositories, local terminal, local models, cloud models, Git, agents, file editing, and commands. Desktop as a whole is defined as Chat plus Code plus Local Models, and Local Models is assigned canonically to Desktop rather than to the web Platform.

Choose a local environment when:

• The repository cannot leave the machine for policy, size, or network reasons.
• You need a local terminal, local Git history, or machine-specific tooling.
• You want to try a local model path alongside cloud models for drafting or review.
• You need coding help during travel, on a restricted network, or inside a controlled checkout.

Local does not mean unbounded. The inspected Desktop IPC file for local models shows what narrow local control looks like in practice:

• The main process owns privileged access to the local runtime endpoint. The renderer can only call named, allowlisted methods.
• Only localhost endpoints on the expected Ollama port are allowed. No arbitrary URL fetch is exposed to the renderer.
• Model names are validated before any adapter call.
• No raw renderer access to Node, filesystem, child processes, shell, or secrets.
• Pull and chat progress streams through a single allowlisted event channel.
• A request registry supports cancellation without exposing raw controllers to the renderer.

That structure is a useful checklist for any local coding setup, not just this one. Ask which process holds privilege, which channels are allowlisted, and how a long pull or chat can be cancelled cleanly.

Local model operations also carry explicit user-confirmation and scope limits in the inspected code:

• Pull and delete are mutations. The main process presents a native confirmation dialog and proceeds only on explicit in-window confirmation. A renderer-supplied approval object is ignored.
• The pull acknowledgement states the download comes from the public Ollama registry to local disk over the network. The delete acknowledgement states the model is permanently removed from disk.
• Chat requests must include a valid model name and messages with roles and content, then stream deltas and completion or error events.
• Installed and running lists, status, and model details are read operations. They do not imply a searchable catalog.

The catalog limit is stated directly in the handler: Ollama does not provide a searchable model catalog API, so the list-catalog channel returns an empty list with guidance to use the CLI or browse the public search page. That is a good reminder for environment choice. Local discovery, download, installed, running, updates, storage, quantization, GPU, CPU, RAM, and local endpoints are listed as Local Models concerns in the architecture direction, but any specific discovery experience depends on what the runtime actually exposes. Verify each operation instead of assuming a full store.

Practical checks for local repository work:

• [ ] File scope: which local paths can the agent read, edit, and execute?
• [ ] Runtime endpoint: is model access localhost-only, and which port and protocol are enforced?
• [ ] Mutation approvals: do downloads and deletions require an explicit out-of-band confirmation?
• [ ] Cancellation: can you cancel a pull or a streaming chat and see a terminal cancelled or error event?
• [ ] Persistence: where do runs live after restart — browser storage, a local JSON file, or somewhere else — and who owns them?
• [ ] Model choice: can the same local workspace use both local models and cloud models, and is the active path visible?

The Desktop Code scope explicitly includes both local models and cloud models. That dual path is convenient, but it makes the active route worth checking on every task. A local checkout does not guarantee local inference. Confirm which path a given run used before you reason about data handling or reproducibility.

History, identity, and restart behavior

Coding environments differ less in how they draft text than in how they keep history. The inspected persistence file gives a concrete local model to learn from, with clear boundaries.

What the file establishes:

• Runs are keyed per signed-in owner under a scoped key, with a legacy global key for anonymous use.
• Binding a new owner discards the legacy global and the previous owner's scoped entries. Same-owner re-entry is a no-op so remounts do not wipe the current actor's runs.
• Sign-out runs a named sweep that discards the legacy key and the signed scope, then broadcasts so follower tabs fail closed. The call is meant to run before any redirect.
• Cross-tab propagation uses a shared broadcast channel with identity-change messages for sign-in, sign-out, and account switch.
• Durable local runs survive restart through browser local storage and, on Desktop or Node, a file-backed JSON document under the application data directory with a temporary-directory fallback. Writes are crash-safe through atomic write-to-temp plus rename. SQLite is explicitly not required for that trial path.
• Stored runs are normalized on load so older builds missing newer fields cannot crash downstream spreads or array calls. Load, save, and clear helpers define the full lifecycle in one place.

What the file does not establish:

• Cloud backup, cross-device sync, or team visibility for runs.
• Server-side audit, retention policy, or access control beyond local owner scoping.
• Any guarantee that a run preserved locally is the same artifact a reviewer sees in a pull request.

Turn that into portable questions:

• [ ] If you sign out, is the previous history removed from the machine or merely hidden?
• [ ] If you switch accounts, can the next account see the prior account's runs?
• [ ] If you open two tabs, does an identity change in one invalidate the other?
• [ ] If the app restarts or the file is corrupt, do you get an empty state or a crash?
• [ ] If you need evidence for review, does the persisted run include events, changed files, checkpoints, approvals, usage, and validation results — or only the final text?

The normalization list in the file is a useful schema hint: events, queued messages, validation results, changed files, patch checkpoints, final review, completion state, repair result, sandbox, approval records, storage mode, usage, limits, evidence chain, handoff, and security validation. You do not need every field on every task, but a workspace that cannot show changed files and validation outcomes is a drafting tool, not a review surface.

A decision checklist you can reuse

Use this table when the choice is unclear. Answer from observed behavior, not marketing labels.

A second, shorter pre-flight list helps before you let an agent touch a real checkout:

• [ ] State the change in one sentence and name the files it may touch.
• [ ] Confirm the active model route: local runtime or cloud path.
• [ ] Confirm the write scope: read-only, listed paths, or whole repository.
• [ ] Confirm how to stop: cancel control, terminal event, and what partial work remains.
• [ ] Confirm how to review: diff, changed files, test output, and approval record.
• [ ] Confirm where history goes: local file, browser storage, shared workspace, or nowhere.

If you cannot answer those six, narrow the scope until you can. Smaller, reviewable steps beat larger, opaque runs in every environment.

Evidence and limitations

This guide is grounded in three inspected local sources, plus two route indexes used only to verify link destinations.

The architecture direction defines the intended separation: Chat stays simple with lightweight Code; Platform holds the cloud Code workspace; Desktop holds local Code and canonically owns Local Models; Computer management stays Platform-only. Its header marks it as final architecture direction. That status supports statements about intent and ownership, not statements that a migration or product has shipped. Target separation is never treated here as release proof.

The coding-run persistence file supports statements about local account scoping, sign-out cleanup, cross-tab invalidation, restart durability through local storage and atomic file writes, and defensive normalization of older run shapes. It does not support claims about cloud sync, team sharing, server retention, or deployment automation.

The Desktop local-models IPC file supports statements about narrow allowlisted channels, a single event stream, localhost-only endpoints, model-name validation, main-process ownership of privilege, explicit native confirmation for pull and delete, cancellable pull and chat requests, and the absence of a searchable Ollama catalog API in that path. It does not support claims about benchmark quality, model rankings, or universal local availability.

Link destinations were checked against the web route registry and the frozen marketing copy index. No invented hosts, article routes, or model slugs are used.

Two boundaries apply to the whole comparison. First, no environment described here is presented as superior. Each fits a different scope for files, execution, and review. Second, no automatic end-to-end deployment is claimed. Preparing a patch, running checks, and releasing to an environment remain separate steps with separate approvals.

Ending

Choose the smallest environment that can hold the change and its evidence. Use conversation for learning, a repository workspace for shared or multi-file work, and a local setup when the machine, runtime, or checkout must stay in your control. Revisit the checklists when the scope grows: the right move is often to graduate the task, not to stretch the tool.