記事のポイントを見逃してるよ。それは実際に君のエピソードと一致してる。

開発者がシステムを理解することにあまり価値を置かず、主に動作する変更を迅速に提供することに多くの価値を置く環境で働くのは同じくらい一般的です。 この文脈では、AIツールがより有利だと思う。 彼らは、人間よりも早く不慣れなコードベースを取り込むことができ、基本的に動作する変更を生成することが多いから。

私もAIとオープンソースで似たような経験をした。 AIのおかげで、あまりよく知らない言語やスタックで機能を実装できた。 その機能が欲しかったのに、他の誰も実装しようとしなかったから。 自分でスタックを直接勉強しようとしたけど、全体像が複雑で、初心者にはドキュメントが不足していると感じた。 Warpターミナル（Claudeを使っている）を使うことで、その壁を乗り越えて、以前は全く得られなかった結果を得ることができた。

俺も似たような経験があるけど、これは研究が言ってるような仕事じゃないよ。「オープンソースの開発者が、自分がよく知っているコードベースでAIツールを使ってタスクを完了しようとすると、タスクを完了するのに時間がかかる」っていうのは、俺も実際にそうだと思う。LLMは新しいコードベースに慣れるのを大幅に早めてくれるけど、プロジェクトに慣れた後は逆に迷わせることが多い。

逸話とデータが一致しないときは、だいたいデータが間違ってることが多い。必ずそうとは限らないけど、AIが実際に人々の生産性を下げているという研究や議論を読むたびに、ほとんどのプログラマーが、俺も含めて、これらのツールに価値を見出している理由が気になる。高水準のプログラミング言語でも同じことがあったんじゃないかと思う。人々は「自分でガーベジコレクタを管理しない方が生産性が上がると思うかもしれないけど、実際は…」って言ってたし。たとえ私たちがもっと「生産的」じゃなくても、何百万もの人がこれらのツールを使いたがっているんだから、何か意味があるはずだよね。そんなことを教えてくれる「研究」は必要ないよ。

明らかにその研究を読んでないね。問題は、開発者たちが自分たちは20%速くなったと思ってたけど、実際は遅くなってたこと。とりあえず、あなたのプロフィールをざっと見た感じ、バイブコーディングに関して利害の対立があるから、あなたの意見はちょっと疑ってかかるよ。

まあ、今のところそれが得意なことだね。ボイラープレートのスターターテンプレート、ランディングページ、使い捨てアプリとか。でも、データパイプラインやセキュリティみたいに精度が必要なプロジェクトでは、生成されたコードには微妙な欠陥がたくさんあって、すべての行を掘り下げないと大きな頭痛の原因になるよ。

TFAは、彼らが取り組んでいるプロジェクトやコードベースに非常に精通している人々についてのものだったんだ。君のエピソードは、まさにその状況とは逆のことを言ってるし、君が説明しているようなプロセスも認めているよ。

あのPR、俺だったら完全に手動で書いてテストするのに、少なくとも数日から2週間はかかるな。ソフトウェア開発の見積もりの正確さってどうなの？いつも「俺だったらこうなった」とかいう生産性の主張を見かけるけど、見積もりが得意かどうかは全然考慮されてないよね。俺は見積もりが苦手だし。PRの質が本来のものと同じかどうかも考えられてないし。手順やシステムの理解をスキップして、早く進めることができるけど、その分バグが出る確率も高くなるんじゃない？AIなしでも同じスピードアップはできるよ。

LLMがそう言ってるからって、どうしてそのコードやコーディングスタイル、プラクティスに自信を持てるの？コードベースを理解してないのに、ハルシネーション（幻覚）じゃないってどうやって確認するの？

「使い方が間違ってる！」って言うのは、2023年以前のオープンソース開発者全員に対する侮辱だよ。 彼らが「AI」の強盗バロンたちが使う全スタックを生み出したんだから。 「AI」を使って実際に価値のあるソフトウェアが生産されたことがないのに、さらに侮辱的だ。

プログラミングは、テーブルソーが手作りの木工に対して持つ意味と同じだ これは全くおかしな比較だね。テーブルソーは精密な道具だけど、エージェントAIは全然違うと思う。

2025年初頭、AIが経験豊富なオープンソース開発者の作業を遅くする。これも一般的すぎるけど、タスクによるよね。オープンソース開発者がAIで時間を節約できるタスクに全く取り組まないわけじゃないし。

これが意味を持つなら、研究はどうやって問題やタスクがどれくらいの時間で終わるべきだったか、AIを使った場合にどれくらい時間がかかったかを合理的に測定できるの？それとも、開発者がAIを使った場合の所要時間と、実際にかかった時間を比較しているの？それには開発者のAIが生産性に与える影響の推測も含まれているよね？問題を完了するのがどれくらい難しいかを見積もるのが難しいとき、研究はこれをどう考慮しているの？推定が難しいために、どのくらいのパーセンテージのスピードアップやスローダウンがノイズになるの？このあたりの測定は本当に難しいことは理解しているよ。

それ、まさに俺も同じ意見だわ。エンジニアが経験のないツールを使うと、どうしても作業が遅くなるよね。AIも同じだよ。

ここで詳しく掘り下げてくれてありがとう！他のスレッドから関連するコメントをコピーしておくね（https://news.ycombinator.com/item?id=44523638）。これがこの点に役立つかも。

