The case for owning the harness
Our studio's whole approach is built on owning the things we depend on — it is the argument we make to clients about bespoke software every week. It would be strange to make that argument and then hand our own core workflow to a single closed box.
OpenCode is an open-source coding agent that runs in the terminal, in the same family of tools as the commercial agents we already use. The differences that matter are not benchmark points. They are structural: the harness is inspectable, the configuration is files in our repository, and the model behind it is a choice rather than a subscription.
What the terminal-first shape buys
Running the agent in the terminal, next to the tools it is editing, changes the texture of the work. The agent reads the same repository state we do, runs the same commands, and its output lands in the same review loop as everyone else's changes. There is no parallel universe of “AI work” — there is just work, some of it delegated.
It also suits how we actually build for clients: static exports, strict type-checking, prebuild gates that fail loudly. An agent that has to pass through the same build checks as a human cannot quietly ship something the pipeline would reject.
Model choice as a numerical decision
A practical benefit that surprises people: separating the agent from the model turns model selection into a per-task decision rather than a per-seat purchase. A fast model can handle file-triage and mechanical edits while a stronger one handles the planning pass, and you can change that split as the model landscape moves — which, over the past year and a half, it has done repeatedly.
When the landscape moves, an open harness moves with it. Upgrading is a config change, not a procurement exercise. For a small studio, that agility is worth more than any single-week benchmark win.
The trade-offs, stated plainly
The cost of openness is polish. Commercial agents are slick, integrated and supported; an open-source CLI expects you to read its configuration and occasionally its source. That is a real cost, and we would not pretend otherwise.
But the offsetting benefit is alignment with everything else we believe: tools you can inspect, configure and keep, on top of a stack you own. The AI workflow is now part of our build system, and parts of the build system should be ours.
The setup, committed to the repository.
The agent's configuration lives in the repository like everything else that matters: instructions, conventions and review expectations versioned alongside the code they govern. New work starting from the same repo inherits the same working agreement without a briefing call.
That may sound like trivia; it is actually the governance model. When the agent's behaviour is a reviewed file, improving the agent is a pull request — and the studio has a written, evolvable agreement with its tools rather than a mood.
How work actually flows.
The daily shape: plan in one session with the stronger model triaging what the work needs, build in the terminal with the fast model making diffs against a spec, review with fresh eyes against the checklist, and let the pipeline — not the mood — decide what merges.
The loop is not autonomous in the sci-fi sense; it is supervised, gated and boring on purpose. The excitement, such as it is, belongs in what ships — not in how the shipping works.
Upstream drift, handled on purpose.
Open tooling has one obligation people forget: it moves, and you have to keep up on purpose. The studio treats upstream updates of the harness the way it treats dependency updates anywhere — changes read before they are adopted, breaking notes treated as commitments, and the version capped where stability matters.
The discipline transforms openness from a risk into an asset: when the tool's behaviour is knowable and its direction readable, an update is an informed decision rather than a surprise.
Getting started if you are not there yet.
For a studio considering the open-agent path, the real prerequisites are cultural: a review culture that actually reviews, tests that encode expectations, and comfort in a terminal — the tool is uncomplicated, but it does not compensate for absent engineering hygiene.
Start with the safest tier of work, adopt the config-in-repo habit from day one, and let the first month be deliberately unimpressive. The compounding starts when the process, not the tool, becomes the thing you trust.
