Your coding agent doesn't always follow your rules

You give Claude Code a feature to build. It splits the work into subtasks, launches multiple subagents, and works through them until it announces completion. Everything looks promising—until you run the result. Something fails. You ask for a repair, receive another assurance, and discover another small omission.

Talha Sheikh’s desired workflow is more appealing: play Cyberpunk on his Xbox while the agent does the work. Instead, he keeps interrupting to request fixes. A specification, detailed instructions, or almost no instructions still leave him checking the result. The user has become the enforcement layer. The agent says it is done, but nothing else establishes whether that is true.

The missing piece is a deterministic check between reported completion and accepted completion. It must answer more than whether the agent produced something: did it complete the task in the way the user requested? That requires turning at least some expectations into criteria that can actually be checked.

Sheikh’s first implementation, Vector V1, uses Claude Code hooks to invoke a checker automatically when the agent finishes. He describes this as finishing a session; current Claude Code terminology distinguishes the Stop event, when the agent finishes responding, from session termination. The relevant mechanism is a hook that can block completion and return a reason, with protection against indefinite continuation.

The configuration defines what Vector should test. The resulting workflow is straightforward:

1. The agent attempts to finish its work.
2. The hook invokes the configured checks.
3. A failed check returns feedback to the agent.
4. The agent repairs the work and tries again.
5. The checks run again before the result is accepted.

For a JavaScript project with test and typecheck scripts, a check command could combine them like this:

#!/usr/bin/env bash
set -euo pipefail

pnpm test
pnpm run typecheck

The command exits unsuccessfully if either check fails. The hook integration supplies the other half of the mechanism: getting that failure back to the agent instead of letting it disappear into a terminal log.

In the output Sheikh walks through, checks initially fail, the agent retries, and eventually all the checks pass. That progression is the useful demonstration: completion becomes something the surrounding system evaluates, rather than something the agent merely declares. The target is trust in task completion, and Sheikh uses Claude as a stand-in for coding agents generally.

After showing Vector at events, Sheikh encounters an objection. He recounts an unnamed Anthropic engineer predicting that another agent or a sufficiently capable model would make enforcement unnecessary. That raises an uncomfortable possibility for someone building a verification tool: perhaps the next model will erase the problem. He also invokes Project Glasswing and Claude Mythos Preview as examples of optimism about advancing capabilities. Glasswing is a defensive cybersecurity initiative using that model, not a promise that verification will become unnecessary.

Capability and reliability are different questions. A more capable model may solve tasks it previously could not solve. The operational question remains whether a particular result satisfies the requirements. Better performance does not, by itself, supply the check that establishes that result.

The same distinction applies to the inputs surrounding the model. A better specification, useful MCP servers, well-chosen subagents, and the right context are all worth providing. They help the agent understand and perform the work. But instructions describe what should happen; verification examines whether it happened. Improving the former does not automatically implement the latter.

Once checks constrain the acceptable output, Sheikh proposes that a smaller model such as Haiku, or an open-source model, might become sufficient for some tasks. A frontier model such as Opus is one route to producing the result; a cheaper model inside a stronger verification loop is another possible route.

His proposed tradeoff has three positions:

He also mentions asynchronous tasks as another possibility. This is a cost hypothesis, not measured savings: the talk supplies no task-specific benchmark or comparison accounting for check execution and retries. The practical question is whether the extra harness work makes a less expensive model sufficient for the required outcome.

Further conversations expose a portability problem. Sheikh sees Anthropic, his own company, and Facebook/Meta building their own enforcement systems. A tool tailored to his requirements will not automatically fit someone else’s. Different teams need to enforce different things, so the reusable element must be the pattern rather than a fixed collection of rules.

The proposed pattern is language agnostic and lets developers supply their own enforcement. It can place checks at several points in a workflow:

• Conversation completion: Check the work when the agent attempts to finish.
• Before committing: Check the changes before they enter a commit.
• Multi-agent workflows: Check work within a larger collaboration between agents.
• Asynchronous operations: Check background work when it reaches the relevant checkpoint.
• LLM judgment: Invoke another model to evaluate criteria that call for judgment.

These are proposed integration points for the shared pattern, beyond the initial hook-driven walkthrough.

The last option makes an important distinction visible: deterministic invocation does not require every evaluator to be deterministic. A system can reliably run a particular check at a particular point while that check uses an LLM whose judgment varies. Cross-language portability depends on being able to invoke the checks through a dependable execution mechanism, not on writing every checker in the same language.

The contract connects a task to the conditions required for its fulfillment. Developers define the checks in between. That separates the reusable orchestration—when to verify and how to return feedback—from the project-specific meaning of acceptable work.

Sheikh connects this pattern to several industry examples, starting with Anthropic’s executor–advisor arrangement. One agent performs the coding work while an advisor provides feedback that can change its course. The current advisor documentation describes strategic guidance rather than deterministic verification; the advisor itself has no tools. The useful comparison is the feedback loop, not a guarantee that advice establishes correctness.

He next points to OpenAI’s harness engineering: the agent receives tools and context within an environment designed to support checking its work. Then comes Qodo’s code review, where review findings and issues feed back into a pull request after the agent has produced changes. In Sheikh’s comparison, these approaches share a refusal to treat generated code as the end of the process, even though their checks and feedback mechanisms differ.

A WorkOS presentation supplies the compact formulation: “Enforce, don’t instruct.” Here, enforcement means making verification part of the workflow itself, rather than relying on the agent to remember that it was asked to check.

This explains why fast code generation does not remove the need to proceed carefully. The agent can produce changes quickly; someone or something still has to establish that they work. Sheikh connects that constraint to calls to go slowly, including a keynote’s blunter instruction to “slow the hell down.” Verification is the work that remains between generating a change and trusting it.

The resulting shift is in where engineering value resides: from the code produced to the verification designed around it. The relevant skill expands from being able to write code to being able to establish that the code satisfies its purpose.

Sheikh’s closing recommendation is to work on the harness and the verification system. The hook, the configured checks, and the failure feedback are what let a result improve without requiring the user to supply every correction manually.

Asked whether the tool exists publicly and can be used, Sheikh says yes: it is called Vector Harness, and he offers to share it through a LinkedIn message. An audience member asks him to restore the LinkedIn slide, and he does. The offered route is direct contact; he does not walk through installation or deployment.

The final question playfully returns to the cost argument: how does using smaller models square with allegations that Sheikh is a top token spender at his company? His reply is that he needs those tokens to build the verification layer. The exchange ends on the expense of building the harness, rather than a claimed measurement of what it saves.