「ワークツリーで並行エージェントを使ってるけど、フライクックが20個のバーガーを同時にひっくり返すみたいに、常に目を光らせてるわけじゃない。時々、エージェントを立ち上げて、明日戻ってきたら進捗があって、今の流れを壊さずに済むっていうのがいいんだ。」

「私がこれを扱う方法は、プルリクエストを作ることなんだ（エージェントに最後にやらせるように言う）。それから後でレビューするために戻ってくるから、常にレビューするためのものがキューに入ってる状態になる。」

「マルチエージェントフローとスピードや正確性への影響についての研究が欲しい。運転中にテキストを送る状況みたいに、スキルの自己認識と測定されたスキルの損失が乖離してる気がする。ただ、このアイデアを裏付けるものは何もないけど。」

複数のエージェントを常に使いこなすのって、生産的なのかな？魅力を感じたことはないけど（たまに2人のエージェントならあるかも）。やってるタスクの種類によると思うけど、大きくて長時間かかるタスクならうまくいくかもしれない。でも、その大きな変更をレビューしたりリファクタリングするのが難しくなるよね。複数のエージェントを使ってると、メンタルのコンテキストスイッチや管理のためのツールのオーバーヘッドもあるし。予測可能で繰り返しのタスクならうまくいくかも。私は基本的に1つのタスクに集中するのが好き（短時間なら2つ同時にやったり、他のエージェントに質問したりすることもあるけど）。タスクを小分けにして、レビューするものができるまであまり時間がかからないようにしてる。その後、レビューして、リファクタリングをお願いしたり、次のステップに進むようにしてる（コードに自信があれば、レビューを終える前に少し続けさせることもある）。小さくて自己完結した部分をレビューする方が楽だし、関連する行が少ないから、AIに何を変える必要があるか伝えるのも簡単だよね。

「結局、私たちは悪い指標に反対していたわけじゃなくて、測られることに反対していたんだ！自分たちで選ぶチャンスがあれば、同じナンセンスに飛びついてしまった。」これは違いのない区別に思えるけど、実際に良い指標があるなら別だけど（それには客観的かつ信頼性のある定量化が必要）。ほとんどの開発者は自分を測りたくないと思ってるんじゃないかな。ただ、AI推進派の人たちは、何かを改善したって説得力のある主張をするために測定が必要だと思ってるだけだと思う。」

もしかしたら著者もそれを知ってるけど、やっぱり話したいんだろうね。記事の最初の行：「コミットは出力の悪い指標だけど、私が持っている最も目に見えるシグナルだ。」

コードの行数は、合計で見ると意味があるけど、個人の貢献を測る指標としては無意味だよね。COCOMOはコードの行数を考慮していて、少なくともアメリカの裁判所が関心を持つ限り、ソフトウェアシステムの価値を見積もるのに正確（十分）だと一般的に受け入れられてる。 https://en.wikipedia.org/wiki/COCOMO

俺もClaudeの使い方を学ぶために色々試してるんだけど、全部新しいことばかりだよ。どんどんアップグレードしていかないとね。

それと、著者が燃え尽き症候群や不安についてのブログ記事を書いてるみたい。もしかしたら、そういうことが全部関係してるのかも。自分を病気にするまで働くのは誇りに思うべきことじゃなくて、何かが壊れてるサインだよ。個人が問題なわけじゃなくて、その人がいるシステムかもしれないし。

複数のエージェントが「異なる機能に取り組んでいる」ってところで、俺はついていけなくなる。どれだけループから摩擦を取り除いても、結局そのコードを見なきゃいけないんだから。5つの異なる機能ブランチを切り替えて、コードをちゃんとレビューするのは、AIの助けがあっても、ちゃんとやるとほとんど生産性の向上を食いつぶしちゃうよ。これを回避する唯一の方法は、ペンシルでレビューをサクサクやることだね。

もちろん、コードの行数は意味のある指標だよ。著者がそれが唯一の意味のある指標だとは言ってないしね。

意味がないわけじゃないよ。ただ、唯一のものとして持ち上げるべきじゃないってこと。時には、いくつかのプロキシを持つのもいいと思う。他の方法でも価値を見ていればね。 /shrug

参考までに、AIを使ってるんだけど、「最大行数/コミット数」じゃなくて、「最小PRコメント数/イテレーション数/バグ数」を最適化してる。最終的には、少ない/シンプルなコードで、より大きなインパクトを目指してるんだ。実際の目標はビジネス価値、そして最終的には人間の価値だよ。それに向けて最適化して、AIをうまく活用していく感じ。具体的には、いくつかのテクニックを試してるんだ：1. 複数のエージェントに要件をゼロから実装させて、彼らのアイデアを自分の考えと組み合わせる。2. ドキュメント（要件、背景情報、用語集など）を集めて、それに向けてエージェントをターゲットにして、役立ちそうな質問を慎重に選んで聞く。3. エージェントに自分のコードをレビューさせて、同意できるレビューコメントを一般的なガイドラインの再利用可能なチェックリストに抽象化して、そのガイドラインを使って次回のコードレビューでエージェントに伝える。時間が経つにつれて、コードレビューがコードベースや取り組んでいる問題にますます適合していくことを期待してる。

俺にとって、コミット数や似たような指標はAIの導入を示すもので、それ以上のものじゃない。今のところ、多くの人にとってそれが目標なんだよね。どれだけ短期的か長期的かは別として。

時々、成果や達成、仕事の成果物は、単に同僚と自分を比べるためだけじゃなくて、もっと役立つことがあるよね。キャリアの初期段階じゃない限り、こういう考え方はちょっと変だと思う。

現代のコンパイラを使うことを自慢してるみたいだ。でも、GHCみたいな現代のコンパイラを使うと、俺が生産性が上がるって言うと、周りの人は俺が変わり者みたいに見るんだよね。

