世界を動かす技術を、日本語で。

AIに関する私たちの立場の構築

概要

  • RCは、6または12週間のプログラマー向けリトリートとリクルーティングエージェンシーの融合型プログラム
  • AI(特にLLM)の台頭により、プログラミング学習や仕事の現場で多様な課題が発生
  • RCコミュニティ内でもAIツールの有用性や影響について意見が分かれる状況
  • LLMの活用には学習促進と依存リスクの両面が存在
  • 今後もAIの進化とともに、RCとして柔軟な姿勢と議論の継続が必要

RCとAI:現状と課題

  • RC(Recurse Center) は、6または12週間のプログラマー向けリトリートと、 リクルーティングエージェンシー の機能を持つ特別な学習環境
  • 教師やカリキュラムが存在しない、自発的な学びとプロジェクト推進を重視
  • 収益源は主に スタートアップ企業向けの人材紹介
  • AI、特に 大規模言語モデル(LLM) の普及により、プログラミング学習や採用の現場で新たな疑問や課題が発生
  • AIツールの存在意義や影響、必要となるスキルの変化、ソフトウェアエンジニア職への影響など、現実的な課題意識

RCのAIへの対応方針

  • 個人・専門的観点 からLLMの影響にフォーカス
  • エネルギー消費・誤情報・業界の変化・倫理問題 など社会的な論点は扱わず、RCの専門性と事業領域に集中
  • RC参加者(Recursers)は LLMの活用方法を自分で決める必要性
  • 3,000名近い卒業生ネットワークを活用し、 多様な視点を持つAIアドバイザリーグループ を結成
    • 好奇心・自主性・厳密さ・親切さ・実践重視・成長志向 を重視した人選
    • 年齢・人種・性別・役割・業界・経験年数・AIへの見解など多様性を確保

コミュニティでのAI活用に関する意見

  • LLMの有用性や現状認識 について、非常に能力の高いプログラマー間でも意見が大きく分かれる
    • LLMをあまり役立たずと感じる人、劇的にワークフローが変わったと感じる人、誤答が多いと感じる人など様々
  • 意見の違いの要因
    • LLM利用歴の長さ・深さ・最近さ
    • プログラミング分野や言語(Python, TypeScript, Go等は有用性を感じやすい)
    • 小規模プロジェクトか大規模コードベースか
  • 学習面でのLLM利用 については、機会と落とし穴の両面を認識する声が多い
    • 「出荷モード」ではLLM活用、「学習モード」ではLLMを使わず自力で学ぶという使い分け
    • LLMは e-bike(電動自転車) のような存在という比喩
      • 速く移動するには有利だが、筋力向上にはならない
    • LLMは 学習促進にも依存リスクにもなり得る という二面性

LLMが学習・コミュニケーションに与える影響

  • 新しい分野を学ぶ際のチューターやラバーダック的役割 としてLLMを活用する例
    • 「愚かな質問」を気兼ねなくできる点を評価
    • コードサンプルの説明や選択理由の解説を求めるなど、 個別最適化された学習体験
  • 初学者のプログラミング学習にLLMを使うべきか については、明確な結論はなく、賛否両論
    • 過度な依存を懸念する声と、Google登場時の利便性向上との類似性を指摘する声
  • LLMによるコラボレーションの変化
    • ペアプログラミング時に、知らない言語のサポートとして有用
    • 一方で、 他のRecursersと直接質問・議論する機会が減ることへの懸念
      • コミュニティ内での相互利益の減少や「技術的な空白」へのエネルギー消費

今後の展望

  • RC卒業生の多くがAIについて意見を変化させており、今後も変化し続けると予想
  • AIに関する議論は今後も続き、 RCとしても柔軟かつ思慮深い姿勢 が求められる

Hackerたちの意見

(著者です。)このプロジェクトは本当に面白かったです。LLMに対する人々の経験や視点が幅広く、しかもその人たちが共通点を持っている(この場合、経験豊富なプログラマー、全員Recurse Centerの卒業生、何らかの形でプロのプログラマー、ほぼ全員がアメリカにいる、など)にも関わらず、意見がこんなに違う分野は他に思いつかないです。

