Three ideas from agent news, turned into checks: what we took into our harness and what we left out

In one week three ideas about AI agents went round every channel I read. Karpathy suggested asking a model to write like an aircraft manual. Google Research published Harness², a framework that improves everything around the model instead of the model itself. OpenAI's engineers described how they removed 800,000 lines of dead code with an agent in two weeks. All three are good. All three also come in the form of "add one magic line to your prompt", and a prompt is exactly the thing that drifts on the next call. So we took them into our open config, github.com/AnastasiyaW/codex-claude-code-config, as checks. Here is what we kept, what we threw out and why.

The aircraft manual: two rules out of ninety

The standard is ASD-STE100, Simplified Technical English. Aviation uses it so that a mechanic reads one meaning in every instruction. On 2 October Karpathy ranked ways to make model output easier to read. Text in this style comes first, then a diagram, then an interactive HTML page, then a custom explainer video. The ladder is useful on its own. Most answers need the first rung, an architecture change needs the second, and a comparison with a lot of numbers earns the third.

The "write in strict STE100" line is weaker than it looks. The full standard has a controlled dictionary of about 900 words and dozens of rules. The dictionary is copyrighted, and models don't know it reliably. Ask for strict conformance and you get an imitation: chopped sentences, not the standard.

Two rules carry most of the value and need no dictionary:

• One concept, one term. If the project says "worker", every sentence says "worker". Models love synonyms for variety. A technical reader then has to work out whether "worker", "handler" and "executor" are three things or one.
• Short sentences. STE caps instructions at 20 words and descriptions at 25.

We made both of them mechanical. scripts/term_drift_check.py takes the project glossary and checks what the agent wrote against it. A glossary entry like обработчик* catches every form of the word, so the check works in Russian too. The existing STE linters don't do that, because the standard itself is for English. Code blocks, links and comments are skipped. The exit code is 0 for clean, 1 for findings, and 2 when the check couldn't run. We need the third state because a check that silently checked nothing is worse than no check.

The first version had exactly that problem. An independent reviewer, a separate agent with a fresh context, found three ways to get a green result without checking anything. Text in a non-UTF-8 encoding, an unclosed code block and a glossary with no synonyms all came back clean. A second reviewer found five more. All of them are fixed, and the self-test now includes cases that must fail, so a broken detector can't pass quietly.

Harness²: the method yes, the auto-patcher no

The idea behind Harness² is strong. The model weights stay fixed. The agent proposes edits to its own surroundings: system prompt, memory, tool guidance, skills, scripts, plugins. It runs them on the task, keeps what helped and remembers the lesson for next time. On three professional-work benchmarks one round of this lifted GLM-5 and Gemini 3.5 Flash by up to 11.5 points.

We didn't install it as is. In the README its executor runs with an open network and the Codex sandbox switched off, and there is no protocol for held-out tasks. For an agent that edits its own rules this is the main risk: it improves on the tasks it has seen and quietly breaks the ones it hasn't.

So we took the method as a small pilot with hard edges:

• a frozen set of three to five tasks, plus at least one held-out task the change was not tuned on;
• one change per candidate, so the cause is obvious;
• mechanical receipts per task, not an opinion about the result;
• the candidate wins only with a strict improvement and no regression on safety or on the held-out task;
• live hooks, permissions and guardrails are never a target of the pilot.

The comparator reads two receipts and writes a verdict. It doesn't run agents and doesn't touch the live config. An accepted result is evidence for a review, not a deployment.

Dead code: the evidence comes from production

OpenAI's numbers are impressive. Over 1,400 merged PRs and over 800,000 deleted lines in about two weeks. One container image got 48% smaller, and median CI time went from about ten minutes to four and a half. The prompts aren't what made it work. The process did.

Deleting code is a special kind of change. Nothing fails when unreachable code disappears. Nothing fails either when you are wrong about it being unreachable, until production does. So the proof has to come from production: telemetry, the live flag state, every call site including indirect ones, the owner. The audit is read-only. Every removal is one small draft PR with the evidence and the reasoning in the description. Killswitches and safeguards are never removed on the agent's word.

We added this as a reference to the refactoring-safely skill. The skill now also triggers when someone asks to remove dead code or stale feature flags.

Comments in code: the research says something slightly different

At the same time I wanted to check an idea we already follow: if agents write and read the code, most comments only waste context. We have had this rule since 15 October, and I looked for research behind it. The answer turned out more interesting than "comments are noise".

• Stale comments pull generated code towards the old implementation.
• Models can trust a comment more than the code it contradicts.
• A missing comment mattered little in the studies I found.
• A correct comment on non-obvious code helped: in one study on legacy mainframe code, accuracy went from about 84% to 90-96%.

The samples are small, and I read two of the papers only as abstracts, so I'd treat the exact numbers carefully. The direction is clear, though: a comment that lies is more dangerous than a comment that isn't there. So we added one requirement to the rule. If you change the code, you change or delete the comment next to it in the same commit. Restating the code goes. The reason, the source of a number and the trap that the next agent would otherwise "fix" stay.

What's in the repository now

• docs/output-legibility.md: the readability ladder and the two rules, with a prompt line that works better than "write in STE100";
• scripts/term_drift_check.py: the glossary check, with tests and a self-test;
• docs/harness-improvement-pilot.md and its comparator: the bounded pilot;
• references/dead-code-sweep.md in the refactoring-safely skill;
• the updated comment rule in rules/quality-code.md.

Everything is in release v2026.10.24, and the full list of changes is in UPDATES.md. An agent can take what it needs straight from the repository: start with CLAUDE.md and README.md, then the skills listed in skills-lock.json.

If something from this saves you a day, a star on GitHub helps other people find the repository. If something breaks, open an issue: that's where most of our rules came from in the first place.