Skip to content
All writing

Harness > LLM: what sits around the model matters more

4 min read

The DeepSeek Harness home screen: a workspace picker set to Default workspace, Workspace Write mode, DeepSeek V4.1 Flash High in the model selector, and a session list of recent work

i keep making the same argument in different words: the harness matters more than the model.

this weekend i finally sat down and tested it properly. i spent two days working inside DeepSeek Harness with v4.1 Flash, which is a small, fast model. the question was not whether the model is impressive. the question was how much of the work the scaffolding around it could carry.

the difference in plain terms

a model on its own answers. it does not open your project, read the file you mean, run the command, watch what breaks, and try again. it does not know the shape of your directory, or that you have a brand voice document, or that the thing you asked for already has a house style it should match.

a harness gives it those things: tools, files, permissions, a workspace, and a place to actually do the work instead of describing the work.

that is a far bigger jump in usefulness than another few points on a leaderboard. at least for the work i do day to day.

most of my tasks do not need a large model

if the task is draft a post, adjust a component, rename a variable, work out why a build is failing, or check what is on next week's calendar — none of that needs the strongest model available. it needs a model that can pick the right tool and read the result honestly.

something like Astra or Fable would be overkill for that. it is like hiring a specialist to write your shopping list.

so the trade looks like this: accept a slightly less capable model, give it real tools, and the total result gets better for most tasks. the harness is where that trade gets won or lost.

case in point

yesterday i published two posts about this, one on X and one on LinkedIn. both were drafted from inside the harness, through Vuti's MCP. i reviewed them, edited them, and approved them. the image on this post is literally the harness window i was working in.

what that actually involved, in order:

  • the model could see the workspace and the existing posts, so it was not guessing at the voice
  • it had a tool interface to Vuti, so it could read the draft, revise it, and attach the right asset instead of describing what it would do
  • it could run shell commands against a real project directory, which is the only way a claim like "this builds" means anything
  • i kept the approval step, because the harness treats publishing as a decision and not a side effect

that last part matters to me. the useful question is not "can the model publish on its own?" it is "can it prepare enough good work that my review is fast and informed?"

what a harness does not fix

a weekend of this also made the limits obvious.

it does not fix judgment. a small model with good tools still makes small mistakes. the harness makes those mistakes cheaper to catch, because you can see the diff, the command output, or the draft — not just the summary of it.

it does not fix facts. harness or no harness, the model should not invent a number, a customer, or a capability. if the detail is not in the workspace, the right move is to not claim it. fluent text is not the same thing as accurate text.

permissions are a feature. a harness that can touch your files, your git history, and your live accounts is a harness that needs scoped access and a human on the approve button. that is not friction to strip out. it is the reason the thing is usable at all.

and the code verdict is still pending. i have been putting it through real projects, not toy ones. one weekend is enough to be confident about the workflow. it is not enough to be confident about a codebase.

why i keep coming back to this

i build an AI product for a living, so this is not an abstract opinion. it changes what you spend effort on.

if the model is the whole product, you are stuck waiting for the next release from someone else, and your feature list is whatever the model got better at this quarter. if the harness is the product, then your work is the part that compounds: your context, your tools, your workflow, your approval boundaries, and the quality of the drafts that reach a human.

that is why i keep saying harness > llm. the model is a part you can swap. the harness is the thing you actually built.

Share