ニック、ありがとう。Recurseの卒業生(s14バッチ2)として、この記事を読んでとても楽しかったです。Recurseでの時間が大好きで、たくさんのことを学びました。投稿の中で特に響いた部分はこれです。「本当の成長は、自分ができることと、ほぼできることの境界で起こる。LLMをうまく使えば、自分の限界をより早く見つけたり、さらには広げたりできるが、理解できることと生み出せることの間にギャップを生むリスクもある。RCは厳密さの場だ。AIを使って学ぶときは、より厳密であるよう努めるべきで、少なくとも何に対して厳密であるべきかは使う際に違うかもしれない。」

RCは厳密さの場だ。AIを使って学ぶときは、より厳密であるよう努めるべきで、少なくとも何に対して厳密であるべきかは使う際に違うかもしれない。これは多くのツールにとって重要なポイントを示していて、多くの人が話さないことだ。つまり、AIのような強力なツールを使うと、健全で思慮深い態度を持つ少数の人がいる一方で、その力が魅力的すぎて不適切に使う多数の人がいる。だから、「より厳密であるよう努める」と言っても、結局はその技術を推進する少数派になってしまう。大多数は、学ぶために不正をしない環境が必要で、基本的な能力を持つことが社会にとってはるかに重要だと思う。個人主義的な人は、これは自由のための避けられない代償だと言うけど、実際には誤解だと思う。たとえば、大学は試験室を監視する必要がある。そうしないと、不正が横行するから。たとえ不正をしない学生がいるとしても、彼らは学びを最大化したいから。AIのような強力なツールを使うときは、個人主義的な傾向を超えて考える必要がある。規律ある人は、こうしたツールの使用を正当化するために自分たちのバランスの取れた哲学を持ち出すけど、彼らが忘れているのは、そうした哲学を推進することでAIの使用に正当性を与えてしまうことだ。一般の人々はそれを扱う能力がない。脆弱な世界では、自分自身を超えた責任を持たなければならず、少数派が正しく使えるからといって危険なツールを推進してはいけない。だから、私はAIに100%反対です。妥協はありません。

ちょっと待って、あなたは「一部の人がツールをうまく扱えないから、みんなを制限しよう」と言ってるの?「規律ある少数派はAIをうまく使えるけど、怠け者の多数派は使えないから、誰も使えないようにしよう」って、どこかで読んだ気がする。短編小説かな?計算機を禁止するべき?一部の学生が依存するから?インターネットを禁止するべき?猫の動画を見るために使うから?「無能を守るためにみんなを引き止める」ことを社会的責任として装ってるけど、実際にはハリソン・バーガロンを読んで「これやろう!」って言う人に出会うとは思わなかった。でも、インターネットは本当に広大で恐ろしい場所だね。

あなたの考えには賛成だよ。でも、結論が「赤ちゃんをお風呂と一緒に捨てる」みたいになってない?この考え方は、計算機やコンピュータ、インターネットみたいな新しいツールにも当てはまるよね。LLMを導入する責任ある方法を見つけるべきじゃないかな?それが大多数を力づけることになるんだから。

ちょっと待って、少数の美しい人たちが90%の大多数よりも楽な生活をしてるってことを知ったらどう思う?何を勧めるんだろうね?

記事の中のe-bikeの例えは良いね。要約すると、低い努力で距離をカバーしたいなら使えばいいけど、フィットネスが目的ならe-bikeは向いてないってこと。

それはいい例だね。今後の教育におけるAIについての議論のために覚えておくつもり。地元の大学がAIの使用に関するポリシーをどう構築するかに関わるかもしれないから。私の考えは、AIがやっていることを教えるコース(新入生向けのライティングコースやプログラミング入門コースなど)では、AIの使用を禁止すべきだということ。そして、明確に「不正」ではない後のコースでは、できるだけ少なく使うべきだと思ってる。ライティングやコーディングの例で言えば、4年制の学位の最も有用な側面の一つは、これらの基本的なスキルを常に鍛えることで得られるものだから。

私の意見では、その例えはあまりうまくいかない。e-bikeは基本的に、普通の自転車が行けるところならどこでも低い努力で行ける。でも、AIと非AIの現在の状態ではそうはいかない。AIは、低い努力で達成できる目標に制限があり、あまり努力をかけたくないならAIを使うことでその目標に導かれる。AIには、どれだけ追加の努力をかけるかによって質のグラデーションがあって、A地点からB地点に行くe-bikeの例えにはないものだ。

