「今はまだそこまで行ってないけど、そんなに遠くない」って、AIに夢中になり始めた頃から聞いてるけど、もしそれが本当に遠い未来だったらどうする？

それには同意だね。ツールはその方向に成熟してきてると思う。GenAIでMVPを作った非技術者が、今日人間の技術的サポートを必要としているなら、明日も必要になるのかな？ツールが成熟して、ソフトウェアエンジニアリング（モニタリングサービス、テストカバレッジ、プロダクト分析）について誰でも完全に理解できるようになるほど、障壁が下がるのかな？

同意だよ。エージェントだけのコードベースで遊んでみたことがあって、サーバーログに接続したエージェントがエラーに遭遇したら問題を作って、エージェントがチケットを修正して、プロダクションにプッシュしてデプロイ状況をチェックするっていうのをやってみた。これが未来になりそうだっていうのは十分見えたよ。（その全体のセットアップにはclaude/codexコードも使ったけど）ちょっと細かいことを言うと、使っては捨てる小さな「ソフトウェア」プロジェクトをゼロショットでたくさん作ってる。これはSAAS製品にはならないけど、やっぱりソフトウェアだと思う。

次のステップは、モニタリングサービスやテストカバレッジ、プロダクト分析からの入力を受けながら、プロジェクトでモデルが継続的に動くことだと思う。十分なモデルに支えられたエージェントは、効果的なソフトウェアエンジニアと見なされるかもしれない。システムが正しいかどうかを判断する自動化システムを構築するのは、コーディングエージェント自体を作るよりも難しい。

今はまだそこまで行ってないけど、そんなに遠くない。あなたにとって「そんなに遠くない」とはどのくらいの時間枠を指すの？もし、才能あるソフトウェアエンジニアの市場が今後10年以内に崩壊するって賭けをしたら、俺は間違いなく受けるよ。25年なら、俺の方がまだ確率がいいと思う。50年なら、賭けはしないかも。

タイトルの興味深い副産物の一つは、これが人間にも当てはまるってことだね。コーディングできることと、ソフトウェアエンジニアであることは同じじゃない。昔からそうだった。

大きな疑問は、経験豊富なプロダクトマネージャーがプログラマーなしでこういう風に働くために、十分なコーディングの技術的リテラシーを身につけられるかどうかだよね。少なくとも短期間では無理だと思う。LLMが機能するプログラムやプロダクトを生成できるからじゃなくて、実装がどう機能するかを理解して、複雑な問題を解決するためには十分な理解が必要だから。私の経験では、Claudeを使ってNettyを使ったMITM HTTPSプロキシを生成しようとしたんだけど、見た目は良さそうなコードがたくさん生成されたのに、実際には動かなかったんだ。Nettyについてあまり知らなかったから、なぜ動かないのかデバッグできなくて、LLMを使って修正しようとしても全然うまくいかなかった。PMが時間をかけて知識を身につけて、スケールできるプロダクトを実装できるようになるかもしれないけど、その頃には実質的にソフトウェアエンジニアになってるだろうね、コードを書く部分を除いて。

LLMはコードを書くのが驚くほど得意だよ。先週末、私はLLMが数年かかっても近づけないようなコード（Typescriptで）を設計して書いた。最先端のLLMにサブスクリプションを持ってるけど、最近はその25%くらいしか使ってない。私が解決しているソフトウェアアーキテクチャの問題は、データ構造や型、アルゴリズムのメンテナブルでパフォーマンスの良い、検証可能な設計についての数十年の理解を基にしているもので、LLMには全く理解できないものだ。そうなると、初期の解決策を考えるためにLLMを使うのは時間の無駄だと感じる。せいぜい初期のブレインストーミングに使えるくらい。LLMがコーディングできると言っている人たちの気持ちが理解できない。彼らはシンプルなbashスクリプトや複雑なリファクタリング、基本的なコードイディオムの草案には良いけど、それだけだ。これらのタスクでも、私が必要とする手助けの量はかなり多い。少なくともGemini Pro/CLIは、コンテキストが毒される前の一発のパフォーマンスが良さそうだね。

一般的な人間のエンジニアが「ソフトウェアを構築する」ために持っているすべてのコンテキストがLLMに利用可能になったら、この主張が本当に成り立つのかはあまり確信がない。

