Herness Engineering

そうだよな、この運用ループが、Herness EngineeringやLoop Engineeringで言われているようなことの実態だよな。

ぼくはおそらく身体感覚を通じて新しい概念を獲得するのが向いているので、DO-GUという小さな小さなウェブアプリケーションの運用を通じて、ひとつでも多くのことをAI Agentに任す、を練習できているのはグッドな状態。

自分の意思決定の記録を構造化されたログに落とし、それをAI Agentと共有すること。Human in the Loopが、ようやく体感としてもわかってきた気がするな〜。

というわけでDekigotoの方もループの中に自分を組み込むべく整備を進めた。DO-GUの運用よりは複雑度が高いので、ループをうまく設計しなくちゃいけない。

予約を取っていたので歯医者に行く日。定期の検診を受ける。思うことがあるので、ここでCoding Agentの話をする。

決定論的に「こうしてほしい」という期待を自然言語で指示して非決定論的に処理させて、エージェントが期待通りに動かなかったときに「いや、そうじゃなくて」とダメ出しして軌道修正していくと、疲弊する。コーディング規約でいえばLinterを導入して「違反があるかどうか」をピッと判定できるようにしてやれば、エージェントも「あ、ここがちがうね、直そう」と自走できるようになる。これがHerness Engineeringで言われているようなことね。

歯科衛生、ハーネスがないんだよな〜。今日の検診でも「もうちょっとちゃんと磨くようにしてください」「気をつけてみてください」と言われてしまって、なかなかむつかしい。毎日ね、一定の時間をかけて歯みがきして、鏡を見て「こんなもんかな」とチェックまでして、これなのよね。「この歯みがきで十分か」を本人が判定できない限り、定期検診のたびにダメ出しが繰り返されるだけ、という感じがする。歯みがきにおけるグッドなハーネスってあるもんですか？なにか知っている人がいたら教えてください。

Herness Engineeringのような流行り言葉、他者とまじめに議論するときには使用を控えるのだけれど、自分の日記では雑に使っている。そのときのトレンドとなっている視点で物事を見てみたらこういうことを感じました、の記録が残るのは自分にとって有益なので。以前には「歯のCIをまわしたい」と言っていた。

ちょいちょい魔虚羅のことを考えるんだけど(？)、あらゆる事象への適応ってところがかっこよくて、フィードバック・ループ、改善、って感じだし、流行り言葉でいうとHerness Engineeringじゃん。自分用エージェントの名前はMakoraにしてもいいかも。かわいい名前だし。あるいは /makora ってAgent Skillsをつくるのもいい。

ワークフローとフィードバック・ループについて考えていた。たとえば、組織におけるオンボーディングを題材にしてみる。新しいメンバーを迎えるときの「受け入れ」の手順が

• まったくまとまっていない
• 誰かの頭の中になんとなく存在している
• 誰かの頭の中に確固たるものとして存在している
• 明確なドキュメントになっている
• 動作するスクリプトになっている

こんなレベル分けができるだろう。上に行くほど不安定で、誰かのときはばっちりだったけれど、別の誰かの受け入れのときはヌケモレがあってドタバタしちゃった、ってことが起きやすいだろう。ドキュメントやスクリプトになっていて、それがフィードバックによって更新されるとしたら。受け入れをこなすたびにどんどん洗練されていくはずだ。

自分は、すべてのワークフローに対してそういう視点を持って関わっているという感覚がある。場のまんなかに「共有された資産」となるものを置いて、関わる人たちがそれを育てていく。フィードバック・ループによってワークフローを洗練させていくというのは、そういうことだ。

…ってなことを考えたり考えなかったりしながら、あらためてMitchell Hashimotoさんのテキストを読んだ。Herness Engineeringって概念が登場したテキストね。

At risk of stating the obvious: agents are much more efficient when they produce the right result the first time, or at worst produce a result that requires minimal touch-ups. The most sure-fire way to achieve this is to give the agent fast, high quality tools to automatically tell it when it is wrong.
I don't know if there is a broad industry-accepted term for this yet, but I've grown to calling this "harness engineering." It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again. I don't need to invent any new terms here; if another one exists, I'll jump on the bandwagon.
My AI Adoption Journey–Mitchell Hashimoto

当たり前のことを言うようだが：エージェントは最初から正しい結果を出すとき、あるいはせめて最小限の修正で済む結果を出すときに、最も効率的だ。それを実現する最も確実な方法は、エージェントが間違っているときに自動的に教えてくれる、高速で高品質なツールを与えることだ。
これを業界全体で受け入れられた用語があるかどうかはまだわからないが、私は「ハーネスエンジニアリング」と呼ぶようになった。考え方はこうだ——エージェントがミスをするたびに、そのミスを二度と繰り返さないような仕組みをエンジニアリングする時間を取る。別に新しい用語を作りたいわけではなく、すでに定着した言葉があればそちらに乗っかるつもりだ。

ここでは「エージェントがミスをするたびに」と主語に「エージェント」が置かれているが、ぼくたち人間が「人間」を主語にしてずっとやってきたことと、構造としては同じことを言っているのだろう。ボーイスカウト・ルールも近いよね。それが、ことCoding Agentに置いては、効果が劇的なのだと思う。うまく環境を整備したら短期的に大きな変化を実感できるので、整備めっちゃ大事やで〜〜って話に「せやな〜！」となっているのが今なのだろう。

Vibe Codingって言葉が生まれた約1年後にはHerness Engineeringって概念が支持を集めているの、おもしろい気がする。拓いて耕す、拓いて耕す、ってイメージ。めちゃくちゃでも地平を切り拓いていく動きと、そうして切り拓かれた場所を整えていく動き。どっちの時期も、どっちの役割も大事よな〜。