誰が AI でソフトウェア開発を変えているのか？AI プログラミングが生み出しつつある、まったく新しいソフトウェア開発者

30 年以上のプログラミング経験を持つ開発者 Lars Jansen は X に投稿し、ある観察を提示した。AI プログラミングはまったく新しい種類のソフトウェア開発者を生み出しつつある、というものだ。

彼が指しているのは、あらゆるフレームワーク仕様に精通し、コンパイラを気軽に書き、インデントにはタブを使うべきかスペースを使うべきかを 15 年議論する伝統的なプログラマーではない。ましてや、チュートリアルに沿って ToDo リストを作り、Accept をクリックし続けるだけで自称エンジニアになる人でもない。彼が言うのは別の一群だ。システムがどう動くべきかを明確に説明でき、テストし、モデルに疑問を投げかけ、おかしいと感じたら見逃さず、ソフトウェアが本当に使えるようになるまで修正を続ける人々である。彼らの中には、以前は自分をプログラマーと呼ぶことすらなかった人も多い。

この投稿はすぐに大量の議論を呼び、多くの「これは私のことだ」という返信も現れた。Jansen はその後、自分のプログラミング経験とこれらの返信を組み合わせて、この意見長文を書いた。これは統計的に代表的な業界調査ではなく、すでに起きている変化を問い直すものだ。自分でコードを書くことがもはや以前のような硬い敷居でなくなったとき、何がソフトウェア開発なのか。そして、誰がそれによってソフトウェア開発へ入る機会を得たのか。

誰がソフトウェア開発に入りつつあるのか

返信によって Jansen は、この人々がコンピューターサイエンス専攻の学生でも、AI でベテランエンジニアになりすまそうとする新人でもないことに気づいた。彼らは長年、具体的な問題に向き合ってきた各分野の専門家である。弁護士、デザイナー、映画関係者、EC 関係者、事業主だ。

彼らに以前欠けていたものは、通常、アイデアではなく、アイデアをソフトウェアにする能力だった。法律事務所の関係者は外部の開発者よりも自分の業務フローに詳しいかもしれない。建築関係者は 10 件のプロジェクトの間でどの情報を追跡する必要があるかを知っている。倉庫管理者は、高価な旧システムにインターフェースを一つ追加するだけで、全員が毎日 30 分を節約できることを理解している。デザイナーも、画像ワークフローがどう動くべきかを正確に説明できる。

しかし、「自分にどんなソフトウェアが必要か」を知っていることは、それを実際に作れることと同じではない。かつてこの壁を越えるには、通常、プログラマー、開発チーム、十分な予算が必要だった。あるいは自分でプログラミングを学ぶために数年を費やす必要があった。領域知識がどれほど深くても、実装能力が欠けていれば、ソフトウェアはアイデアのままにとどまる。

AI はこの敷居を下げつつある。返信者が語っているのは、単なる個人のおもちゃではない。自分の仕事のために社内システムを構築する人もいれば、自作ツールで高価なソフトウェア購読を置き換える人もおり、伝統的な開発背景なしにフルスタックシステムを納品した人もいる。

これはチュートリアルに沿って ToDo アプリを作ることとは異なる。彼らはモデルが生成したすべての関数を書けないかもしれないし、使用している言語の文法の半分にも詳しくないかもしれない。しかし、ソフトウェアがどう動くべきかはよく分かっている。結果が違えば、問題を指摘し、差異をテストし、繰り返し修正し、実装を一歩ずつ本当に必要な状態へ押し進めることができる。

彼らはどうモデルを操縦するのか

AI プログラミングツールを使えることは、自動的にこの記事で言う新しい開発者にするわけではない。本当の分水嶺は、判断権が人の手に残っているか、それともモデルに一緒に渡してしまうかである。

第一のタイプは、AI に機能を作らせ、一度実行し、正常系が通りそうに見えたら次へ進む。彼らはモデルがなぜこの実装を選んだのかを理解しておらず、コードの中にどんな前提が隠れているかも確認せず、正常経路の外で何が起きるかも知らない。現実に、「Airbnb のようなアプリを作って」と入力し、Accept All を 47 回連続でクリックし、ローカルにログインページが現れたのを見て、自分はもうソフトウェアエンジニアになったと思う人もいる。

第二のタイプは、同じ要件から始めるかもしれないが、その後の会話はまったく違う。彼らはさらに問い続ける。

• 同じリクエストを二度送ると何が起きるのか？
• なぜこの状態をここに置くのか？
• 二つの操作の間でプロセスがクラッシュした場合、データはどう復元されるのか？
• 一つの問題だけを直すよう求めたのに、なぜ無関係な三つのファイルが変更されたのか？

彼らはさらに、モデルに失敗経路のテストを書くよう求め、すでに動作している部分を作り直すのをやめ、変更前に既存実装を確認し、疑わしく見える決定を説明するよう求める。

在庫ツールを例にすると、フォームが送信できるかだけを見るなら、最も順調な一つの経路を検証したにすぎない。判断権を保持する人はさらに、重複送信で在庫が二重計上されないか、在庫更新と操作記録の間で中断が起きた後に復旧できるか、複数人が同時に在庫を変更した場合どう扱うか、そしてこれらの失敗ケースにテストカバレッジがあるかを確認する。

