Simon WillisonがD. Richard Hippを引用、SQLの類推がAIによる雇用予測に疑問を投げかける

Simon Willisonは7月29日、D. Richard HippによるSQLの類推を取り上げ、AIがプログラマーを不要にするという予測に対し、歴史的な反例を示した。Hippの議論は、過去の労働の変化から始まる。SQLはかつてカスタムのデータ処理プログラムで行われていた作業を自動化したが、プログラミングは存続し、異なる形で拡大した。

投稿は短いが、そのタイミングは重要だ。AIコーディングシステムは現在、関数、テスト、クエリ、ドキュメント、時にはリポジトリ全体にまたがる連携した変更まで生成する。この進歩は、より強い主張を後押ししている。人々が日常言語でソフトウェアを記述できるようになれば、組織が必要とするプログラマーの数は大幅に減るというものだ。

Hippは、より劇的でないモデルを提示する。新たな抽象化は、ある種の指示を表現するコストを下げ、その後、人間の労力を仕様策定、検証、アーキテクチャ、保守へと移す。SQLはプログラミングを終わらせなかった。どの問題にカスタムコードを割くべきか、どの問題をデータベースエンジンに委ねられるかを変えた。

この類推は、AIが同じ道をたどることを証明するものではない。大規模言語モデルは確率的な出力を生成する一方、データベースは定義されたルールの下でSQLを実行する。それでもこの比較は、ソフトウェア業界のキャリアに関する主張を検証する有用な基準を示す。ツールはエンジニアリング作業を取り除くのか、それとも別の層へ移すのか。

Simon Willison、引用を労働市場の議論へと転換

今回のニュースは、新しいSQLite機能やAI製品ではない。自動化に関する主張を評価するための、より鋭い歴史的枠組みだ。

Simon Willisonは7月29日の投稿で、SQLが利用可能になったことでデータ作業がどう変わったかを説明するD. Richard Hippの言葉を引用した。SQL以前、組織はしばしばプログラマーに依頼し、大規模なデータセットを検索、結合、フィルタリング、要約する手続き型ソフトウェアを作成していた。

Hippは、多少単純化しつつ、そうした人々をCOBOLプログラマーとして挙げた。SQLを使えば、ユーザーは簡潔なクエリによって望む結果を指定できる。データベースエンジンは、その後、従来はカスタムプログラムに含まれていた実行ロジックの多くを生成または選択する。

Hippの比較における重要な表現は、プログラマーが消えなかったという点だ。彼らの仕事は変化した。

この区別は控えめに聞こえるが、現在のAIによる労働力予測を支える最大級の前提の一つに切り込んでいる。多くの予測は、コードの生成をプログラミング労働の決定的な単位として扱う。ソフトウェアがコードを生成できるなら、かつてそれを入力していた労働者は不要になる、という理屈だ。

SQLは、コード量とエンジニアリングの価値が同じではないことを示唆する。宣言型クエリは、何行にも及ぶ手続き型のデータ処理コードを置き換えられる。それでも、データを定義し、結果の意味を決め、権限を管理し、エッジケースをテストし、性能を監視し、要件が衝突した際に対応する人は必要だ。

宣言型プログラミングとは、あらゆる実行手順を逐一記述せず、システムが生成すべき結果を指定することを意味する。SQLが代表例となったのは、ユーザーが欲しいデータを表明するからだ。クエリプランナーは、データベースがそれをどのように取得するかを選ぶ。

Hippは以前からこの区別を強調してきた。データベースに関するプロフィールでは、宣言型言語がどれほど作業を削減できるかを多くの開発者が過小評価していると論じた。彼は、データベースに任せられる結合をアプリケーションコードで手作業で実行している例を指摘した。

この観察はAIコーディングに直接つながる。開発者は今や、すべての文を手入力することなく、アシスタントに機能の実装を依頼できる。この依頼は、SQLクエリが手続き型データ操作を圧縮するのと同様に、目に見える労力を圧縮する。

