- AIコーディングツールの進化により、開発者が新しい言語へ素早く参入できる環境が整ってきている
- 10年間Rubyだけを使ってきた開発者だったが、今年はAIコーディングエージェント（例: Cursor、Claude Code）との協業のおかげで、C、C++、Rustなどのシステム言語でも実質的な貢献が可能になった
- Claude CodeやCursorのようなツールは、言語構文、イディオム、一般理論の面で特に大きな助けとなる
- **AIはコード生成器ではなく「言語の専門家であるペアエンジニア」**として、既存の経験と結びつき、リアルタイムの質問、文脈の説明、例の分析を通じて学習効率を最大化する
- AIがプロジェクトごとの文脈や深い内部構造まですべて把握しているわけではないが、言語構文、典型的なパターン、標準ライブラリなどには即座に助言でき、そのおかげで100時間以上の事前学習なしでも実際の貢献が可能になる
- AIツールの活用によってプログラミング言語の専門性に対する従来の認識が急速に変化しており、ますます多くの開発者が複数言語で生産的に働ける環境が開かれつつある
10年Ruby開発者、多言語への転換
- 筆者は2014〜2024年までRubyおよびRailsエコシステム専任の開発者として活動
- その間、RubyエコシステムでRails、IRB、RDoc、debug gemなど中核ツールの開発と保守の経験を積み重ねてきた
- 2025年からは**Sorbet（C++）、RBSパーサー（C）、ZJIT（Rust）**など、Rubyの外側にあるシステムレイヤーのプロジェクトに貢献している
- こうした変化を可能にした背景には、**AIコーディングエージェントの導入（Cursor、Claude Code）**があった
- Shopify社内でもこれらのAIツールの積極的な活用が推奨されている
機会が完璧に整った状況
- 単にAIだけが理由だったのではなく、いくつかの重要な条件が同時に揃っていた
- Ruby DXチームのロードマップ変更によりSorbetのRBS対応が必要になった → 必然的にC/C++の経験が求められた
- ShopifyのRuby & Railsインフラチームのメンバーによるノウハウ共有と、積極的なチュータリング環境の提供
- 以前から優れたメンターや実プロジェクトの機会は存在していたが、AIが学習障壁とラーニングカーブを革新的に短縮した
システムプログラミングの複雑さ
- ZJIT（新しいJIT Rubyコンパイラ）プロジェクトの事例:
- さまざまな複合的な知識・スキルが同時に必要
- Rust（主言語）、C（Rubyコア実装言語）、JIT/コンパイラ理論、ZJIT固有の構造と設計、Ruby内部動作の原理、Rubyビルドシステム（autoconf、Makefileなど）
- 1つのPull Requestで2〜4個の領域を同時に扱う
- Claude Codeの効率性
- 構文、一般的なコンパイラ理論、Rust/C/C++などの言語文法および表現パターンでは高い精度を示す
- プロジェクト固有の文脈、Ruby内部実装、複雑なビルドシステムの支援にはやや限界がある
- それでも学習過程への参入障壁は半分以下に下がる
- AIが言語構文・理論・パターン学習を即座に支援し、プロジェクト固有の文脈は人間の役割となる
AIとのペアプログラミング
- AIを単なるコード生成器ではなく補完的なパートナーとして認識するようになった
- 実際の協業方法
- 開発者はタスク要件と文脈を伝える
- AIはパターンを見つけ、言語の専門家としての役割を果たす
- 開発者は設計理由を質問する
- AIはコードを修正したり理論を掘り下げたりして結果を返す
- 対話型学習を通じて言語そのものと実際の活用法を同時に習得する
- 例: Rubyバイトコード命令のプロファイリング課題で、AIに過去のPR検索や1行ずつの解説を依頼できる
- 「ばかな質問」も気負わずにできる（「JITコンパイラにはなぜプロファイリングが必要なのか？」など）
- 不慣れな構文に関する即時フィードバックを得られる
- 失敗事例もある
- プロジェクトの方向性を誤ると、最終的には同僚メンターによる修正が必要
- 最終的に、人間の専門家による軌道修正能力は依然として不可欠である
プログラミング言語の壁の解体
- もはや新しいCプロジェクトに貢献するために100時間の事前学習が必要な時代ではない
- C、Rustなど「参入障壁の高い言語」でもAIの助けですぐに貢献可能
- AIが**初心者のミス（構文エラー、型エラー、ツールの使い方の誤解など）**を素早く見つけてくれるため、すぐに実質的な貢献が可能
- 深い専門性は依然として重要だが、複数言語での生産性をより多くの開発者が達成可能になっている
- 文法・標準関数・パターンはAIに任せ、開発者は本当の問題解決に集中する
- 私のようなRuby専業開発者が1年以内にマルチランゲージ開発者になった変化は革新的なトレンドである
- 「1つの言語しか使わない開発者」から「多言語で生産する開発者」への転換が現実になっている
- 今後、言語ごとの専門性という概念自体が変わっていく流れの出発点になる可能性がある
結論
- AIコーディングエージェントはプログラミング言語の参入障壁を急激に下げ、
開発者が複数言語で即座に生産的に働ける新しい時代を切り開いている
5件のコメント
コードの生成はそうだとしても、コードの検収やレビューは誰が……
不慣れな言語を実際に書くことはできなくても、ざっと読むことならできる場合が多いので、以前より時間が短縮されるのは確かだと思います
まだ使ったことのない技術や、経験したことのない領域についても、以前より本当に速く前に進めるようになった気がします。
Hacker Newsの意見
AIが学習曲線を変えているのか、それとも単に経験をより楽にしているだけなのか気になる
10年間Rubyだけをやっていて、1年でマルチ言語開発者になれたのは革命的だと感じたという人の経験に対して、それはむしろ「10年間やってこなかっただけ」だと思う
最初のプログラミング言語を学ぶときと、すでに何年も経験を積んだ状態で新しい言語を学ぶときでは、まったく別の経験になる
私もまったく同じ考え
10年間ずっと1つの言語だけをやっていた開発者には共感しにくい
初期のころは選んだ言語へのアイデンティティが強かったが、本当に経験豊富な開発者たちから「言語はただの道具にすぎない」ということを学んだ
いろいろな言語に触れると視野が大きく広がり、言葉では説明しにくい気づきがある
そういう経験ができたことを本当に幸せに思う
「AIがなくても1年あれば複数の言語を学ぶのは十分可能だった」という意見は、ある程度事実だと思う
私の経験では、o4でPythonのミニプロジェクトをやっているとき、面白い特殊ケースに出会ったが、AIがなければそのせいで作業が何度も止まっていただろう
たとえば、unraidでxml vmを扱うやり方やdockersで起きる問題などで、自力で掘り下げると丸一日かかる
こうした部分も今はAIが案内してくれるので、ずっとスムーズに進められる
だから少し怖くもあるが、本当によく動く
ちなみに私の最初のプログラミング言語は昔のBASICだった
AIは主流言語をさらに人気にする
AIが最もミスしにくい言語は、たいてい大きなコミュニティと膨大なデータセットを持つPython、JS、Rubyのような言語だ
そのため、非主流言語ではアクセシビリティ向上の効果はそれほど大きくない
ほとんどのプログラマーは、細かなバグを見抜けるほど非主流言語に習熟していないからだ
機械学習の教訓と同じで、結局はトレーニングデータの多い側が有利になる
AIはパターンマッチングに強い
問題を既存のパターンに当てはめれば、良いコードサンプルをすぐ提示してくれる
しかし、問題が複雑だったり特殊だったりするほど、AIは役に立ちにくくなる
人間はより抽象的で動的な概念を柔軟に扱える
非主流言語を使う人は、たいてい人気より別の価値（例: 効率、金銭、学習など）を重視している
もし言語の人気が必要なら、専門家がイディオムに沿った良いサンプルコードをたくさん用意し、AIにさまざまな変形を生成させれば、参入障壁は急激に下げられるかもしれない
小規模なコーディングが簡単になれば、人々は言語そのものにももっと関心を持つようになる
LLMは非主流言語でより頻繁にもっともらしくないことを言う傾向がある
私はScala開発者だが、AIの有用性に関する議論の大半は使っている言語の種類次第だと思う
JSのような言語なら、もっと有用かもしれない
AIが新しい言語やフレームワークの登場時に正確なサポートを十分に提供できないと、人々が変化を嫌がるのではないかと心配だ
利点より不便さのほうが大きいと感じるかもしれない
新しいリリースが出るたびに、AIフレンドリーなMCPドキュメントや追加資料が必須になってくる
私の場合はclaudeとElmを使ってみて、とても前向きな経験をした
静的型システムのおかげで精度が高く、大いに助けられた
もちろん、ときどき妙な答えも出るが、みんなそういう経験はあるのではないかと思う
メジャー言語同士の間には、実質的に障壁がほとんどない時代だと思う
今アプリケーション開発で広く使われている10言語を見ても、大半はCやALGOL系で、似た構文、call-by-reference、自動メモリ管理という共通点を持っている
プロの開発者なら、これらの言語の間をそこまで苦労せずに切り替えられる
メモリ管理を初めて学ぶのは少し大変かもしれないが、よくあるパターンや警告、リンターをうまく使えば十分やっていける
実際に学習曲線が厳しい言語はRust、Ada SPARK、Lisp、Forth、MLなどで、これらはメジャーではない
AIを補助的なプログラミングパートナーとして活用している
AIの「広く浅い知識」を使ってまず探索し、その後で特定の領域を深く掘るときに頼んでいる
新しいプログラミング言語よりも、新しい概念や技術（例: webauthnバックエンド、passkey統合実装）を学ぶのに積極的に使っている
初心者の立場でもAIは大いに役立つ
ただし、AIが間違った例（例: 廃止された依存関係)を出してくることもあったが、結果的により深く理解できるようになって、むしろ良い経験だった
AIに完全自動でアプリ開発を任せたいとは思わない
細かなミスがよくあるので、必ずレビューが必要だ
最近初めて触れたSwiftコードベースを学ぶのに、AIが大いに役立っている
疑問を素早く解消し、学習速度を上げてくれる
ただし、複雑なプロジェクトに実際に貢献するには、今でもスキルと経験が必須だ
自分の知っている言語でも間違いは多いのに、知らない言語だとレビューするのも難しい
新しい言語を掘り下げるたび、慣れるまでレビューにかなり時間がかかる
言語の壁が下がったとは言うが、実際にはWhatsAppがデスクトップアプリの代わりにWebアプリへ移るような例もあり、壁は完全には消えていない
Microsoftが以前、.Netプラットフォームを打ち出して、J#、Fortran.Net、Cobol#など多様な言語で1つのチームが協業しようとしていたのを思い出す
この方式なら、優秀な#Intercal人材でも生産性を4倍にできると宣伝していた
AIによって、プログラミング言語は強力なHindley Milner型システムを備えた方向へ進化していくと予想している
Haskellは学びにくいが、データセットさえ十分なら、コーディングエージェントに最適なターゲットだ
高水準でありながら形式検証が可能で、言語サーバーとAIを手軽に連携できる
現実には逆で、HaskellはむしろAI支援から取り残される雰囲気だ
関数型言語が好きなら、なぜ自然言語プログラミングが魅力的なのか考えてみるべきだ
自然言語は結果を曖昧に表現でき、その部分を機械が自動的に補ってくれる
本当の革新にするには、強い論理体系+曖昧さを取り入れたプログラミング方式、たとえばMTLのような論理ベースの導入が必要だ
残念ながらこの分野の研究はほぼ止まり、ニューラルネットが主流になっている
HaskellはLLMの観点では、奥深い言語特性が多く、あまり相性が良くない
LLMは主にテキストのパターンを扱うからだ
単純な特徴と親切なコンパイルエラーを提供する言語（例: Go）は、AIがうまく扱える
個人的には型推論がよく効く言語が好きだが、AIの観点では事情が違う
LSP MCPツール+LLMを使ってみたが、少し期待外れだった
LSPはもともと人間のユーザー向けに設計されているので、AIとの相性が完璧ではない
LLMはパターンマッチングには強く、型構造が単純なら型エラーはほとんど出ない
複雑な構造では、LLMが解決できなかったり、ユーザーが理解できなかったりするかもしれない
「Haskellで大規模な形式検証の事例はあるのか」という疑問もあるが、seL4やCompCertなどは大半がCやCoq+OCamlベースだ
Agdaのような依存型言語の利用が増えるかもしれない
ただし、データセットが少なすぎると、AIの知識移転が難しくなる可能性もある
AIをペアプログラミングのパートナーとして扱うとよい
ユーザーが学ぶほど、AIの役割は、最初は基礎説明と小さなコード生成、その後は高度な議論+大きな単位のコード生成、さらにコードレビューへと変わっていく
時間がたつほど、自分でより多くのバグを見つけられるようになる
AIを単なるコード生成器ではなく、補完的な技術を持つパートナーと見れば、本当に役に立つ
知らない言語なら、AIが示す解決策について細かく質問するべきだ
「なぜこうするのか」「別のシナリオでは?」のように具体的に聞けば、本当に学習の助けになる
質問するとAIは自分の考えを検証してくれるが、何度か繰り返すと完全には信頼しにくくなる
「AIに明確に質問させる習慣」も身につけるとよい
そうすれば、理解の誤りや論理の弱い部分を前もって見つけられる
Geminiのコード生成力を試すためにbashスクリプトを頼んだところ、エラーがあった
幸いbashを知っていたので直せたが、もし知らない言語だったら、これで言語の壁がなくなるとは言いにくいと思う
これはbash特有の問題だと思う
たとえばGoで似たような自動化作業をLLMに任せたときは、一発でうまく動く
bashというよりGeminiの問題だと見るのも難しく、AIモデルに関する正確な情報なしにブランド名だけで批判するのには同意できない
実際、「Gemini 2.5 Pro (Jan 2025), 温度 0.15」などの設定にすると、優れたidiomatic bash scriptをすぐ生成する
（コード例は省略）
ただし、WSL2でWindows Notepadを使って編集したファイルの改行処理の問題にも遭遇したが、Geminiが親切に解決方法も教えてくれた
面白いことに、bashでは最後の行に改行がないと正しく処理されない問題があり、これはbash自体の制約だ
PowerShellならほぼワンライナーで同じ作業ができ、末尾に改行がなくても問題ない
Geminiに手伝ってもらうことで、PowerShellも短いコードに最適化できた
https://ruby-news.kr/articles/…
私が運営しているサービスでの要約です。翻訳したものですが似ていますね。ただ、ギークニュースのほうがより整理されていて見やすいです