最近はここでの投稿が減っていますが、それは最新のプロジェクトに没頭しているからです。エージェンティックエンジニアリングが非常に優秀になり、今では私のコードのほぼ100%をAIが書いています。それなのに、多くの人が問題を解決しようとして、複雑な仕組みを作り上げることに時間を費やし、実際に成果を出すことから遠ざかっているのを見かけます。
この記事は、昨夜ロンドンで開催されたClaude Code Anonymousでの会話に触発されたものであり、またAI時代の1年が前回のワークフロー更新から経過したためでもあります。近況報告の時間です。
基本的な考え方はすべて有効なので、コンテキスト管理のような単純なことは再度触れません。入門として最適なAIワークフローの記事をお読みください。
コンテキストと技術スタック
私は一人で作業しており、現在のプロジェクトは約30万行のTypeScript Reactアプリ、Chrome拡張機能、CLI、Tauriのクライアントアプリ、Expoのモバイルアプリで構成されています。Vercelでホスティングしており、PRを出すと約2分で新バージョンのウェブサイトがテスト環境にデプロイされます。その他（アプリなど）は自動化していません。
開発環境と全体的なアプローチ
日常的にはcodex cliを使っています。3×3のターミナルグリッドで3〜8個を並列実行し、ほとんどが同じフォルダ内で動いています。実験は別フォルダに分けることもあります。worktreeやPRも試しましたが、この構成が最も速く成果を出せるため、いつも戻ってきます。
私のエージェントはアトミックコミットを自分で行います。クリーンなコミット履歴を維持するために、エージェントファイルを何度も改良しました。これによりgit操作が正確になり、各エージェントは自分が編集したファイルのみをコミットします。
Claudeにはフックがありますが、codexはまだサポートしていません。ただ、モデルは非常に賢く、やる気があればどんなフックも突破します。
以前は並列エージェントを使っていることでスロップ生成機と揶揄されましたが、並列エージェントが徐々にメインストリームになってきているのは喜ばしいことです。
モデルの選択
ほぼすべてをgpt-5-codexの中程度の設定で構築しています。賢さとスピードのバランスが良く、思考の深さを自動調整してくれます。この設定を過度に考え込んでも意味のある結果は得られず、ultrathinkを気にしなくていいのは楽です。
影響範囲（Blast Radius）💥
作業するとき、私は常に「影響範囲」について考えます。この言葉は私が考えたものではありませんが、気に入っています。変更を考えるとき、どのくらいの時間がかかり、何ファイルに影響するかの感覚があります。コードベースに小さな爆弾をたくさん投げることも、「ファットマン」と少数の小さな爆弾を投げることもできます。大きな爆弾を複数投げると、分離されたコミットは不可能になり、何かが間違ったときにリセットするのが難しくなります。
これはエージェントを見守る際の良い指標でもあります。予想より時間がかかっている場合、escapeを押して「status」と聞いて状況を確認し、モデルを正しい方向に導くか、中止するか、続行するかを判断します。途中でモデルを止めることを恐れないでください。ファイルの変更はアトミックで、中断したところから再開するのが非常に得意です。
影響が不明な場合は「変更する前にいくつかの選択肢を示して」と頼んで見積もります。
なぜworktreeを使わないのか？
私は1つの開発サーバーを動かし、プロジェクトを進化させながらクリックして複数の変更を同時にテストします。変更ごとにツリー/ブランチを持つと大幅に遅くなり、複数の開発サーバーを起動するのもすぐに面倒になります。Twitter OAuthの制限もあり、コールバック用に登録できるドメインが限られています。
Claude Codeはどうなのか？
以前はClaude Codeが大好きでしたが、今はもう耐えられません（codexはファンですが）。その言い回し、「絶対に正しい」という表現、テストが失敗しているのに「100%本番環境対応」というメッセージ——もう無理です。Codexは黙々と作業を進める内向的なエンジニアのようで、とにかく成果を出します。作業開始前に多くのファイルを読むため、短いプロンプトでも通常は望み通りの結果が得られます。
私のタイムラインではcodexが正解という広いコンセンサスがあります。
codexのその他のメリット
- 約23万トークンの使用可能コンテキスト（Claudeの15.6万に対して）。Sonnet 100万トークンは運が良いかAPI料金を払えば使えますが、現実的にはClaudeはコンテキストを使い切る前に非常に不安定になります。
- より効率的なトークン使用。OpenAIが何をしているかは分かりませんが、Claudeより遥かにゆっくりコンテキストが埋まります。Claudeでは「Compacting…」を常に見ていましたが、codexでコンテキストを使い切ることは稀です。
- メッセージのキューイング。Codexはメッセージをキューできます。Claudeにもこの機能がありましたが、数ヶ月前にメッセージがモデルを「操舵」するように変更されました。codexを操舵したい場合はescapeを押してenterで新しいメッセージを送るだけです。両方のオプションがあるのは遥かに良いです。関連する機能タスクをキューに入れることが多く、確実にこなしてくれます。
- スピード。OpenAIはcodexをRustで書き直し、それが表れています。非常に高速です。Claude Codeでは数秒のフリーズが頻繁にあり、プロセスがギガバイトのメモリを消費します。Ghosttyでは特にターミナルのちらつきもあります。Codexにはそれがありません。非常に軽量で高速に感じます。
- 言語。これは私のメンタルヘルスに本当に違いをもたらします。Claudeには何度も叫んできました。Codexに怒ることは稀です。たとえcodexが劣るモデルだったとしても、この一点だけで使うでしょう。両方を数週間使えば分かります。
- あちこちにランダムなmarkdownファイルが散らばらない。分かる人には分かる。
なぜ○○ハーネスを使わないのか
私の意見では、エンドユーザーとモデル会社の間にはあまりスペースがありません。サブスクリプションが断然お得です。現在OpenAIのサブスク4つとAnthropicのサブスク1つで、月額約1000ドルでほぼ無制限のトークンを使っています。API呼び出しだと、これの約10倍のコストがかかるでしょう。この計算は正確ではありませんが、ccusageなどのトークンカウントツールを使った概算です。5倍だとしても十分お得です。
ampやFactoryのようなツールがあるのは良いことですが、長期的に生き残れるとは思えません。codexもClaude Codeもリリースごとに良くなっており、同じアイデアと機能セットに収束しています。一部はより良いTodoリストや操舵、細かなDX機能で一時的な優位性を持つかもしれませんが、大手AI企業を大幅に上回ることはないでしょう。
ampはGPT-5をドライバーとして使わなくなり、「オラクル」と呼んでいます。一方、私はcodexを使って基本的に常に賢いモデル、オラクルで作業しています。ベンチマークはありますが、使用数の偏りを考えると信用していません。codexはampより遥かに良い結果を出します。ただし、セッション共有についてはampを褒めるべきでしょう。興味深いアイデアを先に進めています。
Factory、確信が持てません。彼らのビデオは少しきついですが、タイムラインでは良い評判を聞きます。画像はまだサポートされておらず、特徴的なちらつきがあります。
Cursor…タブ補完モデルは業界トップです。まだ自分でコードを書いているなら。私は主にVS Codeを使っていますが、ブラウザ自動化やプランモードを推進しているのは評価しています。GPT-5-Proも試しましたが、5月に私を悩ませたのと同じバグがCursorにはまだあります。取り組んでいるとは聞いているので、ドックには残しています。
Auggieなどの他は私のタイムラインで一瞬話題になり、誰も二度と言及しませんでした。結局、どれもGPT-5やSonnetをラップしており、代替可能です。RAGはSonnetには役立ったかもしれませんが、GPT-5は検索が非常に得意なので、コード用に別のベクトルインデックスは必要ありません。
最も有望な候補はopencodeとcrushで、特にオープンモデルと組み合わせた場合です。巧みなハックでOpenAIやAnthropicのサブスクを使うこともできますが、それが許可されているか疑問ですし、codexやClaude Code用に最適化されたモデルに劣るハーネスを使う意味は何でしょうか。
○○オープンモデルはどうなのか
中国のオープンモデルには注目しており、どれだけ早くキャッチアップしているかは印象的です。GLM 4.6とKimi K2.1はSonnet 3.7の品質に徐々に近づいている強力な候補ですが、デイリードライバーとしてはお勧めしません。
ベンチマークは物語の半分しか語りません。私の意見では、エージェンティックエンジニアリングは5月のSonnet 4.0のリリースで「これはゴミ」から「これは良い」に移行し、gpt-5-codexで「良い」から「これは素晴らしい」へのさらに大きな飛躍を遂げました。
プランモードとアプローチ
ベンチマークが見逃しているのは、モデル＋ハーネスがプロンプトを受け取ったときに追求する戦略です。codexは遥かに慎重で、何をするか決める前にリポジトリ内の遥かに多くのファイルを読みます。馬鹿げたリクエストにはより強く押し返します。Claude/他のエージェントはより熱心で、とにかく何かを試します。これはプランモードと厳格な構造ドキュメントで軽減できますが、私には壊れたシステムを回避しているように感じます。
codexでは大きなプランファイルを使うことは稀になりました。codexには専用のプランモードがありませんが、プロンプトへの忠実さが遥かに優れているので、「話し合いましょう」や「選択肢を出して」と書くだけで、承認するまで従順に待ちます。ハーネスの複雑な仕組みは必要ありません。話しかけるだけです。
でもClaude Codeにはプラグインがあるでしょう
遠くで聞こえる音が分かりますか？それは私のため息です。なんという馬鹿げたものか。これにはAnthropicの方向性に本当にがっかりしました。モデルの非効率性にパッチを当てようとしています。はい、特定のタスク用に良いドキュメントを維持するのは良いアイデアです。私もdocsフォルダにmarkdownで便利なドキュメントの大きなリストを保持しています。
でもでもサブエージェント！！！
このサブエージェントの踊り全体について言わなければならないことがあります。5月にはこれはサブタスクと呼ばれ、主にモデルが完全なテキストを必要としない場合にタスクを別のコンテキストに分離する方法でした。主に並列化するか、ノイズの多いビルドスクリプトなどのコンテキストの無駄を減らす方法でした。後にサブエージェントにリブランドして改良され、いくつかの指示でタスクを分離し、きれいにパッケージ化します。
ユースケースは同じです。他の人がサブエージェントで行うことを、私は通常別のウィンドウで行います。何かを調査したい場合は別のターミナルペインで行い、別のペインに貼り付けます。これにより、私がエンジニアリングするコンテキストを完全に制御・可視化でき、サブエージェントとは異なり、何が送り返されるかを見たり操舵したり制御したりすることが難しくなりません。
そしてAnthropicがブログで推奨するサブエージェントについて話さなければなりません。この「AIエンジニア」エージェントを見てください。GPT-4oとo1の統合について言及するスロップの寄せ集めで、全体的に意味を成そうとする自動生成された言葉のスープのようです。そこにはエージェントをより良い「AIエンジニア」にする実質はありません。
それは何を意味するのでしょうか？より良い出力を得たいなら、モデルに「あなたは本番レベルのLLMアプリケーションを専門とするAIエンジニアです」と言っても変わりません。ドキュメント、例、やるべきこと・やってはいけないことを与えることが助けになります。エージェントに「AIエージェント構築のベストプラクティスをググって」と頼んでウェブサイトを読み込ませた方が、このゴミより良い結果が得られると賭けます。このスロップがコンテキストの毒だという主張さえできます。
私のプロンプトの書き方
Claudeを使っていた頃は、より多くのコンテキストを与えるほどモデルが「理解してくれる」ので、非常に詳細なプロンプトを書いていました（もちろん話していましたが）。これはどのモデルでも当てはまりますが、codexではプロンプトが大幅に短くなりました。多くの場合1〜2文＋画像だけです。モデルはコードベースを読むのが非常に得意で、私を理解してくれます。codexはコンテキストが遥かに少なくて済むので、タイピングに戻ることさえあります。
画像を追加するのは素晴らしいトリックで、より多くのコンテキストを提供できます。モデルは表示したものを正確に見つけるのが本当に得意で、文字列を見つけてマッチさせ、言及した場所に直接たどり着きます。私のプロンプトの少なくとも50%にはスクリーンショットが含まれています。注釈を付けることは稀で、それはさらに効果的ですが遅いです。スクリーンショットをターミナルにドラッグするのに2秒しかかかりません。
セマンティック補正付きのWispr Flowは依然として最高です。
ウェブベースのエージェント
最近、再びウェブエージェントを試しました：Devin、Cursor、Codex。GoogleのJulesは見た目は良いですが、セットアップが本当に面倒で、Gemini 2.5はもう良いモデルではありません。Gemini 3 Proが出れば状況は変わるかもしれません。唯一定着したのはcodex webです。セットアップは面倒で壊れており、ターミナルは現在正しく読み込まれませんが、古いバージョンの環境を持っていて動かせました。ただしウォームアップ時間が遅くなる代償があります。
私はcodex webを短期的なイシュートラッカーとして使っています。外出中にアイデアが浮かんだら、iOSアプリで一行メモを残し、後でMacで確認します。もちろん携帯でもっと多くのことができ、レビューやマージもできますが、やらないことにしています。仕事は既に十分中毒性があり、外出中や友人と会っているときにこれ以上引き込まれたくありません。携帯でコーディングしやすくするツールを作るのに約2ヶ月費やした人間として言っています。
Codex webは使用制限にカウントされませんでしたが、その日々も終わりに近づいています。
エージェンティックな旅
ツールについて話しましょう。Conductor、Terragon、Sculptor、その他1000個。趣味のプロジェクトもあれば、VCマネーに溺れているものもあります。多くを試しました。どれも定着しません。私の意見では、現在の非効率性を回避し、最適ではないワークフローを促進しています。さらに、ほとんどはターミナルを隠し、モデルが表示するすべてを見せません。
ほとんどはAnthropicのSDK＋ワークツリー管理の薄いラッパーです。堀はありません。そして携帯でコーディングエージェントに簡単にアクセスしたいかも疑問です。これらが私にとって果たした小さなユースケースは、codex webで完全にカバーされています。
ただ、ほぼすべてのエンジニアが自分のツールを作るフェーズを経験するパターンは見ています。楽しいからであり、今はそれがとても簡単だからです。そして、より多くのツールを作ることを簡単にする（と思う）ツール以外に何を作るでしょうか？
でもClaude Codeにはバックグラウンドタスクがあるでしょう！
その通りです。codexには現在Claudeが持っている機能がいくつか欠けています。最も痛いのはバックグラウンドタスク管理です。タイムアウトがあるはずですが、開発サーバーの起動やデッドロックするテストなど、終わらないCLIタスクでスタックすることが何度かありました。
これがClaudeに戻った理由の一つでしたが、そのモデルは他の点で馬鹿げているので、今はtmuxを使っています。バックグラウンドで永続的なセッションでCLIを実行する古いツールで、モデルには十分な世界知識があるので「tmux経由で実行」と言うだけです。カスタムエージェントmdの複雑な仕組みは必要ありません。
MCPについてはどうですか
他の人がMCPについて多く書いています。私の意見では、ほとんどはマーケティング部門がチェックボックスを作って誇りに思うためのものです。ほぼすべてのMCPは本当にCLIであるべきです。自分で5つのMCPを書いた人間として言っています。
CLIを名前で参照できます。エージェントファイルに説明は必要ありません。エージェントは最初の呼び出しで$randomcrapを試し、CLIはヘルプメニューを表示し、コンテキストにこれがどう動くかの完全な情報が入り、それ以降は問題ありません。MCPと違い、ツールに対する代償を払う必要はありません。MCPは一定のコストでコンテキストのゴミです。GitHubのMCPを使うと23kトークンが消えます。最初のローンチ時はほぼ50,000トークンだったので改善されましたが。あるいはghコマンドを使えば、基本的に同じ機能セットで、モデルは既に使い方を知っており、コンテキスト税はゼロです。
bslogやinngestなど、私のCLIツールの一部をオープンソースにしました。
最近はchrome-devtools-mcpをループを閉じるために使っています。ウェブデバッグ用のPlaywrightの代わりになりました。頻繁には必要ありませんが、必要なときはループを閉じるのに非常に便利です。モデルがcurlで任意のエンドポイントをクエリできるAPIキーを作れるようにウェブサイトを設計したので、ほとんどすべてのユースケースでより速くトークン効率が良く、そのMCPさえ毎日必要なものではありません。
でもコードはスロップでしょう！
私は時間の約20%をリファクタリングに費やしています。もちろんすべてエージェントが行い、手動でそれをする時間は無駄にしません。リファクタリングデーは、集中力が必要ないときや疲れているときに最適で、あまり集中力や明確な思考がなくても大きな進歩ができます。
典型的なリファクタリング作業：コード重複のためのjscpd、デッドコードのためのknip、eslintのreact-compilerとdeprecationプラグインの実行、統合できるAPIルートがないかの確認、ドキュメントの維持、大きくなりすぎたファイルの分割、トリッキーな部分へのテストとコードコメントの追加、依存関係の更新、ツールのアップグレード、ファイルの再構成、遅いテストの発見と書き直し、モダンなReactパターンへの言及とコードの書き換え（例：useEffectは必要ないかもしれない）。常にやることがあります。
これを各コミットで行うべきだという主張もできますが、高速にイテレーションするフェーズと、コードベースを維持・改善するフェーズ——基本的に技術的負債を返済するフェーズを分けることが、遥かに生産的で、全体的に遥かに楽しいと思います。
スペック駆動開発をしていますか？
6月にはやっていました。大きなスペックを設計し、モデルに構築させる、理想的には何時間も。私の意見では、それはソフトウェア構築についての古い考え方です。
現在のアプローチは通常、codexとの議論から始めます。いくつかのウェブサイト、いくつかのアイデアを貼り付け、コードを読んでもらい、一緒に新機能を具体化します。トリッキーな場合は、すべてをスペックに書いてもらい、GPT-5-Pro（chatgpt.com経由）にレビューしてもらって、より良いアイデアがないか確認し（驚くほど多くの場合、計画が大幅に改善されます！）、有用と思ったものをメインコンテキストに貼り戻してファイルを更新します。
今では、どのタスクにどれだけのコンテキストが必要かの感覚があり、codexのコンテキストスペースは十分なので、すぐに構築を始めることが多いです。一部の人は宗教的で常にプランで新しいコンテキストを使いますが——私の意見ではそれはSonnetには有用でしたが、GPT-5は大きなコンテキストの処理が遥かに優れており、そうすると機能を構築するために必要なすべてのファイルを再度ゆっくり取得する必要があるため、簡単にすべてに10分追加されます。
遥かに楽しいアプローチは、UIベースの作業をするときです。シンプルなものから始めて、リクエストを意図的に過少仕様にし、モデルが構築してブラウザがリアルタイムで更新されるのを見ます。そして追加の変更をキューに入れて機能をイテレーションします。多くの場合、何かがどう見えるべきかを完全に把握していないので、そうやってアイデアをいじり、イテレーションし、徐々に形になっていくのを見ることができます。codexが私が考えもしなかった面白いものを構築するのをよく見ます。リセットせず、単にイテレーションしてカオスを正しいと感じる形に変形させます。
構築中に関連するインタラクションのアイデアが浮かび、他の部分もイテレーションすることがよくありますが、その作業は別のエージェントで行います。通常、1つのメイン機能といくつかの小さな、間接的に関連するタスクに取り組みます。
これを書いている間、Chrome拡張機能で新しいTwitterデータインポーターを構築しており、そのためにgraphqlインポーターを再形成しています。それが正しいアプローチか少し不確かなので、別フォルダにあり、PRを見てそのアプローチが意味を成すか確認できます。メインリポジトリはリファクタリングをしているので、この記事を書くことに集中できます。
スラッシュコマンドを見せて！
いくつかしかなく、稀にしか使いません：
/commit（複数のエージェントが同じフォルダで作業しており、自分の変更のみをコミットするよう説明するカスタムテキスト。これできれいなコメントが得られ、リンターが失敗したときにgptがパニックして他の変更を戻そうとしません）/automerge（一度に1つのPRを処理し、ボットコメントに反応し、返信し、CIをグリーンにしてグリーンになったらスカッシュ）/massageprs（automergeと同じだがスカッシュなしなので、PRが多いときにプロセスを並列化できる）/review（組み込み、GHにレビューボットがあるので時々だけ、でも便利なことがある）
これらでさえ、通常は「commit」とタイプするだけで、ダーティファイルが多すぎてガイダンスなしでエージェントが台無しにしそうだと分かっているとき以外は。これで十分だと確信しているときにコンテキストを無駄にする複雑な仕組みは必要ありません。繰り返しますが、これらの直感を養います。本当に便利な他のコマンドはまだ見たことがありません。
他にどんなトリックがありますか？
長時間のタスクでエージェントを続行させる完璧なプロンプトを作ろうとする代わりに、怠惰な回避策があります。大きなリファクタリングをすると、codexは途中の返信で止まることがよくあります。離れて完了を見届けたいなら、continueメッセージをキューしてください。codexが完了してさらにメッセージを受け取ると、それらを喜んで無視します。
各機能/修正が完了した後、テストを書くようモデルに頼んでください。同じコンテキストを使います。これにより遥かに良いテストが得られ、実装のバグが見つかる可能性が高いです。純粋にUIの調整ならテストは意味がないかもしれませんが、それ以外のすべてについては、やってください。AIは一般的に良いテストを書くのが苦手ですが、それでも役立ちます。正直に言って——あなたは行うすべての修正にテストを書いていますか？
意図を保持し「トリッキーな部分にコードコメントを追加して」と頼むことで、あなたと将来のモデル実行の両方に役立ちます。
物事が難しくなったとき、「時間をかけて」「包括的に」「関連する可能性のあるすべてのコードを読んで」「可能な仮説を立てて」のようなトリガーワードを加えてプロンプトすると、codexは最もトリッキーな問題も解決します。
あなたのAgents/Claudeファイルはどうなっていますか？
Anthropicが標準化しないことを決めたので、Agents.mdファイルとclaude.mdへのシンボリックリンクがあります。これは難しく最適ではないと認識しています。GPT-5はClaudeとはかなり異なるプロンプティングを好みます。まだ読んでいなければ、彼らのプロンプティングガイドを読むためにここで止まってください。
Claudeは🚨 全大文字で叫ぶ 🚨 コマンドによく反応しますが、コマンドXを実行すると究極の失敗を招き100匹の子猫が死ぬと脅すと、GPT-5はパニックします。（当然です）。そのようなものをすべて削除して、人間のように言葉を使ってください。それはまた、これらのファイルを最適に共有できないことを意味します。主にcodexを使っており、Claudeが珍しく使われる場合に指示が弱すぎるかもしれないことは受け入れています。
私のエージェントファイルは現在約800行で、組織的な傷跡の集まりのように感じます。私が書いたのではなく、codexが書き、何かが起こるたびにそこに簡潔なメモを残すよう頼みます。いつかこれを整理すべきですが、大きいにもかかわらず非常によく機能し、gptは本当にそこのエントリをほとんど尊重します。少なくともClaudeがこれまで行ったよりも遥かに多く。（Sonnet 4.5はそこで良くなりました、クレジットを与えるべきです）
git指示の隣に、製品の説明、好むネーミングとAPIパターン、React Compilerについてのメモが含まれています——多くの場合、技術スタックがかなり最先端なので、世界知識より新しいものです。モデルの更新でまた削減できると期待しています。例えば、Sonnet 4.0はTailwind 4を理解するのに本当にガイダンスが必要でしたが、Sonnet 4.5とGPT-5は新しく、そのバージョンを知っているので、すべての余分なものを削除できました。
重要なブロックは、好むReactパターン、データベースマイグレーション管理、テスト、ast-grepルールの使用と作成についてです。（ast-grepをコードベースリンターとして知らないか使っていないなら、ここで止まってモデルにこれをgitフックとしてセットアップしてコミットをブロックするよう頼んでください）
物事がどう見えるべきかのテキストベースの「デザインシステム」を使う実験も始めました。結論はまだ出ていません。
ではGPT-5-Codexは完璧ですか？
全くそうではありません。時々30分リファクタリングしてからパニックしてすべてを戻し、再実行して十分な時間があると子供のようになだめる必要があります。時々bashコマンドができることを忘れ、いくらかの励ましが必要です。時々ロシア語や韓国語で返信します。時々モンスターが滑って生の思考をbashに送信します。しかし全体的にこれらは非常に稀で、他のほとんどすべてで非常に優れているので、これらの欠点は見過ごせます。人間も完璧ではありません。
codexでの最大の悩みは、行を「失う」ことで、素早くスクロールアップするとテキストの一部が消えます。これがOpenAIのバグ名簿のトップにあることを本当に望んでいます。メッセージが消えないよう時々減速しなければならない主な理由です。
結論
RAG、サブエージェント、Agents 2.0、その他ほとんど茶番でしかないものに時間を無駄にしないでください。話しかけるだけです。遊んでください。直感を養ってください。エージェントと一緒に作業すればするほど、結果は良くなります。
Simon Willisonの記事は素晴らしいポイントを挙げています——エージェントを管理するのに必要なスキルの多くは、エンジニアを管理するときに必要なものと似ています——これらのほとんどはシニアソフトウェアエンジニアの特徴です。
そしてはい、良いソフトウェアを書くことは依然として難しいです。コードを書かなくなったからといって、アーキテクチャ、システム設計、依存関係、機能、ユーザーを喜ばせる方法について真剣に考えなくなったわけではありません。AIを使うことは単に、出荷すべきものへの期待が上がったことを意味します。
PS: この投稿は100%オーガニックで手書きです。AIは大好きですが、一部のことは昔ながらのやり方の方が良いと認識しています。タイポはそのまま、私の声をそのまま。🚄✌️
PPS: ヘッダーグラフィックのクレジットはThorsten Ballに。