圧縮は現実のものだ。責任が消えるわけではない。

SQLユーザーには正しい結果を要求する責任が残る。AI支援を受ける開発者には、生成されたソフトウェアが意図した挙動に合致するかを判断する責任が残る。どちらの場合も、インターフェースは上位へ移る一方で、重要な意思決定は人間に残る。

Willisonによる選択は、Hippの類推により広い意味を与える。SQLの歴史に関するコメントを、自然言語によるコーディングが自動的にプログラマー不要の未来を生むという考えへの応答に変えている。

この投稿は、安易な反AIの結論も避けている。Hippは、自動化が何も成し遂げないと主張しているわけではない。SQLは明らかに、特定のプログラムを手作業で書く必要をなくした。この類推は大幅な生産性向上を認めながら、生産性から職業の消滅へと直結する見方を退けている。

これが、この出来事の中心的な緊張関係だ。同じ歴史から、二つの読み方ができる。自動化は特定のタスクをなくすが、同時にソフトウェア開発を十分に安価にし、ソフトウェアへの需要をさらに生み出す。

SQLが変えた作業単位

SQLはすべてのプログラミング作業を守ったわけではない。多くの作業を経済的に不要にし、より高次の意思決定へと焦点を移した。

リレーショナルデータベースと広く普及したクエリ言語が登場する以前は、業務データから新たな答えを得るために専用プログラムが必要になることがあった。プログラマーは、レコードレイアウト、アクセスパス、ソートルーチン、ファイル形式、レポート要件を理解する必要があった。

質問に小さな変更を加えるだけでも、新しいプログラムや大幅な改修が必要になり得た。組織が対価を支払っていたのは、単に結果ではなく手順だった。

SQLはこの構図を変えた。ユーザーは、選択、結合、グループ化、並べ替えを用いて結果を記述できる。データベースはその要求を実行計画へと変換する。実行計画とは、要求されたデータを返すために用いられる一連の操作である。

Hippの類推は、引用の枠組みを通じて本人も認めているように、長い技術史を圧縮している。SQLが登場してもCOBOLは消滅しなかった。COBOLシステムは、給与計算、銀行、保険、政府、トランザクション処理のワークロードを引き続き支えていた。

重要な変化は、より限定的だった。組織は、リレーショナルクエリで表現できる通常の質問ごとに、新しい手続き型プログラムを必要としなくなった。

これはタスク単位では、意味のある雇用の代替だ。ツールは専門的な実装に費やされていた時間をなくしても、そのタスクを含む職業そのものをなくすとは限らない。

AIを巡る議論では、仕事とタスクの区別がしばしば見失われる。仕事とは、活動、説明責任、専門領域の知識、コミュニケーション、意思決定を束ねたものだ。自動化がその束のすべてに同じ速度で及ぶことはめったにない。

SQLはクエリ実行を自動化したが、データベース管理、スキーマ設計、クエリ最適化、データモデリング、分析、セキュリティ、アプリケーション統合への需要を生み出した。また、はるかに多くのチームにとってデータアクセスを実用的なものにした。

HippはSQLの永続的な価値を、トランザクション、データ抽象化、宣言型言語という三つの概念で説明している。2024年のSQLiteインタビューでは、リレーショナルモデルは多くの現実世界の問題を表現する上で依然として有効だと述べた。

トランザクションは、関連するデータベース操作が制御された一貫性ルールの下で完了することを保証する。データ抽象化は、論理的な要求を物理的なストレージの詳細から分離する。宣言型言語は、ユーザーが望む答えに集中できるようにする。

これらの機能が組み合わさることで、単にキーストロークを節約する以上の効果が生まれた。専門性は、アプリケーションプログラマー、データベースエンジン、データベース専門家、業務ユーザーの間で再配分された。

