Greg Wilsonは、多くの人々がAIツールの費用対効果を判断するために不適切な指標を使っていることに気づいた。

生成されたコード行数やクローズされたチケットで測定しますか?それとも、開発者がより生産的だと感じるかどうかを尋ねる調査を行いますか?これらのアプローチはそれぞれ異なる方法で欠陥があります。

彼は多くの一般的な指標とそれらがなぜ欠陥があるのかを列挙している。残念ながら、彼はより良い代替案を提示していない。私の見解では、生産性を測定できない以上、いかなる指標もせいぜい弱い証拠に過ぎない。

私は彼の欠陥のある尺度の1つをある程度使用している:「開発者に生産性向上を感じるかどうかを尋ねる」。この尺度の問題点は認めつつ、適切な指標を見つけるのが難しい環境では、たとえ薄明かりでも最善の手段だと考えている。この状況では、この種の質的指標は決定的なものではないかもしれないが、有用である

 ❄                ❄                ❄                ❄                ❄

Benedict Evansは、過去に大規模な自動化が職業の消滅を意味しなかったことを指摘している。

私たちは1世紀にわたって会計業務を自動化してきました。計算機、パンチカード、メインフレーム、データ処理、データベース、PC、スプレッドシート、ERP、クラウドを構築しました。実際、この自動化のためにテクノロジー産業の半分を構築したのです。それでも会計士の数は増加し続けました。

彼は、技術が雇用に与える影響を予測しようとする際に生じる数多くの問題について論じている。よく話題に上るジェボンズのパラドックスがある。あるものが安価になると、人々はそれをより多く行うようになり、需要が増加する可能性がある。多くの場合、たとえ同じ名称であっても、仕事の内容が変わることになる。

今日の会計士は1970年や1980年にしていたのと全く同じ仕事を「もっと」しているわけではありません。彼らは依然として「会計士」と呼ばれていますが、仕事の内容は異なっています。新技術は当初「古いことをもっと」という形で使われがちですが、最終的にはそうならないことがほとんどです。

技術はしばしばビジネス全体に影響を及ぼす。ニュース出版に対するインターネットの影響を考えてみよう。2000年代初頭のスマートフォンの台頭を観察していた人々は、それがライドシェアリングアプリの台頭によりタクシーの経済性を変えることになると予測できただろうか。結論として、AIが私たちの仕事に与える影響を予測することは、少なくともほぼ不可能である。

 ❄                ❄                ❄                ❄                ❄

Stephen O’Gradyは、クローズドモデルとオープンモデルがベンチマークでどのように推移してきたかを検証している。

クローズドモデルはイノベーションのペースを主導し、能力面で絶えず新境地を切り開いています。オープンモデルはそれらを追いかけており、サイクルタイムは短くなっているようです。明確な能力上の護城河は存在せず、今日のフロンティアは明日には最低限の要件となります。

これらのベンチマークでオープンモデルがGPT-4に追いつくまでには13〜18ヶ月かかりましたが、GPT-4oに追いつくにはわずか2〜7ヶ月しかかかりませんでした。

この分析にはいくつかの注意点があり、彼はそれを列挙しているが、さまざまな種類のモデルが私たちが評価しようとしているさまざまな指標に対してどのように機能するかの価値ある調査である。

 ❄                ❄                ❄                ❄                ❄

AIのずさんな使用の最も顕著な例の1つは幻覚引用であり、これはLLMの使用とそれらを駆動する不注意の両方の証拠となる。GPTZeroはAIによる執筆を検出するツールを作成する企業である。彼らのツールが効果的かどうかはわからないが、AIの使用に関する調査を公表しており、幻覚引用を強調した複数の記事を発表している。ある記事はErnst & Young Canadaのロイヤリティシステムに対するサイバー脅威に関する報告書に焦点を当て、参考文献の半分以上が幻覚であることを発見した。この記事は情報を提示する方法に非常に煩わしいアニメーションを多用しており(Safariのリーダーモードを破壊するほど)、しかしこの種のAI生成レポートが引き起こす害は、誤解を招かれた人間だけにとどまらない。

レポートをオンラインで公開することは、本質的にインターネットという知識のプールへのデータ注入の一形態です。レポートに偽の情報(幻覚引用や虚偽の主張)が含まれている場合、特に著名なコンサルティング会社によって公開され、トラフィックの多いウェブサイトにホストされている場合、将来の研究者を誤った方向に導くことで「井戸を毒する」可能性があります。

 ❄                ❄                ❄                ❄                ❄

LLMがプログラミングでより能力を増すにつれ、人々がそれらを使ってソフトウェアシステムを攻撃することを懸念するのは当然である。しかし、これらのモデルは防御にも利用でき、チームが攻撃者よりも先にバグを発見することを可能にする。Mozillaの何人かの人々が、AIモデルを使ってFirefoxの潜在的なセキュリティバグを前例のない数特定・修正した方法についての記事を投稿した。

数ヶ月前、オープンソースプロジェクトへのAI生成セキュリティバグレポートは、主に不要なゴミとして知られていました。もっともらしく正しそうに見えるが実際には誤っているレポートに対応することは、プロジェクトのメンテナに非対称なコストを課します。LLMにコード内の「問題」を見つけるよう促すのは安価で簡単ですが、それに対応するのは遅くて高価です。

このダイナミクスがわずか数ヶ月の間にどれだけ変わったかを過大評価することは困難です。これは主に2つの要因によるものです。第一に、モデルの能力が大幅に向上したこと。第二に、これらのモデルを活用する技術を劇的に改善したこと——モデルを操り、スケールさせ、積み重ねて大量のシグナルを生成しノイズを除去することです。

2025年の間、毎月17〜31件のセキュリティバグが修正されていました。2026年4月には423件を修正しました。

 ❄                ❄                ❄                ❄                ❄

