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

図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は特に、何か役立つことをしているように感じさせるのが得意だから、真実を見極めるのはかなりのスキルが必要だよ。

でも、実際のコードを生産するのはどうなの？

https://metr.org/about AI企業からお金をもらってるみたいで、政府からの資金も受けてるみたいだね。

最大の資金はThe Audacious Projectから得たもので、ここに発表があるよ：https://metr.org/blog/2024-10-09-new-support-through-the-aud... 私たちのウェブサイトによると、「2025年4月現在、私たちが行った評価に対してAI企業から報酬を受け取ったことはありません。」このページの脚注もチェックしてみて：https://metr.org/donate

企業はいつもホワイトペーパーを出してるよね？大体は技術報告、政策提案、組織の広告が組み合わさったものだよ。

世界のほとんどは研究のための資金を提供してるけど、アメリカは以前は資金を提供してたけど、今はほとんど削減されちゃったね。

「学術雑誌に載っていない、またはピアレビューがないものは？」知識論や存在論に興味がある哲学者として、これは宗教と同じくらい嫌悪感を覚えます。「科学」は誰が出版するかは関係ありません。科学は再現性が必要です。心理学の再現性危機は、なぜピアレビューや雑誌への掲載が重要なのかの典型的な例です。

Claude 3.7ではSkynetを作るのは無理だとわかって安心した！

これ、見た中で一番いい研究の一つだと思う。クリックベイトじゃないし、主張がはっきりしてて、すごくわかりやすいフォーマットで提示されてる。ほんとにありがとう！

データセット（生データだけど匿名化されたもの）を独立した統計評価のために公開するか、少なくとも各開発者のタスクごとの絶対時間を論文に追加してもらえないかな？各開発者がAIあり/なしでどれくらいの絶対時間を使ったのか、特にたくさんのCursor経験がある一人が他の人より実際に速かったのか、ただの遅いタイパーがLLMから大きなブーストを得ているだけなのか、すごく気になる。それに、素晴らしい研究だね。単なる雰囲気やハウス効果を考慮しない観察研究じゃなくて、実際に良い評価が見られて嬉しいよ。

AIの助けを借りて実装されるチケットが、AIに適したユースケースかどうかに注意が払われてたのかな？もし指示が「このチケットをAIで実装して」だけなら、それは現実的だけど、管理側がよくやるやり方でもあるし、最適とは言えないかも。AIを使う方法には役立つものもあれば、逆に悪影響を与えるものもある。もし開発者がAIに十分な経験があれば、その違いを見分けられたかもしれないけど、論文を読む限りそういう兆候は見えなかったね。

「私の直感では、この研究は主にAI支援開発の学習曲線が高くて、開発者に既存のワークフローに組み込ませると、その学習曲線を登る間にパフォーマンスが落ちることを示したと思います。確かに。効果的なLLMの使い方は、みんなが思っているほど簡単じゃないです。多くの開発者がチャットを共有するときにやることが2つあります。1つ目は、LLMに人間のように話しかけること。インターネット検索が初めて出たとき、人々は本当に「ジーヴスに聞いていた」ことを覚えていますか？結局、人々は「サンフランシスコの現在の天気は？」なんて入力する必要がないことを学びました。「サンフランシスコ 天気」と入力すれば同じか、それ以上の結果が得られるからです。今、また人々はLLMに人間のように話しかけるようになっています。これは高度なプロンプトエンジニアリングからではなく、ただ単に人間らしく感じるからです。でも、「pandas count unique values column 'Foo'」は、「pandasを使って、'Foo'という名前の列のユニークな値のカウントをどうやって取得するの？」と同じくらい効果的なLLMのプロンプトです。LLMも、そんな風に話しかけられても気を悪くしません。2つ目は、LLMの使い方を止めるタイミングがわからないこと。LLMが80%のところまで助けてくれても、残りの20%を「手動」で処理しようとせず、LLMにプロンプトを続けて生成させようとします。たまにはうまくいくこともありますが、ほとんどの場合は時間の無駄で、LLMの出力を手動で調整する方がずっと効率的です。いわゆるGoogle-fuのように、LLMの使い方もスキルで、何をしているかわからない人は、質の低い結果しか得られません。