AIコーディングアシスタントも、仕組みは異なるものの、同様の再配分を始めている。意図をコードに変換し、未知のリポジトリを検索し、テストを提案し、レガシー関数を説明し、マイグレーションやドキュメントの草案を作成できる。

これらの能力が向上するにつれ、チームが定型的な実装コードを書く時間は減るだろう。この結果を和らげて表現すべきではない。一部の初級タスク、保守業務、外部委託されたコーディング作業には、直接的な圧力がかかる。

しかし、節約された労力だけでは総雇用がどうなるかは分からない。望まれる成果の量が一定であれば、生産コストの低下は労働需要を減らし得る。安価な生産によってさらに多くのプロジェクトが可能になれば、労働需要は増え得る。

ソフトウェアが固定市場のように振る舞うことはほとんどなかった。チームは長いバックログを抱え、社内ツールを後回しにし、手作業のワークフローを容認し、エンジニアリング能力が限られているため統合を延期している。AIがこうしたプロジェクトのコストを下げれば、組織はより多くを構築できる。

したがって、SQLという前例は同時に二つの効果を示す。

• 代替: システムが、以前はプログラマーに割り当てられていた作業を担う。

• 拡大: コスト低下により、追加のソフトウェアおよびデータ作業が経済的に価値あるものになる。

• 再構成: 残る役割では、判断、設計、レビュー、専門領域の知識の比重が増す。

これらの効果は、すべての企業で同じように均衡するわけではない。安定した製品と固定されたロードマップを持つ企業は、AIを採用削減に使うかもしれない。成長中の企業は、人員を維持したまま、より多くの機能をリリースするかもしれない。小規模な組織は、これまで費用面で不可能だったソフトウェア開発を始められるかもしれない。

この変動こそ、「プログラマー」全体についての大まかな主張が弱い理由だ。自動化は、特定の組織における特定のタスクに到達する。雇用への影響は、需要、予算、リスク、そして新たに生まれる仕事の量に左右される。

真の対立は、タスク自動化と職務消滅の間にある

Hippの主な問題提起は、AIコーディングツールそのものに向けられているわけではない。コード生成を自動化すればエンジニアの役割全体がなくなる、という前提に向けられている。

生成された関数は、完了した仕事のように見える。すぐに届き、条件が整えばコンパイルでき、モデルに与えられたテストを通過することもある。この目に見える出力は、人々に実装をソフトウェアライフサイクル全体と同一視させやすい。

本番環境のエンジニアリングには、さらに多くが含まれる。誰かが曖昧な要求を正確な振る舞いへと落とし込まなければならない。その人は、関係者間の対立を解消し、欠落した要件を特定し、システムの境界を選び、データを保護し、どの失敗を許容するかを決める必要がある。

チームは、当初の文脈が変化した後も、その成果を保守しなければならない。依存関係は更新される。規制は変わる。ユーザーは予想外のワークフローを見つける。攻撃者は弱点を探す。データ量は、初期バージョンに組み込まれた前提を超えて増加する。

AIはそれぞれの活動を支援できるが、支援が説明責任を自動的に移すわけではない。生成されたコードがセキュリティインシデントを引き起こした場合、顧客や規制当局はモデルを責任ある運用者とは扱わない。

SQLとの比較は、この境界を見えやすくする。データベースエンジンは実行計画を選べるが、クエリが正しいビジネス上の問いに答えているかどうかを決めることはできない。技術的に有効な結合が誤解を招く指標を生むかどうかも判断できない。

同様に、AIアシスタントは、仕様が組織の実際のニーズを反映しているかを知らないまま実装を生成できる。実装の自動化が進むほど、仕様の品質が結果を左右する度合いは大きくなる。

ここには重要な逆転がある。自然言語はコードより簡単に見えるが、日常言語はソフトウェアが安全に見過ごせない曖昧さを許容する。

