あなたがやるべきタスクを見つけたと思うよ。コードを書くこと自体があなたにとって助けになるなら、AIにその助けを奪われないようにしよう。「生産性」の漠然とした必要性のためにね。私たちは皆、自分の技術を向上させるために時間をかける必要があるし、AIにはその部分を代わりにやってもらえないから。だけど、例えば、行き詰まったり初稿が終わった後に、より良いパターンや言語、ライブラリの機能を示してくれることで助けてくれることはあると思う。それは cheating じゃなくて、友達に頼むことだよ。

これは本当に面白いポイントだと思う。ちょっと年配の視点からいくつか考えがある。今は物事が急速に進んでいるけど、過去10年間の遅さのせいで、さらに速く感じるのかもしれない。俺は90年代中頃から後半にかけてウェブ開発に入ったけど、その頃も似たような感じだった。接続されている人たちはウェブが大きくなることをなんとなく知っていたけど、同時に物事が急速に変わることもわかっていた。学んだことはすぐに役に立たなくなって、次の新しいことを学ぶための肥料になってしまう。ここ10〜15年は本当にずっと安定しているように感じる（人によって感じ方は違うかも）。だから、俺が言いたいのは、そう、実際にこれは普通に戻りつつあるってこと。少なくとも、俺が楽観的な気分のときはそう見える。何かを選んでやってみるといいよ。それが脳の肥料になるかもしれないけど、良い深い肥料があれば、あなたはシニアデベロッパーになれると思う。あまりメタファーが伸びすぎてないといいけど！

数年前、「ライブラリを使う代わりに自分でxを書く」というブログ記事のトレンドがあった。自分のバージョンを作ることで、ソフトウェアについて多くを学べる。クライアントサイドのルーティングがどう機能するかを学びたい？クライアントサイドのルーターを書いてみなよ。LLMのおかげで、何でも「ライブラリ」コードになったと思う。だから、結局はプロジェクトから何を得たいかにかかっている。C#を上達させたいなら、自分でポートするべきだと思う。ポートされたコードを手に入れて他の側面に集中したいなら、クロードにやらせればいい。もし学ぶことが目的なら、何をしても何らかの苦労が必要だと思う。何かが簡単に感じるときは、あまり学んでいないことが多いと気づいた。

35年以上の開発者キャリアの終わりに近づいているけど、LLMに関することではいつもこうしている: 自分が解決できることを一般的に解決するように頼むんだ。ただ、やる気が出ないだけ。例えば、昨日はOpen API 3.0のスキーマに取り組んでいた。サンプル入力に合わせてスキーマを「修正」できることはわかっているけど、つまらないからやる気が出なかった。以前やったことがあるし、何も学べないから。だから、クロードにやらせたら、うまくいった。それから「例」セクションがスキーマと合わなくなったので、クロードが適切な例を書いてくれた。でも、ここでのポイントは、これをやっても何も学べなかったってこと。だけど、何かを学べるときもある。だから、LLMが新しいことを教えてくれたときは、その知識を「知識バンク」に入れている。AnkiのSRSフラッシュカードアプリを使っているけど、他にも「TILブログ」に追加する方法（これもやってる）や、新しいことを解決策を見ずに何度か書き出してコンパイル/実行する方法がある。その後、その知識を別の方法で使う方法を考えたり、要件を変えてそれを書くことを試みたりする。基本的に、脳がこの新しいことと少なくとも2つの方法で関わるようにして、他のことと統合できるようにする。これが重要なんだ。新しい（話し言葉の）言語を学ぶときも、こういうことが多い。新しい単語を学んだら？3つの異なる文に入れてみる。新しいフレーズを学んだら？それに基づいて少なくとも2〜3の新しいフレーズを作る。これで、俺の脳が運動し続けられることを願っている。

プロとして16年コーディングしてきたけど、Claude Codeのおかげで、頭を打ちつけて学ばなきゃいけなかったことがかなり上達したよ。新しいことを学ぶ時は、効率のために、他の学習体験と同じように「簡単に来て、簡単に去る」って感じだね。私の意見としては、完全に学ぶことが目標なら、ゆっくりと忍耐強い方法を優先すべきだと思う（どんなに「物事」が早く進んでいても）。早く学ぶことが目標なら、Claude Codeや他のAIツールが役立つよ。「エージェント」モードより「アスク」モードを使う方が効果的だと感じてる。新しい概念を理解するために、アナロジーやシナリオ、記憶術を作るのが好きだよ。もしただ物事を終わらせたいだけなら、仕様書を書くのが上手くなって、エージェントに任せるのがいいと思う。その際、もちろんたくさんのテストを追加することを忘れずにね。何かを作っている限り、どのアプローチにも少なからず価値があると思うよ。

私の経験では、生成されたコードをレビューしないと、C#に十分精通することができず、コードベースがすぐにゴミになっちゃう。LLMでのコーディングではエラーが重なっていくし、修正しない限り、実際に価値のあるコードベースにはならないよ。友達はその問題がないみたいで、LLMに十分なテストを書かせて、早い段階で脆弱性をキャッチしてるって言ってたけど、私はそのアプローチを試したことがない。残念ながら、私のコードはあまりアルゴリズミックじゃないから、テストが難しいんだよね。

AIの前はコピー＆ペーストがあったよね。Stackoverflowからコードをコピーして理解せずに使ってた人は何も学ばなかったし、それを何度も目の当たりにしてきた。アドバイスや概念を求めるのは全然問題ないと思う。でも、すべてを自動で書かせるのは、確実に学べなくなるよ。とはいえ、開発者として自分の時間を守る必要がある。学ぶべきことは山ほどあるし、ジュニアとしてゲームを作るのが目標なら、GDscriptのコードを移植するのはあまり時間の使い方として素晴らしくはないと思う。もちろん、そこから学ぶことは確実にあるけどね。

コードを生成させて、その後別のインスタンスにそのコードを批評させて、どう改善できるか、なぜそうなるのかを言わせるんだ。そしたら、そのインスタンスに分からないことや理解できないことについて質問してみて。リンクも聞いて、リンクを読んでメモを取る。内面化していく。ある日、ClaudeとRubyのコアメソッドについて議論してたんだけど、全然合意できなかったから、実際のドキュメントを確認しに行ったら、そいつが正しかった。2009年からRubyを使ってるのにね。

こんな感じの時は、Claude Codeにプロジェクトをレビューさせて、設計とアーキテクチャの文書を作成させるかな。次に、C#で再作成するための計画を作らせる。そして、計画文書で定義した小さなステップに従って、C#で新しいプロジェクトを生成させる。最後に、アプリを作る際の経験をレビューさせて、そのインサイトで元の計画文書を更新させる。最初のC#プロジェクトは捨てて、もう一度挑戦する。計画にはテストから始めることを含めるのを忘れずに。