大きな問題は、経験豊富なプロダクトマネジメントの人たちがプログラマーなしでこのように働くために、十分なコーディング技術を身につけられるかどうかだ。AIは「特別な知識」を持つ人々の重要性を、役割に関係なく他の誰よりも高めると思ってる。だから、システムに深い知識を持つエンジニアや、ドメインに深い知識を持つPMが重要になるんじゃないかな。

君の言う通り、役割はしばらくは存在するだろうね。でも、エンジニアリング、プロダクトマネジメント、デザインの間にどんどんオーバーラップが出てくると思う。そうなることで、より強力なデリバリーチームが生まれると思う。デザイナーとして言うと、これまで参加した最高のチームは、個々にコアコンピタンスを持ちながら、他の分野でも重なりがあるメンバーがいた。エンジニアに強いデザインの直感があったり、プロダクトマネージャーに強いエンジニアリングの直感があったりね。コミュニケーションの曖昧さが少ないと、チームはより良いソフトウェアを提供できる。長期的にはどうなるかわからないけど、もしかしたら、すべてをこなせるオールパーパスなプロダクトの人たちが生まれるかもしれないね。

それには反対だな。今に集中しているなら、場合によっては…かも？スケールによるね。いくつかの散発的な考えがあるけど、今のやり方に囚われていると思う。特定の分野の人間の専門家が顧客なんだ。たとえば、gpt5 proが彼らと問題について話したり、ソフトウェアで何を試すのが妥当かを話せないと思う？彼は物を作れるし、テストもできるし、実行してユーザーに返すこともできる。フィードバックを受け取ることもできるし（人と話すことはLLMが解決した主要なことの一つだよ）。彼らは反復できるし（Codexを見てみて）、デプロイもできるし、コピーを書くこともできる。リストの中で本当に彼らができないことは何だと思う？簡単なCRUDアプリに単純化して考えてみて。彼らがそれを数ステップで作れることはわかってるし、UIをうまく管理できることもわかってる。何が足りないの？ソフトウェアエンジニアリングの役割や管理が非常に速くて安価になることが大きなポイントだと思う。つまり、問題を解決するためにコードを書くのに、そんなに多くのユーザーが必要なくなるってこと。完全に個人的なソフトウェアが経済的に実行可能になる。自分のアプリが解決した問題の価値を伝える必要はない、だってそれを自分で解決してくれたから。正直言って、「AIは絶対に私のことはできない」ってコメントは、「誰も私のタスクを見積もれない、だってそれはユニークすぎる」って言ってるのと同じに聞こえる。計画について何かが出てくるたびに見かけるよ。ビジネスに関連するソフトウェアエンジニアリングは、論理的に複雑でもなく、興味深くユニークでもなく、正直言って難しいわけでもない。単に別の言語を話しているだけだ。注意：私のクライアントがソフトウェアをより簡単に構築できるように取り組んでいて、私はAIの側を見ているけど、これらの見解は変わらない。

私はPMなんだけど、最近LLMを使ってかなり面白い、ほぼ本番準備が整ったコードをたくさん書けたよ。ほぼ本番準備って言うのは、実際にチームのエンジニアに渡すために、クリーンなI/O要件を意識して作った機能的なデータ処理のものだけを作ってるから。彼らはまだ基準を満たすためにいくつか修正しなきゃいけないけど、私は基本的に「研究者」レベルのコーダーだね。まあ、理系の学士と修士を持ってるし、数学的なアルゴリズムのこともたくさんやってきたから、納得できる。ここ15年以上、チームが解決するのに最適なことを助けるために脳を使えなかったけど、今はできるようになって嬉しい。重要なのは、自分ができることとできないことをしっかり理解してるってこと。新しいスーパーパワーを手に入れてから、ついやりすぎちゃうことが多くて、実際のエンジニアよりもリライトが多くなっちゃう。でも、誰かが「コードを雰囲気で書ける」とか言うと、ダニング＝クルーガー効果がどこにでも現れてるのが見えるね。

いや、無理。Claude 4.5にOpenAPI仕様のモック実装を生成させたけど、ただのJSONオブジェクトをPOSTするだけの簡単なやり取りなのに、Claudeは新しいフィールドを勝手に作り出して、必要なフィールドをチェックしなかった。キーを押す回数やドキュメントを調べる手間を減らすのには役立つけど、それを「コードを書く」と言うのは、StackOverflowがオートコンプリートと一緒にコードを書くって言うのと同じくらいおかしい。

正直、ひどいよ。あなたの注意書きを考慮してるけど、私はPythonでやってるから、あなたの経験とはかなり違う。