「自動税処理を追加する」という要求は、システムが管轄区域、免税、返金、丸め規則、適用開始日、不完全な顧客データを扱う必要が生じるまで明確に聞こえる。人間のエンジニアは従来、設計と実装の過程でこうした詳細を発見し、形式化してきた。

AIエージェントがコードを書くとしても、そうした問いが消えるわけではない。問いはプロンプト、仕様書、テスト、ポリシー文書、レビュー会議、あるいは本番障害へと移る。

2026年6月に発表されたcodeless futureの分析も、これに関連する主張を展開している。そこではAIをプログラミングにおける抽象化の次の段階と位置づける一方、表層的な形式にかかわらず、厳密な仕様は依然としてコードとして機能すると指摘している。

この点で、Hipp氏のSQLの比喩は最も説得力を持つ。SQLが成功したのは、その宣言的な適用範囲が限定されているためだ。データベースは、形式的な意味論のもとでテーブル、リレーション、述語、グループ化、並べ替え、トランザクションを理解する。

一般的なソフトウェア要件には、それに相当する境界がない。技術的な動作に加え、方針、美観、組織上のインセンティブ、法的義務、そして関係者が明言しないままの前提が混在している。

AIコーディングエージェントは、欠けている詳細を推論できる。この柔軟性は有用だが、同時にリスクも生む。推論された要件はもっともらしくても、誤っている可能性がある。

SQLエンジンも、特に統計情報、インデックス、ワークロードの前提が不十分な場合には、望ましくない実行計画を生成する。その出力は依然として、決定論的なデータベースの意味論に支配されている。大規模言語モデルは、似たプロンプトから異なる実装を生成したり、APIや前提を作り出したりする可能性がある。

したがって、AIコーディングは単なる「すべてのソフトウェアのためのSQL」ではない。より緩やかで、より野心的なインターフェースである。

この比喩は、どちらの技術も実装作業を圧縮するという経済的な水準では成り立つ。しかし、汎用的なコード生成は出力空間がはるかに大きいため、信頼性の水準では弱くなる。

この違いは、検証の価値を高める。開発者には、意味のある振る舞いをカバーするテスト、セキュリティと保守性を検討するレビュー慣行、そしてデプロイ後の失敗を明らかにする可観測性が必要だ。

チームには、持続的に利用できる文脈も必要となる。要件、アーキテクチャ上の判断、インシデント履歴、ドメイン上の制約は、エージェントやエンジニアがシステムを変更する際にも参照可能でなければならない。検索可能な技術ナレッジベースは、特に生成された変更が不慣れなリポジトリにまたがる場合、この作業を支援できる。

その結果としての役割では、手作業でコードを入力する量は減るかもしれない。それでも、形式化、検証、トレードオフ、オーナーシップを必要とする以上、依然としてエンジニアリングに近い。

SQLの比喩が破綻する点

SQLは有用な労働上の先例を示すが、AIがどれほど速く改善するか、あるいは企業がどれだけのプログラミング職を維持するかを決めることはできない。

歴史的な比喩は、類似点を選び出す一方で、相違点を隠してしまう。SQLは特定の種類のデータ操作のために設計された。その構文と意味論は、クエリを記述する人と、それを実行するデータベースの間に安定した契約を生み出した。

AIコーディングシステムは、変化する言語、フレームワーク、リポジトリ、インターフェース、ビジネス領域にまたがって動作する。文書化が不完全で、慣習が矛盾している状況に頻繁に直面する。その仕事は、形式モデル内での最適化だけではない。

このより広い適用範囲により、AIはSQLより経済的に重要になる可能性がある。リポジトリを横断し、複数のサービスを編集し、テストを実行し、失敗に対応するエージェントは、クエリプランナーよりも開発ワークフローの広い部分を担う。

同じ適用範囲は、信頼できる自動化をより難しくもする。限定されたベンチマークでの成功は、長期運用される本番システム内での安全な性能を保証しない。

