Shipping Faster With an AI Workspace and Dev Tools, Without Dropping Human Review

You ship faster with AI coding agents by moving the checking earlier and making it mechanical, so that a person spends review time on judgement and not on things a script can catch. Write the rules down where the agent reads them, enforce the important ones in the build, give each agent its own working copy, define what "done" means before work starts, and hold every risky action for a human decision. Speed that comes from skipping review is borrowed from whoever is on call next month.

This guide describes what Swfte actually does on its own website, what the Cortex and Nexus products do when they hand coding work to an agent, and where the two are different. We have not published speed figures and this post does not offer any.

What should "faster" not mean?

It should not mean fewer people looking at the change. It should not mean an agent granted wide permissions because prompting for each step was tedious. And it should not mean a green tick that nobody can trace to evidence.

Faster, done well, means the dull parts of the loop shrink: finding the right file, writing the first draft of a change, running the same checks every time, producing a summary of what changed and why. The decisions stay with a person: whether the change is the right change, whether it may touch this folder, whether it may push.

A useful test for any AI-assisted workflow is to ask what happens when the agent is wrong with confidence. If the answer is "a person would notice at review", check that review is real and that the person is shown enough to notice. If the answer is "it would go straight to production", you have not made the team faster, you have moved the cost.

How does Swfte build its own website?

In use at Swfte: the website is built with the Claude Code command line tool. The repository has a rules file, CLAUDE.md, that tells any agent working in it how the project is laid out, which commands to run and which rules are not negotiable. We run our coding agents through Nexus capture on the founder's machine, so that what they did is recorded. Several agents often work at once, each in its own git worktree. Larger pieces of work carry a completion-gate ledger, which we come back to below.

The engineering workflow page sets out the same practices with their status labels. Here, we are deliberately modest about it: it is a small, real set of habits, not a platform demonstration.

One line we want to be plain about. Cortex does not front our own website work today. We build the site with Claude Code directly. Cortex can hand coding work to a coding agent through Nexus, and that capability is built, but we do not claim we use it on this repository, and the sections on grants and approvals below describe the product, not our daily routine.

What goes in a rule file?

Write down what a capable new colleague would otherwise learn by making a mistake. A good rule file is short, specific and about consequences.

Include these:

• Layout and commands. Where the app lives, how to install, run, lint and type-check.
• Things that must never change silently. Ours includes localised URL slugs: once a slug ships, its translation is frozen, and the lockfile is append-only. The file says why, in terms of what breaks.
• Workflows for common tasks. "To add a page, do these three things in this order."
• Anti-patterns to refuse. Spell out the tempting shortcuts, such as regenerating a lockfile from the current dictionary, and say no.
• Where to stop and ask. Name the actions that need a person's approval before the agent proceeds.

Leave out anything you cannot defend. A rule file full of preferences trains the agent, and the reader, to treat every line as optional. Keep each rule tied to a reason. If you cannot say what goes wrong without it, delete it.

How do you make the rules stick?

Move every rule you can from prose into a check that fails the build. A rule in a document asks the agent to remember. A rule in a script does not.

In use at Swfte: our prebuild chain runs a script that fails if a page slug is missing from the slug lockfile, and another that fails when price data passes a verification age. The agent does not need to be reminded about either, because the build says no. When an agent or a person tries the shortcut the rule file warns about, the failure is immediate and names the problem.

A caveat we should state: those prebuild checks run locally. Our continuous integration on the website runs security scanning, not these checks. If a rule matters, know where it is enforced, and do not assume a pipeline you have not looked at is doing it.

A good habit is to treat each new "the agent did something silly" incident as a candidate for a check. Write the check, then trim the rule file, so that the prose gets shorter as the enforcement gets stronger.

How do parallel agents avoid colliding, and how do you know a task is finished?

Give each agent its own git worktree. A worktree is a second working copy of the same repository on its own branch, so two agents editing at once cannot overwrite each other's files, and each piece of work can be reviewed and discarded on its own. It also gives you a clean answer to "what exactly did this agent change?": the diff of its branch.

For "done", we use completion-gate ledgers. For a substantial task, a gate list is written before the work starts. Each gate says what must be true, and where it can be checked, names a command and the result expected. At the end, the evidence is recorded against each gate. We say plainly that this is uneven in practice: on our website, only some gates carry a runnable command and many rely on written evidence. The stronger examples are in the audit of our Cortex application, where each gate pairs a check, an expected result and recorded evidence. The point is the discipline. A companion post on automating code and change review, goes deeper into ledgers.

What happens when Cortex hands coding work to an agent?

Built in the product: a Cortex assistant can pass a coding task to Claude Code or Codex through Nexus. The agent starts inside a wrapper that applies policy and records what happens. You control four things.

Folders. Coding work is limited to folders you have granted, checked against the real path on disk, so a symbolic link cannot carry the agent somewhere you did not intend.

Mode. There are three. Plan mode is read-only: the agent can look and propose. Edit mode allows file changes. Run mode adds shell commands. Start with plan, read what it intends, then move up.

Held calls. When the policy says ask, the call is held and appears in the chat as an approval card. The agent waits for you.

Timeouts. A prompt that nobody answers within a short time is treated as a denial. Silence never turns into permission.

Two honest limits. If Nexus is not installed, the handoff falls back to an ungoverned run, so check that governance is actually active before you trust it. And a developer environment flag exists that bypasses tool prompts; it is for testing, it is not the default, and it should never be set where real code or credentials are within reach. For the product view, see Nexus and Cortex.

Which actions always need a person?

Reading is cheap, so the default is generous for reading. In Cortex's Claude Code sessions, the file reading, file-matching and search tools are allowed automatically, and everything else asks.

On top of that sits a gate for high-risk actions: sending, paying, deleting, pushing and running shell commands. In the product, that gate applies on all chat tool routes, even when a user has turned on auto-approve. It is deliberately over-cautious, because a false alarm costs a click and a missed one can cost far more. Approvals are issued by the application's main process and bound to the exact call, so a prompt for one command cannot be reused to authorise a different one.

You can copy the principle without any of our software. Make a list of the five or six actions in your workflow that cannot be undone or that leave your boundary. Require a named person to approve each one, every time, and make the default on silence a refusal. The enterprise AI workspace rollout checklist puts these decisions in a rollout order, and controlled autonomy explains how to widen the list of things an agent may do by itself only when evidence supports it.

What does capture give you?

A record. Nexus capture writes down what the coding agent was asked, which tools it called and what it changed, so that a review can start from "what happened" and not from a guess. It is the difference between reading a diff and understanding the session behind it.

Capture is not governance by itself. It tells you what happened; the grants, modes and approvals above decide what may happen. Run both. And be clear about what a record cannot do: it will not tell you the change was a good idea. That is still the reviewer's job. For wider monitoring, see observability for agents and workflows.

What is built, and what is design intent?

In use at Swfte: Claude Code builds the website, a rules file guides it, prebuild checks enforce some of those rules, agents work in separate worktrees, larger tasks carry completion-gate ledgers, and Nexus capture records our coding agents. Built in the product: Cortex handing coding work to Claude Code or Codex through Nexus, with per-folder grants, three modes, held calls shown as approval cards and timeouts that deny. We do not claim we run that on our own website. Designed for: a company-wide approach where these controls share one policy and one approval inbox; today approvals live in several separate parts of the platform. Where your organisation sits depends on your tooling and configuration. See governed agents for the wider approach.