7月、ウェブ技術・出版分野の著述家・開発者であるBaldur Bjarnasonが「The 'AI' Software Crisis: Software Developers have been promoted into incompetence」と題した記事を公開した。AIエージェントの普及によってソフトウェア開発者が実質的に「管理職」へと昇進させられ、ピーターの法則（Peter Principle）が業界全体に一斉適用される事態が起きているという問題提起だ。
AIエージェントを使ってコードを生成・管理している開発者は、今何をしているか。コードを書いているのではなく、エージェントに指示を出し、出力を監視し、複数タスクを並行管理している。Bjarnasonはこれが「管理職の仕事そのものだ」と指摘する。そして問題の核心は、その管理職への「昇進」が、本人の準備も訓練もないまま業界全体に同時に起きていることだ。
「無能への昇進」とは何か
ピーターの法則とは、1969年にLaurence J. PeterとRaymond Hullが著した風刺書『The Peter Principle』が起源の概念で、「人は組織の中で、自分が無能になるレベルまで昇進し続ける」という原則だ。コーダーとして優秀な成績を収めた人がマネージャーに昇進する。ところがマネージャーに必要なスキル——タスクの並行処理、曖昧な言語でのコミュニケーション、組織全体のバリューフローの監視——は、コーディングとはまったく異なる。結果として「優秀なコーダー」は「無能なマネージャー」になる。
Bjarnasonの主張はシンプルだ。AIエージェント時代に突入したことで、この「昇進」がソフトウェア開発者全員に同時に起きている。
ソフトウェアエンジニアという職種は、管理能力の低さがあまりにも周知されていたため、多くの企業が「ICトラック（Individual Contributorとしてのキャリアラダー）」を用意し、管理職への昇進を回避できる道を作ってきた。その業界全体が、今、準備なしで一斉に管理職に放り込まれている。
AIエージェントの仕事は「管理職」そのものだ
AIエージェントを使った開発の実態を列挙すると、こうなる：
- 非決定論的で混沌としたエージェントの常時監視
- 曖昧で微妙なニュアンスを含む自然言語でのコミュニケーション（AIはそれを完全には「理解」しない）
- 複数タスクの並行管理
- 集中した実装作業ではなく、指示・仕様・プロンプトの記述
そして、大量のコードを管理しているにもかかわらず、開発者自身がコードを書く機会は激減した。
さらに悪いことに、エージェントが管理する「プロセス」は人間の部下よりもはるかに非決定論的で混沌としている。通常のマネージャーより難しい管理業務を、管理の素人が担っているというのが現状だ。
「悪いマネージャー」が引き起こすのと同じ症状
Bjarnasonは、この状況が引き起こす結果を列挙する：
- 価値を生まない作業（busywork）が増加する
- どこで価値が生まれ、どこで失われているかが誰にも見えない
- 不確実性が増すことでストレスと圧力が高まる
- 遅延が増え、タスクキューが長くなり、コストが膨らむ
- コミュニケーションが難しくなり、具体的な情報が乏しくなる
ここで強調されているのが「悪い管理の結果は、仕事が進まないことではなく、間違った仕事が大量に進んでしまうことだ」という点だ。全員が多忙なのに、組織にとって意味のある成果が出ない状態——これがAIエージェント導入後の多くのチームで起きていることだとBjarnasonは見ている。
自動化による「スキルの腐食」
さらにBjarnasonが掘り下げるのが、自動化のパラドックス（Paradox of Automation）だ。
1983年にLisanne Bainbridgeが論文『Ironies of Automation』で提唱した概念で、「自動化が信頼できるものになればなるほど、人間の貢献がより重要になる」という逆説だ。自動化が進むと人間の役割は「得意な実装作業」から「不得意な監視・例外判断」にシフトし、結果として成果が悪化しうる。航空・原子力産業では古くから知られてきた問題だが、Bjarnasonはこれがソフトウェア開発にも起きていると指摘する。
さらにBainbridgeはスキルの腐食（deskilling）を指摘している。記憶と整合的なメンタルモデルに依存する認知スキルは、練習をやめると急速に劣化する。プログラミングスキルのコアにあるのは、まさにこの「記憶」と「メンタルモデル」だ。
AIエージェントが「コードを書く」「デバッグする」「設計を考える」という日常的なトリガーを肩代わりしてしまうと、それらのスキルを維持するための反復練習の機会が失われる。そして皮肉なことに、エージェントの出力をレビューし品質を監視するためには、まさにその劣化しつつあるスキルが必要になる。
では、どうすればいいか
Bjarnasonが提示する選択肢は少なく、かつ全部が明るい話ではない。
最も合理的な戦略は「様子見」だ。ソフトウェア業界はこれまでも、SOAP（2000年代の分散システム標準）、NoSQL（2010年代のスケーラビリティブーム）、GraphQL（2015年以降のAPI設計議論）といった技術を——それぞれ登場時に業界を席巻しながら後から大規模な修正を余儀なくされた事例として——性急な採用と事後修正のサイクルを繰り返してきた。開発ツールや手法においては、ファーストムーバー・アドバンテージは存在しない、というのが彼の見立てだ。
「様子見」が組織的に不可能な場合——成果物の量を価値として測る組織、機能を詰め込むことが目的のクライアント——は、既存のスキルを意識的に維持しながら、管理職に近い新スキルも習得するという、フルタイムを超える自己投資が必要になる。具体的には、AIに任せきりにせず定期的に自分でコードを書く時間を確保すること、エージェントの出力を批判的にレビューする目を養うこと、といった実践だ。
そして記事はこう締めくくる：
Whatever happens next – to your employer, to the software, to the market – is not your fault.
（次に何が起きても——雇用主に、ソフトウェアに、市場に——それはあなたのせいではない。）
有能な経営者なら、これほど大規模に従業員を無能へと昇進させるシステムを作らなかっただろう——責任の所在を個人ではなく構造に置くこの結びは、現場のエンジニアに刺さる言葉だ。
詳細はThe 'AI' Software Crisis: Software Developers have been promoted into incompetenceを参照していただきたい。
