経験のあるソフトウェアエンジニア

Copilot CLI と Copilot SDK を支えるランタイムを TypeScript から Rust へ移したことについての、GitHub 自身による工学の記述である——本番の Rust が832,378行、Rust の単体テストが468,689行であり、主に一人の開発者が数か月で成し遂げた。人が書いた2,639件のメッセージのうち、31.0%はレビュー、テスト、CI に向けられ、17.4%は技術や設計の決定に異議を唱え、15.0%は完成まで詰めることを求めていた。1,130,921回のツール呼び出しのうち61%は、メインのセッションのスレッドではなくサブエージェントから出ていた——それはエージェントどうしの分担であって、エージェントがこなした仕事の割合ではない。開発者が自分の手に残したのは、移行先のアーキテクチャ、どの振る舞いを寸分違わず保たねばならないか、作業をどう区切るか、曖昧なトレードオフ、証拠の見極め、危険の高い領域の手作業によるレビュー、そして最後のマージの決定である。記述はまた、あるエージェントがスキーマのチェックを通すラベルを付け、問いただしてみるとそれがリグレッションを隠していた、という一件も書いている。一人の開発者、一つのプロジェクト、それも提供元自身のコードベースでのことである。能力の記録として扱っており、このサイトでは、能力の記録が判断を動かすことはない。

実演、ベンチマーク、あるいは論文が、その業務をやれることを示している。技術に何ができるかを更新するのであって、雇用主が何をするかを更新するのではない。

内務省のソフトウェアチームを拘束するエンジニアリング標準である。AIの道具はシステムに加えられる決定、設計、変更についての人の判断、理解、オーナーシップ、責任を置き換えられないので、AIの支援を受けたすべてのコードと出力についてチームが全面的に説明責任を負い続けるとし、AIの支援を受けた出力は本番に届く前に人がレビューし承認しなければならないとし、そしてチームは自分たちが動かすもののセキュリティと保守性を明言できなければならないとしている。はっきりした「must」が掛かっているのはレビューであり、設計についての一文は説明責任がどこにあるかを述べている。一つの省庁が公表した標準であり、他の場所での実務を測ったものではない。

失敗、撤回、規制、あるいは費用が導入を抑えている。判断を下げる、あるいはその不確かさを広げることがある。

大規模なオープンソースのコンパイラプロジェクト一つで、その貢献者を拘束する。このポリシーは、good first issue とラベル付けされた GitHub の課題を修正するためにAIツールを使ってはならないと定めている。その理由として、こうした課題は一般に緊急ではなく、新規貢献者の学習機会となることを意図しているからだとする。また、メンテナーからのフィードバックを LLM に渡しても誰の成長にもつながらず、新規貢献者からの変更をレビューすることは次世代の貢献者を育てることの一部であると述べている。この条項はポリシーの初版とともに導入され、2026年1月16日にコミットされた。その後の編集でも変更されていない。これは一つのプロジェクトの規則であり、雇用主の規則ではない。

失敗、撤回、規制、あるいは費用が導入を抑えている。判断を下げる、あるいはその不確かさを広げることがある。

大規模な Linux ディストリビューション一つで、その貢献者とレビュアーを拘束する。このポリシーでは MUST と MUST NOT が標準的な仕様上の意味を持つ。ポリシーは、貢献に関する実質的または主観的な判断を下す際に、AIを唯一または最終の判定者として使ってはならないと定め、貢献を受け入れることの最終的な責任は、たとえ自動化されたシステムによって実行される場合でも、常にその行為を承認する人間の貢献者にあるとしている。客観的な技術的検証のための自動チェックは認めている。バージョン1.0であり、ページ自身の記載では最終レビューは2025年10月24日である。

失敗、撤回、規制、あるいは費用が導入を抑えている。判断を下げる、あるいはその不確かさを広げることがある。

大きく成熟した、自分がよく知るリポジトリ(それぞれおよそ5年)の保守者が対象である。道具は主に Cursor Pro と Claude 3.5/3.7 Sonnet。著者は、この結果が大半の開発者や、新規案件、若手の仕事に一般化できるとは明示的に主張していない。

