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

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

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

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

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

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

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

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

「システム設計のスキルはまだあるし、今のところLLMはこの分野ではそれほど優れてない。プラウザブルなアーキテクチャは提案できるけど、ゼロから始める場合はほとんど使えない。システムを設計する時は、コーダーじゃなくてアーキテクトだから、デザインをエージェントや他の開発者に渡すのと自分でやるのに違いはないと思う。重い作業はもう終わってるからね。この観点から見ると、LLMは学ぶのにかなり役立つ。ただ、コーディングの代わりに、質問したり、例をリクエストしたり、シーケンス図を描いたりして、最終的な製品を可視化するために長時間やり取りすることが多い。」

「これからの大きな問題は、リーダーシップが人に対してますます無関心になり、機能をどんどん早く出荷することにしか興味を持たなくなることだと思う。つまり、まだ自分の技術を学んでいる人たちは厳しい状況に置かれる。日常の仕事でのコンテキストスイッチが異常になってきた。『みんなが何でもできるべき』っていう文化があって（もちろん、ある程度はそうだけど）、実際にはデータサイエンティストが必要ならインフラコードにも触れることが期待されてる。根底には、みんながLLMに頼ってこの仕事を進めるだろうっていう暗黙の前提がある。」

「世界で最高の気分は、数日間問題に頭を悩ませて、次の日の朝には解決策が頭の中に浮かんでることだ。そして、誰かがすでにそれを解決していたことがわかる。だから、Google 2.0、つまりChatGPTを使った方がいいかも。」

「わかんないけど、Claude Codeは本当に遠くまで行けるけど、そこには届かない気がする。結構使ってるけど、自分でもたくさん書くし、ほとんどそのままの出力は使わない。趣味のプロジェクトには最高だけど、仕事の大きなコードベースではうまくいかない。」

今、似たようなモデルがかなり安く手に入るようになったよ。grok 4.1 fastは約10倍安くて、ちょっと性能も良い。

今朝考えていたことなんだけど。目が覚めて、コーヒーを入れて、金融ニュースを読んで、昨日書いたコードを探り始めた。最初に思ったのは、昨日書いたことを抽象化できるなってこと。先週作ったもののバリエーションだったから。次に思ったのは、今日はフラストレーションに満ちたハイパーフォーカスの日になるんじゃないかっていう恐怖感。これを作ったコーディングエージェントが、モジュール化されたクリーンな抽象を作ることができないんじゃないかって。次に、複数の一回限りの解決策を持つ方がいいのか、自分で手動で抽象を作る方がいいのかを考えた。GPT 4のパフォーマンスが悪いことで、人間のループコーディングプロセスに何かしらの正則化が導入されたっていうのには100%同意する。でも、競争の世界に生きているから、優位性を持つ技術を開発する人が成功するんだ。ハイジャンプの技術の進化についての動画があって、ウェスタンロール、ストラドルテクニック、そして最後にフォスベリー・フロップがある。コーディングエージェントを使うのもこうなるだろう。私は150GBの時系列データを扱っている。いくつかの痛点を軽減する必要がある。例えば、異なるLLMモデルを、データを完全に異なるアプローチで分析したり作業させたりしなければならない。それによって、4倍速くなるはずが、各反復が4倍速くなるだけで、2回やらなきゃいけないから、結局は2倍速くなるだけ。1月には$400分のトークンを消費した。これは環境に良くないよね。タイムゾーンの処理は常に手動で検証しなきゃいけない。データの探索はすべてトレインとテストの分割になる。最も痛いのは、AIコーディングエージェントが常にトップのテスト結果を示すこと。トップのトレイン結果のテスト結果を示さないんだ。モデルが有意な結果がないと言う代わりに、それを隠して勝ち組の外れ値だけを提示するのは誤解を招くし、OPの研究が示唆するように非常に危険だ。技術が開発される前に、多くの人が痛い目に遭うだろう。オーバーフィッティングはデータを扱うときの問題だった。時系列作業の参入障壁が低くなったからといって、ARIMAのような古いツールを手動で使うか、AIに作業させるかに関わらず、スキルを開発する人がオーバーフィッティングの問題から逃れるわけじゃない。モデルは常にハッピーで成功したように見える結果を示す。計算機が中等教育で高度な数学を教えるときに使われるのと同じように、AIも教育に使われるだろう。私たちがやっていることは、まだ開発されていない技術とスキルを習得できないことを混同している。私は毎日これらの問題を解決するために脳を悩ませている。何百万もの他のソフトウェアエンジニアも同じようにやっているから、パターンが現れて、後に学校で教えられるスキルになるだろう。

