生産性の向上や低下を特定の技術やプラクティスに結びつけるのは本当に難しい。自己報告の逸話には慎重にならざるを得ない、簡単に自分を欺けるからね。どちらの方向にも主張はしないけど、著者たち自身も研究の限界を認識しているし、みんなもっと大きな誤差範囲を持つべきだと思う。この技術は、私の人生で見た中で一番変なもので、逸話や疑わしいベンチマークから生産性を推測するのは、まるで茶葉を読むようなものだよ。

図21を見ると、初期の実装時間（PRまでの時間）は増加しているけど、レビュー後の時間はさらに増えているね（でも、トータルには大きな影響はなさそう）。でも、図18では、実際にコーディングに費やす時間が減っているのがわかる（これがスピードアップを感じる理由かも）。その分、AIの出力を促したり、待ったり、レビューしたり、全体的に待機している時間に取られているから、5分以内で自分でできるタスクにLLMを使うのはあまり良くないかもね。

質的には、AIが許可された条件と許可されていない条件の間でPRの質が落ちているのは見られないよ。参加している開発者たちは一般的に優秀で、自分のリポジトリの基準をよく理解しているし、「悪いPRを出す」雰囲気にはあまり興味がないみたい。研究のPRの中央値レビュー時間は約1分だよ。ただ、開発者たちの時間の使い方は全然違うから、これはいい指摘だね！論文の10ページ目[1]には、AIがある時とない時で開発者がどう時間を使っているかの内訳が見られるよ。一般的に、AIがあるときはコーディングに使う時間の割合が少なくなって、AIと作業する時間の割合が増える（これは…納得できるね）。[1] https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf

そして残りの20%を終わらせるのに80%の時間を使う これは私のAI導入前の経験でもあったから、最初の部分の時間を取り戻すのは助かる。関連して、経験豊富な開発者がAIについて言っていた良い意見の一つは、「私のスキルの90%が無価値になり、残りの10%が1,000倍価値が上がった」ってこと。ちょっと誇張はあるけど、言いたいことは分かる。

基本的にスタックオーバーフローのステロイド版が必要な時に一番役立つと思う。やりたいことは分かってるけど、この環境でどうやって実現するかが分からない時に使える。デバッグやラバーダッキングにも一般的に役立つよ。

既存のコードベースに何かを追加するのはめっちゃうまくいくよ。「この検索パラメータがあるから、fooも追加して」みたいな感じで。xに関するものは全部削除して…

以前は逆パレートみたいな感じで、80%の作業に80%の努力が必要で、残りの20%の作業にも80%の努力がかかってた。AIコーディングでやるべきことが分かれば、作業がすごく早くなるってのは確かだと思う。昨日、JavaのストリームAPIを使ってListオブジェクトから何かを削除しようとしてたんだけど、ConcurrentOperationsExceptionsに何度もぶつかってさ。これは複数のスレッドが同時にリストオブジェクトを変更しようとするから起きるんだよね。どのスレッドも他のスレッドによって変更されていない最新のリストのコピーを持ってるとは限らないから。リストをディープコピーして変更を加えてからそのコピーを返すメソッドを書こうと1時間くらい奮闘してたけど、AIにスレッドセーフなリスト変更メソッドを作ってもらったら、「もちろん、こうやってやるけど、君が使ってるAPIにはもうこれをやるメソッドがあるよ」って言われた。こういうケースこそ、AIがめちゃくちゃ役立つんだよね - 複雑だけど明確な問題。

古い開発者として、これが本当に欲しいものなんだよね。文法エラーを自動で修正してくれる機能があれば、コンパイルと編集のサイクルを少し減らせるんだ。

同意！「いつももう少しでできそう」って感じが時間を無駄にするよね。AIは特に、何か役立つことをしているように感じさせるのが得意だから、真実を見極めるのはかなりのスキルが必要だよ。