失敗、撤回、規制、あるいは費用が導入を抑えている。判断を下げる、あるいはその不確かさを広げることがある。

177 か国から 49,009 件の回答、収集期間は 2025年5月29日から6月23日。自己選択の標本である:回答者は Stack Overflow 自身のチャネルで募られているので、これが測っているのは「Stack Overflow に答える人たち」であって、開発者の無作為標本ではない。この記録は「コードを書く」ではなく「機械が書いたものをレビューする」に結びつけてある。測られているのは量を押し上げている当のものと、それに対する検証の反応であって、誰が何を書いたかではないからである。どちらの半分もここに属する:84% が AI ツールを使っている、あるいは使う予定であり(一年前は 76%)、職業開発者の 51% が毎日使っている。その一方で好意的な受け止めは 2023年・2024年の 70% 超から 60% へ下がり、AI ツールの正確さを積極的に信頼しない開発者(46%)が信頼する開発者(33%)を上回り、経験の長い層は「強く信頼する」が 2.6% と最も低く、「強く信頼しない」が 20% と最も高い。ここでは利害が両方向に働いており、そのことは述べておく価値がある:AI のコーディング支援が奪うのは Stack Overflow 自身のトラフィックなので、「広く使われている」という結果は同社の商業的利益に反し、「信頼が下がっている」という結果はそれに沿う。調査は、それらのツールが何に使われたか、どれかのレビューが長くかかったか、出荷されたコードの何が変わったかについては述べていない。

ある道具が実際の仕事のために大規模に使われていることが測定されており、しかも使うと決めたのが雇用主ではなく働き手である場合。capability の記録より重い——仕事が実演ではなく本物だからである——そして deployment の記録より軽い。どの雇用主もそれを本番に置いておらず、求めてもおらず、その周りに工程も作っていないからである。重みは `cautious` である——`automating` とは、機械がその業務をできることと、採用の兆しがあることの両方を意味し、これは採用の兆しである——しかし利用は試験的でありうるし、測定の多くは利害のある側から来るので、一件では決して足りず、独立した二件で足りる。誰が数えているかに注意すること。ベンダーの計測データはこれを直に見るが、その道具を売っているので、そうした記録は適用範囲にその利害を明記する。統計機関が企業に「働き手は業務でAIを使っているか」を尋ねる場合、同じ経路を何の利害もなく見ており、それが存在するならそちらが良い出典である。

一つの政府のなかの一つの機関部門（ICE）であり、しかも公表用に選ばれたのではなく、法定義務のもとで当の機関自身が報告したものである ── この目録の地味な項目が読む価値を持つのはそこである。個別報告のCSVの項目番号 DHS-2758。これが立てているのは導入と、それに付いた条件であって、どれだけ使われているかではない：目録には利用量の数字も、人数も、機関自身が「開発者の生産性を高める」と述べる以上の生産性の主張も載っていない。二つの業務それぞれを支えているのは、機関自身の言葉による別々の二文である：出力は「既存のバージョン管理およびデプロイのプロセスを通じてコードベースに組み込まれる前に、レビューと承認を経なければならない」（レビューの業務）、そして「これらのツールは本番システムを直接変更しない。すべての変更は標準の人によるレビュー、テスト、承認のワークフローを通らなければならない」（エージェントが無人で何をしてよいかを定める業務）。名指しされているツールはベンダーからの購入であり、それは知っておく価値があるが、ここで報告している当事者はベンダーではなく機関である。同じ目録には同じ省からの反対シグナルも載っている：項目 DHS-373「商用生成AIによるコード生成」の開発段階は「廃止」である。その行には日付も理由もないので、立てているのは「国土安全保障省がそのような用途を挙げていて、いまはもう動かしていない」ということだけである。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

あなたはまだこのページの人ではないし、ここへ至る道こそが圧力を受けているものである——先に若手のページを読むこと。ここで最も大事なのは、この職業が売っている能力が、ある特定の系についての判断だということであり、それは良い道具を使うことではなく、その系の内側にいることで身につく、ということである。