1. 以前の研究では、スピードアップを見つけたのは、使っているツールに対して同じくらい（またはそれ以下の）経験を持つ開発者たちだった。つまり、「急な学習曲線」理論は、私たちの結果と他の結果を区別するものではない。
2. 研究の前に、90%以上の開発者がLLMを使うための十分な経験を持っていた。スローダウンが見つかる前は、外部のレビュアーたちが経験について心配していたのは、プロンプトのことだけだった。プロンプトが主なスキルだと考えられていたからね。一般的には、標準的な知恵として、CursorはVSCodeに慣れている人にはすごく簡単だと言われていた。
3. もしこれらの開発者がAIの経験をたくさん持っていたら、AIを使わないときにプログラミングが下手になるかもしれない（少なくとも俺には共感できる）。それが、私たちが見つけたスピードアップを引き上げることになるかも（AIが良いからじゃなくて、AIを使うときがひどくなるから）。つまり、私たちはちょっと板挟み状態なんだよね。正しい基準を見つけるのが本当に難しい！
4. 開発者の過去の経験についての情報を専門家の予測者と共有したんだけど、これでも予測者たちはスピードアップについて過剰に楽観的だった。
5. あなたが言うように、これらのツールを使うためのスキルには長い尾がある可能性があるよね。何百時間も使った後にしか気づかないこともあるし。私たちの研究はこの点にはあまり触れていないけど、今後の文献がもっと探求してくれると嬉しいな。一般的に、これらの結果が驚くべきものであることは、論文を読みやすくして、一つの要因を見つけて「これがスローダウンを説明しているんじゃないか」と結論づけるのを簡単にする。私の予想では、要因は一つじゃなくて、いくつかの要因がこの結果に寄与していると思う。少なくとも5つはありそうで、9つは排除できない（11ページの要因表を見てみて）。 重要なポイントとして、AIを使った後の開発者の自己報告がスピードアップ/スローダウンの観点で過剰に楽観的であることは、どのツールを使っているかには関係ないってことも挙げておくよ。生産性の向上を正確に判断するためには、しっかりした現場での測定が必要だってのが、私にとっての重要な教訓だね！（論文のC.2.7セクション「AIツールの平均以下の使用」にもっと詳しい情報があるから、そっちも見てみて。）

Rustの深層学習フレームワーク [...] これはAIツールに関する厄介なトレンドになってきてるね。蛇が自分の尾を食べている。

これは本当に深刻な問題で、これからもっと悪化する一方だと思う。主要なモデル提供者がほとんどすべてのデータを自分たちで保持している現状は、正直言って長期的には好きじゃない。

余談だけど、俺はAIの仕事をしてるけど、主にPythonと理論的な仕事が多い。Burnにどうやって飛び込むのがベストかな？Rustにはずっと興味があるんだ。

これがLLMの好きなところ。答えがわからないときに「それは違うよ」って言うと、「その通りだね。じゃあ直すよ」って返してくる。経験の浅い人や、もう気にしなくなった人が作るコードがどれだけ多いか考えると怖い。脆弱性が出始めたら、すごいことになるだろうね。

これがLLMがやる最もイライラすること。コードの周りに広いtry:catch構造を作って、問題の原因を追跡するのが不可能になる。開発中はコードがすぐに、しかもしっかり失敗してほしい。そうすれば、すぐに問題を解決できるから。

彼らの動機は、ただ記録にコミットを残すことだったんじゃないかな。これはAIツールに関して問題になってきてるトレンドだね。しばらく前から、AIはスパムをより効果的にしてるんだ。

PRを拒否すべきなのは、修正が不十分だからであって、AIが書いたからじゃないよ。悪いコードは、出所に関係なく悪いコードなんだから。コードがどう生成されたかにこだわるのは、生産的じゃないと思う。

最近、同僚のMRをレビューしたんだけど、テストが明らかにAIによって書かれてたんだ。どうやってプロンプトを出したのか分からないけど、「thing1」とか「thing2」とか、かなりひどい変数名がテストケースに使われてた。基本的に、結果セットに表現する必要があるデータの複数の組み合わせだったんだよね。だから、特別なものに基づいて、名前を明確にしてほしいってお願いしたんだ。そしたら、彼はそのフィードバックを受けてAIに変更を頼んだみたいで、すごく長くてユニークな名前をつけてきたんだけど、結局それがノイズになっちゃった。あの開発者にとってPRを書くのはすごく早かっただろうし、自分で書くよりX倍早いって感じたと思う。でも、これはツールにとっても良い結果じゃないよね。もし彼が俺と同じくらいレビューしてたら、得た時間の多くは消えてたと思う。

「AIが知らないコードベースで知らない言語で機能を作ってくれた」って聞くたびにいつも思うこと。素晴らしいけど、何を学んだの？小さな貢献にはいいかもしれないけど、長期的なメンテナンスの話はあまり聞かない。少数派の意見だけど、わかってる。

確かに、何かを学ぶのに役立てることができるけど、理解がより抽象的でLLMっぽくなる傾向があるよね。学ぶときは、いろいろと混ぜてやった方がいいよ。

そうそう！ナビアプリのWazeは、ユーザーを長いルートに誘導することが多いけど、実際には速く感じるんだよね。運転中は、実際の距離じゃなくて、何が起こったかの記憶で旅を速いか遅いか判断するから。Wazeは、人間のドライバーが時間や距離が長くても、曲がりくねった道を進んでいると進捗を感じて幸せだって知ってるんだ。AIツールはプログラミングを楽に感じさせるけど、実際には生産性が下がるかもしれないのは興味深いね。でも、俺たち人間は楽なショートカットを好むから。AIを使ったコーディングの記憶は、苦労しなかったから進歩したって教えてくれる。