これが私にとっての最大のボトルネックなんだ。さらに悪いことに、LLMは冗長になりがちで、触れる必要のないものまで書き直すから、変更の範囲がすごく広くなる。

コーディングエージェントを使って、出荷しない大量のコードを作ってる。でも、コードの出力は出荷してるよ。

私の提案はこれだ：真剣な計画を立てること。計画には制約、範囲、エスカレーション基準、完了基準、テストとドキュメントの計画を含めるべき。単一責任の原則、CQRS、ドメイン分離などを徹底すること。コードをできるだけ理解しやすくするようにする。ドメイン名や関数・変数の命名規則を守って、コードを話しやすくする。コードレビューのボット（Sourcery、CodeRabbit、Codesceneなど）を使う。小さなこと（契約違反、アンチパターンなど）から大きなこと（UXの懸念、アーキテクチャの欠陥など）までキャッチしてくれる。リンティングを徹底する。ルールをできるだけ厳しくして、レビューのボットにルール違反を指摘させる。レビューのボットが頻繁に文句を言うことについて、自分でリンティングを書く。BDDをユニットテストと併用して、ビルド前に.featureファイルを読んでフィードバックを与える。通常のテスト戦略の一部としてプロパティテストを使う。スナップショットテスト、MITMプロキシを使ったe2eテストなど。非自明な複雑さを持つ関数については、制約付きまたは無制約の証明、モデルチェック、未定義動作テストを考慮する。ミューテーションテストやファジングも調べてるけど、まだ学んでるところ。頻繁にコード監査を行うために一時停止する。エージェントにコードの重複、冗長性、誤った仮定、アーキテクチャやドメインの違反、TOCTOU違反を監査してもらう。新しい機能に戻る前に、負債を返済するメンテナンススプリントを自分に与える。エージェントによるコーディングの美しさは、突然これらすべてのための時間ができることだよ。

そうだね。今は生成されたテストケースをレビューしてるだけのことが多いよ。>「壊れたら、エージェントに直させればいい、手動のデバッグは不要！」って？今はすべてのSentryの問題にAIが最初のアプローチをするのは結構トリビアルだよね。

「他の人の/機械のコードを読むのは、自分で書くより難しい」って言うけど、全然そんなことないよ。練習すればするほど簡単になるスキルだから。たくさんのPRをレビューする立場にいると、すぐに上達するし、コードが何をしようとしているかの文脈を知ってると、さらに簡単になる。例えば、チームメイトのPRをレビューしたり、AIに書かせたコードを見たりする時はほぼいつもそうだよね。前にも言ったけど（例: https://news.ycombinator.com/item?id=47401494）、AI生成のコードをレビューするのはすごく軽い作業だと思う。タスクを分解して、コードがどうあるべきかを知ってるから、珍しい問題がすぐに目立つんだ。それに、包括的なテストに頼ってるし、コードよりもテストケースをじっくり見ることが多い。これでもかなりの時間を節約できるよ、特にタスクの範囲が関数からモジュール全体に広がったからね。ただ、同時に複数のエージェントを使ってるわけじゃないから、AIを使った時の生産性はAIなしよりもずっと高いけど、聞いたことがある信頼できる報告ほどではないかな。彼らが個人的にコードをレビューしてるかは分からないけど（例えば、エージェントにレビューさせてるのかな？）、正確性のための戦略は持ってるみたい。

それはブレンドだね。プロダクションシステムには、人間のレビューが必ずしも必要ない変更がたくさんある。ヘルプリンクを追加したり、タイプミスを直したり。強力なCI/CDやシンプルなUI改善、安全な実験を伴うアップグレードもある。フィーチャーフラグや段階的リリースの後ろで安全にスキップできる機能もある。適切なツールを使って進めていけば、かなりのことができるんだ。細かく分ければ、最小限の人間の介入で安全にデプロイできることが多い（もちろんドメインによるけど、多くのシステムではね）。全体のプロセスを見直すことを目指してるんだ。ここにちょっと書いたよ： https://jonathannen.com/building-towards-100-prs-a-day/

AIを使っていくつか探求的な学習をしてみたけど、学ぶのにすごく役立つね。俺の意見では、AIで経済をめちゃくちゃにしてるかもしれない。AIはより良い労働者を育てるべきで、一人に三人分の仕事をさせるために雇われるべきじゃない。AIの力を使って学習をスムーズにし、専門知識を高めることが適応の目標であるべきだよ。もちろん、AIを仕事のアシスタントとして使うのは強力だけど、AIを過剰に宣伝するCEOたちのせいで、経済全体に悪影響を及ぼしてるのが本当に問題だと思う。特に、今のマーケティングが次の世代にAIが完璧に置き換えられる役割を放棄させる原因になってるからね。まるで都市化の人口爆弾がステロイドを使ってるみたいだ。

これが俺がめっちゃ期待してる唯一のユースケースなんだ。これに関しては革命的だよね。賛成！

多くの人がこうやって使ってるよね。弱点を回避しようとするんじゃなくて、強みを活かしてる感じ。「YをするためのX言語のイディオム的な方法は？」って聞くと、数秒でしっかりした役立つ答えが返ってくる。でも、ただの優れたツールであって、終末的なものでも、みんなを解雇するためのものでもないから、ちょっと過剰に期待されがちなんだよね。

あなたが提供したリンクでは、swcは同じものだよ。

両方のリンクは同じで、この文脈でのSWCはおそらくSpeedy Web Compilerのことだね。すごく早くトランスパイルするけど、型チェックはしないんだ。

同じものだと思うよ。2つ目のリンクは、swcをnestjsで使う方法についてだね。