生成された変更は、単体テストに通っても、文書化されていない運用上の前提に違反することがある。リポジトリ内にすでに存在する安全でないパターンを繰り返すかもしれない。目に見えるチケットを解決する一方で、将来の保守コストを増やす可能性もある。

人間の開発者もこうした誤りを犯す。重要なのは、AIがその頻度、検出可能性、規模を変えるかどうかだ。

スピードは、良い出力と悪い出力の双方を増幅しうる。チームが5倍の変更を生み出せば、変更あたりのエラー率が低くても、レビュー作業の総量は増えるかもしれない。逆に、強力な自動テストがあれば、失敗を増やさずに出力を拡大できる可能性がある。

この不確実性は、双方の自信に満ちた予測を弱める。SQLがプログラミング職をなくさなかったからといって、プログラミングの仕事は安全だと断言するのは時期尚早だ。同様に、印象的なコード生成の実演から大規模な雇用消滅を推論するのも時期尚早である。

完全自律型コーディングに関するHipp氏自身の公の発言も、慎重な立場を示している。2024年のインタビューで同氏は、AIは有用だが過大評価されており、完全自動のコード生成よりも支援型コーディングの方が実現可能性が高いと述べた。

この予測は、測定された結果ではなく一つの見解にとどまる。AIの能力と製品設計は変化し続けており、組織はいまなお、統制された開発プロセスの中でエージェントを導入する方法を学んでいる。

職種の区分は存続しても、規模が縮小したり、参入が難しくなったりする可能性がある。銀行はいまもCOBOLの専門家を雇用しているが、それはCOBOLがかつてと同じキャリアパスを提供していることを意味しない。ある技術は重要な専門知識を維持しながら、定型作業を担う人の数を減らすことができる。

ジュニア職には特に注意が必要だ。シニアエンジニアの多くは、小規模なバグ修正、単純な統合、テスト作成、監督下での機能開発を通じて学んできた。まさにそれらは、現在のコーディング支援ツールが得意とする作業である。

企業が研修を再設計せずにこの作業を自動化すれば、将来のシニアエンジニアを生み出すパイプラインを弱める可能性がある。SQLは新たな専門職を生み出したが、基本的な実装を以前ほど頻繁に実践しない人々の間で、AI中心のチームがどのように判断力を育てるべきかには答えなかった。

もう一つの不確実性は、組織の行動に関わる。生産性向上が追加のソフトウェア開発につながるとは限らない。経営陣は、その効果を人員削減、より高いアウトプット目標、短いスケジュール、あるいはそれらの組み合わせとして取り込むことができる。

分配のあり方は、技術的な能力と同じくらい重要になる。開発者はAIを使ってより大きなシステムを管理し、見過ごされてきた問題に取り組めるかもしれない。一方で、経営側がすべての時間短縮を恒久的な追加能力として扱うなら、業務負荷が強まる可能性もある。

Hipp氏の比喩は、この対立を解決しない。それを明確にする。

問いは、AIがプログラミング作業を自動化するかどうかではない。すでに自動化している。問われるのは、節約された時間を誰が管理するのか、どの責任が人間に残るのか、そして増大するソフトウェア需要が置き換えられた仕事を吸収するのか、である。

AIコーディングが企業の求めるスキルを変える

実装のコストが下がるにつれ、組織は正しい成果を定義し、もっともらしい誤りを見抜ける人材をより高く評価するようになる。

SQLへの移行では、クエリ構文を知る人だけでなく、データモデルとビジネス上の問いを理解する人が評価された。AIコーディングも同様に、ドメイン理解、システム設計、テスト、運用上の判断に対するプレミアムを生むはずだ。

プロンプト作成だけが、持続的な代替スキルになる可能性は低い。プロンプトはインターフェースであり、製品が成熟するにつれてインターフェースは使いやすくなる。より希少な能力は、もっともらしい回答が実際の要件を満たしていないことを見抜く力である。

