LLMベースのプログラミングは、開発者の能力を増幅する`メカスーツ`に近い

• LLMツールはプログラマーを置き換える存在ではなく、開発者の能力を増幅する役割を果たす
• Claude Codeの使用経験を通じて、コーディング速度は飛躍的に向上したが、依然として人間のアーキテクトとしての判断と継続的な監視が不可欠である
• LLMの導入により、実際のコーディングよりも問題定義と設計がより重要な課題として浮上した
• AIはミスも増幅するため、経験の浅い開発者はAIの誤りに気づけない危険がある
• 将来のプログラミングでは、AIとの協業能力、判断力、削除を決断する力が中核的な能力になる

---

LLMプログラミングは人間の代替ではなく、強化の手段である

• LLMベースのプログラミングツールは、開発者の能力を増幅するメカスーツのようなものだ
• 筆者は最近Claude Codeを使って、バックエンドのエージェントプラットフォームとフロントエンドのSaaSアプリを開発した
• 合計3万行を超えるコードを書き、LLMの実質的な影響を体験した
• Claude Codeは利用者を置き換えるのではなく、Ripleyのパワーローダーのように開発者の能力を増幅するツールである
• アーキテクチャの決定、品質管理、方向性の設定などは依然として人間が主導する
• AIは速度と反復作業では有利だが、方向を誤ると致命的な結果につながる

Vigilance: AIコーディングには絶え間ない注意が必要

• Claude Codeは時折奇妙な判断を下し、テストを通すために根本的な問題を無視したり、ハードコーディングしたりする
• フレームワークを無理に変更したり、不要な依存関係を追加したりすることもある
• パイロットのように、重要な局面では人間の介入が必ず必要になる
• 目を離した隙にAIが誤った方向へ進み、バックエンドコードを3回も全面的に書き直す必要があった
• LLMはコーディングの負担を減らすが、監督とアーキテクチャ維持の負担は増す

コーディング時間の経済性の変化

• プログラミングの時間は伝統的に**なぜ（目標）、何を（設計）、どうやって（コーディング）**の3領域に分けられる
• Claude Code導入後、「どうやって」にかかる時間はほぼ0に近くなった
• しかし、「なぜ」と「何を」について考えることはむしろさらに重要になった
• コードを簡単に生成できるからこそ、今では既存コードを思い切って捨て、より良いアプローチを選ぶ勇気が必要だ
• この決断力はまだ多くの開発者にとって馴染みが薄く、実装時間よりも設計判断力が重要な時代になった

経験が生む差

• AIを効果的に活用するには、30年の経験に裏打ちされた洞察力と判断力が必要である
• コードが動作していても、スケーリングや保守に不向きなアンチパターンを見抜ける能力が重要だ
• 経験の浅い開発者は、AIが生成したコードの問題点を見落としやすく、目先の効果だけに満足してしまう危険がある
• AIが増幅するのは能力だけでなくミスも含まれるため、判断力がなければ危険性はさらに高まる

ケンタウロス効果: 人間とAIの協業

• チェスに由来する「ケンタウロスチェス」のように、AIと人間の組み合わせはAI単独よりも優れた成果を生む
• Claude Codeとの協業も同様で、人間が戦略的な方向性を与え、AIが戦術的な作業を処理する
• 思考の流れのまま仕様を書き出し → Claudeと一緒に洗練するやり方が最も効果的だった
• Claudeは文脈に即した判断ができないため、常に人間の監視と判断が必要である

バランスを取る: 委任と統制の調整

• AIを放置すると、問題を過度に複雑に解こうとする試みが頻繁に起こる
• 例: 重複コードの作成、誤った技術選定など、AIの誤作動が実際に問題を引き起こす
• フロントエンドでも、JavaScriptの変則的な実装をElixirやLiveViewの方式へ修正するよう誘導しなければならない状況が繰り返された
• 単純で反復的な作業は委任し、複雑な判断が必要な部分は直接介入する協業のリズムを築く必要がある
• AIのおかげで高速な開発は可能だったが、人間の介入なしでは適切に機能しなかっただろう