このページで測られた発見は、自分のコードベースの上ではその道具があなたを速くしなかったこと、そしてあなたはそう思っていなかったかもしれないことである。それを安心ではなく、自分の仕事を自分で測る理由として扱うこと。試験は小さく、一年前のものである。そして伸びているのは打鍵ではない——届いたものをレビューすること、そして自律的な仕組みに何を許したかに答えることである。

留まって強くする

否と言うことを信じてもらえる人になる

生成された変更が増えるほど、詰まりどころは、通る理由を添えてそれを断れる人へ移る。その権限は、特定の系について、人前で、繰り返し正しくあることで手に入る。

職の形を組み替える

自律的な仕組みに何を許すかを引き受ける

自動の変更が何に触れてよいか、どこから入ってよいかを、誰かが決めなければならない。大半のチームでそれは誰にも与えられておらず、だからこそ職務記述書ではなく事故の報告書のなかに現れる。

隣へ移る

正しさが法によって高くつく場所へ移る

決済、安全が絡む系、規制のかかったデータ——監督のない変更が許されていない場所であり、だからレビューと責任は、当然のものとして期待されるのではなく、費用がついている。

業種をまたぐ

問題の側へ移る

ソリューションエンジニアリング、技術寄りのプロダクト、開発者体験——系のしくみと、誰かがそこに何を求めているかの両方を分かっていることが価値になり、しかも書くことがもともと希少ではなかった職である。

このサイトが持っている唯一の無作為化試験は逆の結果を出しており、持っておくべき細部は、測定と実感のあいだの隔たりである。自分が知っているリポジトリの実際の課題に取り組んだ、経験のあるオープンソースの保守者16人は、2025年当時の道具を使ったとき19%長くかかり、自分では20%速かったと見積もっていた。著者は、これが大半の開発者や新規案件を描いたものだとは主張していないし、一年前のものである。それでも示されているのは、成熟したコードベースの上では速くなることが自動ではないこと、そして自分に訊いても決着しないことである。

それを数字で答えられる人はいないし、両方の側の自信たっぷりの答えは、どれも何かを売っている。より役に立つ問いは「仕事のどの部分か」である。部分ごとに速さが違うからである——定型的なコードを書くことはすでに大半が機械の手にあり、それが出したものをレビューすることは独立した仕事に育ち、既知の危険を承知で何を出すかを決めることは、能力ではなく責任なので動いていない。代わりに、自分で確かめられる信号を見ること——いま一週間のどれだけが、自分の書いていないコードを読むことに使われているか。

より安全なのではなく、さらされ方が違うのであり、その二つはつながっている。シニアを育てなくなった職業が抱えるのは、今の安全の保証ではなく、後になって表れる供給の問題である。下から入ってくる人が減れば、かつてチーム全体に分散していた教える仕事は、より少ない人に降りかかる。この道を意図的に守っている技術コミュニティもある。LLVM は good first issue のラベルが付いた課題でのAIツールの使用を禁じ、新しい貢献者がそこで学べるようにしている。

いまのところ、これに証拠で答えられる人はいない。そして、そのことを言うほうが、ひとつ当てずっぽうを出すよりも役に立つ。この三つの晒され方は実際に違うが、存在する研究はもともと技術の積み重ねではなく経験年数を比べるように設計されており、三つを分ける材料がそもそもない。フロントエンドとバックエンドに優劣をつける自信ありげな話は、どれも誰かの印象だと思っておくとよい。証拠が支えるのは別の選び方——自分の領域で「間違えたときにどれだけ高くつくか」で選ぶことであり、これは三つのどれにも横断的にかかる。

自分が書いていないコードをレビューすること、そしてなぜ突き返したのかを言えることである。この技能はもともとこの職のなかにありながら、誰かがそれで採用されたり評価されたりするものではなかった。それがいま詰まりどころになっている。生成が、仕事を産むことから判断することへ移したからである。そしてそれは、否と言うことを信じてもらえる人になるための能力でもあり、この職のなかで、代わりの見当たらない部分である。