Software Engineering on the Platform
Software engineering here is not a single "AI writes code" button. It is a whole experience inside a workspace or a clean room: consoles for submitting governed coding runs, connecting and browsing repositories, and promoting a change stage by stage, sitting alongside the notebook, SQL, and compute tabs the same engineer uses. The engine behind those consoles is documented in the coding agent; this page is the surface, what a developer actually touches, and how it fits the workspace model.
There is no hosted code editor, no language-server integration, and no editor plugin. The only in-console code-editing surface is the SQL editor. The coding consoles are for submitting, watching, and reviewing governed runs against a connected repository, a different product from an AI pair-programmer inside someone's laptop editor.
Software engineering is one of six experiences
A workspace console carries a large tab set. Rather than showing every tab to everyone, the console projects the set through one of six experiences, with governance and identity tabs always on in every one. Software Engineering is the experience that foregrounds the coding surface; the same projection is available in a clean room, whose host passes the room's scope and drops no capability.
*Figure SE1: the software-engineering surface. The Software Engineering role
experience (cyan) projects the coding, repository, and delivery consoles plus the
shared notebook / SQL / compute tabs into a workspace or clean-room console;
submitting from the Coding console runs a governed coding run on the compute
service (green). The same run is also reachable as an agent tool
(coding.submit).
Table equivalent
| Element | What it is | Notes |
|---|---|---|
| Developer | The engineer using the console | Works inside a workspace or clean room |
| Workspace / Clean Room console | The working environment the experience runs inside | Governance and identity tabs are always on; a clean room passes its scope and drops no capability |
| Software Engineering experience | The experience projection that foregrounds the coding surface | One of six experiences (data engineering, data analyst, data science, software engineering, consulting, security) |
| Coding | Submit and watch governed coding runs | Pick crew formation, autonomy mode, model, and budget |
| Repositories | Connect a repository, list bindings, browse branches, read the log and a diff | See Source control & git |
| CI/CD | Pipelines, runs, an approval queue, promotions, and rollbacks | See Source control & git |
| Notebooks · SQL Editor · Agents & Skills · Compute · Automations · Logs | Shared tabs the same experience surfaces | The SQL editor is the only in-console code-editing surface |
| Governed coding run | A run on the compute service | The engine: see the coding agent |
coding.submit / coding.status / coding.cancel | The run exposed as agent tools on the fabric MCP surface | An external or another platform agent can hand work to the coding spine through the node front door |
The three consoles a developer touches
The consoles are the same components in a workspace and in a clean room.
| Surface | What it does |
|---|---|
| Coding | Submit a governed coding task against a connected repository; pick the crew formation, autonomy mode, model, and budget; watch the run list |
| Repositories | Connect a repository, list bindings, browse branches, read the log, read a diff |
| CI/CD | Pipelines, runs, an approval queue, promotions, and rollbacks: approve, reject, and roll back in place |
Inside a run, four panels carry what matters to a reviewer: a live run watch
streamed over server-sent events (plan, seats, elapsed, sub-agents, chain
verdict), a diff-provenance view of the signed receipts, a findings view
of what the pre-commit scan surfaced, and the run's project memory. A
provider-credential banner warns when the model credential behind a run is
expiring or expired, computed from the persisted provider registry, and honestly
reported as unknown where an expiry is not introspectable.
Workspaces for code
A workspace (or clean room) is a whole working environment, not a folder. For software engineering that means the code surface inherits the workspace's identity, governance, and isolation without a separate setup:
- Compartment-scoped retrieval. Semantic code retrieval runs over a vector space physically scoped to the workspace and compartment, so a run cannot reach another workspace's code.
- Workspace-isolated project memory. Conventions, decisions, gotchas, and architecture notes persist across runs, bitemporally (with citations and as-of / valid time); a fact written under one workspace is stamped with it, and a recall under another resolves a scope that never dereferences it.
- The same surface in a clean room. When two or more trust domains must collaborate without trusting each other, the coding surface opens in a clean room with its isolation controls permanently on screen, no capability dropped.
The formation library
A coding task can run as one agent or as a crew. The built-in role blueprints each carrying an enforced tool ceiling, and the crew formations are browsable read-only from the authoring Studio, independent of scope. Studio answers what team runs; the workspace or clean-room Coding tab answers run it on this scope's repository. A seat is equipped with exactly its role's tool ceiling, so a read-only seat cannot apply a patch. The mechanism is covered in the coding agent's crews.
See also
- the coding agent: the engine: consoles, crews, the pre-commit scan, and the disconnected edge surface.
- What a run does: the six phases, the three terminal states, and the signed receipt chain.
- Source control & git: repository governance, graded git authority, and build & dependency hygiene.
- Infrastructure as Code (Terraform), managing the estate as code with the System9 Terraform provider.
- Tools & MCP, the coding run exposed as agent tools.