Recently, I was watching Claude Code work in a project that, of course, also had a CLAUDE.md with instructions for using Haft. Haft itself adds the necessary rules during initialization, while Haft skills and the MCP core provide an additional harness that helps the agent avoid skipping problem framing, exploring alternatives, and other parts of the engineering process.
In short, the infrastructure was there.
The agent still started using the wrong tools at the wrong time. Instead of first understanding the problem, proposing several hypotheses, and comparing the alternatives, it almost immediately rushed into solving the task.
I noticed it quickly only because I was literally inside the session. My attention was there: I could see what the agent was doing, stop it, and steer it back.
Nothing terrible happened. The harness works, but in this thread the human was the last line of defence.
Had this been a failed goal loop, my attention would no longer have been inside the process. I cannot claim that the agent would necessarily have produced a bad result: most results are still good, apparently largely because of careful preparation and modelling beforehand.
Something else is clear: when the engineering process starts breaking down during ordinary agent work, it can probably be properly repaired only by a protein-based engineer.
An instruction only describes desired behaviour
Then I came across a Google paper: From Correctness to Collaboration: A Human-Centered Taxonomy of AI Agent Behavior in Software Engineering.
The authors collected 91 project rule files created by early users of coding agents inside the company and built a taxonomy of “expected behaviour”: standards compliance, code quality, problem solving, interaction with the developer, and all the important intuitive stuff.
Great. As a vocabulary for designing instructions, the paper is useful. It clearly shows what developers want from agents and which expectations they try to encode in rules.
For me, it is important to take a slightly closer look at the object being studied.
A rule file only says how an agent should behave. It just says so. It does not show how the agent actually behaved in a particular session, whether it followed the rules, which decisions it discarded, or what eventually changed in the real project. The authors themselves identify behavioural evaluation as necessary future work.))
This distinction is obvious, but too important to ignore: a file is the carrier of an instruction, while the actual behaviour of our system is a different object. We need to understand that distinction very clearly and never forget it.
AGENTS.md, CLAUDE.md, or skills may contain an excellent engineering method — even the best one under certain assumptions. That does not mean the agent will apply it at the right time, or apply it at all, rather than choosing a “convenient” interpretation or jumping to the first plausible solution.
After all, models are trained to be “helpful”, whatever that means.
In my practice, Haft catches many such deviations. Even this experience gives me no basis for claiming how many of them any particular harness catches, let alone that it catches them all. What I do know is that, given my requirements for formality and ontological precision, Haft is useful more often than not, while a bare rule file or a set of heuristic instructions satisfies those requirements only to a very limited degree.
Fast solutions destroy an important part of engineering work
The most worrying part of that Claude Code session was how easily the agent skipped the process required for a serious technical decision:
- frame the problem;
- propose different alternatives and hypotheses;
- compare them across several characteristics;
- preserve not only the selected option, but also worthwhile alternatives.
A technical problem rarely has one unconditionally best solution (never). One option is easier to implement. Another is easier to roll back. A third scales better but creates additional operational load. Some options form a Pareto frontier: individual options win on some characteristics we care about and lose on others.
The right choice depends on the current constraints. Nothing stays constant, and circumstances change quickly.
This is why I care not only about finding a good option, but also about preserving the option space. Previously rejected ideas may not automatically become more suitable under new conditions, but they can be excellent stepping stones towards a new and better solution.
There is no need to reconstruct the entire context of the engineering exploration: we simply take a small step back.
When an agent turns one hypothesis into a provisional “solution” too quickly or too early, we lose not only the alternatives, but also the ability to revisit the choice.
Human in the loop is more than an operator watching over the agent
I find it difficult to draw a “boundary of thinking” between a human and an AI agent. The extended mind thesis strongly resonates with me.
I see working with AI as a symbiosis, and we have an abstract “slider” for how much human attention we invest. Its position should depend on the project’s complexity, the system’s size, the number of participants, the reversibility of the decision, and the cost of an error.
For a very small task, it is enough to inspect the result and the green tests (and the tests themselves too… right?). No judgement here.)))
An architectural decision needs the minimum engineering process described above: alternatives, reasons for the choice, and a preserved analysis of the constraints.
In serious production systems, I do not think humans should ever leave the loop completely. Whenever I have seen “software factories” that a human did not inspect for several days, people always ended up spending several more days cleaning up the code those factories had produced. Where is the gain? Especially if, on the second day of working independently, the AI misinterpreted one step of the plan and the output of the next billion tokens had to be rolled back and thrown away.
This does not mean an engineer must read every line of generated code. At today’s speed of iteration in software development, demanding that for most projects would simply be foolish.
In the ACM Queue article Where to Draw the Line, Craig Soules argues that line-by-line human review may stop being the central form of control as agents develop. The human still chooses the problem, checks whether the result matches the goal, and remains responsible for the consequences. Basic stuff.
I do not see a scenario in the foreseeable future where living engineers disappear from this “engineering responsibility loop”. Someone with a real stake must still express that stake correctly and take responsibility.
A stake in what? In obtaining something valuable in reality, in changing reality in some “beneficial way”. How exactly does an AI have such a stake? Or do you think we can express all our interests in a rule file of one or two thousand characters? And what about responsibility?
Collaboration is a property of the whole development system
Now let us return to the Google study.
As I said, we care about more than the agent’s behaviour and the quality of rule files.
We care about the entire system in which humans and AI work together:
- Living project instructions, maintained together with the project and not allowed to become badly outdated.
- An executable harness that checks the order of actions, permitted tools, and required engineering steps.
- Decision memory that preserves not only the final choice, but also alternatives, constraints, and reasons for rejection.
- Deliverables and evidence for every substantial piece of work.
- A human who “moves the attention slider” and remains responsible for the quality of the whole system.
No layer replaces the others. None of them works properly without the rest:
- An instruction without verification can be ignored.
- Verification without memory does not preserve the option space.
- A work result without evidence that the required work was actually done only shows that some object — a slop blob! — appeared. It does not prove that the object solves the right problem. Think about it: is asking the agent to simply “write behavioural tests for everything” enough in this plan?
- No agents or harness processes can adequately make project decisions for us, especially in the long term.
Can you feel how human attention runs through every one of these layers? Can you feel how much the quality of the “harness” itself depends on the human?
Simple code is worth nothing. Engineering thinking is priceless
I see no reason to keep fearing AI, much less to preserve the old way of working at any cost. Spare yourself the unnecessary stress.
In business terms, the skill of writing simple code has been fully commoditized. This is already happening, and there is a lot of value in it: a good engineer can test hypotheses, explore alternatives, and build working systems faster.
Just watch the hands: a good engineer must be able to read code and think not only imperatively, but also declaratively. How to acquire these thinking skills without writing code with your own limbs is a separate topic for reflection.
It is also important not to forget the value of designing elegantly, ethically, and systemically. It has not disappeared; on the contrary, the value of this skill keeps growing.
AI amplifies the ways of thinking that already exist in our “protein-based” brains. Strong engineering thinking gains additional leverage. But when slow thinking is replaced by “model confidence”, the scale of error grows together with the speed at which results arrive.
So the most important harness is not AGENTS.md, not a skill, and not the collection of scripts around your agents.
The most important harness is YOU: the human together with your AI agents.
You cannot configure this harness once and forget it. You have to develop, test, and adapt it to the difficulty of the particular work. In a responsible system, a human can delegate more and more execution, but not responsibility itself.
Within this system, the human evolves and becomes smarter, capable of solving more difficult problems that were previously beyond reach, and solving them faster.
Only one question remains: are people interested in this open-ended evolution?