開発者にとって、それは生成されたdiffの先までシステムを理解することを意味する。データの流れを追跡し、信頼境界を特定し、障害モードを評価し、コード変更をユーザーへの影響につなげる必要がある。

コードを書くことの中心性が低下しても、コードを読むことはより重要になる可能性がある。エンジニアは不慣れな出力を検査し、それがローカルの慣習に適合しているかを判断しなければならない。微妙な欠陥を認識するには、十分な基礎知識も必要となる。

テストも変化する。生成されたテストはカバレッジを広げられるが、モデルがコードとテストの両方で同じ誤解を再現する可能性がある。チームには、生成された実装だけでなく、望ましい振る舞いに基づく独立した受け入れ基準とテストが必要だ。

アーキテクチャも別の重要な論点となる。AIシステムはよく知られたパターンを提案できるが、よく知られたパターンが常に適切とは限らない。サービス境界、一貫性、レイテンシー、データ保持、運用の複雑さに関する判断は、個別の制約を反映する。

ドメイン専門家は、モデルが持たない文脈を提供できるため、影響力を増す。医療ワークフロー、財務照合システム、産業用コントローラーには、汎用的な学習データから信頼性高く復元できないルールが含まれている。

これは、すべての開発者がアーキテクトになるという意味ではない。役割の経済的な中心が、自動化された作業を選択し、制約し、検証する方向へ移るという意味である。

一部の仕事は限定的になる。反復的な変換、基本的なインターフェースのひな型作成、定型的なテスト生成には、より少ない人員で済むかもしれない。実装量を売りにする請負業者は、クライアントが許容可能な初稿を社内で作成できるようになれば、価格圧力に直面する可能性がある。

他方で、統合と保証に関わる仕事は拡大する。組織には、AIシステムを非公開リポジトリに接続し、ツール権限を管理し、出力を評価し、開発インフラを維持し、障害を調査する人が必要だ。

レガシーのモダナイゼーションは、この混合した影響を示している。IBMの研究者は、エンタープライズCOBOLのパターンで学習したモデルをJavaへの変換支援に使う方法を説明している。そのモダナイゼーションの取り組みも、CICS、Db2、VSAM、IMS、そして旧システムに埋め込まれたビジネス上の振る舞いを理解することに依存している。

変換は置き換えと同義ではない。システムには、数十年にわたる文書化されていない判断が含まれていることがある。Javaの構文を生成しても、新しいプログラムが必要な振る舞いをすべて保持しているとは言えない。

経験豊富なCOBOLプログラマーは、移行用ルーチンを手作業で書く量が減るかもしれない。しかし、モデルには歴史的・組織的な文脈がないため、その人の知識は検証時により重要になる。

SQLも同様の分業を生み出した。クエリエンジンはアルゴリズム選択を自動化したが、難しいワークロードには、スキーマ、インデックス、統計情報、アプリケーションの振る舞いを理解する人が依然として必要だった。

したがってAIコーディングは、実装とのつながりを失わずに、開発者へより上流の役割へ移るよう圧力をかける。コードについて推論できないレビュー担当者は、レビュー対象と同じシステムに依存することになる。

企業も管理上の課題に直面する。より速いコード生成と、信頼できる成果のより速い提供を区別しなければならない。レビュー、セキュリティチェック、関係者の意思決定、デプロイプロセスが制約されたままであれば、生成コードは積み上がっても顧客価値を高めない可能性がある。

コード行数や完了チケットに基づく指標は、さらに有用性を失う。チームはリードタイム、流出した欠陥、インシデント頻度、手戻り、そしてリリースした機能が意図した問題を解決しているかを検討すべきだ。

持続的な優位性は、自動化を明確な仕様と独立したチェックに組み合わせるチームにある。既存のプロセスにAIアシスタントを加えるだけでは、責任をどこへ移すべきかは明らかにならない。