でも、その間にあるのがeアシスト自転車なんだよね。結構距離をカバーできるけど、やっぱりちょっとは自分の力も必要。フィットネスにも少し役立つし。今のところ、AIアシストコーディングはそんな感じで分類できるかな。

「でも、もしあなたの目標がフィットネスなら、eバイクは選択肢としては良くないよ。eバイクがロードバイクの代わりならそうだけど、ほとんどの場合はそうじゃないと思う。私が話した人たちは、運転の代わりに使っていて、それがフィットネスに明らかに良い影響を与えてる。」

フィットネスの例えで言うと、ウェイトリフティングが新しいことだった頃、古い世代はそれがスポーツに遅くなるって思ってたみたいなもんだね。限られた観察と変化に対する偏見に基づいた、ばかげた感情的な考え方で、時代遅れになるだろうね。

いい例えだね。eバイクがないと行けない場所もあるし、充電や重さのことを考えないといけないから、準備の仕方も変わるよね。

悪い例えだな。eバイクを手に入れてから、山バイクでの走行距離が約2倍になったよ(Stravaによると)。それでも、すごい運動になる。サンプルサイズは一つだけの注意点だけど…過去に使ったより良いバイクの例えは、もし私がスリックロックを乗りに行きたいけど、今まで乗ったことがなかったら、eバイクが私をエンドオーバーさせることはないってことだね。

(全てを開示しますが:私はRCをとても尊敬していて、自分も参加しようか考えたことがあります。これが私の意見に影響します。)この記事は本当に楽しめました。RCの人たちのたくさんのエピソードが素晴らしかったです。特にこのボイスコーディングの動画を共有してくれてありがとう[1]。私がLLMについて考えるときに特に印象に残ったのは、ある非常に熱心なLLMユーザーが「出荷モード」と「学習モード」の2つのモードを持っていると説明したことです。前者はモデルに大きく依存し、後者は少なくともコード生成に関してはLLMを使わないというものです。私がClaude Codeを使うとき、時々プランモードにしたり、コードを書かないように指示して、アイデアが浮かぶまで一緒に考えることがあります。それから、自分でコードを書くんです。Claudeにプランを書かせてコードを書かせるより速くはないけど、もっと学びが得られます。[1]: https://www.youtube.com/watch?v=WcpfyZ1yQRA

Recurse Centerで時間を過ごしたいんだけど、機会コストがめっちゃ高い気がする。

今は機会コストが過去最高に高いかもね(関係ないけど、ビジネススクール考えてる人にも同じことが言える)。なんで興味持ったの?

問題は、Recurse Centerで時間を過ごすためには、まずRecurse Centerで時間を過ごさなきゃいけないことだね。

どの意味で?

ちょっと面白いけど、今の気持ちは他の人とは違うかも。今週はAIを使ったコーディングをたくさんやったんだけど、速さはあまり変わらなかったけど、質が上がった気がする。何かをどうやってやるかの議論をして、コードサンプルをもらって、それを少し変えて「自分のもの」にして、合ってるか確認してフィードバックをもらったりした。時々、知らなかった言語やライブラリの機能を使ってくれたから、すごく勉強になった。いろいろ考えながら深く掘り下げて、具体的な質問をたくさんして、だいたい良い答えをもらえたし、ドキュメントもたくさん確認した。具体的なドキュメントへのリンクや、IDE内のコードへのリンクをくれるともっと助かるな。使い方がわからないライブラリがあったら、IDEの新しいコピーにソースコードを読み込んで、そのIDEで質問するようにしてる。コードを掘り下げて理解するのに時間がかかるから、信頼できないオラクルがいると本当にスピードアップする。だから、早く物事を終わらせる方法とは思ってなくて、むしろ自分とは全然違う強みと弱みを持った誰かとペアを組むような感じで、ペアプログラミングみたいに質が上がる。今週は、自分がすごく満足できる実装を得られて、自分一人でやるよりも多くのことを学べたよ。

具体的なドキュメントへのリンクをくれると助かるな。 超簡単なテストをしてみたんだけど、「python functoolsの中で、3つのマイナーだけど便利な機能は何?」って聞いたら、それぞれのドキュメントへのリンクもくれた。GPT 4oは、いいリンクをそれぞれの例に対してくれたよ。(選ばれたのはfunctools.singledispatch、functools.total_ordering、functools.cached_property)ローカルコードのリンクについては不明。

これいいね。「速く行こう」モードに入りやすいから、こういう可能性を見逃しがちだよね。