Pavel Voroninは、Unmesh Joshiの「コードとは何か」に関する投稿について考察している。彼は、コードベースの腐敗(技術的負債)が常にソフトウェア開発に摩擦を加えてきたことを指摘する。しかし、この腐敗の結果は、LLMが既存のコードを将来の作業の文脈として使用する際に増幅される。

劣化したコードベースでは、モデルは「技術的負債」を負債として見ません。例として見ます。先例として見ます。継続すべきスタイルとして見ます。

LLMは現在起こっていることを増幅する。優れたコードはマークダウンに書かれるものの多くに取って代わるかもしれないという報告を耳にする。なぜならLLMはコードベースにすでに存在するものを模倣するからだ。しかし、悪いコードもまた増幅される。彼は必然的に、負債の比喩の別のバリエーションを導入する。

認知負債は、チームがもはや理解していない抽象化を使用するときに蓄積されます。生成負債は、モデルが継続しそうになる混乱した概念がコードベースに含まれているときに蓄積されます。

認知負債はチームがもはや理解していないことに関するものです。生成負債はモデルが今後再現しそうになることに関するものです。

 ❄                ❄                ❄                ❄                ❄

価値あるメディアである404 MediaのJason Koeblerは、AI生成のゴミが私たちを狂わせていることについて悲痛なエッセイを書いた。ウェブをこのゴミで埋め尽くしているからだけではなく、私たち人間がゴミやゴミの脅威に対してどのように反応するようになっているかによる。私たちは自分の文章を振り返り、気づく。AIのゴミを読むことが私たちを傷つけるだけでなく、AIのゴミのように見えるものを書くリスクもある。AIが私からコピーした言い回しを使うと、私がAIをコピーしているように見えるだろうか。これは「ヒューマナイザー」の出現につながった——私たちの文章をAIらしくなく見せるAIツールである。

ヒューマナイザーはタイポを追加し、ランダムに単語を置き換え、「AIの特徴」を削除し、時にはランダムな文字を挿入します。

それはゾンビインターネットへのさらなる一歩である。

私がそれをゾンビインターネットと呼んだのは、インターネットの大部分がボット同士の会話やボットと人間の会話だけではないという事実 때문です。それは人間がボットと話すこと、人間同士が話すこと、人間が「AIエージェント」を作成し、それらに人間と対話するよう指示することです。[...] それは私のメールの受信トレイです。以前はCIAが秘密の技術を使って仮想の拷問室に監禁していると確信している妄想的な人々から、書式が悪く、文章も稚拙で、非常に長いメールが時折届いていました。しかし今は、AIの意識を証明したと確信し、それを証明するAIのトランスクリプトを持っているという、書式が整っていて、なんとか読める、非常に長いメールが、妄想的な人々から届くようになりました。

 ❄                ❄                ❄                ❄                ❄

Andy Osmaniは、多くのエージェントを生成することは、すべてが単一の調整スレッド——あなた自身——に依存する並列プロセスを起動することに似ていると指摘する。

Pythonにはグローバルインタープリターロック(GIL)があります。好きなだけスレッドを生成できますが、ロックを取得する必要があるため、一度に1つのスレッドしかPythonのバイトコードを実行できません。あなたはAIエージェントのGILです。それらはすべて同時に実行できます。しかし、それらの作業のいずれかがアーキテクチャの真の理解やマージコンフリクトの解決を必要とするとき、その作業はロックを取得する必要があります。ロックは1つだけです。あなたがそれを持っています。

これは、エージェントとのワークフローをそのGILを念頭に置いて設計しなければならないことを意味する。適切にレビューできる数を超えるエージェントを起動すべきではありません。エージェントにオフロードできるバックグラウンドタスクと、注意を要する複雑なタスクを分離すると便利です。その貴重な脳を、機械が自分で検証できることに使ってはいけません。[そして付け加えれば——人間の検証を容易にするツールを機械に構築させるべきです。例えば、アサーション文に埋もれさせるのではなく、テーブルでテストケースデータを表示する方が良いでしょう。]

エージェントを生成することはスキルではありません。誰でも20個実行できます。

本当のスキルは、クローン化も並列化もできない唯一のシリアルリソースを中心にシステムを設計することです。そのリソースはあなたの注意です。

 ❄                ❄                ❄                ❄                ❄

Jamie Hurstはbooking.comのプリンシパルエンジニアで、AIツールに焦点を当てた開発者エクスペリエンスの分野で働いている。彼はこの仕事でLLMを使用する利点と損失について現実的に書いている。

構築のコストは崩壊しましたが、組織的に整合させるコストは低下していません。むしろ上昇しています。3つの異なるチームが以前は提案書を書くのにかかっていた時間で同じ問題に対する動作するソリューションをそれぞれ作成できる場合、ボトルネックはエンジニアリングから調整に移ります。

彼はシニアエンジニアとしてより多くのことを行えると考えているが、それが持続可能かどうか——彼自身と彼が働く組織の両方にとって——懸念している。彼は3年前にはできなかった方法で、複数のワークストリームの方向性を同時に形作ることができる。しかし、1つの損失は、メンターシップに十分な時間がないことであり、これは長期的に雇用主に代償を強いることになる。また、考える時間が十分にないことにも気づいている。

AIによる生産性向上は、出力の質ではなく出力の量によって獲得されました。組織の期待はスピードアップを吸収するまで上昇し、タスク間の余裕——戦略的思考が実際に起こる非構造化時間——は、ダッシュボード上では見えないため最初に食い尽くされました。私はキャリアの中で、思考が仕事の大部分を占めるべき段階にあり、そのほとんどが今や休暇中に起こっています。なぜなら、労働週がそれを収容できないからです。