この研究は参加者がライブラリを学んでいるかどうかを測定してるけど、実際に調べるべきは、ライブラリをうまく使うための効果的なコーディングエージェントパターンを学んでいるかどうかだよ。ライブラリを学ぶことが、未来に必要なことにはならない。 > 「私たちはAIコーディングツールへの自己報告された親しみを集めていますが、実際にはプロンプト技術の違いを測定していません。」多くの人が車の仕組みを説明できなくても運転するし、そういうデバイスを使ったり、説明できない思考を持つ人とやりとりしたりする。社会はそうやって機能してるんだ。完全な理解ではなく、機能的な部分を発展させる必要がある。機械コードを知らなくてもCを書くことができるし、曲を演奏できなくても間違った音を認識できることが多い。論理的誤謬を自分で有効な議論を構築できなくても見抜けるし、翻訳をするのに必要な流暢さよりもずっと少ない流暢さで翻訳ミスを見つけることができる。私たちが必要なのは、生成的な能力ではなく、識別的な能力なんだ。何年も日付や数字（価格、整数、ID、電話番号）をフォーマットするためのライブラリを維持してきたけど、それは正規表現の山だった。でも、各タイプのパースに対して何百ものテストケースを維持してた。新しいエッジケースが出てきたら、それをテストに追加して、スコアを高く保つために繰り返し改善してた。自分のライブラリを完全には理解してないけど、傷が蓄積されてできたものなんだ。もちろん、どの行も説明できるけど、なぜこの順番でこの正規表現があるのかは、もうデータ依存の説明ができない。すべての編集はテストとループで回っていて、スコアが良いときだけPRを送る。正確さは実装を理解することに基づいていなかった。正確さはテストスイートに基づいていたんだ。

同意するよ。これは非常に誤解を招く。著者が実際に言っていることはこうだ: > AIの支援は、特に初心者の労働者において、専門的な分野での生産性向上をもたらす。しかし、この支援がAIを効果的に監督するために必要なスキルの発展にどのように影響するかは不明である。AIに大きく依存して不慣れなタスクを完了しようとする初心者の労働者は、プロセスの中で自分自身のスキル習得を妨げる可能性がある。私たちは、AIの支援があった場合と無かった場合で、新しい非同期プログラミングライブラリの習得について開発者がどのように習得したかを研究するためにランダム化実験を行う。AIの使用は概念的理解、コードの読み取り、デバッグ能力を損なうが、平均して顕著な効率向上はもたらさないことが分かった。コーディングタスクを完全に委任した参加者は生産性が向上したが、ライブラリを学ぶことのコストがかかっている。私たちは、AIとの相互作用パターンを6つ特定し、そのうちの3つは認知的関与を含み、参加者がAIの支援を受けても学習成果を保つことができる。私たちの発見は、AIによる生産性向上が能力への近道ではなく、特に安全が重要な分野ではスキル形成を保つためにAIの支援を慎重にワークフローに取り入れるべきであることを示唆している。

タイトルは変えるべきだと思うけど、この投稿の重複にコメントしたように、学びってのは初心者や学生、"ジュニア"プログラマーの時に始まってそれで終わるものじゃない。仕事自体が学びで、25年やってきたけど、今は毎日以前よりも多くのことを学んでるよ。

彼らは、経験の浅い開発者がまだ知識を得ている段階では生産性の向上は見られないと言っている。でも、それが「学びを妨げる」という意味なんだよ。

学びの速度と忘れる速度が一致する安定した状態に達したよ。

「仕事は学ぶことだ…ずっと出荷する運命だと思ってたのに…」

「大企業でプログラマーの“アドバイザー”として働いてた。そこでのモットーは、プログラミングとソフトウェア開発は主に知識を得ること（つまり学ぶこと？）だってこと。そこからの教訓は、実際にはリポジトリのコード行数よりも知識の方が重要だってこと。従業員の知識を失うより、ソースコードを失った方がいいって言えるかも。もう一つのポイントは、コンサルタントを使うとコード行数は得られるけど、コンサルティング会社は知識を手に入れるってこと！…などなど。だから、プログラミングは学ぶことだと心から同意する！」

そうかもしれないけど、問題解決が大事だと思う。過去にやったことの違うバージョンを出すことで、多くの人の問題を解決できるんだよね。なんか取引みたいな感じだよ。人は自然と学んだことを使おうとするけど、時には必要以上に複雑にしちゃうこともある。履歴書のためにわざと複雑にする人を除けば、これは普通の問題だよ。