手書きコードへの回帰：ソフトウェアエンジニアリングにおけるAIの採用と撤退の分析

AIのスピードとシステム理解の間の緊張関係

大規模言語モデル（LLM）によるコーディングアシスタントが一般的になった一方で、ソフトウェアエンジニアリングコミュニティの一部は、マインドモデルやコード品質を最優先するためにAIの使用を制限したり、逆に手書きに戻ったりしています。この動きの主な理由は、コード生成のスピードが問題解決のスピードや最終製品の安定性と必ずしも相関しないことに気づいたからです。

AI生成コードの認知的コスト

多くの開発者にとって、解決策を導出し、マインドモデルを構築することはソフトウェアエンジニアリングの最も重要な部分です。AIに実装を生成させることで、開発者は論理から切り離され、いくつかのシステム的な問題が生じます。

フローステートの喪失： 自動提案は、心の中のビジョンをコードに流し込む認知プロセスを中断する可能性があります。
アーキテクチャ上の問題の隠蔽： AIが迅速な生成によって難しいタスクを簡単に感じさせると、手動でコードを書いた場合に明らかになっていたシステムの根本的な欠陥に気づかなくなることがあります。
スキルの劣化： 手でコードを書くことは、構文の習熟度や技術面接の準備を維持するための必須な実践と見なされるようになっています。

"コードを導出し、マインドモデルを構築することは、仕事の90％に相当します。コードそのものは10％に過ぎません……このモデル／ビジョンを心に描いた後、私はそれをコードを通じて現実に流し込んでいますが、コードの提案が突然出てくると、そのフローステートが壊れます。"

AI駆動の技術的負債と機能の肥大化

スタートアップ環境では、AIでコードを生成しやすいことにより、「機能の肥大化」とアーキテクチャの規律の欠如が生じる可能性があります。初期開発フェーズでの迅速なイテレーション能力は、管理が困難すぎたり、本番環境に不適切なほど不安定なコードベースを生み出すことがあります。

一部の組織では、システムの単純さ、理解しやすさ、変更の遅さを確保するために、AIを使わずにコア機能を再実装することを検討しています。このアプローチでは、AIは迅速なプロトタイピングのツールとして扱われますが、コアアーキテクチャの安定性にとっては負債と見なされています。

AI使用に対する戦略的・経済的制約

特定の業界や企業規模は、AIの採用に対してより慎重なアプローチを要求します。

ディープテックおよびハイリスク環境： 専門分野では、コードの各行を完全に理解することがセキュリティと信頼性の前提条件です。場合によっては、AI生成コードの存在自体がクライアントにとっての契約破棄要因となることもあります。
企業の撤退： 一部の報告では、フォードやIBM、オーストラリア連邦銀行などの大手企業が、AI関連の採用や取り組みを縮小しているとされていますが、その動機は経済構造の再編から品質管理まで多岐にわたります。
"バイブコーディング"の崩壊： AWSのAI部門内などで「バイブコーディング」と呼ばれるアプローチ（厳格なエンジニアリングよりも、迅速なAI駆動のイテレーションを優先）を採用した部門が、結果としてソフトウェアの安定性に欠けていたため、解体や失敗に至ったという話もあります。

反論：AIは進化のツールである

一方で、多くのエンジニアはAIを禁止することはIDEやコンパイラ、Stack Overflowを禁止することと同義だと主張しています。彼らは、AIが単に開発者の負担から複雑性を移動させる次のステップにすぎず、ガベージコレクションが手動メモリ管理を置き換えたのと同じように、進化の一部だと考えます。

この視点から見ると、生産性の向上は明らかであり、現在の摩擦は成熟したパターンや設計原則の不足によるものです。支持者たちは、AIの最適な用途はコアロジックではなく、周辺部にあると主張しています：セキュリティチェック、パフォーマンス監査、テスト生成などです。

AI使用パターンの要約

アプローチ	主な動機	一般的な用途
完全採用	最大のスピードとトークン最大化KPI	速いプロトタイピング、商品化されたUI、ボイラープレート
選択的使用	スピードと深い理解のバランス	レビュー、テスト生成、周辺チェック
手書きコア	アーキテクチャの安定性とクライアントの信頼	コア技術、ディープテックシステム、複雑な空間的推論
完全回避	リスク低減とスキルの維持	高セキュリティシステム、面接準備