こんにちは、サイモン！論文の詳細な読み込みありがとう - あなたのOSプロジェクトの大ファンです！いくつか重要なポイントを挙げますね。1つ目、スピードアップを見つける以前の研究は、開発者が使うツールに対して似たような（またはそれ以下の！）経験を持っている場合が多いです。つまり、「急な学習曲線」理論は、私たちの結果と他の結果を差別化するものではありません。2つ目、研究の前に90%以上の開発者がLLMのプロンプトに対して合理的な経験を持っていました。私たちがスローダウンを見つける前、外部のレビュアーが持っていた唯一の懸念はプロンプトに関するもので、プロンプトは主要なスキルと見なされていました。一般的に、標準的な知識は、CursorはVSCodeに慣れている人にとって非常に簡単に習得できるというものでした。3つ目、これらの開発者がAIの経験をたくさん持っていたと想像してみてください。これが、AIを使わないときに彼らが悪いプログラマーになる要因かもしれません（少なくとも私には共感できる）、それが私たちが見つけたスピードアップを引き上げることになります（でもAIが良いからではなく、AIを使うときが悪いからです）。つまり、私たちは岩と硬い場所の間にいるようなもので、正しいベースラインを見つけるのが本当に難しいです！4つ目、私たちは開発者の過去の経験に関する情報を専門の予測者と共有しました。この情報があっても、予測者はスピードアップに関して過度に楽観的でした。5つ目、あなたが言うように、これらのツールを使うためのスキルには長い尾がある可能性がある - 何百時間も使った後にしか気づかないこともある。私たちの研究はこれについてあまり触れていません。将来の文献がこれをもっと探求することに期待しています。一般的に、これらの結果が驚くべきものであるため、論文を読みやすくし、共鳴する要因を見つけて「これがスローダウンを説明しているかもしれない」と結論づけるのは簡単です。私の予想では、単一の要因はない - この結果に寄与する要因がいくつかあり、少なくとも5つは可能性が高く、少なくとも9つは排除できません（11ページの要因表を見てください）。また、非常に重要なポイントとして、AIを使った後の開発者の自己報告がスピードアップ/スローダウンの観点で過度に楽観的であることは、どのツールを使うかには関係ないということです。生産性の向上を正確に判断するためには、堅牢で現場に基づいた測定が必要だというのが、私にとっての重要なポイントです！（論文のC.2.7節「AIツールの平均未満の使用」で、ここでのポイントをもっと詳しく探求しています。）

AIツールのおかげで生産性が上がった人もいれば、そうでない人もいることに気づきました。私の仮説は、たくさんのテキスト（またはコード）を素早くスキャンできる人が大きなアドバンテージを持っているということです。役に立たない提案を素早く却下し、役立つ支援にたどり着くための反復が重要です。コードを素早くスキャンできることは経験年数と相関していますが、しっかりとしたペースで書けるシニア開発者もいて、彼らはコードをじっくり読んで理解することを好むこともあります。このような開発者が典型的なAIコーディング支援からあまり利益を得ないとは思いません。また、素早くテキストを読むことができるジュニアもいて、彼らにもアドバンテージがあるかもしれません。素早く「グーグル」できることと似たような効果があると思います。これが同じ特性であるとは驚きません。

「経験豊富なエンジニア」はどう定義されているのですか？私は、全く新しいコードベースをナビゲートする際に、AIが正しい方向に導いてくれるのがとても役立つと感じています。すでに手の内にあるコードについては、リファクタリングのような自動化されたタスクを除いて、あまり役立たないですね。良いツールがしばらく前からあったので。

「私の個人的な理論は、LLMの支援やAIツールから大きな生産性向上を得るには、ほとんどの人が予想するよりも急な学習曲線があるということです。これには完全に同意します。ただ、AIツールから良い出力を得るのが上手くなった後でも、生成しているコードをしっかり学べないと、悪い状況に陥ることがあります。開発者は時間とともに自分が作業しているコードが上手くなりますが、LLMは悪くなります。LLMを使ってたくさんのコードを素早く書くことはできますが、十分に注意を払わなければ、LLMが悪化している間に自分のコードが上手くならないのです。だから、週末に2ヶ月分の作業を終わらせることができても、壁にぶつかることがあります。書かれたコードについて何も学んでいないからです。そして、LLMは最初は合理的なコードを生成していましたが、悪化してしまい、あなたもLLMも効果的に作業できない泥の塊ができてしまうのです。だから、私にとって本当に難しいスキルは、常に誘惑を避けることです。1ヶ月分の機能を作るのに1週間かけるべきで、2ヶ月分を週末にやるのではなく、LLMにクリーンなコードを生成し続けさせるために努力し、自分がそのコードを理解していることを確認することが重要です。コードを理解したいと思っているなら、自分自身で努力しないとそれはできません。」

