- LLM はコード作成の速度を高めたが、ソフトウェアエンジニアリングの本質的な複雑さは減らしていない
- コード生成が容易になったことで、専門性の必要がなくなったという錯覚が広がっており、一部の組織はそれを根拠にエンジニアを削減している
- 実際に難しいのはコードを書くことではなく、システム設計、仕様策定、検証、一貫性の維持であり、AIはこの領域の負荷をむしろ加速させる
- 仕様（specification）、テスト、実装の不一致（spec drift） が急速に深刻化し、システムの信頼性が崩れるリスクが高まる
- 40年以上のキャリアの中で繰り返し観察されてきたパターンであり、1990年代のVisual Basicの時代にも同じ**「専門性は不要」**という主張が現れたが、結局はエンジニアリング規律の必要性が再確認された
- LLMは設計の探索や初期実装の加速に優れたツールだが、エンジニアリング規律を置き換えるのではなく強化する方向で使うべきである
業界の危険な錯覚
- LLMがコードを生成できるようになると、ソフトウェア業界にはソフトウェアエンジニアリングそのものがもはや不要だと結論づける空気が広がった
- アーキテクチャ、仕様、慎重な検証のような規律が、まるで時代遅れの遺物であるかのように扱われている
- 一部の組織ではすでにこの考え方が方針に反映され、AIの進歩を理由にエンジニアを大規模に解雇する事例が起きている
- AIは誤った経営判断や市場からの圧力を回避するための最新の言い訳にすぎない
- AIにプロンプトを入力することが、ソフトウェアエンジニアリングを定義してきた規律を置き換えるものとして、ますます包装されつつある
繰り返される歴史的パターン
- 40年以上のキャリアの中で同じパターンが繰り返し観察されてきた。新しいツールの登場 → 難しい問題は解決されたという宣言 → 生産性の急増と印象的なデモ → 人員削減 → システム複雑性の増大 → 最終的に期待外れの結果
- ツールも主張も変わるが、パターンそのものはほとんど変わらない
航空機整備のたとえ
- 航空機整備の分野では、ツールの改善、コンピュータ診断、デジタルマニュアル、AIによるテレメトリ解釈など大きな進歩があったが、熟練整備士の必要性は依然として変わらない
- 民間航空機は、数百万の部品と数千の相互接続されたサブシステムを含む極めて複雑なシステムである
- 問題の診断には、正しいツールを使ったりチェックリストに従ったりするだけでなく、実際の運用条件でシステムがどのように動作するかについての経験と判断力が必要である
- どの航空会社も、ツールが改善されたことを理由に訓練を受けた整備士をなくし、ゲート係員に修理を任せようとは提案しない
- それなのにソフトウェア業界は、まさにそれと非常によく似た主張を自分たちに対してしている
DIY vs 専門システム
- 趣味のプロジェクト、個人向けの小規模アプリ、新しいアイデアの実験はまったく問題ではなく、コンピューティング史上もっとも興味深いアイデアのいくつかは、こうした実験から生まれた
- しかし、専門的なソフトウェア開発はまったく別のカテゴリである。決済処理、機密情報の保存、インフラ管理、人々が毎日依存するシステムの運用などだ
- 顧客は、システムが正しく動作し、進化してもなお正しさを保ち、それを作る人々がシステムの動作原理を理解していることを当然期待している
- こうした期待は専門的なエンジニアリングの基本条件であり、規律と専門性が避けられない地点である
コードは決して難しい部分ではなかった
- ソフトウェア開発においてコードを書くことが難しい部分だというのは、古くからある誤解である
- 構文（syntax）を入力することは、常にシステム構築の中でもっとも面白みに欠ける部分であり、本当に難しい作業は、システムの振る舞いを決め、コンポーネント間の相互作用を設計し、複雑性が増しても理解可能性を保つことにある
- これはコーディングの問題ではなく、エンジニアリングの問題である
- コード生成の労力が減っても、これらの問題が消えるわけではない。より大きく複雑なシステムをより速く作れるようになるだけだ
- これを生産性向上と呼ぶのは錯覚でしかない。負荷が別の場所へ移っただけである
- コードレビューや生成されたコードを扱うために必要な認知負荷は、コードを書くこと以上に生産性を損なう要因になりうる
- 基盤となる振る舞いが十分に理解されないまま速度だけが上がれば、複雑性が制御不能になる時点を加速させるだけで、成果物も誤ったものになる
すでに見たパターン: Visual Basic時代
- 1990年代のVisual Basicにも同様の約束があった。プログラミングは民主化され、専門知識は不要になるという主張である
- 実際、Visual Basicには、そうでなければ作られなかった多くのアプリケーションを可能にした側面があった
- しかしシステムが大規模化し、相互接続が進むにつれて、ソフトウェア成果物を生産することと、信頼できるシステムをエンジニアリングすることは同じではないことが再発見された
- 現在起きているのは、同じパターンの増幅版である。アプリケーション構築の障壁ではなく、コード生産そのものの障壁を下げたのだ
- ここから専門性はもはや必要ないという魅力的な信念が生まれる
アラインメントの問題
- 信頼できるソフトウェアは、エンジニアリングの外ではほとんど論じられない**アラインメント（alignment）**に依存している
- システムは振る舞いについてのアイデアから始まり、**仕様（specification）**として文書化され、それをエンジニアがテストと本番コードへ変換する
- システムの長期的な信頼性のためには、仕様・テスト・実装の3つが常に整合した状態を保つ必要がある
- この3つがずれ始めると、システムは徐々に完全性を失っていく
- 仕様は、もはや実装されていない振る舞いを記述する
- テストは振る舞いの一部しか検証せず、残りは抜け落ちる
- 後から加わったエンジニアは、元の設計を反映しているかもしれないし、していないかもしれないコードを読みながら、システムの振る舞いを推測する
- 時間が経つにつれて推測は蓄積し、やがて誰も本当には理解していないシステムになる
- この現象を**「spec drift」**と呼ぶ。システムの説明とシステムそのものが徐々に乖離していく状態だ
- コードは変更されたのに仕様はそのまま
- 仕様は進化したのにテストは固定されたまま
- 振る舞いが徐々に変化し、元の意図が何だったのか誰にも確信が持てなくなる
- アラインメントが崩れれば、信頼性は長く維持できない
AIがドリフトを加速させる
- LLMはコード生産を劇的に加速させるが、それこそが最大の強みであり、同時に危険が現れる地点でもある
- コードが、それを取り巻くエンジニアリング規律よりも速く生産されるとき、spec driftを生み出す力は加速する
- かつては慎重な思考と手作業の実装が必要だった変更が、今では数秒で可能になる
- システム全体のセクションが、その振る舞いがいまなお仕様に合致しているか誰も確認しないうちに書き換え可能になる
- コードは概してもっともらしく見え、コンパイルも通り、読みやすく、既存のテストに合格するかもしれないが、システムを支えていたアラインメントはすでに失われている可能性がある
- 生産性に見えるものの正体は、実際には以前より速くミスアラインメントへ向かって進める能力かもしれない
AIが実際に役立つ領域
- LLMは誤りではなく、思慮深く使えば、エンジニアがシステムを探索し設計する方法を劇的に改善できる
- とりわけ優れているのは、問題の推論、設計代替案の探索、複雑なシステムの要約、初期実装段階を加速するためのドラフト生成である
- 苦手なのは、時間を通じて厳密な規律と一貫性が求められる領域だ
- 仕様・テスト・実装の間のアラインメントを維持することは、依然としてエンジニアリング上の責任であり、どんなツールもこの責任を置き換えることはできない（支援は可能である）
- 本当の機会は、LLMをエンジニアリングプロセスを静かに置き換えるものとしてではなく、強化する方向で使うことにある
対話型ソフトウェアエンジニアリング
- LLMが開いた興味深い可能性のひとつは、ソフトウェアエンジニアリングの一部が、より**対話的（conversational）**になりうることだ
- 何十年ものあいだ、システム設計ツールは硬直的だった。仕様は文書、アーキテクチャは図であり、そこに至る推論は会議や廊下での会話の中に消えていった
- LLMによって、エンジニアはアイデアをインタラクティブに探り、仮定を検証し、自然な会話に近い形で設計作業を進められる
- しかし、対話はエンジニアリングではない。対話はアイデアを探索する手段であり、エンジニアリングは、そのアイデアが検証・テスト・保守可能な形として捉えられたときに始まる
- 次世代のエンジニアリングツールの課題は、複雑なシステムに必要な規律を失わずに、この2つの世界をどう接続するかを学ぶことにある
専門性は今なお重要である
- 専門的なソフトウェアには、自分たちが構築するシステムの実際の動作を理解するエンジニアが今なお必要である
- ツールは開発を加速できても、複雑なシステムを設計し、推論し、維持するために必要な専門性を取り除くことはできない
- 業界はこの事実を忘れるには危険なほど近いところまで来ている
- LLMは経験豊富なエンジニアをはるかに生産的にできるが、信頼できるシステム構築に必要なエンジニアリング規律を置き換えはしない
- これらのツールは崇拝するのではなく、効果的に使うべきである
1件のコメント
Hacker Newsの意見
私はこの記事の前提には同意しない。エンジニアリング全般は、良い方向でも悪い方向でも、全体として簡単になったと思う。以前から、理解する代わりにnullチェックだけを大量に入れる人は大勢いた。今はそれが単に大規模に拡張されただけだ。逆に優れたエンジニアリングはさらに増幅され、以前なら数週間かかっていた機能を数日で作る例も見てきた
単体テストを100本書いても、コードの正しさを証明するのが難しい場合がある。ほとんどの開発者は何が十分なのか分かっていない。vibe codingを多用する人たちは、テストすら機械に任せる。システム設計の段階に進むと、全体的な安全性と時間的不変性を保証できる設計が必要になる。だが多くの場合、単に箱と矢印を描いて「ベストプラクティス」を引用するだけだ。ソフトウェアは自然科学により近いというSussman効果のように、観察により多くの時間を使うようになる。GenAIを道具として使うのは有用かもしれないが、考えるのをやめて道具に依存するのは危険だ
数年ごとに新しい道具が出るたび、「ソフトウェアエンジニアリングの難しい部分は解決された」と言われる。生産性は急上昇し、デモは印象的で、業界は自分たちを称賛する。だがその後すぐに人員削減が続く。本当のブレークスルーなら歓迎だが、その結果が解雇なら意味がない。結局のところ問いは同じだ――雇用を減らすことが目標なら、人々が生計を立てられなくなったとき、企業のビジョンとは何なのか？
「コーディングはもともと難しい部分ではなかった」という意見には同意する。専門家たちはすでに何を作るべきか分かっていて、単に反復作業が面倒だっただけだ
AIに過度に依存するジュニア開発者たちは、あとで基礎が身についていない代償を払うことになるだろう。結局、雇用の安定性があるのは経験豊富な人だけになる
「コードを書くことは難しい部分ではなかった」という主張には同意しづらい。もちろん常に難しいわけではないが、時間的制約があるときにはコードを書くことがボトルネックになる。AIは以前なら不可能だった試みを可能にし、より多くのエンジニアリング時間を確保できるようにする
AIは良いエンジニアリングも簡単にした。結局のところ行動の増幅器だ
私はAI懐疑論者だが、同僚の仕事を奪うとは思っていない。代わりに自分の時間を節約してくれる。Googleより優れたリサーチツールとして使い、コードベースの探索、ヘルパー関数の生成、エラーのレビューに役立てている
最近はソフトウェアエンジニアリングとリサーチの区別がはっきりしてきている。AIは探索的研究では驚くほど優れたツールだ。可能性が見えたら、その時点でSWEモードに切り替え、コードを理解し修正し、自分の経験で磨き上げる。AIの役割は限定的だが、それでも有用だ
こういう人たち（悲観論者）が諦めるまで、モデルがあと何回出ればいいのだろう？ 2回？ 3回？