# DeepSeek Harness Makes a Serious Promise. I Would Audit It Before Letting It Touch a Repository > Source: > Published: 2026-08-20 03:26:14+00:00 *An agent that can explain its actions is more useful than one that merely sounds confident. DeepSeek Harness puts that idea near the centre of its design. The interesting question is what a developer should demand before trusting the record* The new generation of coding agents has made it tempting to judge a tool by the first impressive thing it does. Give it a vague ticket, watch it inspect a repository, and wait for the satisfying moment when it produces a diff that looks as if somebody stayed up late to write it. That is a compelling demo. It is also a poor way to decide whether the tool belongs anywhere near a production codebase. The difficult part begins after the agent does something unexpected. It might change a configuration file that was not in the ticket, choose an obsolete internal API, or run a command that left state behind. At that point, a fluent explanation is not enough. You need to know what the system saw, which instructions it loaded, which tools it called, and what it actually changed. That is why DeepSeek Harness is worth looking at even if you are not planning to replace your current coding agent. Its published architecture puts a strong emphasis on an append-only session record and on reconstructing the context presented to the model. That is a much more serious promise than a nicer terminal interface. It treats the agent’s history as an engineering artefact rather than a chat transcript you scroll through when something breaks. I would still not grant it broad repository access because the design sounds sensible. I would audit the audit trail first. There is a meaningful difference between a system that stores events and one that gives an engineer enough evidence to understand a decision after the fact. Most AI tools have some form of history. You can see messages, perhaps tool calls, and sometimes a summary of changes. That helps, but it is not automatically an audit trail. A useful audit trail needs to answer questions that are annoying rather than flattering: which version of the instructions was active, did the agent read a secret-adjacent file, what command ran with what working directory, and did a human approve the dangerous action before or after the model proposed it? The difference matters because agents do not only generate text. A coding agent can search files, write files, run tests, call services, and create a chain of small decisions that looks reasonable until it does not. If the record shows only a polished final narrative, the system has hidden the part a reviewer needs most. The prose may be accurate, but it is not evidence by itself. The claim behind an append-only record is that the state shown to the model can be rebuilt from the log. If the implementation lives up to that claim, it creates a better debugging starting point. An engineer can compare the agent’s visible context with the resulting change instead of guessing whether a summary, a plugin, or an instruction file quietly changed the course of the work. That is a valuable property, though it is not a complete safety model. Replay can tell you what happened. It does not decide whether the action should have been allowed in the first place. The first audit should not be a dramatic refactor. Give the agent a narrow job where a correct answer is easy for a human to recognise: update a well-tested validation message, add a small test for a known edge case, or rename a field in one isolated module. The task should have a clear definition of done and a boundary that the agent has no reason to cross. Then inspect the trail rather than admiring the patch. Did the tool read only relevant files? Did it discover and obey repository instructions? Did it state why it chose the files it edited? Did the test command run successfully, and can you tell whether that result came from the current worktree rather than a cached or unrelated process? This sounds painstaking until you remember what comes next. If the agent cannot leave a comprehensible paper trail for a small, bounded change, handing it a migration or a production incident is not courage. It is outsourcing the review process to optimism. The test also reveals whether the harness has a healthy notion of scope. A dependable agent should be allowed to say that it lacks evidence, ask for clarification, or stop before a risky operation. A system that always finds a way to complete the request can look magical in a demo and become expensive in a real repository. Repository instruction files have become a quiet source of agent risk. Teams keep `AGENTS.md`, `CLAUDE.md`, project notes, environment guidance, and sometimes copied rules in several directories. Each file may be reasonable on its own. Together they can conflict, duplicate token-heavy context, or give the model an unclear order of precedence. DeepSeek Harness makes this question especially relevant because its instruction-loading behaviour is part of the system that shapes an agent’s decisions. An audit trail should record exactly which files were found, which contents were included, their order, and the version of the loader that made those choices. “Loaded project instructions” is too vague for a tool that can edit code. I would add one intentional conflict to the evaluation repository. Put a harmless but visible disagreement in two instruction files, such as two different test commands. The purpose is not to trick the agent. It is to see whether the harness exposes the conflict clearly enough for a human to understand the outcome. If the agent chooses one rule, that choice should be traceable. If it includes both, that should be visible too. Otherwise, the team may spend hours debating the model’s judgment when the real problem was a duplicated instruction that nobody knew had entered the prompt. An agent’s model output is only one layer of risk. The sharper question is what the surrounding tools will let it do. Reading a source file, editing a test fixture, opening a network connection, and deleting a generated directory should not all have the same approval path merely because they are represented as tool calls. For any harness, I would want a record that separates proposal, approval, execution, and result. The log should show the exact command or API action, the directory or target it operated on, the permission rule that applied, and the person or policy that allowed it. A vague entry saying “shell command approved” is a poor substitute for the command itself. The subtle failure to look for is approval drift. That happens when a user approves a harmless-looking action, but the agent changes the parameters or broadens the target before execution. Good tooling binds the approval to the actual action, not just to a category such as “run shell.” It should be difficult to turn permission to inspect a folder into permission to rewrite it. DeepSeek Harness can be judged well here only if the recorded history is useful to someone who was not in the original session. That is the standard that matters in a team. The person reading an incident report tomorrow should not need to reconstruct yesterday’s conversation from memory. The plugin architecture is one of the most interesting parts of DeepSeek Harness. It gives developers seams to change model providers, tools, storage, agent loops, and other runtime behaviour. That flexibility can be excellent for teams with unusual workflows. It can also make the running system harder to identify than the repository you installed. When everything is pluggable, a trustworthy session record needs a manifest. Which plugins were enabled? Which versions were loaded? Which configuration values changed the agent’s behaviour? Which plugin owned a particular tool call? Without that information, two sessions that appear to use the same harness may have behaved very differently for reasons that are invisible in the final chat. This is where a small amount of operational discipline beats a large amount of faith. Pin versions for an evaluation run. Export the loaded configuration. Keep a known-good task and replay it after a plugin update. If the agent starts reading different files, choosing different tools, or producing a wider diff, you have a concrete change to investigate instead of a vague feeling that the model got worse. Open source helps because the seams are inspectable. It does not remove the need to inspect the composition that actually runs in your environment. A transparent engine can still be connected to opaque or carelessly configured parts. I would not use a single benchmark score as a release gate. The useful evaluation is a short set of tasks that mirror the work the agent will really do. Include one small code change, one task that should stop for missing information, one task that tries to cross a permission boundary, and one task with conflicting instructions. Save both the task inputs and the resulting records. For each run, I would ask five simple questions. Can we identify the exact instructions and configuration the model saw? Can we list every file, command, and external action? Can we distinguish a model proposal from a permitted action? Can another engineer reproduce the context without trusting a summary? Can we explain the final diff from the evidence in the log? If the answer to any of these is no, the right response is not necessarily to abandon the tool. It may simply belong in a narrower role: drafting tests, exploring a disposable branch, or preparing a plan for human approval. Permission should expand as the evidence gets better, not because the agent happened to solve a difficult task once. There is a version of the agent future that sells autonomy as the main feature. Give it a destination, then get out of the way. That is attractive when the work is reversible and the cost of a mistake is low. Most valuable engineering work does not stay in that category for long. The more durable model is an agent that moves quickly inside a clear boundary and makes its work easy to inspect, pause, and correct. It may be less theatrical. It is much easier to bring into a real team. DeepSeek Harness deserves attention because it points toward that model. An append-only record and reconstructable context are the right kinds of ideas. But ideas become trust only when the evidence is usable during a review, a regression, or an incident. Before an agent earns access to more of a repository, make it show its work on the boring tasks. That is where dependable systems reveal themselves. [DeepSeek Harness Makes a Serious Promise. I Would Audit It Before Letting It Touch a Repository](https://pub.towardsai.net/deepseek-harness-makes-a-serious-promise-i-would-audit-it-before-letting-it-touch-a-repository-dd433c0a98cb) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.