Simon Willison氏の発言が注視すべき点を示す理由

次の段階は、生成コードの量ではなく、自律性、ソフトウェア需要、キャリア形成に関する証拠を通じて評価されるべきだ。

最初のシグナルは、AIエージェントが限られた人間の介入で、継続的な本番作業を完了できるかどうかである。短いコーディングの実演だけでは、もはや不十分だ。より厳しい試験には、複数ファイルにまたがる変更、曖昧な要件、デプロイ上の制約、セキュリティレビュー、リリース後の保守が含まれる。

エージェントが低い手戻り率と少数の流出欠陥でこうしたワークフローを繰り返し処理できるなら、限定的なタスク代替を予測するものとしてのHipp氏のSQLの比喩は弱まる。AIはエンジニアリング業務の束のより大きな部分を自動化することになる。

人間によるレビューが依然として支配的な制約であるなら、この比喩は強まる。仕事は消滅するのではなく、監督と仕様策定へ移行したことになる。

第二のシグナルは、ソフトウェア需要の総量です。企業は、生産性向上によってチームが小規模化するのか、安定したチームがより長いバックログを処理できるようになるのか、あるいは従来は採算が取れなかったプロジェクトが拡大するのかを明らかにすべきです。

採用データだけでは解釈が難しいでしょう。企業は採用を減速させながら生産量を増やすこともできますし、経験豊富なエンジニアを激しく奪い合う一方で、ジュニア向けポジションを減らすこともできます。見出しとなる人数より、雇用の構成の方が多くを物語ります。

どのプロジェクトに資金が配分されるかを注視してください。社内ツール、中小企業向けソフトウェア、カスタム統合、アクセシビリティ改善への投資拡大は、過去の抽象化の導入後に見られた拡張効果を裏付けるでしょう。利益が既存製品の内部に集中するなら、より強い代替効果を示すことになります。

第三のシグナルは、エントリーレベル業務の構造です。エージェントが従来の初級者向けタスクの多くを担うようになれば、組織には開発者を育成するための信頼できる方法が必要になります。

監督付きAIワークフロー、より充実した徒弟制度、デバッグやシステム推論に基づく評価の証拠は、この職業が適応していることを示すでしょう。代替となる育成策がないままジュニア採用が長期的に崩壊すれば、より深刻なキャリア上の混乱を示唆します。

こうしたシグナルは、単一のリリースやベンチマークではなく、時間をかけて現れるはずです。雇用システムは、モデルの能力よりもゆっくりと調整されます。予算、調達ルール、セキュリティ要件、レガシーアーキテクチャが、技術的な可能性が実務運用へ転化する速度を制約します。

Simon Willisonの投稿が重要なのは、Hippがより良い出発点となる問いを提示しているからです。AIがコードを書けるかを問うのではなく、どの業務レイヤーが宣言的になるのか、そしてその上位にどのような人間の責任が残るのかを問うべきです。

SQLは、膨大な量の手続き的なデータ作業を不要にしました。同時に、より大規模なソフトウェアシステム、より広いデータアクセス、新たな技術専門職を可能にしました。どちらも事実です。

AIコーディングも、この複合的なパターンをたどりながら、より大きな混乱を生み出す可能性があります。定型的な実装の価値は下がります。的確な判断、ドメイン知識、検証、オーナーシップの価値は高まります。

開発者は、AIが本当に作業をなくす領域と、単に複雑さを隠しているだけの領域を検証することで対応すべきです。チームは、生成コードが守るべき制約を文書化し、その後のデプロイ後に成果を測定すべきです。

次世代のプログラマーは、より高性能な実行エンジンを操作するSQLユーザーのようになるのでしょうか。それとも、自分たちがもはや完全には理解していないシステムを監督するレビュアーになるのでしょうか。その答えは、自動化が進む中で、企業が検証、学習、説明責任をどれほど意図的に維持するかにかかっています。