エージェントのニュースから得た3つのアイデアをチェックに変えた：ハーネスに取り入れたものと、取り入れなかったもの

1週間のうちに、AIエージェントについての3つのアイデアが、私の読むすべてのチャンネルを回りました。Karpathy は、モデルに航空機のマニュアルのように書かせるよう勧めました。Google Research は Harness² を発表しました。モデル自体ではなく、その周りのすべてを改善するフレームワークです。OpenAI のエンジニアたちは、エージェントを使って2週間で80万行のデッドコードを削除した方法を説明しました。どれも良い考えです。ただし3つとも、「プロンプトに魔法の1行を足せ」という形で来ます。そしてプロンプトは、次の呼び出しでまさにドリフトするものです。そこで私たちは、それらを公開の設定、github.com/AnastasiyaW/codex-claude-code-config に、プロンプトではなくチェックとして取り入れました。何を残し、何を捨て、その理由は次のとおりです。

航空機のマニュアル：90個のうち2つのルール

基準は ASD-STE100、Simplified Technical English です。航空業界では、整備士が1つの指示を1つの意味で読めるように使われています。10月2日に Karpathy は、モデルの出力を読みやすくする方法をランク付けしました。この文体のテキストが最初で、次に図、次にインタラクティブな HTML のページ、そして最後にカスタムの解説動画です。このはしごは、それだけでも役に立ちます。ほとんどの回答には最初の段で十分で、アーキテクチャの変更には2段目、数字の多い比較にはようやく3段目が必要です。

「厳密な STE100 で書け」という一行は、見かけより弱いものです。標準の完全版には、約900語の管理された辞書と、数十のルールがあります。辞書は著作権で保護されていて、モデルはそれを確実には知りません。厳密な準拠を求めれば、返ってくるのは標準のまがいもの、つまり文を細切れにしたものであって、標準そのものではありません。

ほとんどの価値を担う2つのルールは、辞書を必要としません。

• 1つの概念には1つの用語。 プロジェクトが「worker」と言うなら、すべての文が「worker」と言うべきです。モデルはバリエーションのために同義語を好みます。すると技術的な読者は、「worker」「handler」「executor」が3つのものなのか1つのものなのかを考えなければならなくなります。
• 短い文。 STE は、指示は20語まで、説明は25語までとしています。

私たちは、この2つを機械的に検査できるようにしました。scripts/term_drift_check.py は、プロジェクトの用語集を受け取り、エージェントが書いたものとそれを照合します。обработчик* のような用語集のエントリーは、その語のすべての形にマッチするので、この検査はロシア語でも機能します。既存の STE のリンターはこれをしません。標準そのものが英語向けだからです。コードブロック、リンク、コメントは飛ばされます。終了コードは、問題なしが 0、指摘が 1、検査が実行できなかったときが 2 です。3つ目の状態が必要なのは、何も検査せずに静かに通るチェックは、チェックがないより悪いからです。

最初の版には、まさにその問題がありました。独立したレビュアー、新しいコンテキストを持つ別のエージェントが、何も検査せずに緑になる方法を3つ見つけました。非 UTF-8 のエンコーディングのテキスト、閉じられていないコードブロック、同義語のない用語集は、どれも問題なしで返ってきました。2人目のレビュアーがさらに5つを見つけました。すべて修正しました。セルフテストには、必ず失敗すべきケースが含まれるようになったので、壊れた検出器は静かに通れません。

Harness²：方法は取り入れ、自動パッチャーは取り入れない

Harness² の考え方は強力です。モデルの重みは固定されたままです。エージェントは、自分の周囲、つまりシステムプロンプト、メモリ、ツールのガイダンス、スキル、スクリプト、プラグインに対する編集を提案します。それをタスクで実行し、役に立ったものを残し、次回のために教訓を覚えます。3つのプロフェッショナルな作業のベンチマークで、1回のラウンドにより、GLM-5 と Gemini 3.5 Flash が最大11.5ポイント向上しました。