どちらのタイプも AI を使ってコードを書いているが、している仕事は同じレベルではない。前者は技術的判断をモデルに外注し、後者はモデルを実装ツールとして扱い、自分が方向づけ、疑問を投げかけ、テストし、最終検収に責任を持つ。すべてのコードを自分で書けるかどうかは、もはや唯一の境界線ではない。実装がすでに逸れていることに気づけるかどうかが、より重要な違いである。

これこそが「雰囲気プログラミング」（Vibe Coding）が区分力を失いつつある理由でもある。この言葉は、一日中 Claude や Codex を使うベテラン開発者を形容するのにも使われ、データベースを理解せずモデルの出力を受け入れ続けるだけの初心者を形容するのにも使われ、自分のツールを真面目にテストする非プログラマーも含まれる。三種類の人を同じラベルに入れても、彼らが実際にどんな能力を持つかを判断する助けにはならない。

この能力は実は技術プロダクトマネージャーやアーキテクトの仕事だと言う人もいる。行動を定義し、ユーザーを理解し、結果をテストし、境界問題を見つけることだ。この判断は一部当たっているが、過去のプロセスにおける最後の層が欠けている。伝統的なプロダクトマネージャーは要件をエンジニアリングチームに渡した後も、それを動くソフトウェアに変える人が必要だった。現在では、同じプロダクトとビジネスを理解する人が自然言語を通じて実装層を調整し、要件からデプロイまでの一連の流れを自分で完結させるかもしれない。呼び方が重要なのではなく、新たに加わったデリバリー能力こそが重要である。

なぜベテランプログラマーは依然として重要なのか

判断権を自分の手に残すことは、本番環境に必要なすべての経験をすでに備えていることと同じではない。ベテラン開発者が提起する疑問には根拠がないわけではない。なぜなら、本当のソフトウェアエンジニアリングは、正常系をローカルで動かすこととはほど遠いからだ。

セキュリティ、保守性、認証、競合状態、再試行、データベースインデックス、レート制限、バックグラウンドタスク、CI/CD、デプロイは、いずれも画面のスクリーンショットでは見えない場所に隠れている。データベースがダウンしたらどうなるのか？ 二人のユーザーが同時に同じ操作を実行したらどうなるのか？ モデルが表面上は合理的だが、実際には危険な誤りを含むコードを書いた場合、使用者はそれを見分けられるのか？

Jansen は 30 年以上コードを書いており、モデルが 500 行の Go を簡単に生成できるからといって、ソフトウェアがこれで簡単になったとは考えない。AI は人により速くより多くのソフトウェアを作らせるが、より速くより多くの悪いソフトウェアも作らせる。これは AI に反対する理由ではないが、無視できない現実の代償である。

より困難な問題は通常、第二版で現れる。第一版が二年動いた後、コードはすでに 400 回変更されているかもしれない。新しい要件が古い前提と衝突し始める。システムは数百万行のデータを移行する必要がある。依存ライブラリは保守されなくなる。新しいモデルは、前のモデルが推奨した設計を壊すよう提案するかもしれない。

ソフトウェアは歴史を蓄積し、大量の複雑さはまさにその歴史によって生み出される。人々がすでに依存している 15 の機能を壊さずにオンラインシステムを変更することは、白紙の上に新しいアプリを作るよりもはるかに難しい。ベテランエンジニアは、こうした問題がどう発生するかを見てきており、ある一見不器用な約束事がなぜ存在するのかを知り、一見無害な一行の変更が誰かの週末を台無しにしうることも知っている。本番事故によって残されたこの判断力は、一つのプロンプトだけで得られるものではない。

彼らが最初に変えるのはどの種類のソフトウェアか

この人々が何を変えるのかを理解するには、まずソフトウェアのリスクを区別しなければならない。彼らがベテランチームを置き換え、銀行を 18 年間動かしてきた取引システムを保守すると考えるなら、もちろん非現実的である。金融、医療、インフラ、セキュリティに敏感なシステム、大規模分散アプリケーションでは、一度誤ればユーザーを傷つけたり巨大な損失を引き起こしたりする可能性があり、深い技術理解はここでは選択肢ではない。

しかし、多くのソフトウェアは決済ネットワークでも Netflix でも航空機の制御システムでもない。それらはフォーム、データベース、ワークフロー、レポート、CRUD、API、通知、業務ルール、定期タスクである。こうした普通のソフトウェアにとって重要なのは、最高水準のアーキテクチャ基準を満たせるかどうかではなく、それが存在するその問題を確実に解決できるかどうかである。

新しい開発者が最初に変えるのは、過去には経済的に割に合わないためにそもそも開発されなかったロングテールソフトウェアである。著者は簡単な計算を挙げている。専門チームはカスタムツールに 5 万ドルを見積もるかもしれないが、その問題は要求者にとって 5000 ドルの価値しかない。従来の商業論理では、このプロジェクトは発生しない。