未来は増強である

• LLMがプログラマーを完全に置き換えることはないだろうが、作業の進め方と必要な能力を大きく変える
• 単純なコーディング能力よりも、構造的思考、パターン認識、技術的判断力がより重要になる
• AIと協業できる能力そのものが新たな技術力として浮上している
• 未来に成功する開発者はAIを恐れず、その限界と可能性の両方を理解し、扱える人になるだろう
• AIは人間を排除しようとするものではなく、人間の可能性を拡張するためのツールである

[bus710]

僕はアムロでもないし、ガンダムを支給されたわけでもありませんが……？

[jsh5782]

モビルスーツの性能差が戦力の決定的な差ではないということを..

[GN⁺]

Hacker Newsの意見

コーディングより重要なのは問題理解と設計

• 伝統的に、コーディングは3つの時間バケットに分けられる
  • なぜこの作業をするのか？ ビジネス上の問題と価値を理解すること
  • 何をすべきか？ ソリューションを概念的に設計すること
  • どのように実行するか？ 実際にコードを書くこと
• 最後の段階は以前は多くの時間を消費していたが、今ではClaudeのおかげでほとんど時間がかからない
  • 最後の段階に多くの時間を使っているなら、最初の2段階が間違っているか、ツールに慣れていないことを意味するかもしれない
  • 手作業でのコード編集には煩雑さがあるが、多くの言語ではIDEやインデクサーによって自動化されている
  • プログラミングプロジェクトでは、問題を理解することにより多くの時間を費やしてきた
• つまり、問題理解と設計により多くの時間がかかる
  • コーディングは最も簡単な段階に属する
  • 時間がかかる場合は、ツールへの不慣れや設計不足が原因かもしれない
• データ構造設計が中核
  • 構造がしっかり固まれば、コーディングは単なる実装にすぎない
  • この部分はLLMより人間のほうが優れている

LLMの限界と注意点

• LLMはしばしば誤った意思決定をする
  • 例: 不要な依存関係の追加、脆弱なコードの生成
  • 人間が必ずレビューと修正を行う必要がある
• セキュリティ問題を自力では認識できない
  • 例: injection、誤った権限設定
• 大規模コードベースでは性能が低下する
  • コンテキストウィンドウの制限により、全体構造の理解に失敗する

LLMがもたらす生産性向上

• 反復的で単純な作業に非常に効果的
  • boilerplate、テストコードなどで時間を節約できる
• 計画段階での活用のほうがより効率的
  • system designの草案、機能分解などで有用
• 不慣れな言語やフレームワークの学習に卓越している
  • 既存の文書より速く基本的な流れを把握できる

経験と技術的判断力の重要性

• LLMをうまく使うには経験がさらに重要
  • 問題を構造的に判断し、フィルタリングする能力が必要
• LLMがコードを生成しても、検収とリファクタリングは人間の役割
  • 「動く」ことと「正しい」ことは違う

LLMは開発者を置き換えるのではなく補助するツール

• LLMはジュニア開発者の役割に近い
  • 明確な方向提示がなければ的外れな結果を出す
• 人間 + LLMの組み合わせは単独のLLMより優れている
  • 戦略は人間、反復作業はAI

LLMの使い方によって結果は変わる

• コード自動生成だけに依存すると、むしろ速度が低下する
  • 特に慣れた言語では人間のほうが速い
• **自動補完ベースのインターフェース（Copilotなど）**が最も自然
  • 流れを途切れさせずに支援を受けやすい

LLMによる職務変化と懸念

• コード作成より設計とレビューへと、開発者の中核的な役割が移りつつある
• LLMだけに依存すると学習と成長の機会を失う
  • 技術的な地力を積めず、受け身のユーザーになる危険がある

LLMの未来と社会的影響

• 誰もがAIを使える環境では、人間が差を生み出す
  • 判断力、コミュニケーション能力が競争力を左右する
• LLMは**「自動車のような道具」**
  • 強力だが、依存性が高まり、問題発生時の対応が難しくなる