今週はAIを使ったコーディングをたくさんやったんだけど 新しいの?最初はすごく良いって感じで、最後は「AIを諦める」みたいなブログ投稿が増える、っていうのが結構あるあるだよね。俺もそれを経験した。今でもチャットボットをスタックオーバーフローの代わりに使ってるけど、実際にAIにコードを書かせるのはやめた。質だけじゃなくて、自分の思考や理解に与える影響が、自分でやるのと比べて結果を改善しないから。

何ができるかも知らずにコードのスニペットをコピー&ペーストする人もいるし、ある意味で技術的負債を広めているんだよね。LLMは、無知な人たちが広める技術的負債を下げてくれる。君も無知な側にいたから、LLMが君のコードを改善して、広めるはずだった技術的負債を減らしてくれたんだ。

「何かをどうやってやるかについての議論をする」って、普通のデバッグの思考プロセスと比べたことある?問題について考える別の方法を与えられるかもしれないけど、別の人間の方がいい場合もあると思う。特に若いメンバーに、メールやチャットじゃなくて電話を取るようにするのが大変なんだ。音声チャットなら数分、いや数秒で問題が解決するのに、子供っぽいメールのピンポンゲームをするよりもね。自分もメールとかやっちゃうし、さっき言ったこととは逆だけど、コミュニケーションの効果的な使い方はスキルだと思う。でも、どの方法を使うべきかを理解する必要があるよね。

アシスタントとして見るのが一番だと思う。助けてくれる存在で、オーバーパワーなオートコンプリートみたいな感じだけど、考えてくれるわけじゃない。

とても考えさせられる、よく書かれた記事だね。AIについての一番の心配は、将来のプロフェッショナルの学習プロセスに与える影響なんだ。これを読むと、未来への窓を覗いている気分になる。特に、異常にやる気のある学習者(全体の中のほんの一部だけど)への影響を示唆している感じがする。バランスの取れた、探求的なトーンが良かった。

考え深い、非常に能力の高いプログラマーたちが、今日のモデルが何をできるか、そしてそれが現在役に立つのかどうかについて意見が分かれている。誰かがこの問題に対してジョン・ヘンリーのように、同じ製品を同時に作るために並行チームを作っているの?

これは微妙なラインなんだけど、「スキルの萎縮」って部分が一番滑り込みやすいと感じる。個人的にこのツールが好きなのは、特定の問題に対していろんなアプローチを試す余裕を与えてくれるから。そうすれば、有効なものを「公式な実装」に変換するのがすごく簡単になるんだ。自分は仮説を検証するために「やる」ことが好きなタイプで、効率的に何かを書く方法についてのタスクがあったら、結果を組み合わせるための後処理が必要になることもある。クラウドコードが登場する前は、実験や仮説の検証、未知の未知を明らかにするために、ちょっと雑なプロトタイプ(MVCの「スライス」を一つのJavaファイルにまとめたような感じ)を書いていたんだ。これが自分のプログラミングのアプローチで、これからも変わらないと思う。手を汚さずに何かについての仕様を書くのは、いつも不完全で現実と矛盾していると思ってるから、書いて、プロトタイプを作って、構築する。検証済みの実験があっても、製品化するためにはまだたくさんのクリーンアップや後処理が必要なんだ。今はプロンプトになってるけど、学びのプロセスはまだまだ仮説を検証することなんだよね。でも「正式なコードへの翻訳」部分は基本的に解決されている。もちろん、複雑なクエリや、抽象が間違っていると感じるけど良いものが見えない時に、すごく役立つアンブロッキングメカニズムでもある。

特に熱心なLLMユーザーが、2つのモードを持っていると説明していた。「出荷モード」と「学習モード」で、前者はモデルに大きく依存し、後者は少なくともコード生成に関してはLLMを使わない。文の前半には同意したけど、後半には完全に驚かされた。私にとって「学習モード」はLLMが必要な時なんだ。新しい領域にいて、何をググるべきかもわからないし、どんなライブラリがあるのか、どんなキーワードや概念が関連しているのかもわからない。そこでLLMが輝くんだ。基本的な汎用コードを見て、すぐに新しいことの要点をつかむことができる。そして「出荷モード」では、品質が最優先で、微妙なバグは本当に避けるべきなんだ。特にAIが書いたコードでよく遭遇するようなバグね。