•
5 min read

Using Opencode as a Harness for AI-Assisted Development

A practical look at opencode as the harness around model choice, prompt routing, repo context, and CLI workflow for planning, refactoring, debugging, and iterating faster

Using Opencode as a Harness for AI-Assisted Development

The AI tools I keep around change more often than my editor theme, but the shape of the workflow is starting to settle. For me, opencode fits into the part of the process where I want a fast, conversational loop around the codebase itself.

The important distinction is this: opencode is not really the model. It is the harness. It is the layer that wraps whatever model I choose, handles the CLI flow, and helps me move from prompt to action. If Claude is using one model, Codex another, and opencode can point at Kimi, Claude, or GPT models depending on how I configure it, then the real comparison is not “which one is smartest?” The real comparison is “which harness gives me the best working loop for the task?”

What I Want From a Harness

Before choosing where a harness fits, I try to be honest about the job I want it to do.

  • I want it to help me break a problem into smaller steps.
  • I want it to suggest a first draft, not a polished final answer.
  • I want it to stay grounded in the repository I already have.
  • I want the cost of correction to be low enough that I can iterate quickly.

That is where opencode works well for me. It is especially helpful when I am:

  • refactoring an existing module
  • tracing through a code path I have not looked at in months
  • asking for a migration plan before making changes
  • generating a small chunk of boilerplate that I will immediately edit

The key is to keep the task tight. If the prompt is too broad, the output becomes generic. If I keep the ask small and specific, the quality goes up dramatically.

The other thing I care about is model flexibility. If I can point opencode at Kimi for one task, Claude or GPT-5.5 for another, and still keep the same CLI workflow, then I am comparing the workflow around the model rather than pretending the wrapper is the model.

The Best Use Case: Small, Well-Bounded Tasks

The best AI-assisted development sessions are the ones with a clear finish line. I like to use opencode when I already know the shape of the change but want a second brain to help me move faster.

For example:

  • convert a helper to TypeScript
  • extract repeated logic into a utility
  • rewrite a fragile API handler to be easier to test
  • add schema validation around incoming data

Here is the kind of instruction I usually start with:

You are working inside an existing codebase.

Task:
- inspect the current implementation
- identify the smallest safe change
- keep the public behaviour the same
- prefer simple code over clever abstractions
- explain any tradeoffs before editing

Output:
1. short plan
2. proposed diff
3. risks or follow-up work

That prompt does a few things at once. It tells the tool to stay in the repo, keep the change small, and explain the tradeoffs before it starts inventing solutions. That final part matters because the wrong kind of AI momentum is dangerous. It can make a bad idea feel productive.

A Refactor Example

Let’s say I have a WordPress-to-Astro migration where an API response is being transformed in three different places. I want to pull that into one utility. The workflow is usually:

  1. ask opencode to locate the repeated shape
  2. ask it to propose a single source of truth
  3. review the diff and trim anything unnecessary
  4. run the change locally and inspect the result

The useful part is not that opencode writes the final code perfectly. The useful part is that it gets me to the review stage faster.

// Example: normalize WordPress content before it reaches the Astro layer
export type WordPressPost = {
  id: number;
  slug: string;
  title: { rendered: string };
  excerpt?: { rendered: string };
  date: string;
};

export type PostCard = {
  slug: string;
  title: string;
  excerpt: string;
  publishedAt: string;
};

export function mapWordPressPost(post: WordPressPost): PostCard {
  return {
    slug: post.slug,
    title: post.title.rendered,
    excerpt: post.excerpt?.rendered ?? '',
    publishedAt: post.date,
  };
}

If I ask a tool like opencode to help with that kind of refactor, I do not want it to invent a new architecture. I want it to tell me whether I should:

  • keep the mapper pure
  • add tests around the transformation
  • normalize HTML content before storing it
  • move the conversion to the import step instead of the render step

That is a much more useful answer than a giant “improved” abstraction that I will have to unwind later.

Harness vs Model

I do not think of these tools as interchangeable, but not for the reason people often assume.

  • Claude is a model and product experience I often use for broader reasoning, article drafting, and multi-step explanation.
  • Codex is a model plus workflow that often feels better for code-oriented iteration and repo-aware edits.
  • Opencode is the harness that can sit in front of one of several models and give me a CLI-first flow around a specific code task.

That means the interesting question is not whether opencode is “better” than Claude or Codex in the abstract. The better question is whether the harness gives me a cleaner path through the work, especially when the underlying model can be swapped.

In practice, opencode is often the one I reach for after I have already thought through the problem enough to know the next move. It is not the beginning of the process. It is the middle of the process, where momentum matters most.

A Prompt Pattern That Works

The biggest improvement I made was moving away from vague instructions and toward structured prompts. This pattern works reliably:

Goal
What should change and why?

Context
What part of the codebase is involved?

Constraints
What must not change?

Success criteria
How will I know the change is done well?

That format keeps the response concrete. It also makes it easier to compare multiple AI workflows against the same task. If opencode gives me a clearer implementation path than another harness or CLI route, great. If it does not, I know quickly and can switch.

What I Think Makes It Worth Using

Opencode is most valuable when I want:

  • fewer context switches
  • a faster first draft
  • a better starting point for code review
  • less friction when I am cleaning up repetitive work

That sounds modest, but modest gains compound quickly. If a tool saves me 10 minutes on five separate tasks in a week, that is real time back.

The main rule is still the same: use the tool to accelerate judgment, not replace it. The more specific I am about the task, the more useful the output becomes.

Final Thought

I like tools that help me move faster without making me less careful. That is the bar. Opencode earns its place in my workflow because it gives me a flexible harness, keeps the task small, and gets me to a reviewable result quickly.

If you are already using Claude or Codex and you want something more CLI-shaped for day-to-day coding, opencode is worth experimenting with. Keep the prompts tight, keep the task small, and treat the wrapper as the thing you are comparing, not just the model behind it.

Back to all posts