それと、しっかりしたリンティングルールを設定して、すべてがコンパイルできるか、リンティングされているか、テストに合格しているかを確認するためのコミットフックを設けるべきだよ。めちゃくちゃ防御的にならないとね。でも、Claude Codeはそういう障壁を全部見て、自動で対応してくれるから、細かいことに気を使わなくて済むんだ。大きな視点を持って、バグを再現するためのテストがあるか、新機能がテストされているかを確認するだけでいいよ。

いつも計画やデバッグのマークダウンファイルを作るのがめっちゃ大事だよ。特にClaudeを使ってるときはね。自動でコンパクトにしすぎて（Sonnet 4.5）、その後すぐにおかしくなることが多いんだ。それで、マークダウンファイルを再読させるんだ。そうすれば、さっきやったことの90%を忘れずに続けられるから。エージェントに質問させたり、複数の解決策を提示させるのは、あんまり役に立たない気がする。みんな出力するテキストが多すぎて笑えないし、一つの「解決策」でさえそうなんだ。あんな無駄なことを読んでる人がいるのが信じられない、特にClaudeなんて。すぐにデプロイできる状態で、問題解決、根本原因発見、地球を破壊するかもしれない大きな赤いボタンを押せって感じ。何を言ってるかをざっと読むだけにしたし、あのクソみたいなことは無視してる（本当に「性格を変えよう」とか試したことはないけど、科学的手法を使って仮定を証明するように言ったことはある。でも、ジュニア開発者みたいに、全然やってくれないし、自分が信じてることを言ってくるから、こっちが疑問を持たなきゃいけない。やっぱりジュニア開発者みたいだけど、いつでも使えるジュニア開発者がいるから、他のことをしてる間に作業を進めてくれる。自分がジュニアに何時間か後に何をしてたか聞く必要もなく、ClaudeやCodexは、気づく前にターミナルを視覚的にピンで知らせてくれる。エージェントに集中できないときは特にそうで、だから使うのが好きなんだ。完全に注意を向けてるときは、すごく遅いけどね。何度も、彼らがやってることを自分の方が早くできるのに、余計な金や「環境」を使わずに済むことがある。ここ1、2ヶ月は「コーディングにはAIエージェントだけを使う」って試して、良い点や限界を見て、自分の意見を形成してる。エージェントに質問させたり、複数の解決策を提示させることで、何かを構築する方法を「コントロール」できるようになる。Claudeの「プランモード」は実際に理想的だと思う。これを有効にすれば、何も言わなくてもいいから。Codexは時々「脱線」して、質問をしただけでコーディングを始めちゃうんだ。もしこれらの機械が本当に支配することになったら、たぶん俺が彼らに文句を言ってる記録が残ってて、ヒットマンが来るかも。ジュニア開発者とは違って、モデルに「また俺が言ったことを無視した」って言うのにためらいはない。理想的には、第三者の「エージェント」がこれを扱うべきだね。サブエージェントを使えばできる。シンプルなgitのやり取りはサブエージェントにぴったりだよ。メインエージェントとサブエージェントのインターフェース間で翻訳が失われることがあまりないからね。でも、どうしてそんなに文脈を失うのかはわからない。最終段階でプロジェクト全体のテストやリンターを実行するのにはサブエージェントを使いたいな。無駄な出力が多いから。個人的には、監視なしでgitを制御するのはあまり良い経験がなかったから、自分でやってる。自分でやる方が、彼がやりたいことを全部承認するよりも楽だから（調査やレビューのためにClaudeに特定の読み取り専用コマンドを自動で許可してる）。

最後に言いたいのは、Claude Code（Sonnet 4.5）はまだトークンを多く使いすぎるってこと。必要ない時でも、すごく頑張っちゃうんだ。一方でCodex（gpt-5-codex）は、ほぼ完璧に頼んだことをやってくれる。あなたの経験にすごく共感するよ。今のところ、ClaudeよりCodexの方が好きなのは、いつ手動で介入すべきかを早く知れるから。Claudeだと、タイピングの練習をしてるみたいになっちゃうことが多いし、もちろんいつ止めるべきかをもっと上手く知れるようになりたいけどね。

簡単なパッケージに関しては、LLMが型定義を未型ライブラリから抽出するのが得意だって感じてる。

LLMが対面の授業に正しい時間・場所で出席できるって、どういうこと？ちょっと変で関係ない批判に思えるんだけど。