AIがソフトウェアエンジニアを代替していない理由、そして今後も代替できない理由
(normaltech.ai)- ソフトウェアエンジニアリングはAI導入が速い職種だが、AIが一定の能力に達すると大規模解雇が起きるという物語は、現時点の証拠では支持されていない
- Block、Snap、Intuitの事例ではAIが解雇の名目として登場したが、実際の背景は財務圧力、コスト削減要求、管理階層の縮小とより直接的に結びついている
- ソフトウェア開発は意思決定・実行・提供のサンドイッチ構造であり、AIは実行層を圧縮するが、何を作るかを決め、結果を検証し責任を負う層は自動化に強く抵抗する
- 「vibe coding」は監督・レビューなしでエージェントに任せる方式であり、実際のエンジニアは人間が統制と責任を維持するagentic engineeringの形でエージェントを使っている
- AIによってソフトウェア生産コストが下がれば、より多くのソフトウェア需要が生まれる可能性があり、個々のエンジニアのキャリアは揺らいでも、全体需要は強く維持される可能性がある
AIがソフトウェアエンジニアを代替していない理由、そして今後も代替できない理由
-
Coding agents as normal technology
- AIが仕事を代替するのではないかという不安と不確実性は大きいが、この問題を見るには、AIの能力向上と導入が急速に進んだソフトウェアエンジニアリング職を検討する必要がある
- AIの能力が特定の閾値に達すると大規模解雇が起きるという物語は、十分な証拠によって退けることができる
- 規制障壁がほとんどない分野でさえ大規模解雇の物語が成り立たないなら、他の職種にはさらに大きな緩衝装置がある可能性が高い
- 知識労働とソフトウェア開発はdecide-execute-deliver sandwichとして見ることができ、AIは実行層を圧縮するが、意思決定層と提供層は能力向上だけでは自動化されない
- ソフトウェアエンジニアリング需要の将来には慎重な楽観が可能だが、全体需要が健全でも、個々のエンジニアのキャリアは不安定になりうる
ソフトウェア分野におけるAI起因の大規模解雇事例は典型的な「AI washing」に近い
-
Blockの事例
- Blockは2月に4,000人の解雇を発表し、Jack DorseyはAIが「より小さくフラットなチーム」を可能にすると述べ、2025年末までのモデル能力向上に言及した
- その後の報道は、Blockがパンデミック期間中に人員を3倍以上に増やした後、強い財務圧力に直面していたという別の姿を示した
- Cash AppチームのデータサイエンティストNaoko Takedaは、Blockが全社員にAI利用を強いた一方で、生産性向上は非常に限定的だったと書き、75%の残留昇給案を断って退社した
- インタビューに応じた他の社員たちは、BlockにおいてAIが何をできるのか、またDorseyが論点を正しく理解していたのかについて、大きく異なる認識を持っていた
- Aaron Levieは、CEOたちは高速なプロトタイプは作れても、それを完成品にするために必要な90%の作業を見落としがちで、そのためAIの有用性について錯覚に陥りやすいと指摘した
-
Snapの事例
- Snapは4月に約1,000人を解雇し、Evan Spiegelは解雇メモの中でAIを主要な理由として挙げた
- Spiegelは、新規コードの**65%**がAIによって生成されたと述べた
- 実際の解雇は、コスト削減を求めたアクティビスト投資家のキャンペーンの後に起きた
- Snapは2017年のIPO以降、毎年純損失を計上しており、2026年には株価が30%以上下落した
- 人員削減の性格は、拡張現実部門で多様な職務150件を削るものであり、もしAIが原因なら想定される全社的なプログラミング職・AI露出職の削減とは一致しない
-
Intuitの事例
- Intuitは5月に3,000人削減を発表し、AnthropicおよびOpenAIとの契約もあわせて伝えられた
- メディアはこれをAI中心のリストラと結び付けたが、CEOは削減はAIとは無関係だと反論した
- 削減対象は「調整の多い役割」と過剰な管理階層だったと説明された
- Block、Snap、Intuitの事例は、AIが解雇の表向きの名目として使われても、実際には組織事情やコスト構造のほうがより直接的な背景だったことを示している
-
AI washingは経済全体の現象
- 検討したAI起因のソフトウェアエンジニアリング解雇の話はどれも、同じ形の物語の不一致を示している
- 米国の採用管理者の59%は、採用凍結や解雇を説明する際、財務制約よりもAIを強調したほうが利害関係者に受け入れられやすいと認めている
- ForresterのJ. P. Gownderは、AI起因の解雇を準備している企業に成熟した検証済みのAIアプリがあるかと尋ねると、10社中9社はないし、始めてもいないと述べた
- HBRの調査では、世界の役員1,000人超のうち21%がAIを「見越して」大規模な人員削減を行い、39%は低〜中程度の先制的削減を行っていた
- 実際のAI実装に関連してすでに大規模な人員削減を行った割合は2%で、これは予想ベースの削減と実装ベースの削減の間に大きな隔たりがあることを示している
-
WARN Actデータ
- WARN Actは、100人を超える労働者に影響する事業所閉鎖と大規模解雇について、特定の開示を求める法律である
- ニューヨーク州は2025年3月、米国の州で初めてWARN Act提出様式にAI開示のチェックボックスを追加した
- 最初の1年間で160社超がWARN通知を提出したが、AIボックスにチェックを入れた企業は1社もなかった
- 5月末時点でニューヨーク州労働局の確認によれば、Nespressoの1社だけがチェックボックスを選択していた
- 提出資料が正確なら、その期間にニューヨーク州で解雇された約25,000人のうち、AIの影響を受けた人数は46人、約0.2%だった
-
解雇はAI生産性効果を見るうえで誤ったシグナル
- AIの生産性効果は、既存社員をより多く解雇する形ではなく、採用鈍化を通じて作用するという研究結果がある
- 既存社員を解雇すると、AIを効果的に使うために必要な暗黙知や組織資本を失うことになる
- 解雇は退職金、士気低下、再採用リスクの面でもコストが大きい
- 自然減だけでも数年で同じ結果を得られるため、大規模解雇はたいてい不要である
-
雇用トレンドデータ
- Federal Reserveのエコノミストによる論文は、米国文脈で関連証拠を総合している
- 雇用は依然として増えているが、ChatGPT以後は、AIがなかった場合の反実仮想的な経路より年率約3ポイント遅く成長している
- この研究手法は自営業を捉えられないため、成長鈍化の一部が起業に吸収された可能性がある
- 他の研究は、AIが起業をより容易にする証拠を示している
- 実際の姿は、Federal Reserveの研究が示すものより健全かもしれない
-
実在するが別タイプのAI関連雇用喪失
- AIが製品需要を減らす場合、ソフトウェアエンジニアリングの雇用損失は起こりうる
- CheggとStack Overflowは、AIが宿題支援や技術支援製品への需要を減らした事例として挙げられ、両社とも解雇を行った
- この場合、AIが労働者の仕事を直接行ったのではなく、その仕事の必要性を減らしたのである
- 1950年の米国国勢調査にある270職業のうち、自動化で消えた職業はエレベーター運転手1つだけだったが、電報技師のように新技術で不要になった職業はいくつもあった
- AIを買う企業ではなく、売る側のIBMやSAPのような企業の解雇は、労働者代替というより、既存機能から急成長する製品ラインへ人員を再配置する通常の企業再編に近い
コーディングエージェントが労働代替につながっていない理由: decide-execute-deliver sandwich
-
AIが書いたコード比率は労働代替とほとんど結び付かない
- 一部の技術リーダーは、AIが書いたコード比率を、解雇や将来の雇用減少予測とあわせて提示する
- このやり方は、AIがすべてのコードを書くようになればコーダーは不要になるという単純な発想を強める
- しかし、AI作成コード比率は、労働代替を判断する中核指標とはほとんど無関係である
- コードを書くことはボトルネックではなく、過去にもボトルネックではなかった
-
コードを書くことはボトルネックではなかった
- 2019年の論文は既存研究を総合し、開発者がコーディングに使う時間は研究によって9%から61%と驚くほど少ないと結論づけた
- この結果はMicrosoftの開発者6,000人の社内データとも一致する
- コーディングエージェント導入が始まった後の2025年末の複数の記事でも、コード作成はボトルネックではないと指摘されている
- 開発者たちは、エージェントがコードの大半を書いたとしても、全体生産性への影響は小さいことを認識している
-
実際のボトルネックは3つ
- 実際のボトルネックは、何を作るかを決めて仕様化することである
- 引き渡される結果を検証し責任を負うことも、重要なボトルネックである
- コードベース、ビジネス、環境に対する深い人間的理解は、意思決定と提供の両方に必要である
- ソフトウェアエンジニアの仕事は、意思決定・実行・提供のサンドイッチであり、理解は3層すべての前提条件である
- AIはサンドイッチの真ん中を圧縮したが、両端はほぼそのまま残った
-
“Writing Code vs. Shipping Code”の証拠
- Writing Code vs. Shipping Codeは、GitHub開発者100,000人を対象にAIの生産性効果を分析した
- AIエージェントは書かれたコード行数を8倍に増やし、これは実行層が大きく圧縮されるという説明と一致する
- リリース増加は30%にとどまり、これは意思決定層と提供層の人間的ボトルネックがなお残っていることを強く示唆する
-
意思決定層はさらに薄くなりにくい
- 開発チームは何を作るかを決めなければならない
- ジュニアソフトウェアエンジニアが学ぶ重要な教訓の一つは、要件定義は想像以上に時間がかかるという点である
- 要件定義を圧縮すると、後続段階でより大きな痛みが生じる
- この層は、ユーザー需要、市場シグナル、組織の優先順位、場合によっては規制制約を考慮しなければならず、自動化が難しい
- AI能力が向上すればAIに委任できる意思決定の種類は増えるが、委任可能な意思決定はもはや競争優位の源泉ではなくなる
- 人間の意思決定の価値はより上位段階へ移動し、ソフトウェアの複雑性は時間とともに増すため、この過程に明確な上限はない
-
提供層が残るのは責任と検証のため
- 人間のチームは、自分たちが提供する結果について責任を負わなければならない
- 将来のある時点では、チームが十分にテストも理解もしていないミッションクリティカルなコードをデプロイすることもあるかもしれない
- 現在のAIは非常に不安定で、そのような無秩序なやり方はソフトウェアチームと顧客にとって実存的な脅威になる
- 技術的障壁が消えても、人間がAIに統制を渡す必要はない
- 共通規範、法律、政策を通じて人間の責任を維持する選択は可能である
- 責任法や分野別規制はすでに速度の障壁として機能しており、今後さらに強化されうる
-
未来のソフトウェアエンジニアはクレーン運転士に近づく
- 実行層がより多くAIに委任されるほど、ソフトウェアエンジニアの役割はクレーン運転士に近くなる
- AIエージェントは認知的な重作業の大半を担い、人間はエージェントを監督し統制することが中核業務になる
- 一部には、人間が統制する未来はコスト面で成り立たないと主張する人もいる
- 監督不足のコーディングエージェントが本番データベースを削除したり、他の被害を出したりした事例はすでに話題になっている
- こうした事例は新たな標準というより、衝撃性ゆえに広まる例外的事件であり、AIへの過度な依存を警戒させる学習機会になっている
- 高リスク業務で監督不十分なAI利用が増えているかを検知することは、ソフトウェアエンジニアリングだけでなく経済全体にとって重要なデータ欠落である
-
プログラミング縮小はAIだけの現象ではない
- サンドイッチが押しつぶされる傾向は新しいが、AIだけの結果ではない
- 20年以上前からBureau of Labor Statisticsは、プログラミングとソフトウェアエンジニアリングを分けて追跡し始めている
- おおむねプログラマーは実行だけを担い、ソフトウェアエンジニアはサンドイッチのより大きな部分を管理する
- プログラミングは縮小し、単純な実行業務と見なされるため報酬も大幅に低い
- AIは長年の傾向を加速させ、純粋な技術的実行能力の価値をさらに下げる
- 人間が意思決定と提供の両端に深く関与し、AIが中間の実行層を自動化するパターンは、知識労働全般に広く適用されうる
Vibe codingはagentic engineeringではない
-
用語の混乱
- 「vibe coding」という用語が広い範囲の慣行を指して不正確に使われることで、ソフトウェアエンジニアリングの変化に関する混乱が生じている
- 実際のvibe codingでは、ユーザーはエージェントにやることを伝えた後、実行中に監督せず、コードもレビューしない
- このユーザーはコードをレビューする能力がないかもしれず、目立って壊れている場合を除けば結果を評価しないこともある
- これは大半のソフトウェアエンジニアがエージェントを使う方法とは異なる
-
Agentic engineering
- 大半のソフトウェアエンジニアは、人間が結果に対する統制と責任を維持したまま、エージェントを道具として使っている
- この慣行を指す用語としてagentic engineeringが広まりつつある
- agentic engineeringが標準化するにつれ、エンジニアたちはコーディングエージェントの監督に予想以上の時間がかかることを発見している
- Simon Willisonは、エージェントを監督していると午前11時ごろには精神的に消耗すると述べており、これは実際の経験とも一致する
-
SWE-chatデータ
- SWE-chatは、ロギングツールに自発的に参加したオープンソース開発者のコーディングエージェント相互作用データセットである
- この研究では、エージェントが作ったコードのうち、ユーザーのコミットまで生き残った割合は44%だった
- vibe-codedなコミットは、人間のみが書いたコミットより9倍高い割合で脆弱性を導入した
- 最も一般的なユーザー意図は新規コード生成ではなく既存コードの理解であり、比率は19%対13%だった
- データセットは自己選択サンプルなので、この研究だけで強い結論を出すことはできない
- それでも、vibe codingとagentic engineeringが異なるパターンだという他の証拠を補強している
-
核心的な違い
- vibe codingとagentic engineeringは完全に分離された2つのカテゴリではなく、スペクトラムの両端である
- すべてのプロジェクトが単発プロジェクトかミッションクリティカルなプロジェクトかに分かれるわけではない
- すべてのワークフローが表の左列または右列に正確に当てはまるわけでもない
- 雇用の問題における重要な含意は、企業が検証されていないvibe coderをソフトウェアエンジニアの代わりに雇い、本番ソフトウェアをデプロイすることはできないという点である
これから何が起きるのか
-
大規模解雇予測が成り立ちにくい理由
- AI擁護派は、大規模解雇はまだ来ていないだけだと主張するかもしれない
- しかしサンドイッチモデルが正しければ、その予測は実現しない
- AIはすでにサンドイッチの中間層を大きく圧縮しており、この圧縮は実際には数十年前から始まっていた
- 実行層が即時かつ完全になっても、現在の状態からの変化は小さい
- 意思決定層と提供層がAIに抵抗する理由は、能力限界のためではない
-
ソフトウェアエンジニア需要は増える可能性がある
- AIによってソフトウェアエンジニアリングの仕事が消えるどころか、需要が増える可能性すらある
- 技術による生産性向上でソフトウェアを作るコストが下がれば、人々はより多くのソフトウェアを購入する
- ソフトウェアは経済学の用語で言えば価格弾力性が高い
- AIがソフトウェアエンジニアを代替しないなら、より多くのソフトウェア需要は、より多くのソフトウェアエンジニアへの派生需要につながる
- 「Jevons’ paradox」は、AI言説の中でこの概念を説明する際によく使われる経済学用語である
-
歴史的パターン
- 米国のプログラマー雇用は1950年ごろにはほぼ0に近かったが、今日では数百万人に増えている
- これは、機械化と自動化で労働需要が大幅に減った農業のような職業とは大きく異なる
- 人のカロリー消費量は比較的固定されているが、生産されるソフトウェア量は100万倍に増加している
- 現代の自動車には、複数のオンボードコンピュータで動く約1億行のコードが含まれている
- コード需要に上限があるとしても、現在はまだその近くにはいない
- ほぼすべての認知業務はソフトウェアの恩恵を受けており、AIがコーディングコストを下げることで、業務用・個人用の単発ユーティリティが作られつつある
-
Big Techだけが大きくなるという意味ではない
- 将来、ソフトウェアがはるかに増え、ソフトウェアエンジニアも増える可能性はあるが、それは大手テック企業がさらに巨大化することを意味しない
- 今日のソフトウェアエンジニアの多数は、すでにソフトウェア企業以外の社内組織で働いている
- この比率は今後さらに高まる可能性がある
- 「AI rollups」は、ベンチャーキャピタルやプライベートエクイティが歯科医院や会計事務所のようなMain streetビジネスを買収し、そこにソフトウェアエンジニアやAIエンジニアを入れてAI-nativeに作り替える構想を指す
- この構想は単なる誇大宣伝で終わる可能性もあり、まだ判断するには早い
-
民主化予測への反論
- 一部には、AIがソフトウェアエンジニアリングを民主化し、ソフトウェアエンジニアリング需要が減ると予測する人もいる
- 彼らは、生産されるソフトウェアもソフトウェア生産に使われる人間時間も増えるが、その仕事をするのはソフトウェアエンジニアではない人々だと考える
- たとえば法務ソフトウェアは、ソフトウェアエンジニアリング訓練を受けた人より、法律訓練を受けた人のほうが作りやすいという考え方である
- こうした主張は、vibe codingとagentic engineering、実行層とサンドイッチ全体を混同する罠にはまっている
- FORTRAN、COBOL、SQLのような過去の言語も、登場当時はプログラミング民主化への期待を伴っていたが、そのようなことは起きなかった
- 障壁は文法学習ではなく、責任を維持しながら良い意思決定を下す熟練した判断力である
-
個人のキャリアには大きな構造変化が起こりうる
- 時間がたつほど、人々がコンピュータで新しいことを行わせるために使う時間は増える可能性が高い
- この活動は、ソフトウェア構築、エージェントを活用した複雑なワークフロー管理、あるいは別の形を取るかもしれない
- 必要な能力は、ソフトウェア技術、AI技術、ドメイン専門性の組み合わせになる
- 今日のソフトウェアエンジニアがこうした新しい役割に最もうまく適応するかどうかは、まだ分からない
- ソフトウェア労働全体の需要が強くても、個々の労働者が影響を受けないという意味ではない
- AIはソフトウェア生産のあり方に大きな構造変化をもたらし、どのエンジニアが得をし、どのエンジニアが損をするかは、勤務先企業の種類、地域、キャリア水準、適応速度によって変わる
1件のコメント
Hacker Newsの意見
コンピュータ産業の歴史を通じて、私たちはソフトウェアエンジニアリングの自動化を積極的かつ熱心に進めてきたが、そのたびに、より大きくより良いものをより速く作れるようになってきた
そうして生産性が上がると仕事の価値も高まり、期待値も一緒に上がり、これまで世界のソフトウェア需要は尽きることがなかった
AIがソフトウェアエンジニアを置き換えられていない理由は、生産性が上がるたびに目標地点も一緒に動いてきたからだ
この流れが終わるケースは2つあり、1つ目は、ついに世界のソフトウェア需要をすべて満たせるほど生産性が高まることだ
まだその証拠は見えておらず、今回がコンピュータ産業全体の歴史と何が違うのかを明確に説明する必要がある
2つ目は、AIが自律的に行動したときに人間より優れたソフトウェアエンジニアになる場合だ
つまり、AI+人間の開発者がAI単独より優れていない状態だが、これまでの証拠ではAIは開発者の増幅器であり、良い結果を出すには専門家が方向性を定め、AIが最大90%を担う程度に見える
近い将来にこのどちらかが起きる強い証拠はないため、ソフトウェアエンジニアは当面は安全だと見ている
ただし、技術の幅が狭く特定領域、たとえばフロントエンドWeb開発に集中しているなら、より警戒すべきだ
AIがソフトウェアエンジニア全体を置き換えられなくても、ゼネラリストが指揮する形で特定ドメインを完全に吸収する可能性はかなり高い
ソフトウェアの終着点はそれほど遠くないと思う
すでに全体としては、人々が本当に望む以上のソフトウェアが作られており、そのかなりの部分はゴミから露骨な詐欺、さらには悪意に近いものまで含まれている
最終的には、ToDo管理やファイル同期のような一般人に必要な小さなソフトウェアを、それぞれのAIが個別に合わせて書くようになる気がするし、ソフトウェアエンジニアは大企業のプロジェクトにだけ残るのではないか
ここ数十年の商用ソフトウェアの圧倒的な傾向は、極端に反ユーザー的な非カスタマイズ化だった
1つのハッピーパスだけを残し、合わなければ自分で何とかしろ、という形になっていた
日常の人々向けの商用ソフトウェアはほとんどなく、オープンソースですら一般ユーザーから離れつつある
まもなく普通の人々が、自分のやり方で問題を解決するソフトウェアを直接作れるようになるだろう
ほとんどの場合、品質や正確性はそれほど重要ではなく、個別最適化されていて無料であり、侵襲的な監視・広告プラットフォームではないことのほうが重要だ
フロントエンドWeb開発の例は少しおかしく感じる
フロントエンド開発者として見ると、現在の最先端モデルは、自分が気にしない退屈な裏側の配管作業はうまくやるが、実際に顧客が求めるカスタムデザイン作業はまだうまくできていないと思う
誰が完全に正しいとか間違っているという意味ではなく、より幅広い技術領域を持つことが新時代で成功する最善の方法だという点には同意する
ただ、LLMがスタックのどこか一部分を完全に支配して、その分野の専門家が消えるほどではまだない
「こうしたことが起きている証拠は見当たらない」という話とは別に、少なくともモバイルアプリストアではすでに似た現象が見えている
最近の分析によれば、リリースされるアプリ数は大きく増えた一方で、レビュー総数とダウンロード総数は停滞している
つまりアプリはずっと増えたのに、ユーザーはそれほど、あるいはほとんど増えていないということだ
"WRITING CODE VS. SHIPPING CODE: PRODUCTIVITY EFFECTS ACROSS GENERATIONS OF AI CODING TOOLS" の p40 / figure 12 を見ればよい: https://www.nber.org/system/files/working_papers/w35275/w352...
分析は42〜43ページにある
パイが固定されていることは証明できないが、逆にパイが無限であることも証明できない
ソフトウェアの経済成長の話で人々が見落としがちな核心は、お金はどこかから来なければならないという点だ
成長し続けるには、今はソフトウェアにお金を払っていない誰かが新たに支払い始めなければならず、その人たちが誰で、どれだけの資金を持ち、どんな他のコストと競合するのかを見る必要がある
「世界のソフトウェア需要は尽きなかった」という言葉は、みなが最新最高の技術を求めているという意味ではない
多くの企業はいまだにカスタムスプレッドシートやMicrosoft Accessのような技術に依存している
望むことを正確にやってくれ、コストが固定的で、追加の修正や保守がほとんど不要だからだ
私たちが閉じこもっているバブルの外に出てみれば、多くの人はアップグレードに関心があるのではなく、すでに知っている古いものがそのまま動き続けてほしいと思っていることが分かる
AIが専門家の指揮の下で作業の90%をこなせるなら、それは**開発者の90%**を職から押し出すという意味だ
そして、その比率が99%になれない理由もよく分からない
AIがソフトウェアエンジニアを置き換えるのは間違いない。
欠けている部分は、文中で述べられているようにデリバリーと運用であり、それはソフトウェアエンジニアというより DevOps/SRE/Cloud エンジニアの領域だ。
私はクラウドエンジニアとして働いているが、エンジニアではない友人たち数人から、今では各自がサイドプロジェクトをゼロから複数言語で作り、ローカル、Web アプリ、ネイティブアプリとして動かせるようになったと連絡が来た。
彼らに足りないのは、「普通の開発者」のように簡単にデプロイして維持できるプラットフォームだ。
今はこの足場を作る作業がかなり煩雑だが、AGENTS.md、skills、厳格な総合テストがあれば十分可能だ。
一度作ってしまえば、非技術ユーザーは claude/codex に望むことを伝えるやり方で、ソフトウェアエンジニアを雇わなくても継続的に開発できる。
claude/codex はあらかじめ定めたアーキテクチャに基づいて判断し、非技術ユーザーを導くことができる。
私の逸話的な事例では、AI はすでに複数のソフトウェアエンジニアを置き換えている。
こうした足場が製品化されれば、グリーンフィールドプロジェクトはエージェントコーダーとプラットフォームエンジニアリングを通じて、製品観点だけで管理できるようになると思う。
これが今であり、5年後を想像すればいい。
非エンジニアが作ったアプリを持ってきたからといって、AI がソフトウェアエンジニアを置き換えた、あるいは置き換えるという意味にはならない。
症状を Dr. Google で調べ、生活習慣の改善、ハーブ療法、一般用医薬品を試して実際に効果が出ることはあるが、だからといって医者が消えるわけではまったくない。
生成 AI で音楽理論も、音楽的センスも、創造性もなく音楽を作ることはできるが、それで音楽的才能を持つ人たちがいなくなるわけでもない。
AI の助けで家の DIY ができても、エンジニアがいなくなるわけではない。
ドメインエキスパートが実際に必要としているものをプロトタイプ→改善の反復によって明確にするのを、誰が助けるのか。
趣味のソフトウェア制作者たちが依存している OS、言語、バージョン管理システム、エディタとターミナルエミュレータ、知識・ドキュメント管理システム、PaaS プラットフォームなどは、誰が書いて保守するのか。
彼らが作ったものは、堅牢だと保証できるほどきちんとテストされているのか。
起こりうる境界条件を理解しているのか。
セキュリティは大丈夫なのか。
プロンプトで素早く何かを作り出すことは、エンジニアリングと同じではない。
ソフトウェアエンジニアリングの価値が主として生成されたコード、つまりビット列そのものにあると見る誤りのために、そう見えてしまうのかもしれない。
プロジェクトの主たる価値は、理論と抽象化を作り上げていく過程にある: https://pages.cs.wisc.edu/~remzi/Naur.pdf
2週間でアプリを作って二度と手を入れないエンジニアもいるかもしれないが、それで生計を立てている人はあまり知らない。
「あなたの事業のための WordPress サイト」のような仕事なら可能かもしれない。
問題は、機能が432個ある中で433個目の機能を追加しながら、他を壊してはならないときに起きる。
少しでも間違ってはいけない場合もあるし、1つの機能がエンジニアの処理速度を超えて複雑さを増し、時間とともにプロジェクトが管理不能な規模になることもある。
大きなシステムと連携する小さなアプリケーションのアイデアで、2〜3日、3〜4コミットで概念実証が作られた。
印象的ではあったが、その作者はこの3か月でそのプロジェクトにさらに400コミットを重ね、修正が続いた結果、事実上そのアプリを作って保守することがパートタイム、あるいはフルタイムの仕事になった。
その人は訓練を受けていないソフトウェア開発者になり、セキュリティやベストプラクティスは理解していない。
Claude がもっと良くなれば負担は減って、一日を食い潰すことはなくなるかもしれないが、現時点では私たちの会社のこうした初期の「バイブアプリ」はすべて保守業務になっており、ますます多くの時間を食っている。
人々がソフトウェアを以前より欲しがらなくなるのではなく、より欲しがるのは明らかだ。
伝統的なソフトウェアエンジニアリングは消えるかもしれないが、拡大するプラットフォーム管理、セキュリティ、複雑性、文書化、ビジネスロジックは、依然として私たちの会社の前に残っている。
テキストでプロジェクトを作れるというのは事実だが、最も単純なソフトウェアでない限り、「設定して忘れる」ことなどなかったと感じる。
依然として誰かが全体を管理しなければならない。
その人がソフトウェアエンジニアリングの訓練を受けているかどうかにかかわらずだ。
経験のある開発者は、やはり訓練を受けていない人よりもうまくやれる可能性が高い。
もちろん好奇心の強いビルダーたちは素早く追いつくだろうが、伝統的な開発者には大きな優位がある。
私たちは常に内部がどう動いているかを知りたがってきたからだ。
彼らが数か月かけて作った現在のバイブアプリは、AI を使えば私なら1時間で作れただろう。
vercelを実行するだけのレベルまで下がっており、エージェントも依頼されれば何の問題もなくできる。デスクトップソフトウェアの配布は、プラットフォームによってはもう少し難しい。
それでも、サイドプロジェクトと優れたソフトウェアの間の隔たりは依然として非常に大きく、その隔たりがいつか埋まると信じるのは難しい。
AI 以前にもすでに解決されていた問題が、なぜ先に置き換えられないのか分からない。
個人プロジェクトに複雑なインフラが必要だとも信じがたい。
無期限に保守しなければならない金融アプリを、バイブコーディングで作ることはないだろう。
レガシーシステムにも手を出さないだろう。
AI が一部のエンジニアを置き換えたのは確かだが、非エンジニアの友人たちがサイドプロジェクトを作った事例は関連性が薄い。
それが今や可能になったから作ったのであって、もともと誰かを雇って作る予定だった可能性は低い。
これまで雇ってこなかったのと同じように。
開発エージェンシーで働いており、顧客の大半は素早く市場に出る必要があるスタートアップである。
約1年半にわたり エージェントベース開発 を使ってきたが、その間に私たちの役割は大きく変わった。
プロジェクト流入量は正確な数字が分からないので言いにくいが、目に見える変化としては、納品可能な範囲に対する期待値が変わったことがある。
以前は5人でやっていたプロジェクトを、今では通常1〜2人でこなしている。
現実的に、グリーンフィールド・プロジェクトはかなりの部分が自動化された。
UX/UIデザインの反復、システムアーキテクチャの反復、明確な測定指標のない難しい問題に複数のアプローチを試すことなど、多くの手作業が今では即座に行われる。
頭の中で理解できるなら、それを100分の1の時間で世に出せるということだ。
この期間に、働き方とシステムの考え方も大きく変わった。
LLMと共生するようになり、今では本当にそれなしでは難しい。
だからといって、LLMが書くコードを理解できないという意味ではなく、すべての変更を追いかけ、コードベースについてもLLMよりはるかに深く理解している。
ただし、手でコードを書く能力はかなり衰えたが、それは問題ないと思っている。
今は、ビジネス目標とそれを最もよく支える技術との間にある 翻訳レイヤー のように感じる。
依然として問題解決ではあるが、はるかに高いレベルの問題解決であり、今でも興味深く楽しい。
開発者にとってこの時代の最善の戦略は、批判的思考を保ちつつツールを有利に使うことだと思う。
今や誰もが超能力を手に入れた。
もう会社で働く必要すらなく、1人の開発者がとてつもないものを作れるので、他人に依存する必要も以前ほどない。
もしかすると未来は、各自が世界に固有の何かを提供する マクロ製品経済 なのかもしれない。
エージェントコーディングがグリーンフィールド・プロジェクトを作れるほど十分に良くなるなら、それは開発者だけでなく、会社全体や産業部門全体にも影響する。
開発エージェンシーというビジネスモデルは、技術に弱い会社がソフトウェアの扱い方を分かっていないから存在しており、場合によっては、初期の労働集約的な作業を外注したいという機会主義もある。
しかし今や、その技術はすでにエージェンシー顧客の指先にあるのだから、CEOや管理職がバイブコーディングを始めて、「技術感覚が少しある開発者1人だけでいい」と気づくのは時間の問題だ。
これは多くのSaaSビジネスにも広がりうる。
今なお多くの中小企業が手作業をなくすためにカスタムソフトウェアを欲しているが、本格的なソフトウェア開発者は常に高すぎた。
そのため、誰かの甥が作った雑なコードや、かろうじて動くSaaSを使うことがよくあった。
今では、やはりかなり雑ではあるだろうが、自分向けのソリューションを作ってより多くを得られる。
ビッグテックがやっていることは景気後退に合わせた再調整に近く、より懸念すべきなのは 中小テック部門 の混乱である。
顧客を獲得するための コネクション がないからだ。
ほとんどの開発者は、自分が得意な仕事に集中できるよう、少なくともマーケティングは会社に担ってもらう必要がある。
コード生成とコードの判別は、脳における別の能力である。
プログラミングには主に細かな構文上の詳細が多いため、コードを書くのに苦労してもレビューはうまくできることがある。
https://xcancel.com/karpathy/status/2015883857489522876
現実世界で成功している企業は、データ、特許・知的財産、ネットワーク効果などによる堀を持っている。
開発時間が100分の1になったからといって、すぐに新しい事業を作れるわけではない。
今のテック業界を見渡すと、機敏なAIベースのビルダーに破壊されそうに見える企業は多いが、ロックイン効果のため実際にはそうなっていない。
「1950年の米国国勢調査の270の職業のうち、自動化で消えたのはエレベーター運転手1つだけ」という主張は誤解を招く。
同じ期間に 農業雇用 は労働力の15%から2%に減った。
農業のように、機械化と自動化によって労働需要が大幅に減った職業とは異なるとしている。
人々が消費するカロリー量は比較的固定されており、25%増えただけでも肥満の流行が起きたが、生産されるソフトウェアの量は100万倍に拡大した、という違いである。
比率の数字は、労働力全体が増えたため減少を誇張している。
しかし、より広い 食品産業 の雇用を見るとかなり増えている。
したがって、「コーダー」の雇用は減っても、より広い「ソフトウェア/テック」産業の雇用は増える可能性がある。
その仕事の95%ほどはすでに自動化されているが、彼らはよくフクロウのせいにする。
工場やコンベヤーベルトも同じである。
自動化が入るたびに人々は仕事を失い、私たちは彼らが別の仕事を見つけることを「期待」するか、「ゼネラリストになれ」「専門家になれ」「サービス業へ行け」「コーディングを学べ」「石炭を掘れ」といった極端で首尾一貫しない希望論を浴びせる。
@pmarcaを聞いているだけでも、テックのリーダーシップがどれほど道を見失い incoherent になっているかが分かる。
産業自動化に関するStripe Pressの最新書籍も参考になる: https://press.stripe.com/origins-of-efficiency
AIを最も素朴に信じていた人たちは、たいてい いじくり回す人たち だった。
LLM支援コーディングのおかげで、何かをいじるスピードは驚くほど速くなったのだから、それも無理はない。
いじることはプロセスであり、人は作ったり調整したりする行為そのものに大きな喜びを見いだす。
結果は二次的、三次的な考慮事項だ。
AIは、私たちが行動し、したがって手を動かしていじる能力を大きく広げたが、それ自体で意味のあるインパクト、つまり「エンジニアリング」を生み出すわけではない。
活動よりもインパクトの方が重要だ。
プロトタイピング、デバッグ、テストなどは、速く行われるからといって偽の仕事ではない。
コンパイラもそれ自体ではインパクトを生み出さない。
CI、IDE、フレームワーク、クラウドインフラも同様である。
それらは使う人の レバレッジ を高める。
妻はAIに置き換えられた
妻はプログラマーで、会社は公然と妻や数人を置き換える目的でエージェントを作り、それが動き始めて約1か月後に妻を解雇した
私たちのチームは18か月前に新しい上司を迎えたが、露骨なえこひいきがあり、彼のお気に入りは唯一の非チームプレーヤーだった
彼は18か月の間に、過去の実績と無関係にリモート勤務者を全員解雇する方法を見つけ出した
そのうちの1人は上司より上のレベルの表彰を何度も受けていたが、上司はいつもその有害な人物だけを評価していた
AIによる置き換えではなかったが、人々が自分には価値がないと感じる空気は、AIに置き換えられるときと似ている気がする
私のスーパーバイザーを含め、そのチームの全員が別の職に応募中だ
そのスーパーバイザーは高機能自閉症で、上司にしばしば嘲笑されている
彼らのメンタルヘルスのためにも、ぜひ成功してほしい
HRに問題を何度か提起し、業務規程の中で上司が違反している条項も見つけたが、少なくともここではそうした規程はただの文字にすぎないと学んだ
むしろ自分の背中に標的を描くようなものだったので、去るしかなかった
ほかの何人かも懸念を提起したが、その大半はその後別の仕事を見つけた人たちだ
幸い、私はもうすぐ移る新しい職場を見つけており、楽しみにしている
大丈夫であることを願う
その後どうなったのか、新しい仕事を見つけたのか、今もソフトウェア業界にいるのか気になる
AI解雇に関する企業コミュニケーションが虚偽だからといって、リスクが無効になるわけではない
企業側の話が嘘であっても、技術の影響は現実のものになりうるし、この文脈ではノイズにすぎない
記事のバーガー図のように、実行段階は縮小する一方でほかのすべての段階が膨らみ、バーガー全体の大きさはそのままだという仮定も、それほどもっともらしくはない
ただ、ソフトウェアエンジニアリングの一部の領域は、まだ脅かされるにはかなり遠いように思える
特に正確性が核心である領域がそうだ
Web開発はかなり強引に進められる余地がずっと大きいが、ロケットの航法コードは別だ
LLMはどちらもできるかもしれないが、後者を近いうちにバイブコーディングする人はいないだろう
AIは文字通りすでに一部を置き換えており、今後さらにそうなるだろう
すべてのソフトウェアエンジニアを置き換えるわけではないが、パンドラの箱が開いた以上、低努力・低リスクの作業はAIが担うことになる
Lovableのようなサービスには、実際に本番運用されているプロジェクトが非常に多く、代替案は人間が作ることだった
仕事を置き換えるのは常に事業主だ
グラフィックカードの束を擬人化すべきではない
記事のこの部分には確信が持てない
「本当のボトルネックは、(1)何を作るかを決めて仕様化すること、(2)納品されたものを検証して責任を負うこと、(3)コードベース・ビジネス・環境に対する深い人間的理解だ」という主張だ
コーディングが高コストでボトルネックだと見なされていたからこそ、その入力が正しく、出力物を無駄にしないよう、上流と下流の両方で多くの労力が注がれていたのかもしれない
コーディングが速くて安い工程だと見なされるなら、出力物を捨ててもよいので、上流で同じ水準の監督は必要ないかもしれない
ソフトウェアが誤作動したときの影響と、下位互換性の維持のほうがはるかに厄介だ