Making a personal harness work for colleagues
Harness для коллег: 5 шагов из личного опыта
B · Useful, limited A detailed first-hand account from a platform specialist at the Russian software vendor Directum on turning a one-person Claude Code harness into a team tool; strong practice detail, no measured outcomes.
Summary based on the full text·Original: about 11 minutes to read
In short
A Habr post (29 October 2026) on the Directum company blog by a specialist who builds prototypes on the Directum RX platform. His personal Claude Code harness (subagent roles, a Markdown knowledge base, a spec-driven pipeline, MCP access to the platform's development studio) worked well for one person and broke as soon as colleagues used it, because the author was its main component. The post lists what it took to remove him from the loop: a resumable installer, an update hook, evals for skill edits, permissions enforced by the file system, a local pseudonymiser, and issue reporting that counts only a real issue number as proof of delivery.
Key numbers
- 3attempts allowed in each design and code fix loop before the coordinator agent calls a human
- 3reviewer subagents checking code, security and architecture fit in parallel
- 5-hourClaude usage window that agent-assisted environment setup sometimes used up before any useful work
As reported by the source.
Russian·Web page·opens habr.com
What it reports
- Harness: product owner, architect, developer, tester and reviewer subagents; a coordinator script that checks each stage's outputs and saves pipeline state so work resumes after a break.
- Two fix loops (design and code), each capped at three attempts; then a human is called and the bug, checks and attempt history are saved. Without a cap, subagents "fix each other" and burn subscription limits.
- Humans approve the requirements document, handle exhausted loops and accept the result; a security blocker cannot be outweighed by a good code score.
- Distribution choice: local install per person on their own subscription, over a shared sandbox service, because teams run different products, versions and databases. The author finds a subscription cheaper than API tokens for his use.
- A clean virtual machine exposed forgotten dependencies (Python, Node.js, libraries). Agent-led setup sometimes consumed the whole 5-hour Claude window. Bash entry points were moved to Node.js because Bash under antivirus on Windows was unstable.
- A session-start hook detects new versions, updates, checks tools and supports rollback. Evals run after any skill change to catch regressions; a smoke test ends install and update.
- Protecting the base solution: an instruction explains the rule, directory permissions block writes from any tool, the agent cannot change permissions, and a pre-build diff check stops work if protected code changed. Deletes, deploys and outbound sends need a confirmation naming the action.
- The agent once reported an issue as "filed" while GitLab stayed empty (missing token rights); now only an issue number and link count as confirmation.
How they got it
The author's own build and rollout, described in prose and one pipeline layout. No figures on time saved, adoption or defect rates.
Limits
- No measured outcomes; the author says some parts still need work and calls it personal experience, not a recipe.
- Published on the vendor's own corporate blog.
- Specific to one platform and to Claude Code; the sandbox option is discussed but not tried.
Why it matters for companies
Most internal agent tooling starts as one person's setup. The post is a practical checklist for the step where it becomes shared: test on a clean machine, separate shared, project and personal settings, enforce bans with file-system rights instead of prompts, regression-test skill edits, and never accept an agent's own statement that something was sent. The final point, that people still need in-person help to frame tasks and know where not to trust the agent, sets realistic expectations for rollout.
Key passages in translation
Russian original
Главной её частью оказался автор, а автора через установщик не поставишь.
Its main component turned out to be the author, and you cannot ship the author through an installer.
Russian original
Нужен фактический отказ в операции. Обещание агента «я больше так не буду» для этой проверки не годится.
You need an actual refusal of the operation. The agent's promise "I won't do it again" does not pass this check.
Russian original
Агент подготовил описание, попытался отправить и бодро сообщил, что проблема передана. А в GitLab пусто.
The agent prepared the description, tried to send it and cheerfully reported that the issue had been filed. GitLab was empty.
Summary based on the full text. Read the original for the full argument and data.Read the original on habr.com