ほとんどのテストをAIで自動化してるんだけど、具体的にはどうやってるの？エージェントに「これのテストを書いて」って言うだけ？それとも、テスト対象の仕様を何かしら渡してるの？それに、これらのテストって失敗することあるの？最初の選択肢だと、バグが確定しちゃう気がするんだけど、逆にした方が良くない？テストを書いて、AIにコードを生成させるって感じで。テストは基本的に仕様を表してるから、AIが全てのテストを通過するものを生成しても、実際には求めてるものじゃなかったら、テストの穴ができちゃうよね。

本当に驚きはないよね。AIを使って新しい視点を探ったり、初期のスケッチを提案することはできるけど、小さな変更以上のことをするには、必ず書き直さなきゃいけない。レビューだけじゃなくて、実際に書き直す必要がある。AIは機能を追加するのは得意だけど、アプリのコードを感覚で作って賢くなることはできない。こういうことを言う人たちが、実際にTwitterやredditをカジュアルに見たことがあるのか、SOTAモデルを使って「大きな」アプリを作ったことがあるのか、時々疑問に思う。

だからこそ、AIを使い始めてから私のコードの質が向上したんだ。以前は一つの概念を探るのにかかってた時間で、全体のアプローチを反復できるようになった。でもAIは人間の意図を増幅するものだから、私はメンテナブルでスケーラブルなコードベースが欲しいんだ。これはYOLO的なコーディングとは違うよね。バイブエンジニアリングって感じかな。

Anthropicがこの研究を行い、発表してくれたことに感謝したい。AIを使う上での私の一つのアドバンテージは、20年以上にわたって他の人のコードの「最後の手段のデバッガー」だったことだ。アプリケーションコードを壊していたコンパイラのコード生成バグを見つけて修正してきた。チームで働くのに慣れていて、仲間に多くのコード作成を委任することもできる。そして正直言って、今は月ごとのJavaScript ORMの専門家になりたくない。どうせ2年後には流行遅れになるし、古いコードで突然壊れたら、修正するために必要なことを学べばいい。とりあえず、コードレビューするための知識と、潜在的なセキュリティ問題をしっかり理解するための知識があれば十分。それだけでいい。同様に、最近ClaudeにRustプロジェクトをいくつかanyhowからmietteに変換させたけど、mietteについてのクイズには絶対合格できない。これでいいんだ。新しいことに深い専門知識を持つことはできるけど、戦略的にやってる。大きなレバレッジを提供するのか？来年もグリーンフィールドプロジェクトで使われるのか？だったら、学ぶつもり。だから今の技術の状態では、Claudeは基本的に私が戦略的に学ぶのを助けてくれる。基本をしっかり理解していて、重要な新しいことを学んでいる。

でもソフトウェアは進化し続けてる - 手動でアセンブリをコーディングする時間がなかったからって、キャリアに影響はなかったよ。そうだね。君は（おそらく）高級言語で書いたコードのデバッグをしてたわけだし。リンクされた記事では、問題解決（デバッグ）の低下が最も大きいと明確に示されてる。今日AIを使い始めたジュニアたちは、自分でその問題解決をすることは絶対にないだろうね。

アセンブリを読めるようになったおかげでデバッグが楽になったよ。書く必要はないけど、書けるようにはなっておくべきだね。同じことがマニュアルトランスミッションやポケット計算機にも当てはまるよ。