そのまま導入はしませんでした。README では、その実行器はネットワークを開いたまま、Codex のサンドボックスを切った状態で動きます。そして、ホールドアウトのタスクのためのプロトコルはありません。自分のルールを編集するエージェントにとって、これが主なリスクです。見たタスクでは改善し、見ていないタスクでは静かに壊すのです。

そこで、方法だけを、厳格な境界を持つ小さなパイロットとして取り入れました。

• 凍結された3〜5個のタスクと、その変更でチューニングしていない、少なくとも1つのホールドアウトのタスク。
• 候補ごとに変更は1つだけ。原因がはっきりするように。
• タスクごとの機械的な記録（レシート）。結果についての意見ではなく。
• 候補が勝つのは、厳密に改善し、安全性やホールドアウトのタスクで後退がない場合だけ。
• 常時動いているフック、権限、ガードレールは、パイロットの対象にはしない。

比較器は、2つのレシートを読んで判定を書きます。エージェントを実行せず、稼働中の設定にも触れません。受け入れられた結果は、レビューのための証拠であり、デプロイではありません。

デッドコード：証拠は本番から来る

OpenAI の数字は印象的です。約2週間で、1,400件以上のマージされた PR と、80万行以上の削除です。1つのコンテナイメージは48％小さくなり、CI の中央値時間は約10分から4分半に下がりました。効いたのはプロンプトではありません。プロセスです。

コードを削除する変更は、特殊な種類の変更です。到達不能なコードが消えても、何も失敗しません。到達不能だという判断が間違っていても、本番が壊れるまで何も失敗しません。そのため、証明は本番から来なければなりません。テレメトリ、稼働中のフラグの状態、間接的なものを含むすべての呼び出し元、担当者です。監査は読み取り専用です。すべての削除は、証拠と理由を説明に書いた、1つの小さなドラフト PR です。キルスイッチや安全装置は、エージェントの判断だけで削除されることはありません。

これを refactoring-safely スキルへの参照として追加しました。スキルは、デッドコードや古い機能フラグを削除するよう頼まれたときにも発火するようになりました。

コードのコメント：研究は少し違うことを言う

同じころ、すでに従っている考えを確かめたくなりました。エージェントがコードを書き、読むなら、ほとんどのコメントは文脈を無駄にするだけです。私たちはこのルールを10月15日から持っていますが、その背後にある研究を探しました。答えは「コメントはノイズだ」より、もう少し興味深いものでした。

• 古くなったコメントは、生成されたコードを古い実装へ引き寄せます。
• モデルは、矛盾するコードよりもコメントを信頼してしまうことがあります。
• 見つけた研究では、コメントがないことはあまり問題になりませんでした。
• 正しいコメントは、自明でないコードで役に立ちました。レガシーなメインフレームのコードを扱った1つの研究では、正確さが約84％から90〜96％に上がりました。

サンプルは小さく、論文のうち2本はアブストラクトしか読んでいないので、正確な数字は慎重に扱うべきです。ただ、方向は明らかです。嘘をつくコメントは、そもそもコメントがないことより危険です。そこでルールに1つ要件を足しました。コードを変えたら、同じコミットでその横のコメントも変えるか、消すこと。コードをそのまま言い直すだけのコメントは消します。理由、数字の出典、次のエージェントが「直して」しまうであろう罠は残します。

リポジトリには今何があるか

• docs/output-legibility.md：読みやすさのはしごと、2つのルール。「STE100 で書け」よりうまく働くプロンプトの一行も入っています。
• scripts/term_drift_check.py：用語集のチェック。テストとセルフテストつき。
• docs/harness-improvement-pilot.md とその比較器：範囲を限ったパイロット。
• refactoring-safely スキルの references/dead-code-sweep.md。
• rules/quality-code.md の、更新されたコメントのルール。

すべては、リリース v2026.10.24 にあり、変更の全リストは UPDATES.md にあります。エージェントは、必要なものをリポジトリから直接取れます。まず CLAUDE.md と README.md、次に skills-lock.json に挙がったスキルを読んでください。

この中から1日分の時間を節約できたものがあれば、GitHub でスターを付けていただけると、他の人がリポジトリを見つけやすくなります。壊れているものがあれば、issue を立ててください。私たちのルールの多くは、そもそもそこから生まれてきました。