もし問題を最もよく知る人が数週末で十分使えるバージョンを作れるなら、この計算は変わる。原文が挙げる範囲は広い。社内ツール、ワークフローアプリ、バックオフィスシステム、専門計算機、在庫ツール、WordPress ユーティリティ、データインポーター、レポートダッシュボード、垂直業界システム、個人ツール、コミュニティアプリ、小規模 SaaS、家庭用レシピシステム、工房のトラッカー、そして 300 人にとってだけ意味のある小さなアプリ。

「専門のプログラマーなら一時間で書き直せる」は有力な反論ではない。確かに彼らはできるかもしれないが、過去には誰も書きに行かなかった。今、領域専門家がそれを作った。

このロングテールソフトウェアのすべてが成功するわけではない。品質が非常に悪いものもあり、六週間後に放棄されるものもあり、予期せずデータベースをインターネットに露出させるものもあるかもしれない。「すでに完成したように見える」アプリを作ることは、その下にあるすべてを理解するよりも簡単である。しかしその中からも、本当に役立つツールが現れるだろう。なぜなら、時には最良のソフトウェアはプログラミング言語の細部に最も詳しい人からではなく、問題を最もよく知る人から生まれるからだ。

彼らは実践の中でどうエンジニアリングを学ぶのか

領域専門家がこうしたツールを自ら構築し始めると、プログラミングを学ぶ順序も変わるかもしれない。

伝統的な経路は通常、変数、関数、ループ、データ構造、一つの言語、何らかのフレームワークを先に学び、それから徐々に大きなプロジェクトに入り、アーキテクチャ問題に遭遇する。AI は別の経路を可能にする。本当に関心のあるアプリを先に作り、プロジェクトで何か問題が起きたら、それを解決するために必要な知識を学ぶ。

• 誰がシステムにアクセスできるかを制御する必要があり、そこで認証を学ぶ。
• 外部サービスのイベントを受け取る必要があり、そこで Webhook を理解する。
• 同じことが二度処理され、そこで冪等性を学ぶ。
• データクエリがどんどん遅くなり、そこでデータベースインデックスを研究する。
• 二つの操作が同時に同じ状態を更新し、そこで競合状態を理解する。
• 操作の途中でプロセスがクラッシュし、そこで復旧機構を考え始める。

これらの概念はもはや「将来いつか使うかもしれない」教科書の章ではなく、目の前のプロジェクトが続行できなくなる具体的な原因である。Jansen は、自分はある知識が本当に必要なときに学ぶほうがうまくいくと言う。返信の中にも似た経験を描写する人がいる。モデルに問い、説明を読み、コードを確認し、実装を壊してから直すことを通じて、ソフトウェアを構築しながらアーキテクチャを学ぶのだ。

危険もここにある。AI は動作する冪等実装を出せるが、使用者が冪等性を本当に理解していないままにすることもできる。自分が理解していない実装を積み重ね続けるだけなら、最後に責任を持つのはほとんど説明も保守もできないシステムかもしれない。先に作ってから学ぶことが有効な経路になりうるかは、使用者が問い続け、確認し、理解するかどうかにかかっている。結果が一時的に動けばよい、ということではない。

新しい入場券とは何か

ここまでの変化は同じ結論を指している。AI は技術的敷居をなくしたのではなく、最低限有効な技術能力の位置を変えた。

過去には、アイデアをソフトウェアにしたいなら、まずそれをどう書くかを知る必要があった。現在では、一部の人は実装をモデルに任せられるが、自分自身は次のことを完了できる程度には理解していなければならない。

• 本当に解決すべき問題を定義し、それを合理的な部分に分解する。
• 良い実装と、正常に見えて実際には問題のある実装を区別する。
• テストを設計し、正常経路の外の結果を確認する。
• モデルを既存システムの境界内にとどめ、疑わしいコードを調査する。
• 最初の案が間違っていた後も修正を続け、ソフトウェアが本当に納品されるまで進める。

構築を始めるのに必要な技術知識は減るかもしれないが、技術的判断はより重要になる。ソフトウェアを完成させて公開できることは、もともと独立した能力である。多くの技術的に優れた人も、未完成プロジェクトのフォルダをいっぱいに持っている。AI は誰にとっても最後のこの道のりを取り消してはいない。

ソフトウェア開発は常に抽象化のレベルを上げてきた。開発者は HTTP サーバーを自分で書く代わりにフレームワークを使い、データベースエンジンを自分で実装する代わりに PostgreSQL を使い、Stack Overflow を参照しても、それによって開発者としての立場を失うことはない。AI は同じ方向における、より大きな一歩にすぎないかもしれない。それは、過去には必ず手で行わなければならなかった実装層に、言語を通じて触れられるようにする。

だから、AI が生み出したのはまったく新しい人間ではない。プロダクト感覚、領域知識、プロセス理解、論理的思考、テスト能力を持つ人は以前から存在していた。過去に欠けていたのは、これらの能力をコードに変える道筋だった。今、彼らは別の扉から入ることができる。モデルに疑問を投げかけ、結果を検証し、修正を続け、最後に本当に使えるアプリをサーバー上に置くのである。