ハクソク

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

型付き言語はバイブコーディングにより適しています

2025年8月4日原文(solmaz.io)

概要

  • Claude Code 登場以降、 Python が新規プロジェクトの第一選択肢でなくなった体験
  • 型付きコンパイル言語 （TypeScript、Rust、Go）での開発が効率的になった理由
  • AIツール が安全性と速度を両立させる要因
  • Python の利点と欠点、AI時代での位置づけ
  • 今後のPython採用減少 予測とその根拠

Claude Code登場後のプログラミング習慣の変化

  • Claude Code の登場により、10年以上続いた Python中心の開発習慣 が変化
  • 新規プロジェクトで TypeScript、Rust、Go など、得意でない言語も積極的に利用
  • 型付き・コンパイル言語 の安全性保証による“vibecoding”との相性の良さ
  • Python は直感的に使いやすいが、安全性やスケーラビリティで不利
  • Claude Code + Rust の組み合わせで、大規模開発でも 速度と安全性 を両立

AIツールによる開発効率の劇的向上

  • AIツール の活用で、得意でない言語でも 安定した開発 が可能
  • 例：TextCortexのTypeScriptフロントエンド大規模リファクタリング
    • Claude Code がタスクごとに tsc を実行し、コンパイルエラーを未然に防止
    • 数千行規模の差分も 短時間で安全に適用 可能
  • Python では得られない コンパイル時保証 による安心感
  • LLM（大規模言語モデル） は抽象化の漏れはあるが、 プロトタイピングの速さ と 安全性 を両立

Pythonの今後の立ち位置と予測

  • AIツール の普及で、 Pythonの利点 （高速プロトタイピング）が他言語でも実現
  • Pythonの欠点 （安全性の低さ、速度、曖昧さ）が目立つように
  • 企業における Python採用の減少、特に 本番運用 での利用減少を予測
  • 「AIツールがなくても型付き言語の方が良い」という意見もあるが、状況次第で異なると主張

まとめ

  • Claude Code などの AIツール によって、 型付き・コンパイル言語 での開発が容易かつ安全に
  • Python の「速さ」はAIによって他言語でも実現可能に
  • 今後、 本番環境 での Python利用 は減少傾向との見立て

Hackerたちの意見

この主張には評価が必要だね。逆に、LLMはPythonのコーディングが得意だって主張することもできるよ。だって、トレーニングセットにはC++やRustよりもPythonが圧倒的に多いから。いずれにせよ、型付き言語の利点は、LLMに常に型注釈付きのPythonコードを出力させて、ruffやtyを使ってその出力を検証するルールを追加することで簡単に得られるよ。

└

私も、LLMのトレーニングセットにはRustよりもPythonのトレーニングデータが圧倒的に多いってことには同意する。でも、C++はPythonより前から存在してたと思うから、PythonのコードがC++よりも2桁も多いとは思えないな。

└

あなたはPythonの型付けの能力を過大評価してると思うよ。

└

tyはまだmypyがキャッチするものを見逃してるね。それに、Pydanticへのサポートもまだ同じレベルじゃない。速さが魅力で使ってるけど、mypyと一緒に使う感じで、まだ置き換えにはならないかな。確かにmypyは遅いけど、完了を待ってるエージェントには関係ないよね。

上の論理は正反対の結論を支持することもできる。LLMは動的型付け言語をうまく扱えるから、型エラーを解決する必要がなくて、いくつかのコンテキストトークンを節約できるんだ。実際、LLMを使ったコーディングエージェントは、TypeScriptのような徐々に型付けされる言語でanyを使って型エラーを回避しているって報告されてる。私も何度かその使い方を見たことがあるし、Rustのような強い型付けの言語でもLLMエージェントを使ってみたことがある。複雑な型エラーが発生すると、エージェントはそれを修正するのに苦労して、最終的にはtodo!()を使うことになった。こういう経験は、トレーニングデータが不十分なせいかもしれないけど、イデオロギー的な推測よりも評価の重要性を示しているよ。

└

それとも、単に悪いトレーニングデータかもね。「any」がどこでもカジュアルに使われているのを見たことがあるよ。

└

私の経験では、リンターのルールでそれを禁止して、ローカルのClaudeファイルを使って、何かをするたびにリンティングの問題を修正するよう指示すれば、回避できるよ。

実際の評価が必要だって言われてる通りだね。経験上、エージェントがエラーを修正しようとして無駄に時間を浪費する「スピンアウト」状態が最悪で、結局は意味のない（あればだけど）「解決策」にたどり着くことが多い。私の経験では、TypeScriptではこういう「スピンアウト」状況はほぼ常に型に関連していて、ひどい「any」キャストが多く含まれていることが多いんだ。

└

だから、私はLLMに対して非常に具体的なルールセットとリンティングを設けていて、anyを一切許可していないし、他の品質チェックも行ってるよ。

└

質問は2つの方法で聞けるね：(1) 現在のLLMは、ユーザーのワークフローに関するいくつかの仮定のもとで、型付き言語の「雰囲気コーディング」が得意なのか？ (2) LLMは技術として原則的に型付き言語に向いているのか？ それともRLパイプラインはその方向に進むべきなのか？

└

そうだね、エージェントは「any」に対してすごく反応が早いのに気づいたよ。Rustでの作業は楽しかった。Rustでは型システムを無視するのがそんなに簡単じゃないし、「unwrap」や適切なエラーマネジメントに関しても文化がより厳格だと思う。だから「unwrapを使うのをやめて」って言うことは、ほとんど「anyを使うのをやめて」って言うことより少ない気がする。

└

LLMには、コンパイルされた型付き言語のように、どんな型も禁止すべきだと思う。

Hacker Newsで議論の続きを見る