本動画は、Claude Opus 4.5が実際の開発現場でいかに革新的な生産性向上をもたらしているかを実証する開発者の率直な体験談である。従来は数ヶ月単位で構想していた機能を数分で実装可能にするOpusの能力により、コーディングスタイルそのものが変化し、エディターモードよりもエージェントモードでの作業時間が長くなるという劇的な変化が生じている。GPT-5やGemini 3 Proとの比較を超越し、もはや他モデルとのベンチマーク自体に意味を感じなくなるほどの実用性を示すOpusは、プロトタイピングから本番コードまでをカバーする実践的な開発パートナーとして機能している。
Claude Opus 4.5との出会いが変えた開発スタイル
正直に告白しなければならないことがあります。最近、フラッグシップモデルについてずっと考えているんです。確かに今日はDeep Mindのシャツを着ていますが、これはたまたまFlash 3の発表日だったからです。Googleが本当に優れた新モデルをリリースしました。でも、以前ほど熱中できないんです。なぜなら、私が日々取り組んでいる問題をほぼ解決してくれるモデルを手にしているからです。
そのおかげで、コーディング量が増えました。通常ならここでモデルに関する画面に切り替えるところですが、今回はT3 ChatのGitHubの実際の画面をお見せします。10月以降、プルリクエストを一つも出していなかったのに、一日で7つも出すようになったんです。確かに忙しかったのは事実ですが、それにしても驚異的な変化です。
このコードがOpusによるものだというミームがたくさん出回っていることは知っています。実際、T3 Chatのアカウントが私をこう攻撃してきました。「レビューされたコードが良すぎる。彼のものではないはずだ。Opusに違いない」と。大部分はその通りです。でもこれは私が怠け者だとか、コーディングが下手だとかいうわけではありません。Opusがそれだけ優秀だからなんです。
コーディング体験を根本から変えたモデル
これはコーディングの仕方が少し変わった瞬間の一つになりました。GPT-5がこの感覚に最も近いものになると思っていました。でもOpusは違うレベルでインパクトを与えています。当初はOpus対5.2対Gemini 3 Proといったより詳細な比較動画を作る予定でした。でも、そんなことをする気になれません。もう気にならないんです。ただOpusを使いたいだけなんです。
様々なモデルを比較したり、ベンチマークを実施したりする時間を使うくらいなら、Opusで開発していたいんです。チャートや評価指標、そういったものに時間を費やすくらいなら、Opusを使っていたいんです。新機能やプラン、T3の将来について議論する時間があるなら、Opusでプロトタイピングしていたいんです。
本当に優れたモデルで、最初の動画では十分に評価できていなかったと思います。まだ毎日使っていなかったからです。今は数週間、継続的に開発に使い続けて、もっと多くのことを語れるようになりました。ただ、推論にかける費用も通常より大幅に増えていて、誰かがこの請求書をカバーしなければなりません。
Convexが実現する開発体験
今日のスポンサーであるConvexについてお話しします。以前も紹介したことがあると思いますが、今回はすべての機能を説明するのではなく、文字通り今日やっていたことをお見せします。T3 Chatのwrapped機能をリリースしたばかりで、構築は大変でしたが、Convexのおかげで多くの部分がはるかに簡単になりました。
Convexのツールスイートをほぼすべて使っています。Convexダッシュボードで、T3 toolsアカウントにある異なるプロジェクトを確認できます。本番環境や、今ノートパソコンで動いている開発環境をdevをクリックして確認できます。
環境全体、実行中のすべての機能、存在するすべてのデータが見えます。これには作業中の機能のwrappedデータも含まれています。このデータを削除すると何が起きるか見てください。削除しました。ここに戻ると消えています。再計算中です。最適化を加えたばかりなので、かなり早く処理されるはずです。
このコードは複雑に違いないと思うでしょう?いいえ、違います。定義したAPIでuse queryを使うだけで動作します。誤解しないでください。複雑さを隠しているわけではありません。すべての問題を解決する魔法の特効薬を提供しているわけでもありません。彼らが提供しているのは、はるかに扱いやすい異なるプリミティブです。
ここにT3 Chatでwrappedを生成するワークフローがあります。これは失敗時に再試行して再実行できる異なるアクションです。この場合、かなり高い失敗率を持つ大きなリクエストでPosthogにアクセスしているので、これらのステップはそれぞれ実行され、失敗時に再試行されます。これにより、エラー率が約14%から基本的にゼロまで下がりました。実行ごとに1、2回再試行するだけです。
これはすべてファイルの先頭にあるワークフローで定義されています。並列処理の程度から、再試行回数、各再試行中のバックオフ時間まで、すべてが定義されています。対処するのに疲れていたこういった小さなことすべてを、Convexはコードベース内のファイルにしてくれます。
設定するダッシュボードもなく、変な作業もなく、同期を機能させるためのカスタム作業もありません。ターミナルのこのエラーを見てください。データベース内のデータがスキーマの形状と一致しないため、今は変更をプッシュできないと教えてくれています。このデータを削除します。すると、ターミナルが自動的にプッシュを開始します。
コマンドを打ったり、何かを再実行したりする必要はありませんでした。Convexによって私の生活から消えたこういった小さな問題の数は圧倒的です。Convexを使っていないプロジェクトに戻るたびに、すべてをConvexに移植します。対処するのに疲れたすべてのことに対処するより、Convexに移行する方が簡単だからです。
実際の開発事例:レガシーモデル機能
簡単なプルリクエストから始めましょう。これはOpusによって全く書かれていません。比較的簡単なものです。面白いですね。この動画はOpusがどれだけ好きかについてなのに、最初のプルリクエストはT3 ChatのデフォルトをGeminiに変更するものです。矛盾しているように見えますが、Opusは会話したり一般的な質問をしたりするのに最適なモデルではないと今でも思っています。
Opusは働き馬です。ハーネスが必要なモデルです。馬が何か取り付けられていないとカートを引けないのと同じように、Opusは何かに乗られたり制御されたりしないと役に立ちません。Geminiは会話に最適で、だからデフォルトにしました。でも、このレガシーモデルのプルリクエストのような他のものは、長い間T3 Chatで欲しかった機能です。
たくさんのモデルがあるので、UIをすべてで散らかすのではなく、このレガシーモデルセクションに詰め込むことができます。結果的に、80~90モデルのうち55が今やレガシーになりました。良いUIと良いパターンでこれを実行するのは、例えばスレッドをフォークしたい場合、これは私のT3 Chatのお気に入り機能の一つですが、これを分岐させて別のモデルを選び、新しいDeep Sequenceのいずれかを選ぶか、レガシーモデルを表示してそれらのいずれかを選ぶことができます。
このUI、この機能性のすべては、ほとんどがClaude Opusによるワンショットパスでした。Cursorの実際のT3 Chatコードベースにいます。このノートパソコンを最近セットアップしたばかりなので、すべての履歴はここにありませんが、チャットアーカイブ機能から始めました。上にスクロールすると、スクリーンショットとプランを渡しました。
スクリーンショットはコアUIだけでした。ちょっとしたヒントを与えたかっただけです。これにアーカイブチャット機能を追加しています。ああ、これはアーカイブチャットだけのものです。レガシーモデルはもっと古いものでした。いいですね。冒頭で、ユーザーに圧倒的にならないようにモデルの表示方法を変更したいです。主な変更はレガシーモデルを作ることです。すべてのモデルが表示される代わりに、古いバージョンのモデルはレガシーとしてタグ付けされ、何らかの折りたたみの下に置かれるべきです。
つまり、GPT 5.2があるので、5.1はレガシーになるべきです。新しいフラグを追加して、それに応じてUIを更新してください。そうしたら実行しました。レガシー用の新しいタグを追加しました。レガシーのtrue/falseでモデルを更新しようとしましたが、ほぼすべてを間違えました。そこで、手作業ですべてのモデルにタグを付ける必要があり、これが断然最も遅い部分でした。
幸いなことに、私はすべてのモデルをよく知りすぎているほど知っているので、これを比較的早くできました。でも、AIはそれができませんでした。この種の奇妙なデータ作業があまり得意ではなかったのは変です。でも一方で、実際の実装は本当に素晴らしかったです。
ファイルを読み込んで、構造を理解しました。レガシーモデルをマークしましょうといくつかマークしました。マークしたのはClaude 3.5でした。Claude 3.5が古いことは知っていましたが、他のものはあまり知りませんでした。ベストを尽くしましたが、あまり正確ではありませんでした。それからUIパスを実行しました。ソートを作成しました。状態を作成しました。必要なものすべてを作成しました。
本当に良い仕事をしました。型チェックとlintチェックを実行して、すべてが正常であることを確認しました。小さなミスを見つけました。欠けている依存関係を見つけました。それを処理しました。そして、何をしたか教えてくれました。フィルタリングが機能していないと思うと言いました。非常にわずかに変更しました。それから良くなったようでした。そして、すべての手動タグ付けを実行して、完成しました。
フィルタリングが機能しているかわからないと言った1回のやり取りでした。いくつか変更して、良くなりました。プルリクエストを提出し、マージされ、今では出荷されています。これが私とAI、主にAIによって行われたすべての変更です。oxintにレガシーフィールドを追加しました。これをすべて正しい順序で持っていることを確認するlintプラグインがあり、Juliusがそれを追加するよう頼みました。
これは私がやりました。この1つの文字列、アーカイブアイコン、これらすべてのUIはOpusによって作成されました。まだすべてOpusのコードです。すべてOpusのコードです。まだすべてOpusのコードです。そして、折りたたまれているmodel DBファイル、それは私がやりました。なぜなら、レガシーをたくさん追加したからです。ここにレガシーを持つ型、それはOpusでした。
おわかりでしょう。私はあまり作業をしていません。コードを読みました。うまく機能することを確認しました。でもこれは何ヶ月も欲しかった機能で、チームの誰も座って考えて実装する時間がありませんでした。だからOpusに指示したら実行してくれました。非常に少ない追加指示でワンショットで。
アーカイブ機能の実装
この時点で、このモデルとの関係が変わりつつあることに気づき、もう少し先に進みたいと思いました。これでどこまで行けるか見たかったんです。以前から欲しかった別の機能、チャットのアーカイブについて尋ねました。このブランチに素早く切り替えましょう。まだブランチとして残っているので。アーカイブスレッドです。基本的なアーカイブがあります。
アーカイブが欲しかったんです。メインコンテンツではないけれど、ここに表示したくない、でも削除したくないものをアーカイブに入れられるようにです。そこに行ってそれらを見ることができます。オブジェクトにバリデーターにない余分なフィールドshow archiveが含まれています。追加の変更が行われ、適切にプッシュされたかわからないためです。
document IDとthread tablesが一致しません。わかりました。それは変更されました。それを削除させてください。実際、Convexについて本当にクールだと思うことの1つをお見せしたいんです。コードベースの変更が今Convexのデータベースにプッシュできません。データベース内のデータがスキーマの形状と一致しないからです。
これを修正したらどうなるか見てください。どのthread IDか教えてくれました。この特定のthread IDを見つけることができます。実際にやってみましょう。これがこの行です。これが悪いものです。もう存在しないフィールドがいくつかあるからです。これを削除します。すると、Convexに関数をアップロードしています。できなかったのに、今はできます。
他にも悪いフィールドがあるようです。でも、Convexのライブアップデートがそこまで行くのはどれだけクールですか?ユーザー体験をライブアップデートするだけではありません。データベースとそれにプッシュするコードもライブアップデートしています。ここで最も簡単な解決策は、ローカルDBのすべてのスレッドを削除することです。必要ありません。
すると、再びプッシュしています。selected proのせいで壊れているようです。プロファイルの作業をしていました。だからすべてが壊れているんです。関数の準備ができています。でも、オブジェクトにスレッド内の余分なフィールドvisibilityが含まれています。すべてのスレッドを消したと思いました。消していません。メッセージかもしれません。何でもいいです。
これをすべてクリアします。新しいスレッドを作ります。テスト。テスト2。テスト3。3つのスレッドができました。すべてが期待通りに動いているようです。右クリックして、アーカイブ。このスレッドが消えました。アーカイブに行くと、ここで見えます。ローディング状態は、Opusで行った別のプルリクエストで修正しました。
でも、このような機能、ユーザー体験全体の動作を分割する機能も、ワンショットだったのはどれだけクールですか。Cursorがこれをどう処理したか見てみましょう。公平に言うと、伝統的なワンショットではありませんでした。プランを作らせました。このアプリにアーカイブチャット機能を追加しています。アーカイブはスレッドの右クリックメニューのオプションであるべきです。
アーカイブされたスレッドは、UIのどこか論理的な場所にあるアーカイブボタンからアクセスできるべきです。変更を計画してください。参考のために現在のUIの状態を添付しました。少しスクロールします。プランが見つかります。ここにプランがあります。プランがCursorでひどく壊れているため、壊れているようです。消えました。
本当にクールですね。ありがとう、Cursor。プランはもう存在しません。Cursorがファイルの動作を知らないからです。Claude Codeでこれの多くをやってみましたが、Claude Codeはさらに嫌いでした。CursorはOpusを使う私のお気に入りの方法です。他にも十分うまく機能するハーネスはたくさんあると確信していますが、Cursorのプランモードは、バグと戦う意志があれば、それだけの価値があります。
今週初めに彼らのオフィスにしばらくいて、これらのバグについて不満を言っていたように、彼らとたくさん座ってきました。機能を出荷するだけでなく、これを修正するために多くの時間を費やすと約束しています。エディターが安定したら信じます。彼らは薄氷の上にいて、Cursorクラッシュアウト動画は彼らがこれらのことに対処することを待っています。
プラン機能の実装
それにもかかわらず、プランをお見せできません。彼らがプランを食べてしまったからです。エディターが機能しないからです。それを知っておいてください。それにもかかわらず、私の言葉を信じてください。プランは問題ありませんでした。いくつか小さな変更を加えるよう頼んで、実行しました。そして、構築するよう指示すると実行しました。To-Doがあります。Convexに新しいインデックスを追加する必要があります。
Convexにshow archiveパラメータを追加する必要があります。visibilityも追加する必要があります。次に、サイドバーにuse archive thread mutationフックを作成します。コンテキストメニューにアーカイブとアーカイブ解除アイテムを追加し、サイドバーフッターにアーカイブボタンを追加します。これで、すべてが見えます。そして、これらすべてを驚くほど素早く実行し、良い結果を出しました。
期待通りに動作しました。満足しました。最後に、クライアント状態でやっているだけだったので、クエリパラメータを使ってやりたかったんです。リフレッシュすると奇妙な状態になり、適切なタイミングで適切なメッセージを表示するのが難しかったです。question mark archive equals trueのクエリパラメータを入れるよう頼みました。
これらの問題の多くが修正されました。本当に良かったです。驚くほど有用で機能的なものを作りました。いくつか小さな指摘がありました。指摘が何かを伝えました。指摘を修正して、人生が続きました。この時点で、このモデルの能力は思っていたより大きいことに気づいています。それほど難しくないけれど、多くの部分に触れるものを頼みました。
見ての通り、このバージョンのT3 Chatのローディング状態はあまり良くありません。リフレッシュすると、ぼやけた大きな塊がある巨大なスケルトンが表示され、ローディングが完了すると消えます。これは私にとって不快でした。幸いなことに、今T3 Chatに行くと、そうなりません。左下ではまだやっています。
好きではありませんが、修正する計画があります。でも、本番のT3 Chatに行くと、テストに使えるものは何ですか?コーギーがスケートボードをしているのを使います。これでリフレッシュします。今はすべてが素敵にエレガントにフェードインします。この変更はOpusで2回行いました。最初はサイドバーだけを修正したかったんです。サイドバーの見た目が本当に悪かったので。それだけをやるよう頼みました。
このアプリのローディングスケルトン状態の動作が気に入りません。ログアウトしたユーザーには、存在しないスレッドがたくさん表示されてひどいです。ログインしたユーザーにとっても、コンテンツが入る前に表示されるコンテンツが多すぎて悪いです。より最小限のスケルトンと、スレッドが出現時にフェードインするような、より良いローディングアニメーションを好みます。そうしたら実行しました。
かなりまあまあの仕事をしました。正直に言うと、処理方法には感心しませんでした。最初は動作すらしませんでした。スレッドリスト全体にフェードインをしていましたが、データのロードはスレッドリスト内で起きていました。だから、トリガーしてからデータをロードし、以前と同じようにポップインしていました。文句を言いました。
実際、最初のパスでUIを完全に壊しました。こんなことをしました。通常この時点で、フレッシュショットをして、より良い指示を与えるのですが、このモデルは良いんです。継続してほしかったんです。何をしたかわからないけど、これは超壊れていると伝えました。transform in my animationが、各アイテムを正しく配置するvirtualizer translate Yの位置をオーバーライドしています。
リストの仮想化がtransformを壊していることに気づいたのは良い認識でした。だから、それを取り除いて修正しました。でも、問題は上下にスクロールすると、アイテムがDOM上に再出現するため、再フェードインすることでした。これを言いました。リストが仮想化されているため、上にスクロールすると、すべてのコンテンツが再フェードインします。
ここで「ユーザーが正しい」が出てきました。見るのがとても面白いです。その通りです。仮想化リストはスクロールするとアイテムをアンマウントして再マウントします。だから、アニメーションが毎回再生されます。スレッドアイテムからフェードインを削除しましょう。そこから削除しました。アニメーションがなくなりました。だから、トップに追加しました。これは実際にはるかに良くなりました。
データが最初にロードされるとスレッドリストが一度フェードしますが、個々のアイテムはスクロールしても再アニメーションしません。コンテナのアニメーション、最初のアイテムのアニメーションではありません。素晴らしい。はるかに良く見えました。でも、常にローディングスピナーを表示していました。気に入りませんでした。だから、伝えました。2~3秒経過するまでローディングスピナーを遅延させられますか。
すぐにJavaScriptでやろうと急ぎました。私はJavaScript派ですが、JSでやるべきものではありません。そう言いました。これもまた、モデルがすべての作業をしているわけではないようなものです。驚くほど多くの作業をしています。これは、かなりスキルがあるけれどそれほど知識豊富ではない従業員とやり取りするようなやり取りのように感じます。このすべてのやり取りには数日かかるでしょうが、代わりに約2分で起きています。
なぜJSでやるんですか?2秒間出現を遅延させるCSSアニメーションを付けられないんですか?また「ユーザーが正しい」です。素晴らしい指摘です。CSSの方がはるかにクリーンです。追加したばかりのJSをすべて削除し、単一のfade in animation delay 2秒のようなものを追加して、今は良くなりました。そして、チャレンジを与えました。
明確にするために、この部分は十分気に入ったので、ブランチを作って、コミットして、プルリクエストを提出しました。でもこの時点で、Opusが何をしているかわかっているというハイな状態にいました。だから、さらに先に進むよう頼みました。これは素晴らしい見た目です。でも、難しいものがあります。ロードしなければならない主要なコンテンツが2つあります。メインチャットビューとサイドバースレッドです。
両方を同時にフェードインさせたいんです。スレッドリストのロードは、メッセージコンテンツよりわずかに長くかかります。両方がロードされてから、どちらもレンダリングするようにしてください。プランモードに切り替えました。これがミスナンバーワンでした。Cursorでプランモードに切り替えると、たくさんのランダムなものが壊れるからです。
このプランはまだ見えるかもしれません。いいですね。これはまだ存在します。ここに書いたプランがあります。協調フェードインローディング。これは更新版だと思います。そうですね。最初に書いたプランはダメだったので、これは更新版です。ここのTo-Doがまだ間違っているのでわかります。適切に更新できなかったからです。
この間に遭遇した奇妙なCursorのバグの量は驚異的です。幸いなことに、彼らはすべてに取り組んでいますが、これについて彼らと30メッセージのSlackスレッドがあります。今のところプランモードをやるなら、プランモードで始まる新しいフレッシュスレッドで常に行ってください。さもないと、彼らが非常にゆっくり修正している多くの厄介なエッジケースに遭遇します。
とはいえ、作ったプランはダメでした。特に、すべての完了チェックをアトミックステート、つまりスレッドとメッセージローディングのページロードの両方に存在するジョディピースのようなものに移動して、完了したときに相互に通知するために同期するつもりでした。これは本当にダメで悪いです。
これはデータローディングを集中化することで行われるべきで、完了したかどうかを明確に示す状態を持つべきです。正直、これはモデルが明らかに間違ったジュニアなことをしているのを見た最初の機会で、ちょっと腹が立ちました。
だから、そう言いました。Atoms以外にできる戦略はありますか?suspenseのような、データローディングを共有するとか、両方をロードするフックとか。オプションを提案しましたが、すべて嫌いでした。実際の答えがわかっていたからです。だから、やらせました。いくつかのメッセージが削除されたと思います。To-Doを更新していなかったため、何度も再試行して元に戻したからです。
何らかの理由で、モデルはプランを更新できましたが、インラインで新しいTo-Doを作成していて、これらのTo-Doを更新していませんでした。本当に厄介でした。CursorとどのセットのTo-Doをbuildを押したときに使うかについて、継続的な賭けをしていました。私が正しくて彼らが間違っていました。間違ったセットを使いました。
Cursorが私たちを少し後退させています。うまくいけば、これはすべて近い将来に修正されるでしょう。この動画が公開される頃には修正されているかもしれません。わかりません。修正されていたら、コメントで知らせます。それにもかかわらず、新しい提案としてuse app content readyフックを作りました。どこかの時点で、フック内で2つがローディングしているかチェックするだけと伝えました。
これは基本的に実装するよう伝えたものです。ページクエリからステータスを取得し、他のスレッドデータクエリのis loadingを取得して、どちらかがローディングしているかチェックします。どちらもローディングしていなければ、完了です。どちらかがローディングしていれば、完了していません。use content readyがtrueになったら、完了です。これはすべてReact queryを内部で使っているので、これらのフックを複数の場所で呼び出しても関係ありません。
すべてバッチ処理され、一緒に処理されます。超素晴らしいソリューションです。結局、はるかにクリーンになりました。望んでいたものを構築しないように伝えて、代わりにこれらの変更を加えたからです。でも、プランが修正されたら、これがプランモードをとても好きな理由の一部ですが、悪いコードを記述する計画を読んで修正してもらうのは、実際に悪いコードを生成してもらうよりはるかに快適です。
悪いコードを読むのは、悪いプランを読むよりはるかに遅くて苦痛です。悪いプランを修正する方もはるかに簡単なので、その後良いコードを得られます。一般的に言えば、Opusが入る前に良いプランを持っている限り、ほぼ完璧に実行します。これらすべての例で気づくでしょうが、プランが設定されて進めと伝えたら、ほとんど他に何もさせません。
このやり取りはすべてプランについてで、プランが終わったら、フォローアップはありませんでした。動作したからです。この時点で、感心しています。Cursorには不満がありますが、モデルの能力には感心していて、さらに先に進みたいんです。私という人間の性質上。だから、手を伸ばしました。遠くまで手を伸ばしました。
プロファイル機能の本格実装
長い間T3 Chatで欲しかった機能がプロファイルです。アイデアは、ChromeやArcでプロファイルを持っているように、仕事用、個人用、その他何でも、T3 Chatでもそれらを持てるというものです。コード用に1つ持てます。それは公開しているものです。あまり共有しない、よりパーソナルなものを1つ持てます。
より伝統的な、チャットが自動的に消える一時的なチャット用に1つ持てます。それらに異なるプロファイルを入れられます。システムプロンプトに異なる設定を入れられます。このプロファイルのアイデアが本当に好きです。これを出荷したいんです。
チームの誰もこれを試したり構築したりする時間がありませんでした。だから、モデルがやってくれたらどうなるか見てみることにしました。プランを作るよう伝えました。スレッドの保存方法に大きな変更を導入したいです。コンセプトはプロファイルです。1人のユーザーは、名前、カスタムパーソナライゼーション、色、アイコン、スレッドを持つ多くのプロファイルを持てます。
例えば、個人用、仕事用、コード用です。それらを切り替えると、サイドバーにそのプロファイルで作られたスレッドが表示されます。これは、特定のコンセプトやアイデアに基づいてスレッドをグループ化する方法になります。Convexスキーマにプロファイルを実装し、新しいインデックスでスレッドにリンクする必要があります。十分です。シンプルな説明、どこから始めるかの基本的なアイデア。プランを作りました。
ロードしないプランです。Cursorにひどく腹が立っていたので、これを失いたくないほど大きかったため、保存したと思います。ブランチを切り替えたら、プランがこのブランチにありました。見えるようになりました。プロファイル機能実装、スキーマ変更、これらのスキーマ変更を提案しました。
スレッドテーブルを更新します。ユーザー設定を更新します。定義する必要がある新しいConvex関数。素晴らしい。十分良さそうでした。質問しました。これのUIを作成することは、プランの一部であるべきですか、それとも別のプランであるべきですか?これはすべてバックエンドの変更だけだからです。バックエンドだけをここでやって、UIは別のプランとして保つべきだと思うと伝えてきました。
やってみようじゃないか、確かに。この旅に参加しています。どこに行くか見てみましょう。構築するよう伝えたら構築して、すべて問題なさそうでした。これで実装されました。おそらく動作します。UIがなかったのでテストは簡単ではありませんでした。そこで、UIプランを構築しに行きました。T3 Chatのプロファイルに適切なUIを作りたいです。
重要な部分は、サイドバーのドットメニューでそれらを切り替えることです。それと、プロファイルに必要な他のUIの実装方法を計画しましょう。既存のスタイルシステムを使用し、アプリが今どのように見えるかの一般的な雰囲気に従ってください。すでに完了したバックエンドプランを参照し、そのプランへのリンクを付けました。そして、新しいプラン、フロントエンドプランを作成しました。
コンポーネントがどのように関連するかのアーキテクチャを作りました。構築する必要があるフックの実装詳細、プロファイルスイッチャーを作りました。どのように見えるかの素敵な小さなテキストモックUIまで作りました。プロファイルダイアログコンポーネント、サイドバーへの統合、スレッドクエリの更新。
これに徹底的な読みではなく十分な目を通してから、To-Doを深く見て、かなり良いと思いました。だから、buildボタンをクリックして、構築して、構築して、構築して、成功しました。でも、バグがありました。デフォルトプロファイルから切り替えると、未定義のプロファイルだったため、戻れませんでした。
だから、偽のデフォルトプロファイルを入れてエッジケースをふさぐ必要がありました。すべて動作するようになりました。default defaultと表示されるのが気に入らなかったので、修正するよう伝えました。修正しました。ローカルホストに行くと、デフォルトプロファイルがあります。仕事用プロファイルがあります。仕事用にしかないスレッドがあります。
デフォルトに戻せます。ここに異なるスレッドがあります。どこかの時点で何か別のものを壊しましたが、新しいものはうまく動いています。そのデータのリンク方法について何か変更しました。それにもかかわらず、おわかりでしょう。機能全体を構築しました。少なくとも9ヶ月間考えていた機能です。
冗談でGPT-5でテストした機能で、コードベースに72個の型エラーを追加し、コンパイルすらできず、使えるものを作ることもできませんでした。だから、これはモデルで構築できないタイプのものだと思い込んで、限界がどこにあるか見てみようと、ヘイルメアリーとしてOpusに投げつけました。
そしてまた、意味のあるプランを与えれば、ほとんど動作するコードを提供してくれます。対処しなければならない小さなエッジケースは常にありますが、それらを乗り越えれば、完全に機能するものが得られ、チームの厳格なコードレビューをパスします。チームにレビューを依頼する前に、これらに正直な目を通しました。
自分でまだ読んでいないコードをチームにレビューするよう頼む人には決してなりません。でも、神のご加護を、GraileとCode Rabbitが本当に良いパスをして、最初に物事を見つけてくれました。ちなみに、両方ともプロファイルコードをこき下ろしました。たくさんのコードです。約3,000行です。変更しなければならないことがたくさんあるからです。
その多くは生成されたConvexのものと、プランをコミットしたことです。残しておきたかったんです。これは悪いマージコンフリクトのせいです。修正できます。その多くが実際に悪いマージコンフリクトだと思います。それで差分がそれほど悪くなくなるか見てみましょう。今は1,000行だけです。それはもっと理にかなっています。1,000行の変更です。少なくとも3分の1は生成されたファイルだと思います。生成された変更です。実際、生成されたのは2行だけです。
Lorはすべて本物のコードで、ほとんどが非常に意味のあるコードです。Graileはそれについて意見がありますが、問題ありません。これは、いくつか変更せずには出荷しないコードですが、少なくとも完全な機能を実装することがどのように見えるかを見させてくれ、それを使うことがどのように感じるかの感覚を与えてくれます。これは大きな、大きな勝利です。ほぼ1年間頭の中にあったこの機能を取り上げて、プロトタイプを構築するのに数日かける必要があると思っていたものを、1時間でできるようになったのは狂っています。
コーディング方法を根本的に変えたものでした。これは、プロトタイプを作る価値があるかどうかのラインを完全に越えていました。このようなフィーチャーアイデアがあるとき、通常のイベントの順序は、深く考えて、チームと話し合って、プランをスケッチして、最終版がどのように見えるかを考え出してから、実行することです。今は、アイデアがあれば、20分かけてOpusでさっと作るかもしれません。
巨大な機能追加や、データレイヤーの根本的な変更や再設計であっても、ほとんど関係ありません。これが私たちのデータベースをConvexから何か別のものに変更できますか?いいえ、おそらく無理です。でも、想像できるほぼすべての機能を、プロトタイプやテストに使える動作する形式で構築できますか?絶対にできます。
たった2日間で、7つのプルリクエストを提出し、そのすべてがコードの大部分をOpusによって書かれました。シンプルなものは超簡単にこなしました。小さなミスをした中程度のものは、簡単に調整し、修正して、本番に出荷しました。非常に少ない誘導で、プランニングフェーズでの少しの助けだけで、この巨大な見直しで、ほとんどのエンジニアに同じ作業をさせた場合に期待するより良いものを構築できました。
AIが私たち全員をエンジニアとして置き換えるとここに座って主張するつもりはありません。これのために多くの誘導をしなければなりませんでした。でも、何だこれは。これは、2020年代の終わりまでにこのレベルになると思っていたものをはるかに超えています。2025年の終わりなんて言うまでもありません。このものがどれだけ良くなったか信じられません。ここに座ってモデルをもっとからかえたらいいのにと思います。
本当にそう思います。癖があり、たくさんからかってきました。でも、本当に良いんです。適切に紹介していないと思います。他の多くの人もそうしていないと思います。これは、何ヶ月、何年も頭の中にあった機能の本物の本番作業が、数分で完成するものです。AIが私を10倍生産的にしたというあのことを、私たちはいつもバカにしています。
バカにし続けてください。バカげています。でも同時に、このモデルとそれがどれだけ簡単にしてくれたかがなかったら、T3 Chatにない本物の機能です。機能追加がこれほど簡単だったことはありません。とはいえ、機能のクリープも問題になります。このパスを長期的に探求し続けたいなら、これらのモデルはデバッグやエッジケース、エラーの理解においてはるかに優れている必要があります。
バグに遭遇してOpusに助けを求めたとき、しばしば解決したのと同じくらい多くの新しいバグを引き起こしました。これらのより深いニッチなCSSバグタイプの問題のいくつかについて、GPT-5に戻ることになりました。それでも2回しかする必要がありませんでした。びっくりです。このものがこんなに良くなるとは思っていませんでした。
今日のように使うとは確実に思っていませんでした。タブ補完がかなりクールだから、エディターモードよりエージェントモードで過ごす時間が長くなり、Cursorでそうなったスピードは狂っています。実際、Command Eを押してエディターモードに戻ることを気にすることが珍しくなっています。
それは、バグだらけで2つのモードの分割方法が悪いからというだけではありません。そうです。そのことについてチームと長い講義をしました。エージェントモードが素晴らしいからというだけです。ファイルをチェックする必要がありません。モデルを正しい場所に誘導する必要がありません。モデルを正しいソリューションに誘導します。
それは私にとって大きな精神的シフトです。Opusの能力に非常に驚かされて、ここに座ってそれについて話さなければなりませんでした。脳が壊れています。ためらっていたなら、うまくいけばこれがあなたも試してみるきっかけになります。このモデルは根本的に違うからです。試してみてください。
感心するかもしれません。私は感心しました。これは小さなコードベースでもありません。世界最大のコードベースだとここに座って主張するつもりはありませんが、60,000行のTypeScriptは冗談ではありません。すべてがどこにあるかを知って、効率的に良い変更をする能力、本当に印象的です。びっくりしています。
コードの品質とOpusができるコードベースの理解の一貫性に非常に、非常に感心してきました。試してみてください。ここに座ってバカにしたいんです。できません。このモデルは素晴らしいです。コーディング方法を変えています。あなたにとってもそうなるか気になります。
私がただ狂っているのか、これが本当にこんなに良いのか?皆さんがどう感じるか気になります。どう思うか教えてください。次回まで、またねオタクたち。
コメント