私の個人的な理論は、LLMの支援やAIツールからの生産性向上を得るのは、多くの人が予想するよりもずっと急な学習曲線があるということ。ここで的を射た意見だね。AIコーディングアシスタントが役に立たないと強く主張している人をたくさん見てきた気がする。AIコーディングアシスタントを使って楽しんでいる私としては、この研究のアプローチは…うーん…現実に根ざしているとは思えないかな？これらのツールを使っているなら、役に立つという事実はかなり否定できないと思う。もし「生産性の蜃気楼」がここで起こっていると思うなら、それはそれでいいけど、まずは役に立つ部分を認めて、その後に自分の方法が私たちが見ている現実を説明していることを示す方が良いんじゃないかな。AIが特定のタスクやコンテキストで役に立たないかもしれないというのは理解できるけど、私はその限界を押し広げ続けていて、彼らがどれだけ能力があるかに驚かされているから、そうじゃないことを証明するのは難しい気がする。

さて、75%の参加者（全員がLLMを使った経験がある）が生成AIを使うと遅くなるというのは、2つの解釈ができるね。LLMには非常に急で長い学習曲線があるということ（ただし、他の返信の論文の著者の指摘も考慮してね）。現在のLLMは、プログラミングアシスタントとして売られているほど良くないし、人々はその有用性について常に間違った方向に予測したり自己報告したりしている。

その話はもう1年以上聞いてるけど、チャットボットを使うのはそんなに難しくないよね。「AI」前にオープンソースで生産的だった人たちも、今は特に成果が上がってるわけじゃないし。そういう話を信じてる人の多くは「AI」マネーと関係があるけど、勘違いしてる人もいるかもね。

「私の直感では…」 - 同意する！効率的に作業するためにはいくつかのことをやる必要があると思う。 - AIの助けを借りて、質問に答えたりコードの設計や構造のあいまいさを明確にするためのarchitecture.mdファイルを維持すること。 - bootstrap.mdファイルも多くのタスクに役立つよ。AIに読ませて、テーマについて正しいアイデアを持たせるのは、いろんなタスクの時間を節約できる。 - 定期的にAIにコードをリファクタリングしたり、簡素化したり、モジュール化したり頼むこと。これが経験豊富な開発者の役割だね。VIBEコーディングはあまり効果的じゃないことが多いけど、具体的な変更を頼むと喜んで応じてくれる。 - AIが生成したコードを読み、注意深くレビューすること。そして、問題がある部分に気づいて修正を頼む。 - 自分がもっと効率的にできる編集作業は引き継ぐ。 - AIがうまく機能するような解決策やアーキテクチャを構築すること。AIが得意なことを考えてね。 - AIの使用をやめて自分でコーディングするタイミングを知ること。特にAIが混乱のループに入ったときは、自分で修正した方がいい。 - AIを使うのをやめるべきタイミングを知ること。直感的に、AIに安全に作業させられないコードがあるってわかるよね。ソフトウェアを壊さないようにしよう。 ---- AIの助けが特定のプロジェクトを早める保証はないし、逆に遅くなることもあるけど、全体のタスクやプロジェクトを通して見ると、メリットはかなり大きいと思う。多分、他の人も同じような経験をしてるんじゃないかな。

PDFの例題を見てみると（「Sentencizeが複数の文を誤って分割している...」）、これらは本当に明確で定義されたバグ修正に見える。AIはこういうタスクを簡単にこなすべきだから、あまり期待できないね。

シニアレベルでも、AIがコーディングを早めて（引き継いで）、より高いレベルの決定や抽象的な概念に集中できるようになるって言われてるけど、これらの貢献はそれとは違うし、以前の予測に基づくと生産性は上がるはずだったよね。