プロダクトマネジメントのスキルを測定しようとしたらよかったのに。私の仮説では、AIを使うことでコーディングスキルはあまり向上しないけど、仕様書や要件を書くスキルは改善されると思う。でもデータがないから、ただの推測だね。直感的には、AIがエントリーレベルのプログラマーに要件を明確に表現することに焦点を当てさせている気がする。それが悪いことではないかもしれないね。

そうそう！たまにJetBrainsのAIアシスタントを使うんだけど、突然真っ白なウィンドウしか出てこないことがあるんだ。何も得られないよ。でも、クレジットが消費されてるのは見える！もし完全に依存してたら、困ったことになってたね。幸い、そうじゃないけど。

その素晴らしさには納得できないな。研究結果は、AIがタスクの完了時間を改善しないけど、新しいライブラリを使うときにプログラマーの理解力を低下させることを示唆してるから。

ウェブ開発者としてかなり長いキャリアを持ってるよ。始めた頃は、インターネットがダウンしても何か作業できるように、開発環境の設定にこだわってた。でも、時間が経つにつれて、より大きなプロジェクトに取り組むようになったり、業界が変わったりして、それが現実的でなくなったんだ。じゃあ、インターネットがダウンしたらどうしてるかって？ここ10年くらいずっとやってることだけど、仕事をやめるんだ。それで、世界中のいろんな場所で働いてきたけど、発展途上国や熱帯の島、小さな山小屋でも。接続の問題で1日分の仕事を失ったことはあるけど、モンスーンの中で熱帯雨林にいても4G接続があったこともある。もしAnthropicがダウンしたら、Geminiに切り替えればいいし。クレジットが切れたら（クレジット使ってる人いるの？私は月額サブスクリプションだけど）、基本的な作業をするための無料クレジットを見つけることができる。ますます、ローカルモデルを使えば、いくつかのことには十分な性能が得られるようになるし、将来的にはさらに良くなるだろう。だから、これらは有効な議論ではないと思う。今の時代、みんな仕事のためにオンラインサービスに頼ってるし、銀行業務やメッセージング、オフィスワークなどもそうだよ。もし何かの災害でそれが壊れたら、私たちはみんな困るし、LLMに依存しているコーダーだけじゃないよ。

いつかインフラみたいに扱われるようになるよ。クラウドフェアが壊れたり、AWSがダウンしたときに、典型的なソフトウェアエンジニアがやってることだね。

AWSがダウンしたときと同じことをするよ。昔のデスクトップ時代に停電があったときと同じことさ。そういえば、在宅勤務が一般的になる前の日、トイレが壊れたせいで午後はみんな休みになったこともあったな。100人がトイレなしでオフィスにいるのは無理だからね。いろいろあるよ。もしそれが本当に許容できないなら、効率の悪い解決策に多額の投資をする覚悟で、解決策に投資することになるね。

スタックオーバーフローの時代はそんなに昔じゃないし、オンラインソースを参考にしないとライブラリコールも書けなかったよ。開発者がインターネットに依存してることについて心配するのは、少なくとも10年遅れてる。LLMの時代が来る前には、もう完全にそうだったからね。

これは素晴らしいけど、これらのツールが使えなくなったらどうなるの？インターネット接続が切れたり、エージェントが誤設定されたり、単にクレジットが切れたりしたら。やるべき非コーディングのタスクが山ほどあるから、それに取り組むか、ただ働かないかだね。GitHub Actionsがダウンしたらどうする？

Qwen Coderをローカルで動かせるパワフルなノートPCに投資したけど、かなりいい感じだよ。ローカルモデルが未来だと思う。クレジットやインターネット接続をあまり心配しなくて済むからね。

水や電気について同じ質問をどう答える？ピザ屋は素晴らしいけど、冷凍庫への電力供給が途絶えたらどうする？そのとき、どうやってレストランを運営するの？

なんでこんなにお金が流れ込んでるのか、理由がわかる気がするよ。デジタルの麻薬みたいなもので、ビジネスをたくさん中毒にさせられれば、サブスクリプションの防壁ができるからね。オラクル化って感じ。

AWSのことを心配してるのと同じくらいだね。