はじめに
AIがどんどん進化していく中、自分が今、AIとどう付き合っているのかを記録しておくと、後から振り返ったときに面白いんじゃないか、と思いました。
なんとなく記事にしてみます！
語彙の紹介
この記事でいうハーネス周りの文言の定義は以下の記事を参考にしています。
以前ほど定義がカオスではないと思いますが、記載しておきます。
開発での使い方
Humans in the Loop と Humans On the Loop を行ったり来たり
下記記事の分類がわかりやすいので引用します。
現在私は、基本的には Humans On the Loop 的な働き方を目指しており、Agents に指示 → 結果に問題があればハーネスをupdate のループを回しています。
ただ、Agentsの出力結果のチェックの粒度は Humans in the Loop チックで、コードを結構細かい粒度まで確認しています。
ハーネス化できていない細かいドメイン知識・業務ルールがあることや、
Rvすると、画一的にルール化できない細かい内部品質の指摘がまだまだ出てきてしまうためです。
内部品質が気になっている
私が Humans in the Loop と Humans On the Loop を行ったり来たりしている最大の理由は、外部品質だけを確認していると、すぐに内部品質が劣化してしまうという（トラウマのような）意識があることです。
プライベートのちょっとしたことをAgentsに任せていると、（私がずさんな指示をしていることもありますが）みるみるrepoの品質は下がっていってしまいます。
OpusやFableなどの上位モデルに任せても、レガシーなコードに引っ張られる、などの理由からノールックでApproveできるようなコードが生まれることはまれだと思っています。
コンテキストやハーネスが不足しているだけだ、という思いと、何を用意すればこれらが解決できるのかわからないという思いがせめぎあっています。
色々な記事を参考にしていますが、これだ！という解き方がないように思っています。リサーチ不足であることを祈っています。
また、まったく別の議論として、今私が担保しようとしている内部品質は、人間がコードを読み書きしてメンテし続ける世界観の延長にある問題意識な気もしています。
Agentsが読み書きする世界観では、また新たな観点が、内部品質の項目として現れるのかもしれないと思っています。
誰かが良い感じの記事を出してくれないか待っています。
計算的なハーネスを作成する
一方、内部品質以外の部分はかなり満足している、というか、かなりAIに任せることができるようになったと思います。
チケットの起票～実装～UT～E2E～Rv～ハーネスの更新、が最近の基本的な開発ワークフローです。
私が主に行っているのはE2EとRvです（まだまだin the Loopだなぁ・・・）。
Rvは上記した通り気になることが多く、手戻りが頻発しますが、E2Eはわりと確度高く行えています。
また、UTやE2Eテストの結果としてバグが発覚することもなく、かなりしっかり実装してくれているな、という印象です。
開発だけではなく、アラートの調査・報告・対応手段の提案もほとんどAIです。
この出力を支えているのが、計算的なハーネスだと思っています。
なるべくスクリプト化するのが丸いと思います。
計算的なハーネスについては以下を参考にしています。
計算的（computational）= スクリプトやlinterのように結果が決定論的なもの。
推論的（inferential）= AIコードレビューなどの、LLM が推論する、結果が非決定的なもの。
MEMORY機能が苦手
なるべく計算的にハーネスする、が個人的な鉄則であるため、Claude CodeのMEMORY機能が苦手です。
「次から気を付けましょう！」はレトロやポストモーテムの結論としてあまりよくない、みたいな言説があると思います。
同じ理由で、MEMORYに保存したので、覚えておきますね的な態度は禁止させています。やりすぎかもしれません。
がんばってすこしでも計算的なハーネスを作る努力をする
AIは圧倒的に私より賢いです。なので、ハーネスさえあればほとんど人間の介入は不要だと信じています。
とにかく、「なんとかして AI にやらせてみる / 人間の手から離れるように工夫する」マインドが大事だと思います（誰かの名言なのですが、出典不明）。
Fable賢い
賢い。
少し前はSonnetがメイン、Opusは必殺技、みたいな立ち位置でしたが、いまはOpusがメイン、Fableが必殺技って感じです。
Fableがメインになる日が来たら最高ですね。私のエンジニアとしての価値がなくなる日がその日かも。
認知負債
一時期かなりしんどかったです。だいたいあってるのがタチ悪いですね。
コードだけではなく、後述するPR概要など、AIが生成する量にとにかく圧倒されていました。
最近はeli5などのHTMLで説明させるテクニックのおかげでかなり認知負債に立ち向かえるようになった気がします。一度に大量の情報を咀嚼しようとせず、往復して大事な部分だけを食べきることが大事だと思います。
mizchiさんのskillsも良さそう。
あとClaudeのブログにあったクイズを出題されるテクニックもよかったです。
AIが生成した文章の取り扱い
AI語
イラっとする → あきらめて許容する → イラっとする ・・・ をループしています。
「効きます」はとくに私に効きます。あとさっき「段１」なる単語が出力されました。phase？
こういうわかりやすい特徴があって、見分けることができるうちはまだ幸せなのかもしれないな、とも思います。
AI PR概要
PRのRvを依頼された時、私はとりあえずAIに説明を求めます。PRの全体を確認させ、上記したHTMLなりを生成してもらいます。
私自身が他者のPRにこのような対応を行っているため、最近まで、PRの概要などもえいやでAIに書かせていました（みんなそうしてると思ってました）。
あるチームメンバーが、Rv依頼が来た時、まずPR概要を自分の目で確かめている、といった話を聞きました。
PRをRvするという責任をとる姿勢として、それがとても立派に思えました。
他者がオーガニックに目を通す以上、AIにえいやで書かせるわけにはいきません。
PR概要はAIに生成させた後、推敲を行うよう作業の仕方を変えました。
自分でPR概要を考えることで、変更の理解の促進にもつながり、結構良いなと思っています。
AI生成文章の量
伝えたいことから逆算して、削る / 必要な項目を伝える べきだよね、ということをチームで会話しました。
これはその通りだと思い、意識するようにしています。
t-wadaさんも少し違う形ですが、AI成果物を丸投げすることは、確認を他者に押し付けているだけだ、といった旨を発言されており、そうだなぁと感じます。
Rvコメント、Slack
Rvコメント や Slack の返信もなんとなくオーガニックに対応しています。この記事も基本的には手でぽちぽちしています。
なんとなく、人と人のコミュニケーションなので、自分でやりたい、という気持ちなのかもしれません。
AIが自動返信してくれるLINEの機能も使ったことがないです。
AI記事
我ながら潔癖すぎますが、AI語が出ると即離脱してしまいます。
最近はもう、記事を初見で読むとき、内容を楽しんでいるのか、AI製かどうかをチェックしているのか、自分でもわけがわかっていません。
「AI Slop」的な単語が流行ってきて、なんとなくAI記事が減ってきている？気がしています。・・・そんなことないかもしれませんが。
AIが登場する前も、質の低い記事はコミュニティにとって害ではないか？というような議論が少しあった気がします。私は質が低くてもアウトプットすることは素晴らしいと思っていましたが、AI Slopに対しては真反対の立場です。不思議なものだと思います。
私の中では、RvコメントやSlackの返信のように、記事は人と人のコミュニケーションのツールなのかもしれないと思いました。だからオーガニックな手触りが恋しいのかもしれません。
AIを通した途端、「伝えたいこと」という熱が消え、「仕事だから作ったもの」「バズりたいから作ったもの」的な下心を勝手に受け取ってしまうのかもしれません。我ながらやはり潔癖すぎますね・・・。
AI時代のエンジニアのキャリア
深津さんの記事が出たころは色々もんもんと考えていましたが、最近は深く考えないようにしています（よくない）。
私が好き好んでいたプログラミング的な作業はもう既にAIに奪われていますし、これからより奪われていくと思うので、もうどうにでもなれーって感じです（よくない）。
さいごに
思いついたことを書きなぐってみましたが、結構楽しかったです！
AIの進化はすさまじいので、定期的に自分の考え、困りごとを目に見えるところに残しておくと、あとから振り返って楽しいはず！！