本動画は、Anthropic CEOのDario Amodeiが2024年3月に予測した「3〜6ヶ月以内にAIがコードの90%を書くようになる」という発言の検証である。当初は荒唐無稽に思えたこの予測だが、9ヶ月後の現在、実際にAnthropicの開発者たちがClaude Codeで100%のコード貢献を行っている事例が報告されている。シニア開発者の32%が既にコードの半分以上をAIに依存しており、コード生成の劇的な効率化が実現している一方で、開発者の役割は「コードを書く」から「コードをレビューし、設計を決定し、システムを統括する」へと根本的に変化しつつある。この変化は特にシニアエンジニアに受け入れられており、彼らは既にコードレビュー中心の業務に慣れているためAIツールの恩恵を最大限に享受している。ただし、ジュニア開発者にとっては基礎スキルを習得する機会が減少するという懸念も指摘されている。技術進歩により1日で12,000行のコードを生成することが可能になり、テストやデバッグの負担も大幅に軽減されているが、同時にAI生成コードは人間が書いたコードの1.7倍の問題を含むというデータも示されている。
AIがコードの90%を書く時代の到来
2024年3月、Dario Amodeiがこう発言したのを覚えていますか。
コーディングやプログラミングを見てみると、これはAIが最も進歩している分野の一つですが、私たちが発見しているのは、AIがコードの90%を書く世界からそう遠くないということです。3ヶ月から6ヶ月以内にはそこに到達すると思います。
当時、私はこれを技術系CEOが歴史上発したあらゆる発言の中で最も馬鹿げたものの一つだと思いました。そして実際、馬鹿げていました。公平を期すために言えば、彼は間違っていました。実際には9ヶ月かかったんです。
Borisは、Claude Codeの開発責任者です。彼は数日前にアップデートを投稿し、元々Claude Codeはサイドプロジェクトだったのに、今では彼のコードの書き方を変えてしまい、もうほとんどエディタを開くことがなくなったと語っています。彼が過去30日間に259件のプルリクエストで書いたすべてのコード、そのすべてがClaude CodeとOpusで書かれたものです。文字通り、Claude Codeへの彼の貢献の100%がClaude Codeによって書かれたのです。
確かに彼は会社の従業員ですから、もちろんそう言うでしょう。でも私自身、Claude CodeをOpusとともにもっと使い始めたんです。私はClaude Codeを実行していないときにTwitterから締め出すChrome拡張機能を作りました。これは自分にもっと使うよう促すためです。そして、会話ビューが別になっている全く新しい画像生成スタジオを構築しました。気に入った写真を選んでフォローアップができ、よりダイナミックな編集体験ができるものです。
それをモバイルアプリにもしました。これらすべての詳細が知りたい方は、Claude Codeの使い方についての専用動画がまもなく公開されますので、ぜひチャンネル登録して見逃さないようにしてください。でも今日お話ししたいのはそれではありません。Darioがこのパネルで述べたことと、この会話が起こるときにしばしばスキップされるその直後の部分、そしてこれが開発者としての私たちにとって何を意味するかについてお話ししたいと思います。なぜなら、彼のタイムラインは若干ずれていたかもしれませんが、Darioは完全に正しかったからです。
スポンサー紹介
そしてコードを書いてお金をもらえなくなるかもしれないので、ここでスポンサーブレイクを挟みましょう。
GitHubが自社を恐れていると誇らしげに言える企業は多くありませんが、今日のスポンサーはそのうちの一つです。DepotはGitHub Actionsの実行において非常に優れているため、Microsoftはわずか数週間前にGitHubブランド全体を破壊し、それを使用することに課税しようとしました。
彼らはその後これらの変更を延期しましたが、たとえ実施されたとしても、それでも価値があります。なぜならDepotはそれほど優れているからです。PostHogのようなプロジェクトで37倍という実世界のパフォーマンス向上について話しているんです。そして覚えておいてください、PostHogはオープンソースです。ここに魔法のトリックはありません。自分でコードを見て、アクションが突然これほど短時間で済むようになったことを確認できます。
2時間以上から1分50秒、4分への違いについて話しています。正直に言いましょう。理由もなく失敗するビルドを追いかけることにどれだけの時間を無駄にしていますか。変更しているコードを実際にマージできるようにビルドが完了するのを待つのにどれだけの時間を費やしていますか。新しい変更をプッシュすることにどれだけためらいを感じますか。CIがさらに1、2時間かかることを知っているから、何もできないとわかっているからです。これらの問題がすべてない生活を想像してみてください。
プルリクエストを出すとビルドがただ動く。GitHubアクションが不安定なために遭遇するランダムなエラーや失敗ケースがない。それらが数時間ではなく数秒で起こる。CIを待つという地獄のない生活を想像してください。まだ試していないなら、時間を無駄にしています。今すぐsoyv.link/depoで解決してください。
Darioの予測の全容
まず第一に、Darioの発言全体を皆さんと一緒に見ていきたいと思います。
これについてはかなり懸念しています。一方で、比較優位というのは非常に強力なツールだと思います。コーディングやプログラミングを見てみると、これはAIが最も進歩している分野の一つですが、私たちが発見しているのは、AIがコードの90%を書く世界からそう遠くないということです。3ヶ月から6ヶ月以内にはそこに到達すると思います。そして12ヶ月後には、AIが基本的にすべてのコードを書く世界にいるかもしれません。
彼が最初にこの発言をしたとき、私は反応動画を作りました。なぜなら、これの測定方法が本当に本当に難しいからです。まず、コードとは何かを定義する必要があります。コードの90%とは何でしょうか。人々がプロダクションに出荷するために報酬を受け取っているコードについて話しているのでしょうか。GoogleやMicrosoft、Anthropicのような企業で書かれているコードについて話しているのでしょうか。それともすべての場所から作成されたすべてのコードについて話しているのでしょうか。
なぜなら、Lovable、V0、Boltなどのツールによって、インスタンス化されているリポジトリの量と書かれているコードの量は、単純な行数だけでも前年比で意味のある量だけ変化していると想像できるからです。2024年と比較して2025年に書かれたコードが2倍未満だったら本当に驚きます。2026年になってしまってすみません、皆さん。でも言いたいことはわかりますよね。2025年には2024年と比較しておそらく2倍以上のコードが書かれ、生産されたと思います。
そのほとんどがゴミ箱に入るのでしょうか。確かに。でもはるかに多くのコードが生み出されました。これに異論を唱えることはできません。これは単なる当たり前のことです。私たちがどちら側にいても、昨年はるかに多くのコードが生成されたということに同意しなければなりません。
実際のビジネスにおけるAIコードの割合
とはいえ、実際のビジネスについての実際の調査が行われています。GoogleのAIサマリー機能によれば、実際の調査から、業界全体では、その数字は少し低いようです。どうやらMicrosoftではコードの30%がAIによるものだそうです。Sundarは2024年末時点で25%以上がAIによって書かれたと述べました。その後のアップデートがあったかどうかはわかりません。
しかしここから事態は狂い始めます。シニア開発者については、最近の調査で、32%が少なくともコードの半分がAIから来ていると報告しています。ますます多くのシニア開発者が、自分たちのコードの多くがAIから来ていると言っているのです。これは2025年に起こった最大の変化の一つです。もはやコードの一部をオートコンプリートしているだけの開発者ではありません。
スキルを持っていない初心者だけがスキルギャップを埋めるためにAIを使っているわけでもありません。今や経験豊富な開発者が時間のギャップを埋めるためにこれらのツールを使っているのです。そして私自身も同じことをしていることに気づきました。システム、プロジェクト、機能について、そしてコードベースで修正したいものについて、非常に多くのランダムなアイデアがあります。
そしてツールが良くなり、ハーネスが良くなり、もちろんモデルも良くなるにつれて、以前なら永遠にバックログの山に埋もれていたであろうJiraチケットを切っていたかもしれないこのランダムなものを、今ではOpusに投げて、コードを取得し、GitHubでレビューして、マージすることができます。
コードレビューに対する開発者の意識
また、私たちの仕事が何であるかについても問題があります。人々がコードレビューをどれだけ好きかを見るために簡単な投票を実施しました。初期の結果を見ると、50%が嫌いだと言っています。中立以上の選択肢が4つあるにもかかわらずです。投票が続くにつれて、まあまあだけど疲れるという回答が増えています。
しかし依然として26%が嫌いと言い、10%が中立、45%がまあまあだけど疲れると言っています。コードレビューが好き、または大好きという開発者の割合は非常に小さいのです。私はこのセクションにいます。好きなセクションにいると言えるでしょう。私はコードレビューを楽しんでいます。もっとやることを正当化できればいいのですが、私のスケジュールは完全にカオスです。でもコードレビューは好きです。
これはまた、より経験豊富な開発者になるにつれて時間をかけて克服しなければならないことの一つだと思います。AIツールの使用を乗り越える必要があるということではなく、コードを書くことに費やす自分自身の時間を乗り越える必要があるということです。実際、私は少し前にMarkと長い話をしました。ご存じない方のために言うと、MarkはT3の私のCTOで、私たちが構築したすべての楽しいもののCTOです。
Markは今、スタッフが増えたので、つまりJuliusがアメリカでフルタイムでいて、Yoshも週を通して貢献できるときは貢献しているので、Markの時間はもはやコードを書くことに費やすのが最善ではなくなりました。以前は、Markがほとんどのコードを書き、Juliusが奇妙な問題を解決し、私がいくつかの舵取りと一般的なコードレビューをするという流れでした。
今は、起こっていることが多すぎるので私はもっと離れています。会社を経営するのは大変な仕事で、CEOとしてあまり良い仕事をしていません。コードベースにもっと関与しようとしていますが、私の時間を使うのに最適な方法ではありません。つまりMarkも、特にモバイルアプリの開発も進行中なので、オーケストレーションとコードレビューをもっと行うために少し外に出なければならなくなったということです。
チームを管理し、モバイルアプリを構築し、チームを管理し、ウェブアプリとサーバーとバックエンドを構築・維持し、Upload Thingを管理し、私たちが維持している他のすべてのサービスを管理する。彼はもうコードをあまり書いていません。そしてほとんどの人がキャリアでこれが起こったときに経験するように、それはくそったれです。
もはやコードを書かなくなったときに、突然生産的でないと感じるようになります。そして以前は、一日の成功を、どれだけのコードを書いたか、エディタでどれだけの時間を過ごしたか、どれだけの問題を解決したかで測っていました。GitHubのPRタブで時間を過ごしていて、エディタにいないと、何も成し遂げていないように感じます。
そしてMarkが大量のコードレビューをし、大量のものを出荷し、大量のサポートケースを処理し、これらすべてのことをやったのに、単にエディタにいなかったというだけで何も成し遂げていないように感じた回数は。それは日常的な出来事になり、彼はその感覚を愛していませんでした。なぜならそれは最悪だからです。そして私は、多くの開発者が管理職へ、テックリードへ、コードを書くことよりもコードをオーケストレーションすることが仕事になる役職へと移行するにつれて、これが起こるのを見てきました。
これはシニアエンジニアになることの一部です。これが、より多くのシニア以上の開発者が、コードの大部分がAIから来ていると報告する変化を見ている最大の理由だと思います。私たちは常にコードをレビューすることにもっと慣れています。平均的な開発者はおそらく、レビューするよりも多くのコードを書いているでしょう。
既にその壁を乗り越えた開発者、大きなオープンソースプロジェクトを維持している人々、多くのエンジニアがいるチームを運営している人々、多くの規律ある仕事を多くの人々が行うことを必要とするシステムを構築している人々。これらが、過去数ヶ月間でこれらのAIツールに最も激しく恋に落ちている人々です。
既にその山を越えていて、それに慣れている人々が、今最大の恩恵を受けている人々です。20件のプルリクエストを提出してそれらすべてをGitHubで確認する日があります。この時点で、エディタで実際にコードを読むよりも、コードを生成してGitHubに載せることに多くの時間を費やしています。それは狂っています。
コード作成からレビューへの役割変化
しかしそれはまた、多くの人々にとって最悪です。私自身を含め、多くのエンジニアが、コードをレビューするよりも書くことを好むことを知っています。実際、この投票から、開発者の大多数がコードを読むよりも書くことを非常に好んでいるようです。理解できます。でもそれは今後の私たちの仕事で最悪な部分になるでしょう。私たちの仕事の中で、これらのツールによって行われる決定と作業をレビューすることが増え、自分で作業を行うことが減っていきます。
最悪ですが、それが現実です。そしてそのジャンプを喜んで行う人々は狂ったような成功を見ることになるでしょう。趣味としてコードを書き始めたときには最悪です。正直に言うと、自分の趣味が自動化されるのは恐ろしい気分です。一方では、これは完全に理解できます。離れていくのは奇妙でした。もう一方では、私には2つのポイントがあります。
まず第一に、これはエンジニアとして良くなるにつれての自然な進行です。委譲することと、もっと多くの話し合いとオーケストレーションと長期計画とチームの管理と開発速度と入ってくる変更とそれらがどのように入ってくるかなどを行うことを学ぶ必要があります。それがエンジニアとしての成長です。
コードを書く部分が十分に上手くなったら、レベルアップし続けるためにこれらの他のことを上手くなる必要があります。コードを書くことが実際にあなたに利益をもたらす量には上限があります。このもう一つの側面は、これはエンジニアとして私たちがずっとやってきたことだということです。私たちは他の人々の趣味だったものを自動化するコードを書いてきました。私たちは既にコードで非常に多くの分野を破壊してきました。私たちの分野の楽しい部分が侵食され始めるのは時間の問題でした。
しかし私は、最近全体的にコーディングがずっと楽しくなっていると言って反論します。これらのエージェントをどこまで押し進められるか、彼らができる狂ったことは何かを見るのははるかに楽しいですし、コードがひどいからといって捨てるときに罪悪感を感じません。最悪の気分は、従業員やチームメイトや気にかけている誰かが狂った方向に進み、何かを深く掘り下げ、狂った解決策を構築し、そして多くの理由のいずれかで、それがうまくいかないときです。
プロジェクトに合わない、マージできない、そしてPRを閉じなければならない。痛いです。最悪です。同僚や仲間や友人が行った大変な仕事を捨てるのは本当に悪い気分です。でもそれがエージェントなら、私は気にしません。ただPRを閉じるだけです。だから私は実験をもっと楽しんでいます。新しいことを試すのがもっと楽しくなり、新しい言語で遊ぶのが楽しくなり、コードベースを見直すのが楽しくなり、新しいものを実験するのが楽しくなっています。
私はこれまでになく喜劇的に多くのコードを書いています。1日で12,000行のコードプロジェクトをまとめました。何ですって。1日で12,000行のコード。さまざまな調査によると、平均的な開発者は平均的な日に、徹底的にテストされデバッグされた10から40行のコードを書きます。Opusと私は12,000行書きました。
これはハッタリに思えるかもしれませんが、平均するとこれは非常に現実的です。チャットのみんなが「いや、それは馬鹿げてる。それは狂ってる」と言っているのは知っています。でも月曜日に250行のコードのPRをやり始めて、火曜日にPRを出して、徹底的なレビューを得るのに2日かかる。木曜日にようやく十分なレビューを得て変更を加える必要がある。
それで変更を加えて、金曜日に出荷される。240行のコードで5日間でした。それは正しいです。そしてそれは滑稽です。それは馬鹿げています。これが人々が話している10倍から100倍です。コードを書くだけでなく、テストを書き、テストプロセスを自動化し、エンドツーエンドのテストを設定することが大幅に簡単になったときです。
テストとコード検証の新時代
GMOがこれについて投稿したばかりで、それについて考えれば考えるほど、彼が正しいかもしれないと思うようになりました。AIコーディングは世界で最も厳密にテストされ、型チェックされ、証明可能に正しいコードをもたらすでしょう。まず、テストと検証のフィードバックループがエージェントを助け、スロップを防ぎます。その通りです。神よ、Claude CodeはLSPが追加されたときにずっと使いやすくなりました。
ちょっと壊れていますが、すごく助かります。しかし第二の部分、テストは常に面倒な作業でしたが、高いテスト数が与えるチェックマークの山が嫌いな人がいるでしょうか。エージェントは私たちが望むだけ多くのテストを喜んで書いてくれます。その通りです。テストを書き、維持する苦痛は大幅に減少しており、私は自分のプロジェクトのテストとの関係を再考し始めています。
これは最もクールな部分の一つです。実際のコードよりもテストコードを書くのにずっと時間がかかっていました。なぜならテストを正しくすることは難しく、退屈で、遅く、イライラし、実際に私たちがやりたいことではないからです。今やエージェントがその部分をやり、それから実装をやり、それからコードを出して、それからコードレビューの最初のパスをやり、間違いを見つけて、それからあなたが行って最終的な部分を見て、それに親指を上げるか下げるかする。
それは全く異なる構築方法であり、ソフトウェアについての考え方を変えています。引用の残りの部分に戻りましょう。なぜならこれは多くの人が見逃していると思う部分だからです。
しかしプログラマーは依然として何をやっているかの条件は何か、作ろうとしている全体的なアプリは何か、全体的な設計決定は何かを指定する必要があります。書かれた他のコードとどのように協力するか。これが安全な設計か不安全な設計かについて常識をどのように持つか。だから、プログラマー、人間のプログラマーがやる必要があるこれらの小さな部分がある限り、AIが得意でない部分、人間の生産性は実際に向上すると思います。
この部分を本当に強調したいです。なぜならこれは私がコーディングについて愛していることの大きな部分だからです。それは単に、エディタで美しい行を書き、それを見つめて微笑み、スクリーンショットを撮ってツイートできるというプロセスだけではありません。
それはシステムについて考える方法、部分がどのように組み合わさるか、適切な抽象化が適切な場所で適切な方法で機能するとき、すべてがうまく組み合わさるときです。使いたいツールのセットをまとめて、それらが適切な方法で組み合わさるとき、またはそのうちの一つが必要な方法で全く機能しないので、他のものと交換すると機能するとき。
そしてすべての部分が正しく機能するときのその一体感。それが私がコードを書いているときの一番好きなことです。すべてのピースが組み合わさって、結果が素晴らしいものになるとき。維持する能力に自信を持っているものであり、また実際に組み立てている製品に対して実際に使うのが楽しいものでもあります。
これは素晴らしいです。これはとても楽しいと思います。それは違います。それは奇妙です。毎日コードを書く方法の根本的な変化です。これは日常業務、キャリア、雇用する人々について何を意味するのでしょうか。解雇しなければならないかもしれない人々については。私たちの労働力はどのように変化するのでしょうか。多くの人々が、Anthropicがエンジニアの90%を解雇しなかっただけでなく、実際にはまだもっと雇おうとしているので、この予測は明らかに真実ではないと言いましたが、彼らは実際にもっと多くのコーディングをしています。実際、Darioは人々が彼の見解に疑問を呈したときのフォローアップでこれについて実際に言及しました。
このクリップの音声を修正してくれたFaZeに感謝します。これで実際に聞くことができます。
Anthropicにおける実践例
Anthropicで書かれるコードの70、80、90%はClaudeによって書かれていると言えるでしょう。3ヶ月か6ヶ月前にこのようなことを言いました。人々はこれをソフトウェアエンジニアの70、80、90%を解雇するかのように考えるので、それを反証されたと考えます。
しかし実際に起こることは、私たちがまだ書いている10%、人間はAIシステムのマネージャーになります。比較優位の原理のために変化があります。だからそれはあなたが思うよりも普通に見えます。最終的にはすべて、最終的にはその論理が成り立たなくなるかもしれませんが、これらの予測には、未来を見ることにはある種のSF的な輝きがあって、異なる色のメガネを通して見ることになる、スターウォーズのようなものがあるでしょう。
これらの予測が実現するとき、それは野生的ですが、ある意味では普通でもあります。そう、彼らは単にもっと多く構築しているだけで、それはとても理にかなっています。そしてそれに慣れると、もはやそれほど狂っているとは感じなくなります。そして私自身もそれを少し感じています。Claude Codeで遊んでいるだけのとき、必ずしも、ああ、これはすべて一度に起こったとは感じません。
コンピュータから離れて友人とそれについて話していたとき、IDEを一度も開かずに2つのプロジェクトを構築したことがどれほど馬鹿げているかが私に襲いかかりました。それは本当に狂っています。それは馬鹿げています。非常に馬鹿げているので、今やBorisは再び彼の日々の仕事のすべてをClaude Code 2で行っています。そしてDarrenは数日前に、1人の高度に熟練した人が10人のエンジニアの仕事に相当することができるはずだという投稿をしました。
コード需要の増加とジェヴォンズのパラドックス
これは、それだけで十分なら、業界がエンジニアのトップ10%だけに削減されることを意味するのでしょうか。私たちは懸念すべきでしょうか。私はSimonの反応が本当に好きです。コードが10倍安くなれば、コードの需要は10倍以上になります。以前はカスタムソフトウェアを買う余裕がなかった多くの企業が突然その市場に参入します。
そして数年のロードマップを持つ既存の企業は、それを乗り越えるのを助けるためにもっと雇うでしょう。これはジェヴォンズのパラドックスとして知られています。ジェヴォンズのパラドックスは、技術の進歩がリソースをより効率的に使用できるようにし、それによって単一のアプリケーションに必要な量を減らすときに発生するものです。
しかしコストが下がり、需要が価格弾力的であれば、これは需要の増加をもたらし、総リソース消費量が増加する可能性があります。そして私たちは既にこれを見ていると思います。間違いなくもっと多くのコードが起こっています。これまで以上に多くの企業が独自の内部ツールの構築に興味を持っていることは間違いありません。
たとえば、スタートアップ向けの財務管理会社RAMPでは、プレーンテキストの作業記述を受け取ってそれを実行するOpen Codeを使用する独自の内部ツールを構築しています。これは、Sentryで最も一般的な20のセンサリー問題は何かと尋ね、それらすべてを修正する子セッションを起動するというものです。そしてどうやらそれは機能しました。
彼らはSentryの問題を見て、それからそれらすべてを修正するために20のエージェントを起動し、それから20のプルリクエストを提出しました。それはちょっと狂っています。これはコードをレビューするのにずっと多くの時間を費やすことを意味しますが、このようなものをすべてリンクするプロセスもあります。そして彼らが作ったこのInspectツールのコードの90%以上がおそらくバイブコーディングされたものだと確信しています。
これが変化していることであり、狂っています。そして自分で飛び込んで遊べば遊ぶほど、これらのことについて考える方法が変わることに気づくでしょう。ツールを立ち上げることができて、それがそれほど大変ではないことに気づいたとき、試さなかったであろうことを試すようになります。私は自分のチームに最小推論支出を設定することを検討しているくらいです。
T3 Chatのみんなが少なくとも月に200ドルを推論に費やすことを期待するようにするかもしれません。そうすれば、彼らは新しい奇妙なことを試しに行くでしょう。彼らに減らすのではなくもっとお金を使うように圧力をかけたときに何をするかを見たいのです。そうすれば彼らはもう少し実験して、もっと狂ったことをするかもしれないからです。
この時点でおそらくそうするつもりです。あまりにも考えすぎています。おそらくそうします。この楽しいレポートが撮影中にリンクされて、それを含めたかったのです。なぜならこれは、AIが書いているコードをレビューしなければならない理由のもう一つだからです。AIコードは1.7倍多くの問題を作り出します。私の最初の質問はこれがいつ公開されたかでした。なぜならそれはこのレポートについての考え方を大きく変えるからです。
そしてそれを見つけることができませんでしたが、チャットのみんなはそれを見ることができると言っていました。これを見てください。モバイルサイズに縮小すると、日付が表示され、12月17日と表示されます。そしてズームアウトすると、12月17日、7分で読めると表示されるサイドバーが表示されます。しかしサイドバーが収まるにはズームインしすぎているが、モバイルモードをトリガーするほどではない場合、そこに値が表示されません。
UIをバイブコーディングするときに発生するバグの一例です。AIコードで人間が書いたコードよりも最大70%多くこれらのバグを見つけることについての記事でこれらのバグの一つを見るのは面白いです。このレポートは470件のPRにわたり、320件がAIが共同執筆したもので、150件が人間のみで、Code Rabbitの構造化された問題システムを使用した多くのオープンソースプロジェクトにわたっています。
そしてそうです、AIは出力を加速しますが、特定のカテゴリーの間違いも増幅します。驚き、驚き、おわかりでしょう。興味深い点の一つは、彼らがPRごとにしか測定しなかったことです。コードの行ごとには測定しませんでした。また、高い問題の外れ値がAIPRでより一般的でした。つまり、ランダムにはるかに多くの問題を抱えたPRがあるということです。平均では1.7倍ですが、90パーセンタイルでは2倍です。
だから悪いことをするとき、はるかに悪くなります。クールな情報で、再びコードレビュー部分を行う必要があるもう一つの理由です。しかしこれは私の最大の懸念、ジュニア開発者を残します。そして正直に言って、それについて何ができるかわかりません。
ジュニア開発者の課題
私はほぼ20年間コードを書くことでこれらのスキルを構築してきました。そしてこれらのスキルは、これらのツールの日々の使用において依然として不可欠です。CSSがどのように機能するかについての奇妙さやスクロールコンテナがブラウザで奇妙であることを知っているだけです。Claude Codeに、オーバーフロールールが設定されているボックスからツールチップが出てくる能力を持っていないことを思い出させなければならなかった回数。
これを知っているかどうかわかりませんが、ボックスにオーバーフローXルールを設定すると、Y方向に出ることができません。だからホバーしたときにボーダーカラーがあるような動作がある場合、それはカットオフされます。または正方形の隅に小さなXボタンがある場合、それはカットオフされます。そして私はこれについてOpusに何度も思い出させなければならなかったので、それは私のグローバルQuad MDファイルに追加することを提案しました。
これらのツールで成功するためにはこれらのことを知っている必要があります。しかしこれらのツールが存在することで、これらのことを学ぶインセンティブが劇的に低下します。なぜなら間違ったことをすることのコストは以前は本当に高かったからです。そしてそれを理解することのコストも本当に高かったです。あなたはそれをするために時間を費やすでしょう。
今、これらのことが起こる理由を知らなければ、問題をスクリーンショットして、モデルに見せて、「ねえ、これを修正して」と言うことができます。そしてそれが正しく行う3分の1の確率があり、それから永遠に何度も何度もそれを続けます。これらのタイプの問題の量は常に減少するでしょう。しかしまた、これらのツールにやらせている作業の量も常に増加しています。
以前は100行のコードごとにこれらの間違いの一つを犯していたなら、それはちょっと便利でした。今、それは1,000行のコードごとです。多分彼らは10,000行ごとに到達するでしょうが、それはAIでそのバグを解決することを容易にするわけではありません。そして今、その経験をどのように得るかわかりません。本当にわかりません。これについて多く考えています。
ジュニア開発者向けのビデオのようなものでフォローアップをしたいと思っています。初期キャリアのエンジニアのために今これについてどう考えるか。そして何を言うか、推奨するかわかりません。自分がどのようにできるかわからない仕事をする方法としてではなく、やる時間がない仕事を分解して委譲する方法としてこれらのツールを使うことを試みることが本当に重要だと今でも思います。
それが彼らが最も強いときです。能力の欠如を回避するためではなく、自分自身の能力を倍増させるためにこれらのツールを使用しているとき。しかし今、それらの能力をどのように得るかわかりません。絶対的に最低限、特に早期で、時間をかけて維持したい実際のプロジェクトである実際のプロジェクトを立ち上げているときは、生成しているコードを読む必要があります。
手動でコードを書くことは依然として学ぶための非常に良い方法ですが、正直に言って、かなり深くなり、実際の人々が使用するものを構築する複数のプロジェクトに入るまで、おそらく質問をするためにチャットアプリを使用することを優先すべきだと思います。またはCursorのようなものを使用して、コードを変更しない質問モードを使用してもっと学ぶことでこれをショートカットできるかもしれません。
タブ補完と組み合わせれば、理解をレベルアップし続けることができます。でも、これは本当に急速に変化しています。そして私が決して期待しなかったことは、シニア開発者としての私のスキル、それは主にオーケストレーションと計画と並行して物事をやっている人々の管理です。その部分が今まで以上に重要になっているということです。これは一方では素晴らしいです。なぜなら今、多くの開発者が話すスキルをスキルアップするようになるからです。
プロンプティングは多くの点でエンジニアリングスキルというよりもコミュニケーションスキルですが、また同じ方法で細部まで学ばないかもしれません。これは難しいです。ここでの私のポイントが何なのか、私の困惑を表現する以外に本当にわかりません。おお、Leroがここにいます。そう、どうやら彼らはCursorに教師モードを追加しているそうです。これは実際に本当に本当に本当にエキサイティングです。特に彼らが学生層でこれをさせてくれるなら。
今後の開発者教育とツール
学校に通っている場合、無料で手に入れられます。ああ。ああ、それは本当に良いでしょう。また、Code Craftersのようなツールは私の意見ではこれまで以上に有用です。Code Crafters、Boot.devのようなもの、実際のプロジェクト構築を奨励するものです。これが今学ばなければならない方法です。そしてAIがあなたをブロックされにくくし、難しい部分を乗り越えるために誰かに助けを必要とする可能性を低くします。
ええ、これは深く入りすぎていることはわかっています。おそらくこれを考え抜く必要があります。座って、何が機能するかを本当に考え、業界に入ったばかりの最近の人々と話し、それから多分これについて専用のビデオを作るかもしれません。でも今は、それについての考えをどのように整理すればいいかさえわかりません。
視聴者としてのあなたにもう一つ質問です。もし私があなたに尋ねたら、Opusと比較してコードを書く知性と能力の面でどこに自分が当てはまると思いますか。自分をより良いエンジニア、ほぼ同じレベル、または悪いエンジニアと考えますか。どこに自分が当てはまると思いますか。そして私のチャットはどんな答えを出すと思いますか。その分裂はどうなると思いますか。ちょっと考えてみてください。
自分をどこに置くかのアイデアと、私自身の視聴者の分裂がどこにあると思うかを考えてください。結果の準備はできましたか。私の視聴者の61%がOpus 4.5が自分たちより良い開発者だと考えています。16%が逃げの答えをしました。13%が自分とほぼ同じくらい良いと言いました。そして10%が悪いと言いました。それが私たちのいる場所です。これらのものは馬鹿げたほど速く動いています。
今コードを書く方法は、少なくとも私が3、4ヶ月前にコードを書いていた方法とは全く異なります。それは年初とは全く異なり、それはその前の年とは全く異なります。しかし私のワークフローにおけるこれらの変化が起こる速度は凝縮しています。今では3ヶ月ごとに大規模な変化が起こります。
以前は6ヶ月ごとでした。それから1年ごとでした。それから数年ごとでした。狂っています。遅れないでください。私は近い将来、これらすべてに追いつく方法について専用のビデオを作るつもりです。Claude Codeの私自身の使用法についてのビデオももうすぐ来ます。それに注目してください。
私はそれについて非常にエキサイティングです。だからそう、このものを使い続けてください。新しいことを試し続けてください。そして最高のものを構築するために最善を尽くし続け、周りに存在するツールを利用してください。詐欺師や、私のように今日話したこれらのツールのいくつかに投資した人々を恐れているからといって、これらのものを却下しないでください。ほとんどありませんでした。
ただ構築することに集中してください。それが常にあなたを最も遠くに連れて行くものです。そして構築すべきものがこれまで以上にあります。そして構築する方法もこれまで以上にあります。私は今日ほどコードを愛したことはありません。たとえそれとの関係が1年前とは非常に異なっていても。そして自分自身を振り返り、これらのものを試してみることをお勧めします。
皆さんがどう思うか、そして今日これらのツールをどのように使用しているか教えてください。
コメント