AIを用いた自律的コーディングツールの普及により、開発者の生産性は劇的に向上した一方で、スキルの低下や認知負債の増大といった新たな問題が浮上している。本動画では、外部記事の考察を交えながら、AIツールに依存しすぎることの危険性と、技術の仕組みを深く理解することの重要性について解説する。プログラミングにおけるAIの正しい活用法と、これからのエンジニアに求められる姿勢を問う内容である。
AIコーディングの台頭と罠
AIによるコーディングはすでに現実のものとなり、これからも定着していくでしょう。その生産性の向上を目にしていない人はいないはずです。企業のCEOが毎日3万7000行ものコードを書いているという話すらあります。開発者としての私たちの人生に、これ以上の何があるというのでしょうか。これほどの量のコードを生み出せるなら、他のことをする必要があるのでしょうか。でも、これが将来自分たちの首を絞めることには絶対に終わらないですよね。スロットマシンへの依存度が高まるにつれてスキルをすべて失い、その結果スロットマシンはただのスロットマシンになってしまい、何も本来の動作をしなくなるなんてことはないですよね。現在進行形でそんなことは起きていないし、誰もそれに気づき始めてなんていないですよね。
ええ、エージェントによるコーディングは罠です。今回はとても興味深い記事になりそうです。ご想像の通り、これについては私にもたくさんの考えがあります。一方で、私はコーディングが大好きです。物を作るのが好きですし、構文の細かい部分にもこだわります。自分の特定の技術的な好みをベースにしてスタック全体を構築し、それが大きな反響を呼んで、このようなプラットフォームで私のキャリア全体を築く助けにもなりました。その一方で、私はこれらのAIコーディングツールをとても楽しんでもいます。あまりに好きすぎて、技術や自分が構築するものに対する考え方が根本的に変わってしまったほどです。そして、実際にコードを書くことに費やす時間がこれほど少なくなったことはありません。実際、今コードエディタを開いても、中のコードすら見ていません。プロンプトファイルを見て、現在エージェントで実行しているすべてのデータのCSVをたくさん見ているだけです。もうコードなんてほとんど見ていません。
代わりに増えた作業もあって、それはそれで面白いです。例えば、人生でこれほどGitが上手くなったことはありません。SSHやリモートボックスを今ほど使ったこともありません。あらゆる種類の新しいことを試しています。新しい技術をいろいろ学んではいますが、同時に自分のスキルの一部が衰退しているのを感じることもあります。そして何かがうまくいかないと、今度こそ求めている出力が得られるかもしれないと期待して、ただスロットを何度も回している自分に気づくのです。そのレバーを引くのにはたくさんのお金がかかります。何が得られるかは決してわかりませんが、少なくともスポンサーの休憩で何が得られるかはわかっていますよね。
スポンサーメッセージ：Browserbase
あなたはエージェントがどんなツール呼び出しを行っているかに注意を払うタイプですか。私はそうです。そして、彼らが頻繁に行うあることに気づきました。それはcurlです。ウェブページやドキュメントなどの情報を取得するためにエージェントがcurl呼び出しを行う頻度は、正直なところちょっと笑えるくらいです。特に、それが失敗する頻度が高いからです。なぜなら、curl経由でアクセスした場合、ウェブの多くは実際のコンテンツで応答しないことがわかったからです。コンテンツを読み込むためにJavaScriptが必要な空のHTMLページであれ、キャプチャやファイアウォール、あるいは何らかのレイヤーの背後に隠されているものであれ、エージェントがcurlだけに頼っていると苦労する可能性が高いです。そのような場合でも失敗しないように、curlリクエストを何らかの形でラップできたら本当に素晴らしいですよね。ああ、もう画面に出ていますよね。はい。
今日のスポンサーはBrowserbaseです。彼らは新しいfetch機能を追加し、あらゆるウェブサイトから実際のコンテンツを取得するのをこれまで以上に簡単にしました。HTML、JSON、あるいはマークダウンとして取得したい場合でも、彼らがすべて処理してくれます。目的のサイトに直接curlを実行する代わりに、彼らのAPIエンドポイントにPOSTリクエストを行います。目的のURLを含む本文を渡し、あとはAPIキーさえあれば、エージェントはそのサイトを確実にスキャンして、あなたの欲しいものを取得できるようになります。実行にJavaScriptが必要なページでも、Browserbaseはクラウド上で実際のブラウザを立ち上げることができるため、問題ありません。それが彼らの存在意義であり、名前の由来でもあります。彼らは、エージェントがウェブ上で実際の作業を行うための実際のブラウザを提供します。ボタンのクリック、サインイン、情報の取得、JavaScriptの実行など、あらゆることに対応しています。
でも、皆さんには正直に言いますが、クラウドブラウザがあまり得意ではないユースケースもいくつかありました。例えば検索です。ああ、また画面に出てしまいましたね。これ、やめないといけません。検索機能も本当に素晴らしいんです。エージェントが検索を行い、自分自身のブロックを解除するために必要なコンテキストを取得する実際の方法を追加できることは信じられないほど素晴らしいですし、だからこそ多くの企業がその機能のために彼らを頼りにしています。ですので、もしあなたのエージェントが、より良い検索、より良いフェッチ、より良いcurl、あるいは実際のブラウザを通じたウェブへのより良いアクセスを必要としているなら、Browserbase以上のものはありません。
認知負債とスキルの衰退
さて、話を戻しましょう。ラース・フェイが書いたエージェントコーディングは罠だという記事です。実はこれ、とても楽しみにしているんです。私が信頼している複数の人から、この記事を見てほしいと送られてきました。まだ読んでいないので、皆さんと一緒に読み進めていき、何か面白いことを付け加えられたらと思います。
認知負債と衰退に対する警戒を怠らないこと。ここでの視点が技術的負債ではなく認知負債であることは興味深いですね。すでにこの記事をとても気に入るだろうという予感がしています。なぜなら、私個人的に、技術的負債はAIで対処するのに最もクールなものの一つだと気づいたからです。コードベース全体で新しいlintルールを機能させたり、5000箇所で使われている定義を壊したパッケージを更新したりするような面倒なタスクに、モデルがいかに喜んで取り組んでくれるかは、実はちょっと驚くべきことなんです。私はこれまでの人生で、あまりにも多くの力技と人力を必要とするため、割に合わないようなクレイジーな技術的負債の解消作業をやってきました。
Twitchでのある時のことを今でも鮮明に覚えています。GraphQLレイヤーの移行作業をしていて、確か8000個くらいのTypeScriptファイルが壊れてしまったんです。そこで私たちは、壊れたファイルをすべてGoogleスプレッドシートにまとめ、別のエンジニアたちにチャンクを割り当てて、共有ブランチ上で手動で更新していき、すべてを最新の状態にしようとしました。そういった作業は、以前は手作業でやっていて、修正プロセスに人手がかかりすぎて割に合わないため、そのまま放置され、技術的負債としてただそこに存在し続けることがよくありました。AIはそういったことに驚くほど優れています。ですから、AIが技術的負債を引き起こすといった主張を見るたびに、私はイライラします。なぜなら、AIは潜在的に引き起こす可能性のある同じ技術的負債の多くを解決してくれるからです。しかし、認知負債はずっとずっと興味深いアイデアです。それでは、ラースが何と言っているか見てみましょう。
彼はある引用から始めています。AIがコーディングを行い、ループ内の人間はオーケストレーターである。これが現在業界全体で誇大に宣伝されている感情です。従来のコーディングはほぼ死滅しました。インスペクト駆動開発が未来です。さて、私たちがまだほとんど始めていないのに彼がすでにインスペクト駆動開発について文句を言っているなら、私たちは本当に意見が合うと思います。やれやれ。
あなたは計画を立て、コードを書くことから離れます。エージェントはよりよく知っていて、すべての実装を処理してくれます。あなたは専門家としてそこにおり、良いセンスを提供し、出力をレビューし、細心の注意を払ってまとめた計画をエージェントが実行するように常に方向付けます。皆さんはこれらの計画をどれほど細心の注意を払って書き出しているのでしょうか。なぜなら、私は信じていないからです。後でエージェントが実行されるのを監視していないのであれば、あなた方の誰も実際には計画にそれほどの労力を費やしていないと私は思っています。
ええ、ここでの専門家ということについては別の角度から話すこともできます。もう少し読んでからにしたいので、まだ深くは入りませんが、すでにたくさんの考えがあります。現時点ではワークフローには多くの形がありますが、一般的には、ミクロとマクロのレベルで同時にプロジェクトの要件を定義するプロセスです。ここの指摘は非常に良いですね。彼らは計画を立て、スロットマシンのレバーを何度も引き、多くの場合複数のエージェントインスタンスを使って、完了するまでイテレーションを繰り返します。その間ずっと、オーケストレーターと実際に生成されコミットされるコードとの間の距離は広がり続けています。
コーディングエージェントは役に立ち強力ですが、すでに議論する必要のある定量化可能なトレードオフがいくつかあります。まず第一に、AIの非決定性による曖昧さの増大を軽減するために、周囲のシステムの複雑さが増加していること。これは非常に現実的な問題です。第二に、幅広い人々の間でスキルが衰退していること。これは私にも間違いなく見え始めています。第三に、個人およびチーム全体のベンダーロックイン。クラウドコードの障害によって、すでにチーム全体が立ち往生したことがあります。ええ。そして、ツールへのアクセスにかかるコストの変動と増加。従業員のコストは固定されていますが、トークンは常に動く標的です。
トークンコストとAIの進化
ええ、需要が高まることでコストが増加し、少し私たちの頭がおかしくなっているとは思います。しかし、長期的に見てエージェント作業のコストが上がり続けるとは思いません。人々がAIでより多くのことを行い、より多くのトークンを使用するようになるとは思いますが、特定のレベルにおける知能のコストは継続的に下がっています。フラッシュバンの警告です。新しいGPTモデルはトークンあたりのコストが高いため、私はこのことについてよく話します。つまり、古いモデルと新しいモデルの間で同じ作業となる特定の入力と出力を測定した場合、GPT-5.5は2倍高価になります。入力トークンと出力トークンのコストが2倍になるのです。
しかし、知能のレベルと生成されたトークンの数で比較すると、事態はずっと興味深いものになります。GPT-5.5は人工的な分析で最もスコアの高いモデルです。60点ですが、前世代のOpus 4.7、Gemini 3.1 Pro、GPT-5.4はわずか57点でした。意味のある改善ですが、これにもう一つ付け加えます。GPT-5.5 LowとGPT-5.5 Mediumです。ここがとても興味深いところです。GPT-5.5 MediumのスコアはGPT-5.4x Highと同じです。そしてGPT-5.5 Lowも依然として非常に良いスコアを出しており、Claude Sonnet 4.6に匹敵します。
しかし、コスト効率に話を戻すと、これはベンチマークスイート全体を実行するために人工的な分析が支払った、あるいは無料で提供されなければ支払っていたであろうコストです。Opus 4.7はGPT-5.5よりも賢くないにもかかわらず、5000ドルと群を抜いて最も高価です。しかし覚えておいてください、GPT-5.5 MediumとGPT-5.4x Highは同じレベルの知能です。GPT-5.4x Highはこのベンチマークを実行するのに2800ドルかかりました。GPT-5.5 Mediumは1200ドル未満です。つまり、そのレベルの知能で十分であれば、コストは半分以下に削減されたことになります。以前と同じタスクを実行するのに、今では50パーセント未満のコストで済むのです。これは非常に、非常に意味のある変化です。
確かに、世界で最も優れたモデルは2800ドルから3300ドルへとわずかに高くなりましたが、2ヶ月前に登場して私たちが完全に満足していた以前と同じレベルの知能が、今では半額以下になっています。そして、少しだけ賢さが下がっても構わないのであれば、それほど賢さが下がるわけでもなく、Sonnetレベルであれば、価格はなんと500ドルまで下がります。さらに価格が半分になるのです。そして、このモデルGPT-5.5 Lowは、4200ドルで2番目に高価なモデルであるSonnet 4.6 Maxと同じくらい賢いのです。このモデルもごく最近出たばかりです。ですから繰り返しますが、これを1ドルあたりの知能レベルに基づいて見ると、ここでのIQポイントあたりのコストはわずか数ヶ月で8分の1に低下しています。Sonnet 4.6は今年初めに登場し、このベンチマークを実行するのに4200ドルかかり、ベンチマークで51点でした。私が思うに、はるかに賢く、一緒に働きやすいモデルであるGPT-5.5 Lowは、同じレベルの知能で価格は8分の1です。
ですから、私はこの点に飛びつきたかったのです。なぜなら、毎月同じことをすれば数字が上がるという意味でコストが増加しているというのには必ずしも同意しないからです。私たちがトークンでより多くのことを行っているということです。つまり、私たちが使用しているトークンの量は増えていますが、1ドルあたりでより多くの知能を得る方法も見つけているのです。したがって、タスクあたりのコストと知能レベルあたりのコストは下がっています。ですから、私たちはそれらの違いについて現実的になる必要があります。
だからといって、企業がここで少しひどい目に遭っていないわけではありません。なぜなら彼らは多くの開発者を雇い、彼らに給料を支払っているからです。例えば、ある企業が昨年開発者に年間500万ドルを支払い、Cursorに10万ドルを支払ったとします。今年はわずか数ヶ月でCursorにすでに50万ドルを支払っています。それは彼らが負担している正当なコストであり、最悪です。ですから、請求書上は価格が上がっているように見えますが、実際に物事がどのように変化し改善しているかという指標で見れば、そうではありません。単に私たちがAIをより多く使っているだけです。これ以外の部分についてはほぼすべて同意できるので、その点にだけ触れておきたかったのです。
認知負債とアーキテクチャの理解
コーディングエージェントへのこのアプローチで成功するかどうかは、かなり重要な要素にかかっています。批判的に思考し、アーキテクチャレベルで快適に操作できる熟練した開発者だけが、問題になる前に生成された何千行ものコードの中の問題を見つけることができます。しかし、皮肉な運命のいたずらで、AIツールが現在悪影響を与えていることが証明されているのは、個人の批判的思考スキルと認知的明晰さなのです。これはすべて認知負債という言葉をめぐるもので、これは本当に良い表現です。
サイモン・ウィリスやマーティン・ファウラーのような多くの関連する人々が、認知負債の経験を直接的に説明しています。彼らは自分自身のプロジェクトで迷子になり、自信を持って新しい機能を追加するのが難しくなっていると話しています。より速く動くことはできますが、決定を意図に、そして意図をコードに結びつける深い意味形成を失ってしまうのです。これに対する私の率直な意見は、もしすでにその一部を経験していなかったとしたら、あなたの開発のスピードが十分ではなかったということです。私はこれまでに、1ヶ月間本当に一生懸命取り組み、かなり良い状態になり、その後別のことをしなければならなくなり、戻ってきたときにはもう何がどうなっているのかさっぱりわからなくなっていたプロジェクトがどれほどあったか数え切れません。人が十分に多くの異なることをしている場合、これは本質的に人間の働き方なのです。すべてのもののコンテキストの詳細をすべて頭の中に入れておくことはできません。
私がここで認識している問題は、AIのおかげでより多くの人が私のようになってしまったということです。私はAIが登場する前、年に5つ以上のプロジェクトをリリースしていました。物を作り、それを人々に提供することがただ好きだったからです。それには、伝統的な意味での専門知識というわけではありませんでしたが、私が物事を構築する方法、物事について考える方法、そして成果物として使用可能なバージョンを可能な限り効率的に得るためにプロジェクトの範囲をどのように削るかという、私のやり方がありました。
一体全体、これが私がT3スタックを作った理由です。すべての部品を完全に理解しなくても、確実に機能するものを自信を持って迅速に構築しやすくしたかったのです。私はある意味、初期のバイブコーダーでした。コードをすべて書くためにAIを使っていたからではなく、それが機能した瞬間に次のことに移り、自分がさっき何をしたかを忘れてしまっていたからです。コードの巨大なチャンクを手当たり次第に削除し、数千のものを更新するためのコード修正を書き、それが機能することを願い、最後にビルドが正しく出力されるかどうかを確認するだけでした。私はキャリア全体を通じて、自分の専門知識のレベルにしては多すぎるコード行をスリングしてきました。そして、私がここ10年ほど抱えてきた問題を、他の皆さんが抱えるのを見るのは面白いものです。特に、コードベースのどこに何があるかを覚えたり、コードをレビューするときに物事が実際に正しい方向に変化していると確信を持ったりすることに関してです。
また、多くの人が反論するでしょうが、両方の立場は理解できます。これを行う私の能力は斬新であり、潜在的に例外的であったと私は主張します。もうそうではありませんが。チームで私を特別な存在にしていたのは、以前は不可能に思えた障害を取り除き、物事を進め、期限を守ることができたからです。私は仕事での交渉のカードのようなものでした。他のチームが不満を言っている問題のブロックを解除するために私を彼らに貸し出すよう、私のチームが他のチームと交渉し、その代わりとして私たちがやらなければならないことのブロックを解除してもらうのです。物事をより速く進めるために私がトレードに出されるのはごく普通のことでした。
今では、プロンプトを使ってそれを乗り越えることができます。問題は、私がそこに到達するために努力しなければならなかったということです。私が専門家であったかどうか、だからこれができたのかどうかは議論の余地があります。しかし、私がこれができることが斬新なことであったという事実は議論の余地がありません。それは私が非常に良い給与を受け取り、本当に良いキャリアを築くのに十分斬新でした。なぜなら私は多くのことの間を飛び回ることができ、これらすべての異なることの間を行き来する認知負荷と認知的シフトに対処できたからです。今では誰もがそれをやっており、ほとんどの人はこれに向いていないため、最悪なことになっています。
しかし、これと組み合わさる別の問題があります。私がこれを行うことができた理由は、この方法で構築するために使用した構成要素を深く理解していたからです。それらをどのように組み立てたかは正確には覚えていないかもしれませんが、パズルを組み立てるために使ったピースのことは十分によく知っていたので、ピースに関する自分の知識に基づいて問題が起きた理由を推測することができました。AIは、あなたがそれらのピースについて学ぶインセンティブを失わせます。そしてそれが最大の問題だと思います。
学習の苦痛とAIスロットマシン
人間は痛みにとても敏感です。自分が愚かだと感じるのは痛みを伴います。何かを試して理にかなっていないとき、あなたは痛みを感じます。何かを試して期待通りにいくと、気分が良くなります。AIは、その痛みを避け、その報酬を感じることを容易にしました。かつてはピースを学ぶために支払う必要があった先行投資であり、その後パズルを解くという報酬を得ることができたものが、今ではスロットマシンになっています。そしてあなたの選択肢は、パズルを正しく解けるようにピースを学びに行くか、期待する正しい答えが出るまでスロットマシンを引き続けるかのどちらかです。なぜなら、理解していない言語のドキュメントを読んだり、自分のメンタルモデルと正しく一致しないライブラリを学んだり、絶望的に感じるものをデバッグしたりするよりも、レバーを引く方がずっと痛みが少ないからです。
私はこれをスケートボードから学びました。ほとんどのスケーターが、キックフリップはおろかオーリーを学ぶ前に諦めてしまうのは、とても気分が悪いからです。他の人がいとも簡単にスケートボードに乗り、階段をオーリーで下り、おしゃれなトリックをすべてこなしているのを見て、自分はボードを地面から浮かせることすらできないと感じるのは嫌なものです。そして、少し頑張りすぎてすねを強く打ってしまい、数日間歩くのが不快になったりします。ほとんどの人は、痛みがとても大きく、自分が愚かで無能だという感覚がとても強いため、それを乗り越えたいとは思わず、それらのトリックを学ぶ前に諦めてしまいます。
少なくともコードの世界では、肉体的な痛みはありませんでした。ただ自分が愚かだと感じればよかったのです。そして正直に言うと、私は自分が愚かだと感じるのを少し恋しく思っています。最近はそこまで経験していません。だから、新しいプロジェクトを作るときには、Rustのように知らない言語を意図的に選び、理解できずにそれについて学び始めなければならないような方法をわざと見つけようとしています。しかし、自分が愚かだと感じ始めるたびに、うずうずしてきます。スロットを引きたいという誘惑、今度こそ解決策が生成されて、もうそのことを学ばなくて済むかもしれないという期待を込めて、もう一度実行したいという誘惑を感じます。
そして、他の人々には同じような意志の強さがないのだと思います。それがそれほど例外的なことだとは思いません。以前は必要ですらなかったと思います。しかし、開発者としてノーと言う能力は、今ほど重要なことはありません。そして、自分が愚かだと感じることを厭わず、細部にまで目を通し、AIに助け出させないようにする意志の強さは超能力です。個人的には、このおかげでこれまで学んだ以上に多くのことを学んでいます。AIについて、特にビジネスサイドについてすべて学んでいるからというのもありますが、以前は自分が愚かすぎると感じていたものに、より多くの楽しみを見出しているからでもあります。
例えば、暗号化についてより深く学んでいます。暗号化の課題を作成しているんです。自分にそんなことができるようになるとは思ってもみませんでした。私はいつもそれに魅了されていました。今ではそれをやり、それについて質問し、エージェントとやり取りをしています。最初にAIの回答能力を使い果たすので、それについて友人を煩わせることにそれほど罪悪感を感じなくなり、今ではその分野に深い知識を持つ友人に迷惑をかけるときには、より良い質問ができるようになりました。そしてここには恐怖という側面もあります。後でそれについて話すことになる気がするので、まだ深くは掘り下げません。記事に戻りましょう。すでに喋りすぎになっていますから。
抽象化の罠とAIによるスキルの低下
次のセクションは、単なる別の抽象化ではない、と呼ばれています。コミュニティでよく聞かれるフレーズは、プログラマーは単にスタックを上に移動し、異なる種類の抽象化に入っているだけだというものです。これらのツールがそもそも本当に抽象化レイヤーであるかどうかは、決着のついた問題ではありません。高いレベルの曖昧さは、高いレベルの抽象化ではありません。厳しい言葉ですね。彼がここで言及しているのは、私たちがすでに抽象化を行ってきたという考えです。例えば、昔はパンチカードを使っていましたが、アセンブリ言語ができたことでカードに穴を開ける必要がなくなりました。その後C言語が登場し、書くのがずっと簡単になり、異なるシステム向けにアセンブリコードを生成できるようになりました。それからC++が登場し、以前はC言語で自分で構築しなければならなかったことの多くが含まれるようになりました。その後、コンパイルする必要すらないPythonやJavaScriptのような言語が登場しました。これらは単に仮想レイヤー、つまり他の言語で構築されたランタイム上で実行されました。
私たちは抽象化をどんどん高くしていきました。そして現実を見ましょう。どれだけのJavaScript開発者がアセンブリを読めるでしょうか。いや、本当のところ、現時点でどれだけのJavaScript開発者がJavaScriptすら読めるでしょうか。しかし、意味はわかるでしょう。これらの抽象化は、あなたが下層のレイヤーについて多くを知ることを妨げるでしょう。しかし最高のエンジニアたちは、自分がいる場所の少なくとも1つ上と1つ下のレイヤーを学ぶ強いインセンティブを持っていました。私が知っている最高のC++開発者は皆、JSランタイムであるV8に非常に精通しています。私が知っている最高のJavaScript開発者は皆、V8とその癖に非常に精通しています。中程度の開発者は自分の上と下のものを理解していません。しかし偉大な開発者は、自分が通常いる場所の少なくとも1つ、あるいは2つか3つのレイヤーの上と下にいる傾向があります。
しかし、自然言語はこれらのような別の抽象化の1つなのでしょうか。マークダウンにとってのJavaScriptは、JavaScriptにとってのC++と同じなのでしょうか。以前はそうかもしれないと思っていましたが、今では答えはおそらくノーだと学びつつあります。ラースがこれについて何と言っているか見てみましょう。抽象化の議論を脇に置くとしても、プログラマーが新しい言語や新しいプログラミング方法に慎重になる傾向があるのは事実です。Fortranがリリースされたとき、プログラマーはそれにも懐疑的でした。彼らは同じような主張をしていました。バグや不安定性をより多く導入する可能性が高いと。アセンブリを直接書く方がより効率的だと。後に、コンパイラの統合をめぐる議論があり、プロセスに魔法を導入しすぎていると言われました。これらは、これらの新しい技術が受け入れられた場合、何が失われるかもしれないという恐怖をめぐる規範的な議論でした。今日起こっていることとの違いは、以前のそうした恐怖は推測であり理論的なものであったということです。
AIツールが存在してわずか数年の短い期間で、私たちはすでに重大な影響を目にしています。これらは単なるジュニア開発者だけでなく、10年以上の経験を持つ人々にも当てはまります。ここに彼がRedditから拾ってきた投稿がいくつかあります。
AIのせいでコーディング能力を失っている。皆さんこんにちは。あまり話題に上りませんが、数年コーディングをしてきた後でも、1年以上日常的にAIを使っていると、自分のコーディング能力についてずっと不安を感じるようになりました。コーディングの方法を知る必要がまったくないかもしれないと同時に感じながら、自分のスキルが本当に低下しているように感じます。
AIを使用する必要があるため、自分が愚かになったりスキルを失ったりしていると感じる状況への対処。最近、私の会社はすべてのソフトウェア開発にAIのみを使用することを強制し始めました。それはひどいアイデアですね。コードを消す。この開発者がとても深いところにいるので、コードがCodeXに自動修正されてしまうのが面白いですね。AIがコードを書き、エージェントがコードをレビューする、などです。私たちは結果だけを見てコードを見ないアーキテクトであるべきだということです。背景として、私は9年の経験があります。31歳で、1歳の子供の父親なので、仕事の後のサイドプロジェクトは選択肢にないということに同意してください。すべてを行うためにAIを使うたびに、自分のスキルを失い、より悪い専門家になっているように感じます。特に、新しい仕事に就きたい場合、主に、そしてほとんどが技術的スキルに基づいて評価されるのだからなおさらです。AIに100パーセントのコーディングをさせたら脳が焼け焦げました。助けて。
AIへの依存と認知機能の低下。スケジュールを整理したり、コードをざっと確認したり、実際に小さなスニペットを書いたりするなど、効率を上げるためにAIをますます使うようになっています。
これを経験している人々は間違いなくいます。私もこれを経験するのではないかと恐れていましたが、どういうわけかそうなりませんでした。何度も同じ比較をしているのはわかっています。私の仕事がコーディングだけではなく、しばらくの間そうではなかったという事実が、この事態への準備をより良くしてくれたのだと思います。私はもう10年近くエンジニアのチームを持っています。そして、自分の時間を最も有効に使うのは、雑草の中にいてコードを書くことではないと気づいたのです。それは、チームがより効果的に実行できるように助けることであり、同時に問題が発生したときに彼らがデバッグするのを手伝うのに十分なほどシステムを理解していることです。私は製品全体でコードの5%未満しか書いていませんが、障害の半分以上を解決しています。そして私はそれを本当に誇りに思っています。私のシステムに対する理解は時間とともに低下するのではなく、向上しています。そしてAIツールは、その理解を維持し、システムを設計する際にチームをより良く導くのを助けてくれています。私は、これら4人のうち誰も、これまでチームを管理したことがないに違いないと断言します。
チャットでChris Titus Techも同じような経験をしているのを見ました。彼はシステム管理者とインフラのバックグラウンドを持っています。以前、彼のコーディング能力のほとんどはスクリプト作成を中心に回っていましたが、今ではAIのおかげで本当に多くの扉が開かれました。以前なら決して時間がなかったであろう低レベル言語に飛び込むことができるようになったのです。私も同じことを経験しました。自分が愚かだと感じる長い期間を経験することの摩擦や、質問をして他の人に負担をかけることがあまりに大きかったため、学ぶ価値がなかったことがたくさんありました。AIはそれを底辺まで引き下げてくれました。ですから、ここでの正しい考え方は、あなたをより生産的にし、本当にクールな方法で学ぶ能力をはるかに高めることができます。
経験の浅いエンジニア、例えばジュニアエンジニア、キャリアチェンジした人、あるいは以前はただ理解できていなかった人たちは、ここでは少しひどい目に遭っていると言えるでしょう。私のチャットで、22歳のオースティン・ケネディのこのツイートが送られてきました。彼はClaude Codeが自分の脳を劣化させていると考えています。過去6ヶ月間毎日、彼は6つから8つのClaude Codeのターミナルを開き、75パーセントの確率でエンターキーを押せるように応答を待っていました。それが彼に何かをしました。どうやら、彼の友人たちもそれをかなり頻繁に話題にするようです。彼らの誰も、以前ほど鋭敏だと感じていません。自分たちだけなのか、それとも同じように感じている20代の他の人たちもいるのかわかりませんが、彼がずっと考えていることです。
ええ、物事を本当に理解するための何年にもわたる摩擦を経験してこなかったなら、スロットマシンに夢中になってしまうでしょう。私はこの特定の罠に落ちている人をたくさん見てきました。また、最悪なのは、常に本当に不安を抱えていた人たちです。率直に言って、インポスター症候群を持っていない人たちです。彼らはただの詐欺師です。私はこの恐ろしい例をいくつか見てきました。例えばGoogleで4年間働いているのに、SSHの使い方を知らないような人たちです。こういう人を私はよく見てきました。そしてそういう人たちは今、スロットマシンに依存しています。彼らは、以前はちょっとダメだったけれど、少なくともあちこちでPythonを書くことくらいはできていた状態から、チームにとって単なるマイナスの存在へと変わってしまいました。おかしいことに、同じ人物が、すべてをChatGPTに尋ねることに慣れきっているため、自分の鍵をどこに置いたかを直感的にChatGPTに尋ねに行くのを見たことがあります。このタイプの人たちは、私は以前から特に役に立たなかったと主張します。そしてAIは、すでに浸食されていた彼らの脳をさらに浸食し続けているだけなのです。
優れた開発者とそうでない開発者の格差
優秀なエンジニアとそうでないエンジニアのギャップは大きく広がっており、AIがそれを加速させています。そして再び、業界の人々からの例ですが、チームのジュニアたちは非常に速くコードを出荷しているが、自分たちが実際にコードを書いていないものをデバッグする方法を知らないと言っています。ある開発者は、AIでコーディングを学んだジュニアを雇いました。彼はAIなしではデバッグできません。彼をどう助ければいいのかわかりません。
AIデバッグは過小評価されています。それはAIで構築することとは別の特定のスキルです。現時点では、AIなしでデバッグすべきではないと私は思います。なぜなら、バグがあり、それがユーザーに影響を与えているなら、問題を解決する可能性を高めるためにできることはすべてやるべきだからです。数日前、私たちのビデオ製品であるPingで障害が発生したとき、私はそのコードベースを4年間触っていませんでした。エージェントのテストのために時々アップグレードするのを除いては。しかし、それは私が発明したスタックである古いT3スタックで構築されていました。私はそのレイヤーをとてもよく知っています。どこで障害が発生する可能性があるかを知っています。
そこで、最初にぶつかったエラーをコピーしました。それをCodeXのインスタンスに貼り付け、すぐにより多くの情報を得てデバッグするためにブラウザに戻りました。私は最終的にそれがおおよそ何であるかを突き止めました。Prismaが、実行していた結合のデータを取得するために参照整合性チェックを行おうとしたときに、IDにnullを受け取り、それが原因で失敗しただけでした。私がこれを突き止めたときには、実行されていたエージェントは自分自身のまったく異なる理論を持っていましたが、私は気にしませんでした。私はT3 Codeで別のタブを開き、別の質問をしました。これらのテーブルの参照整合性チェックのうち、どれが問題を引き起こす可能性が最も高いか、そして高速モードに切り替えました。それが実行されている間、私はコードとエラーログに目を通していました。リクエストが完了したという通知を見ました。見に行くと、ユーザーテーブルとどのユーザーがルームにいるかの結合の間のリンクである可能性が非常に高いと書かれていました。
この時点で私は何をすべきかわかっていました。この死んだユーザーに対する、ルームとユーザーの間のすべてのリンクを削除しなければなりませんでした。私はSQLクエリを間違って書きたくありませんでした。そこで、私たちのスキーマをAIに伝え、この特定のパターンに一致するすべての行を削除するクエリを書くように頼みました。そしてそれは機能し、作業は完了しました。
このデバッグ中に、私はAIエージェントへのリクエストを3回ほど行いました。最初のものが何を出力したかさえ知りません。私がデバッグしている間、バックグラウンドで実行させていただけです。より可能性の高い根本原因を見つけ、2番目のエージェントにそれについて尋ねました。それは問題が発生するであろうテーブルを正しく特定しました。影響を受けた行を突き止めるためのクエリを書くように頼みました。AIはそれを実行しました。私はそれを貼り付けました。正しい結果が得られました。その結果をエージェントに戻して貼り付けました。AIはそれをクリーンアップするために実行すべきクエリを教えてくれ、問題は修正されました。
これは、私とAIが、より効果的にデバッグするために、私のシステムの機能と私たちが経験していることに関する理解を共有し合いながらやり取りしたものです。私がすでにシステムを知らなければ、これはまったく機能しなかったことに注意してください。また、AIがなければこれを解決するのにはるかに時間がかかっていたでしょうし、マイアミのイベントにいるときにこのためのクソみたいなSQLを書きたくなかったので、自分の解決策に対してもっと不安になっていたでしょう。
ですから、私はデバッグプロセスでAIを使うことに全く問題はありません。そうでないと言う人は、愚かか悪意があるかのどちらかです。問題は、システムを理解していないのにAIに頼る人々、そして自分が愚かだと感じるのが嫌だからシステムを学ぶことを拒否し、結果としてAIがなければ何もできなくなっている人々です。これは別の問題であり、私はここでの区別を非常に明確にしておきたいのです。繰り返しますが、自分が何をしているのかわかっている場合、これらのツールは本当に役に立つからです。
記事に戻りますと、ラースは今回は実際に違うと言っており、私も同感です。これはC++開発者がPythonやJavaに移行するのとは違います。なぜなら、彼が言うように、彼らは移行したときにブレインフォグ（脳の霧）について文句を言わなかったからです。彼らはJavaで採用しなければならなかったひどいオブジェクト指向プログラミングパターンについて文句を言ったのです。システム管理者がAWSに移行するとき、ネットワークを理解する能力を失っているとは感じません。その点について言えば、Vercelがネットワークの理解を奪ったと主張する人はたくさんいますが、それはまた別の機会に別の会話で。
シニアエンジニアが管理職に移行し、コーディングの練習が減るにつれてコーディングの勘を失い、錆びついていくことは新しい現象ではありません。これは専門知識の自然な進歩でした。エンジニアは数十年のコーディングと多くの摩擦を経験し、その経験が蓄積され、結果としてスキルと知恵を確固たるものにするために必要な時間と経験を得て、仕事が構文についてではなく、より高いレベルのアーキテクチャ上の決定についてになったときにその知恵を適用することができたのです。そのような個人は極めてまれであるだけでなく、私たちが皆、コードを書くこと、問題解決、デバッグの摩擦を放棄しているのであれば、次世代のシニアエンジニアを得ることはできないでしょう。
まさにその通りです。これこそが私の懸念事項です。私はこれに関連するやり方ですでにコーディングをしていたので、このクソみたいなものを上手く扱える素地があります。そして、リーダーシップのポジションに移り、コーディングをしたり雑草の中にいたりしながら、多くの異なるチームにアドバイスをしていたとき、私はこのスキルを本当に早く構築することができました。そして、愚かな22歳の若造が役割を大きく逸脱して、アーキテクチャ上の決定を主導し始めたり、関わるべきではない障害発生時に手助けしたりするのを許してくれた一緒に働いた人たちに、私は本当に感謝しています。関与すべきではないP1レベルのインシデントに関与し、物事がどのように機能するかだけでなく、より重要なこととして、どのように失敗するかを学ぶこと。
私は自分のデバッグスキルを本当に誇りに思っています。私が何年もほとんど触っていないコードベースに障害があるという理由で入っていき、「ああ、たぶんあれだ」と言って、70%の確率で正解するものですから、私のチームはほとんどイライラしているほどです。もし間違っていても、次の3回のトライ以内に正解を出します。通常は、私のシステムへの理解と、1と2と3を結びつけて全体像を構築する能力によるものです。それが私の得意なことです。
最初からそうだったわけではありません。一度に多すぎることをしていたため、そのスキルを構築しなければなりませんでした。そして幸運なことに、私が本来やるべきことの枠を大きく踏み出しても平気な人たちに囲まれていました。正しい考え方と焦点を合わせれば、私が構築したスキルは、十分に大きなシステムを構築し、それがどこで失敗するかを理解することに努力を注げば、今なら独立して構築できると思います。その一方で、そのためのインセンティブは低下しており、基礎を構築することへの関心もそれに伴って低下しています。
私はかつて、基礎的なコンピューターサイエンスを学ぶことに反対するような人間でした。さまざまなソートアルゴリズムや、さまざまな問題に対する解決策のさまざまなビッグO記法をすべて暗記する必要があるとは思っていませんでした。ほとんどの開発者は、二分木を反転させる方法を知る必要はないと思います。しかし、そうしなければならない瞬間が来たら、それを解き明かすことができるべきです。これが常に私の見解です。基礎は、それが重要になるまでは重要ではありません。そして、それが理にかなっているときに、つまりそれから利益を得られる問題があるときに、基礎を学ぶための正しい考え方を持っているべきです。何かが本来あるべき速度より遅く、自分のソートアルゴリズムの実行に時間がかかりすぎていることに気づいたなら、より良いソートアルゴリズムを学ぶ時です。
私のその見解がこの時代にも通用するかどうかはわかりません。すべてのデータをuseEffectでフェッチしているために問題が発生したときに、他の人がどのようにやっているかを調べ、React Queryを見つけてくれることを願いますが、エージェントがそれをあなたに代わって実行し、あなたはその違いを決して学ばない可能性の方が高いと思います。私がそう疑うのは、AIが登場する前からすでに多くのエンジニアがそうするのを見てきたからです。React Queryを使えばいいのに、新しいことをまた一つ学ぶのが嫌だという理由で、コードベース全体で非常に一貫性がなく信頼できない奇妙なパターンでデータをすべてフェッチし、コードを滑稽なほど悪くしているエンジニアをどれだけ見たことか。基本的にはアンラーニング（学習棄却）です。コードも労力も少なくて済みます。非同期関数のためのシンプルなラッパーです。これ以上簡単なことはありません。しかし、学ぶべきことがもう一つ増えるという考えは、平均的なIQの低い開発者にとってはわざわざやる気をなくさせるのに十分だったのです。そして今、その人はそれをさらにどうでもよくするためのレバーを与えられました。最悪です。AIは悪い開発者を最悪な開発者にするでしょう。
しかし私は、これを愛し、単に機能しているという感覚だけでなく、物事がどのように機能しているかを本当に気にかけている開発者が、これらのツールを利用して学習と成長の速度を加速させるだろうという希望をまだ少し持っています。そして私はすでにこれを目にしています。少数の人々ですが、私のコミュニティにはそういう人たちがいます。彼らは、実際の実務経験がない若い年齢でありながら、本来やるべきこと以上のことをしています。なぜなら、彼らは自分たちの身の丈以上の大きなものを構築しており、なぜそれが壊れるのか、そして私が愛する根本的なレベルで問題をどのように解決するのかに好奇心を持っているからです。
熟練したオーケストレーター問題
ここでの枠組みも好きです。現在起こっていることは、深く理解することにつながるような長寿や30年以上の摩擦を経験したことのない開発者が、シニアエンジニアが何十年もかけて獲得したのと同じスキルを必要とする、AIエージェントを管理するというより高いレベルのワークフローに移行させられているというトレンドです。はい。さらに一歩踏み込みましょう。
巨大なコードベースを持つには、優れたエンジニアでなければなりませんでした。その大きなコードベースで手伝うために雇われたか、自分で構築したかのどちらかです。「入場するにはこれだけの身長が必要です」というような、知性と能力の要件、必要な摩擦のようなものがありました。以前は、実際の仕事をするにはこれだけの能力と経験が必要だったのです。今では、Claudeを使えば、5年の経験を持つエンジニアでも不安になるようなコードベースを保守する立場になれます。しかも、実際に学んだかどうかは別として、たった1ヶ月前にコードの書き方を学んだばかりの人でも。
最大の問題は、自分の能力の範囲をはるかに超えている開発者がいて、彼らは自分の能力を高めるためにツールを使っているわけではないということです。彼らは自分の能力を超えて手を伸ばすためにツールを使い、そして物事が壊れたときにはただお手上げになってしまうのです。
Chris Titus Techからのもう一つの素晴らしい指摘です。彼は絶好調ですね。彼はこれをさらに発展させて、もしあなたがオープンソースに関わり、コントリビューターを持っているなら、それが間違いを指摘するのに役立つだろうと言っています。私はあなたの指摘よりさらに一歩踏み込みますよ、クリス。オープンソースのメンテナーは、AIの世界において平均的な開発者よりも圧倒的に優れたパフォーマンスを発揮しています。なぜなら、彼らはスロップ（粗悪なコード）を投げつけられ、さまざまな能力やレベルのエンジニアからのランダムなクソみたいなものに対処することに慣れているからです。彼らの多くは自分よりよく知っており、多くは自分より知識がありませんが、そのすべてが学ぶ機会なのです。そしてこれこそが、あなたが伝統的な意味での開発者ではないにもかかわらず、私があなたを例外的な開発者だと考える理由です。なぜなら、あなたははるかに難しいことをしているからです。あなたはWindowsを修正しようとしていますが、それとは別に、人々が毎日依存しているこれらの真の正当なオープンソースプロジェクトを維持しようともしています。新しいWindowsをインストールするたびにwin utilに頼っている人間として言わせてもらえば、その頻度は多すぎますがね。
その経験が、あなたをはるかに多くのことを学び、詳細がはるかに重要になる立場に置いています。あなたは、伝統的な意味でのエンジニアではないにもかかわらず、自分がやっていることで事実上毎年5年分の現実世界の経験を積むことを自分に許してきたのです。それは愚かでばかげています。そして、私があなたがもっとたくさんのお金を稼ぐのを手助けしたいと思う多くの理由の1つです。ですから、コントリビューターであろうと、コードを精査するのを助けるメンテナーであろうと、人々が依存し使用している実際のオープンソースの作業を行っているのであれば、キャリアの現段階での経験レベルは、そうでない場合に期待されるよりもはるかに高くなるでしょう。例えば、私は主にオープンソースの作業で1年の経験しかない人が、Microsoftで5年の経験を持つ人を完全に凌駕しているのを知っています。
著者は、シニアエンジニアも免疫があるわけではないと思い出させてくれます。Djangoの作成者であり、このチャンネルの良き友人であり、AI開発者スペースでこれが実際に開発者としての私たちにどのような影響を与えるかについて語る最高の人物の1人であるサイモン・ウィリス。彼は30年の経験があります。彼は私が生まれる前からコーディングをしています。彼は、自分が構築するアプリケーションが何を実行でき、どのように機能するかについて確固たるメンタルモデルを持っていないと報告しています。つまり、機能を追加するたびに推論するのが難しくなっているということです。そして私はそれを完全に理解できます。
熟練したオーケストレーター問題。最近のAnthropicの調査の中に埋もれていた、コーディングエージェントに定期的に関与することのリスクについて語った驚くほど正直な瞬間でした。コーディングスキルの衰退が懸念される理由の1つは、監視のパラドックスです。Claudeを効果的に使用するには監視が必要であり、Claudeを監視するには、AIの使いすぎによって衰退する可能性のあるまさにそのコーディングスキルが必要になります。
LinkedInのソフトウェアエンジニアリングのディレクターで、50人のエンジニアを部下に持つ人物は、それが組織全体に蔓延していることに気づき、批判的思考や問題解決を必要とするタスクにはAIツールを使用しないようチームに要請しました。スキルを伸ばすには、人は困難を経験する必要があります。問題について深く考える筋肉を発達させる必要があります。批判的思考を持たずに、AIが正確かどうかをどうやって疑問視できるでしょうか。ええ。今、これらのスキルを構築することがどのようなものになるのか、私にはわかりません。以前とはまったく異なります。新しい方法があるはずですし、これらのツールを使えばさらに効果的になるはずですが、私にはすでにスキルがあるので、それがどのようなものかはわかりません。これらすべてのことを知る前の脳に適切にリセットすることはできないのです。
誤った部分を加速させるAI
この過剰使用とは何かという疑問もあります。これらのスキルが、時には数ヶ月以内に、急速に衰退し消散する可能性があるという、データに基づく証拠と逸話的な証拠の両方がすでにあります。これは、多くのAI推進者が二枚舌を使っている矛盾です。コーディングエージェントの使用は、その同じコーディングエージェントを効果的に管理するために必要なまさにそのスキルを積極的に低下させているのです。
LLMは間違った部分を加速させます。ああ、ここは面白いセクションになりそうですね。現在支持されているシナリオとは反対に、私たちは必ずしも、特に完全に理解していないコードを、さらには妥当な時間内にレビューできないほど大量に、より速く書く必要はありませんでした。AIが登場する前、優れた開発者の優先順位リストは次のようだったかもしれません。
-
コードとそのコードベースとの関係の理解。
-
コードが文書化された効率的な基準に合致しているか。
-
可読性を維持しながら目標を達成するために必要な、できるだけ少ないコード行数。
-
ターンアラウンドタイム（所要時間）。
私は同意しません。ここで言及している優れた開発者がどのようなタイプかによります。開発者を優れているとする要素はたくさんあり、それが何であるかについては誰もが意見が分かれるからです。ある人は、細心の注意を払って詳細な仕様書を書き、コード1行につき5つの単体テストを書く人が優れた開発者だと考えます。またある人は、ユーザーとコードベースを十分に理解し、その両者を結びつけられる人が優れた開発者だと考えます。またある人は、他の誰の考え方ともかけ離れた斬新な解決策を思いつき、5年後まで誰も理解できず、その後にみんながそれを使うようになるような人を最高の開発者だと考えます。
私は、優れた開発者とは現実の問題を解決する人だと考えています。私は、コードベースを理解し、よく調整された標準的なコードを書き、できるだけ少ない行数のコードを書く（これは実は非常にまれですが）開発者と一緒に仕事をするのが好きです。これらを行わず、優れたターンアラウンドタイムを持つ素晴らしい開発者もたくさんいます。しかし私は、上限レベルにおけるこれらのスキルのどれか一つでも、あなたをユニークにするのに十分なほど斬新であることに気づきました。例えば、あなたが非常に効率的なコードを書くなら、それはあなたがそれで知られているということです。私のCTOであるマークはコードゴルファーだと私は知っています。彼のお気に入りの一つは、アドベント・オブ・コードの問題全体をJavaScriptの1行でできるかどうかを確認することです。
そして、前にも述べたように、ターンアラウンドタイムは私のスキルの1つでした。それは私のキャリアを有意義に押し上げるのに十分なものでした。私が介入して、ロードマップを不必要に複雑にしているものを見つけ、削減を手伝い、私たちが実際に構築したいものに本当に集中できるようにしました。そうすることで、ほとんどの時間を要し何の価値ももたらさないすべてのものに気を取られることがなくなりました。ですから、偉大な開発者はこれらすべてのスキルを持っていると言えますが、良い開発者とは、それらの間で適切な妥協点を持っている人です。問題は、エージェントコーディングやLLM全般がこのリストを逆転させていることです。
ええ、ほとんどの開発者は速くコードを書くことを許されるべきではありません。それには同意します。私は頻繁に速くコードを書いてきた人間として、他の人たちがそれについてこようとするのを見て、多くの痛みを伴う結果になるのを見てきました。そしてその解決策は、多くの場合、私がスピードを落することでした。私のコードにバグが増えていたからではなく、私の周りの全員にペースを合わせようとするのをやめさせるためでした。なぜなら、彼らがそうしようとしたとき、すべてが崩壊してしまったからです。そして今、AIのおかげで誰もがペースを合わせようとしており、今、すべてが崩壊しつつあります。
彼らの能力と使用法は、指定された時間枠内に生成できるコードの量を増やすことによって、スピードに焦点を当てる傾向があります。スピードは高い適性の自然な副産物です。それが強制されると、常に正確さの低下につながります。よし、この枠組みは大好きです。実は、これは完璧です。私はスピードを出す権利を獲得しました。あなたたちはまだです。いや、多くの人は獲得していますね。イベントなどで皆さんに会うと、視聴者の皆さんの多くがどれほど有能であるかに本当に感銘を受けています。皆さんの多くがやっているクソすごいことに私は圧倒されています。しかし、あなたのイライラする同僚たちは、まだ速く出荷する権利を獲得していません。その結果がスロップ（粗悪品）です。
私のチームのジュリアスは、速く出荷する権利を絶対に獲得しています。彼は私がこれまでやってきたよりも速く出荷し、エージェントができることの限界を押し広げていますが、同時に、ほとんどの誰よりも物事がどのように構造化されているかについて非常に細心の注意を払っています。そして著者が言うように、AIツールの統合は、より深い理解や簡潔さにあまり焦点を当てない傾向があります。
そして、私はここで非常に明確にしておきたいのです。なぜなら、私がこのようなことに言及するたびに、「ああ、それを行うより良いツールが必要だ。それはたくさんのお金を稼ぐはずだ」という反応が返ってくるからです。そして、OpenAIのGPT-5.5のイベントで、AIをただ使うのではなく、AIでより良く学ぶのを助けるためのAI教育製品を作っている自分の会社に投資してもらおうと、5人の人が私に近づいてきました。カジノと、カジノについての本を売っている人のどちらが多くのお金を稼ぐと思いますか。どちらがはるかに上手くいくかはかなり明白です。私は、収益を上げているものも含め、あまりにも多くの教育投資で痛い目を見てきたので、人々がこれを求めているとはまったく信じていません。良い気分にさせてくれるスロットと、嫌な気分にさせるレッスンの選択肢が与えられたら、99パーセントの人は前者を選ぶでしょう。これを構築するビジネスは存在しません。資本主義における人間の本質が、あなたを教育するツールが成功するのを妨げているのは最悪です。しかし、それはユーザーとしてのあなたたちの責任であり、ビジネスの責任ではありません。ビジネスがどれほどうまくやっても関係ありません。ユーザーがそれを望まなければ、それは機能しません。信じてください、私は多くの経験から話しています。
あなたが十分に決意していれば、実際にあなたがより多くを学び、システムをよりよく理解できるような方法でこれらのツールを使用することは絶対に可能です。しかし、それは彼らが使用されている方法ではありません。多くの企業は、AIでより多くのことを行わなければならないという強制的な命令を出しており、悪い使用法を奨励するようなクレイジーなリーダーボードなどを設けています。そして、それに関するすべての誇大宣伝は、事態がどれほど悪化しているかを示しています。
コーディングは計画すること
コーディングイコール計画。これは面白いセクションになりそうです。あまり強調されていませんが、開発者の間には対立があります。私たちの中には、コードを使って計画を立て、思考する方がうまくいく人がいます。コードで思考し、作業することは、単なる無意味な苦役ではありません。セキュリティからパフォーマンス、ユーザーエクスペリエンス、保守性に至るまで、技術的なレベルで物事について考えることを強制されます。
ここには非常に同意します。私はコードで計画を立てるのが好きです。私がよく話すことの1つは、Twitchで「theoメソッド」と名付けられたものです。私たちがすべてがどのように機能するかを知っていると仮定して、非常に長くて退屈な仕様書を書き、その後製品を構築して、仕様書がまったく意味をなさないことに気づく代わりに、私はそのアイデアの最小限の実行可能な形である、非常にシンプルで最小限の実装から始めます。数日でそれを構築する中で、私はしばしば多くのことを学びます。時には、そのまま出荷できるほど良いものになることさえあります。またある時は、実装を面倒にしているすべてのことを見つけ出し、自分が学んだことに基づいて良い仕様書を書くことができます。
チャットのDeath Fudgeが完璧に表現してくれました。一度書いて、捨てて、それから構築する。そうです。まさにその通りです。そしてもしAIがそれをするのを助けてくれるなら、素晴らしいことです。私はこれをあまりにも多くやったので、前に伝統的なやり方で働いていた会社では私の名前で呼ばれるようになりました。最初に雑草の中に入ることは本当に強力です。コーディングせずにコーディングでそれを行うことは実際にはできません。コードベースの中にいないとき、私はずっとひどい計画を書きます。それが現実です。そして私がチームで働いているとき、私はチームに提案する前にしばしば最初のパスを行います。そうすることで自分の提案の基礎となる根っこを持つことができます。
そして、どうでしょう。プランモードはそれとは違います。プランモードはそれとは全く違います。最近のインタビューで、仕様駆動開発について議論した際、オープンソースのコーディングエージェントであるOpen Codeの作成者でもあるDaxが次のように引用されています。ちなみに、DaxはOpen Codeの作成者ではないことに注意してください。彼はOpen Codeのデベロッパーリレーション（DevRel）です。彼が言ったことは次のとおりです。
何か新しいことや難しいことに取り組むとき、私がコードを打ち込むことは、私たちがそもそも何をすべきかを解き明かすプロセスなのです。私はただそこに座って、機能が正確にどのように機能すべきかについて巨大な仕様書を書き出すのが本当に苦手です。私は型を書き出すのが好きです。いくつかの関数がどのように連携するかを書き出すのが好きです。さまざまな概念がどうあるべきかを確認するために、フォルダ構造をいじるのが好きです。そしてこれはすべて、ほとんどの人、ほとんどのプログラマーが常にやってきたことだと思います。
その点には同意しません。これらを一切やらないプログラマーがどれほど多いか、あなたは驚くでしょう。彼らはチケットが適切に切られるまでただ待ち、その後文書を書くのに時間をかけすぎ、機能さえ完成させる前に昇進できることを願うだけです。ほとんどの開発者はこれをやりません。なぜなら、ほとんどの開発者は平均かそれ以下だからです。優れた開発者はこれをやりますが、ほとんどの開発者はやりません。
私たちが必ずしもこれをやめるべきではないという点については、彼に同意します。やめる正当な理由はありませんし、何をすべきか、そしてそれをどう正しく行うかを私たちが解き明かす方法なのですから。しかし、ここで私が大きく反対する唯一の部分は、間違えたときにそれを修正するのがこれほど安上がりになったことはないということです。私は、新しいフォルダ構造や、型システムの新しいやり方、あるいはデータフェッチの新しいやり方にコミットするとき、常に恐れを感じていました。もし自分が間違っていたら、それを取り除くのは地獄だからです。今では、forループでそれを取り除くことができ、それは素晴らしいことです。これらのことを実験しようとする私の意欲は格段に高まりました。以前ならクソみたいな結果になるリスクが高すぎたため、決して試さなかったであろうパターンを試しています。しかし、それらは本当にうまく機能することが判明し、私は驚いていますが、以前はそれだけの労力をかける価値はありませんでした。ですから、ここでも2つの側面があります。
記事に戻りましょう。あなたが言うことは、多くの場合あなたが意図することではなく、LLMは曖昧さを仮定、あるいはさらに悪いことにハルシネーションで埋め合わせます。それはより多くのレビュー、より多くのエージェントの修正、より多くの消費されたトークン、そして作成されているものからのより多くの切断につながります。逆に、あなたがこれまでに書いた中で最も美しく、明白で、完璧に構造化されたプロンプトに驚嘆したとしても、LLMは依然としてハルシネーションのメソッドを出力する可能性があります。なぜなら、LLMは根本的に次のトークンを予測するエンジンであり、コンパイラではないからです。決定論的なシステムを確率論的なシステムに置き換えて、曖昧さがゼロになることを期待することはできません。JavaScript開発者として、私は気分を害しました。
ベンダーロックインの嘘
ああ、ここは面白いセクションになりそうですね。ベンダーロックイン。少し前に起きたクラウドの障害中にLinkedInを見ていたとき、特定の開発者やエンジニアリングチームが立ち往生していることを強調する多数の投稿に気づきました。彼らのワークフロー、彼ら自身のコーディング能力は、すでにこれらのベンダーに大きく依存する時点に達していました。かつてはキーボードとテキストエディタだけで実行できたスキルが、突然AIモデルプロバイダーへのサブスクリプションを必要とするようになったのです。
しばらく自分自身の宣伝をしていなかったので、今回だけ許可してください。もしあなたが今ベンダーロックインを経験しているなら、それはあなたの責任です。モデルを切り替える機能を提供するだけでなく、サブスクリプションとプロバイダーを切り替える機能を提供する優れたツールはたくさんあります。もちろん、私自身のT3 Codeもその1つです。Claude、CodeX、Cursor、Open Codeのすべてが同時にダウンするような世界はありません。そして、これらの間を飛び回ることは実は非常に価値があります。GPT-5.5にOpusのスロップをデバッグさせたり、OpusにGPT-5.5のコード用に少し良いUIを作らせたりしたことが何度あったかわかりません。
多くの開発者がこれを間違って行っています。彼らは一つのものに過度に依存しているのです。多くの開発者がUS East 1に過度に依存しているのと同じです。違いは、どういうわけかAnthropicがUS East 1よりも信頼性が低いということですが、問題は同じです。そして、この問題に対する優れたオープンソースのソリューションはたくさんあります。繰り返しますが、T3 Codeは完全にオープンソースのデスクトップアプリであり、現在はウェブアプリでもあります。これを使って、既存のサブスクリプションですべてのエージェントを実行し、すぐにそれらの間を飛び回ることができます。Claudeがダウンしていて使いたいと思ったときでも、GPT-5.5に切り替えて問題なかったこともありますし、Cursorに切り替えて、そこで他のプロバイダーを通じてOpusモデルを使用して問題なかったこともあります。また、ClaudeをAmazon Bedrockなどの上でデプロイすることもできます。これにより、Claudeを直接使用するよりもはるかに高い信頼性と稼働率が得られます。
ですから、私はこのベンダーロックインの指摘は好きではありません。他のすべてのことと同様に、信頼性は開発者としてのあなたの関心事だと思います。ここでの問題は、私たちが皆一つのことに依存して身動きが取れなくなっていることではありません。愚かな開発者たちが、使っているものがダウンしたときに他にやることがないからネット上で文句を言っているということです。
ここでの興味深い指摘は、トークンコストが予測できないということです。モデルプロバイダーは多額の補助金を受けており、モデル自体も常に変化する基盤の上に構築されています。リリースされるすべての新しいモデルは、高いベンチマークの後に誇大宣伝が続き、その後実際の使用の現実が続き、みんながそれらが弱体化され、同じ仕事をこなすために2倍か3倍のトークンを消費していると文句を言うという同じパターンをたどります。
これはClaudeの不満です。これは間違いなくClaudeの不満です。OpenAIではそんな風には機能しません。あなたたちはClaude Codeに深く入り込みすぎていて、脳が脱落しているんです。どちらの側にいようと、Claude Codeの熱狂的なファンであろうと、Claude Codeのアンチであろうと、Claude Codeがこれらの多くのことに関する議論を特に台無しにしてきました。ああ、それを引用しないでください。あのPrimagenのビデオ、あのビデオではありません。あまりにも間違っていたので私が粉々に引き裂かなければならなかったあのビデオです。ああ、ダメだ。それを引用しないで。この記事はここまでとても良かったのに。
従業員のコストがいくらかかるかはわかっていても、トークンのコストが日々、月々、年々いくらになるかはまったくわかりません。もしあなたのコストがすべて固定されているなら、あなたはまともなビジネスをしていません。完全に固定されたコストでうまくいっている会社と仕事をしたことはありません。すべては柔軟です。すべては変動します。関税やRAMの価格上昇でコンピューターのコストは急騰しました。レストランでは卵の価格が急騰しました。固定費のビジネスは失敗するビジネスです。一般的に言って、私は同意しないので、この段落は飛ばします。
率直に言って、ベンダーロックインの議論は能力の欠如だというのが私の一般的な考えです。良いベンダーはより少ない作業を行うことを容易にし、特定のベンダーからの移行は、あなたが避けてきた作業をただ引き受けるというだけのことです。私がよく挙げる例はVercelです。Vercelからの移行は簡単です。まだ書いていなかったコードを書くだけです。私はVercelでしか動かないコードは書きません。私はVercelで動くコードを書きますが、Vercelを使っていてVercelが処理してくれるから書く必要がなかった部分が欠けているコードです。Vercelを離れるときは、それらの部分を追加し直さなければなりません。
Claude Codeを使うということは、手作業でコードを書く必要がないということです。Claude Codeを離れるということは、もうコードが書けないということではありません。自分でまたコードを書くか、他の15のプロバイダーのいずれかを使わなければならないということです。非常に多くの選択肢があるのです。私はただ、この主張が好きではありません。ベンダーロックインは、このすべてに対する正しい枠組みではありません。
AIの真の価値と新しいワークフロー
それでは最後のセクションに行きましょう。AIの役割を降格させ、もちろんすべてのコードを手動で入力することを提唱しているわけではありません。プログラマーは常に、コードを書かずに作成する方法を探してきました。だからこそ、VS Codeの短縮形のためのオートコンプリートシステムであるEmmetのようなものがあるのです。個人的にはEmmetはいつも嫌いでしたが、人それぞれです。従来のオートコンプリートスニペットもあります。私はかつて、スニペットやテンプレートに最も反対する人間でした。AIのおかげでもう気にする必要がなくなり、それは素晴らしいことです。COBOLでさえ、MoveやWriteなどの英語のような単語を使用することで、より少ない記述でより多くの命令をカプセル化するように設計されました。BigQueryのモットーは「記述は少なく、実行は多く」でした。LLMは、このコード生成ツールの配列への新たな追加です。
しかし私が提唱しているのは、生産性の祭壇で個人のスキルを犠牲にしない方法として、LLMとコーディングエージェントを二次的なプロセスとして活用することです。シナリオを逆転させ、プロセスの計画部分のブレインストーミングで彼らに頼りながら、実装全体を通して積極的に関与し続けることができます。必要に応じて彼らに委任するのです。生産性の向上を活用し、理解の負債を軽減することができます。
彼（著者）のワークフローを一通り見てから、私のワークフローと、少し違うかもしれない私の考え方について話そうと思います。彼はLLMを使って仕様や計画の作成を支援し、彼自身が実装を促進しています。これはオーケストレーションのフローの逆転です。彼はタスクに応じて、依然として20%から100%を手動でコーディングしています。私はLLMを調査に使用しますが、計画を書くためには使用しません。それは興味深いですね。モデルと関わるとき、私は頻繁に疑似コードを書いています。リクエストと生成されたコードとの間の距離を縮めるのです。はい、その通りです。私は疑似コードを書くのが大好きです。疑似コード上でモデルとやり取りするのも好きで、モデルに疑似コードを生成させます。私が推奨事項を出します。やり取りを繰り返します。私は「よし、それはいい。私のコードベースではどうなるか」といった具合です。
彼はまた、モデルをアドホックなコード生成やインタラクティブなドキュメントのための委任ユーティリティとして、また継続的に質問、イテレーション、リファクタリング、そして明晰さを得るための調査ツールとして使用しています。よし、面白くなってきましたね。後でそこに戻りましょう。彼は、1回の作業でレビューできる量以上のものを生成することは決してありません。レビューする量が多すぎる場合は、ペースを落としてタスクを分割し、最終的な結果を包括的に理解できるように必要に応じて手動でリファクタリングします。そして、彼がこれまでにやったことがないこと、または自力でできないことをLLMやエージェントに実装するよう求めることは決してありません。ただし、純粋に教育やチュートリアルの目的である場合を除いては。そして多くの場合、それは後で破棄されます。
よし、彼はここで、彼自身がまだ受け入れているかどうかわからない概念の周りを踊っています。厳しい現実は、ほとんどのコードは、何千回も実行されないのであれば、以前は書く価値がなかったということです。コードで解決できるタスクなら、人間にも解決できます。ただ必ずしも効率的ではないというだけです。しかし、一度だけやればよくて、1000行のコードが必要になるようなことなら、そのコードを書く価値はありませんでした。私は手作業でそれをやるでしょう。
重要なことは、あなたが書いている各関数がどれほど重要かを考えることです。あなたが書いているコードは、ユーザーによって1日に何千回も実行されるコードですか。それとも、移行の際に一度だけ実行されるコードですか。あるいは、何らかのデータ分析をしていて、CSVの50万行から何かを掘り出したくて、コードを一度だけ実行しようとしているとします。この情報だけが欲しいのです。コードの一部がどのくらいの頻度で実行されるかを理解することは、そのコードがどれほど重要か、そしてそのコードを理解することがどれほど重要かを理解する上で不可欠です。
そして、これを内面化したら、さらにそれを進めることができます。ただ1回だけ実行して二度と考えないようなものだから品質が問題にならないコードがたくさんあることに気づいたとき、あなたは以前なら書かなかったようなもののためにコードを書き始めるでしょう。私は、自分が行ったある特定のタスクの数字をチェックするための1回限りの計算機や、クソみたいなものの間でたくさんのファイルを転送している最中にNAS上のアセットを管理するための2000行のJSファイルなど、クソみたいなもののために本当にたくさんのコードを書いてきました。そうしたもののためにコードを書くことは、以前は決して価値がありませんでした。なぜなら、座って自分でタスクをこなす方が速かったからです。
今、突然、そうしたものに対してコードを書くことがはるかに価値を持つようになりました。そしてそれが私にとっての最大の変化です。以前なら書く価値がなかったコードを書くためにAIを使い、同時に書く価値のあるコードをよりよく理解するためにAIを使うことです。
厳しい現実は、エージェントと一緒に働いている人々のほとんどが、どのコードが多く実行され、どのコードが1回だけ実行されるかはおろか、どのコードが実行されているかさえ言えないということです。そして、もしあなたにそのレベルの理解がないのなら、それを修正する必要があります。しかし、一度この理解を得て、この範囲で自分のやっている作業について考えることができるようになれば、あなたはそのスペクトルの両端にさらなる価値を見出すでしょう。
個人的に数回実行するだけのコードを書いている側では、より多くのことを行い、より興味深い問題をより興味深い方法で解決するようになります。そしてもう一方の側では、最も複雑なコードをエージェントに説明してもらい、ホットパスを見つけ、それがどのように設計されているかについてより多くを学ぶことができます。そしてもしそれに何か問題があれば、エージェントを使って以前はできなかったような大規模な調整を行うことができます。
私は、多く実行されてユーザーに出荷されるコードと、1回限りのタスクで使用するコードとでは、AIの使い方がまったく異なることに気づきました。これを認識し、AIを使って両方の分野でより良い結果を出せることに気づくこと、それが、私が皆さんの多くに持ってもらおうとしている強力なアンロック（解放）なのです。
著者は次のセクションのタイトルを「私は速く進んでいないが、より質の高い仕事をしている」としています。両方ともやってみてはどうかというのが私の挑戦です。1回限りのことをより速く、問題をより速く解決し、以前はやる価値すらなかったことをより速くやる。しかし、人的資源がかかりすぎたものの品質を向上させ、完全には理解していなかったものの品質を向上させ、今ではそれが可能になっています。コミットしたいものを固める前に、より多くのバージョンのものを出すのです。重要なコードは、AIのおかげでより高い品質になるはずです。そして、重要ではないコードは、AIのおかげで10倍以上多く生み出されるはずです。私たちはその両方を得るべきです。そしてその2つが混同されると、すべてが崩壊します。
結論：AIに思考を委ねてはいけない
素晴らしい記事だったので、そろそろまとめましょう。本当のことを言うと、彼に最後の言葉を委ねたいと思います。
これらのモデルからの生産性の向上は本物です。そして、頻繁に触れながら実際に作業に携わることから生まれる摩擦や理解も本物です。コーディングを理解せずにコーディングを民主化しようとする数え切れないほどの失敗した試みにもかかわらず、私たちはコードに関わらなければコードを理解することはできないという現実に直面しています。また、書き続けることに関与し続けなければ、その理解との接点を失う可能性があることも明らかになりました。そうなれば、そもそもオーケストレーターとしてのあなたの能力は低下し、AIコーディングのこのフェーズは奇妙で不必要にストレスの多い幕間となってしまいます。
もしかしたら私は心配しすぎなのかもしれませんが、歴史には教訓があります。しかし、これはすべて、私たちが自分自身に対して行っているもう一つの大規模な実験のように似ていると感じます。私たちは、長期的な影響を理解しないままソーシャルメディアが導入された同じような時期を経験し、現在では広範な規模で注意欠陥やその他の多くの問題に直面しています。今回、私たちははるかにリスクの高いものでギャンブルをしています。
彼はジェレミー・ハワードの引用で締めくくっています。今AIエージェントに全力を注ぐ人々は、自分自身の陳腐化を保証している。もし自分の思考をすべてコンピューターに外注すれば、スキルの向上、学習、そしてより有能になることをやめてしまうことになる。
まったく同感です。これはラースによる驚くべき記事です。彼のブログをチェックすることを絶対にお勧めします。彼の他の投稿を見たい場合は、説明欄にリンクがあります。これは決して彼の唯一の素晴らしいブログ投稿ではありません。「AI時代における不可欠な価値（indispensable value in AI era）」の投稿や、「今年から誰でも委任できるようになった（everyone can delegate now）」も絶対にチェックしてください。これを書いてくれたラースにとても感謝しています。これは素晴らしい読み物であり、皆さんがそこから何かを学んでくれることを願っています。
AIに思考を奪わせてはいけません。AIにあなたの思考を前進させ、あなたがより多くを学び、より多くの問題を解決するにつれて、より良く、よりスマートなものを構築できるようにしてください。もしAIがあなたをより賢くしていないのであれば、あなたは間違った使い方をしています。それらの貴重なスキルを失う前に反省することを強くお勧めします。今こそ、これまでにないほどこれらの物事のトップに立つことが本当に重要な時期です。それらのスキルを衰えさせることは、長期的にあなたのキャリアを傷つけることになります。今のところ、私からこの件について言えることは以上です。
コメント