新しいLLM中心のワークフローは、今やただのマネジメントの仕事になっちゃった。マネージャーやプロジェクトマネージャーは価値のある役割で、重要なスキルセットを持ってるけど、昔のソフトウェア開発の役割とはほとんど関係がないんだよね。「ビルダー」という一つのラベルの下にこの二つの役割をまとめるのはちょっと変だと思う。EDIT: コーディング（そしてすぐに他の知識労働も）今やただのマネジメントタスクだってことについて、もっと詳しく書いてるよ: https://www.oneusefulthing.org/p/management-as-ai-superpower...

同じことに気づいたけど、これを言葉にするのは難しかった。LLMベースのコーディングを試してみて、理解して賢く話せるようになりたいと思ってる（ただの不機嫌な人になりたくないから）。Claude Codeを使いながら、頭の中でずっと思ってるのは、「プログラミングが好きで始めたのに、これが何なのか…」ってこと。確かに、バカなものを早く作れるようになったけど、たくさんのものを作りたいからプログラミングを始めたわけじゃないんだ。データ構造やコンピュータが理解できる命令で問題を定義する楽しさ、そしてその命令をコンピュータに入力して、実行されるのを見て勝利を感じるのが好きだった。もし何かにやらせることに知的な興奮を感じてたら、マネジメントに進んでたはずだよ。

この分け方は、書くことにもっと関係してると思う。コンパイラ用の形式的な言語を書く仕事から、ジュニアの金魚のような記憶力を持つ開発者のために自然言語を書く仕事に根本的に変わらなきゃいけない。これはマネジメントに近くて、貢献者とは遠い。俺にとって、この違いが二つの主要なキャンプを分けてるんだ。

個人的には、これが完全に「新しい世界」ってわけでもないと思うんだよね。ただ、意見がさらに強調される新しい領域って感じ。これって、いろんなところで起きてるのが不思議だよね。要するに、コンパイル言語とインタープリタ言語、型ありと型なし、テスト戦略なんかがあって、少なくとも一部は、速さや出荷とメンテナンス性のトレードオフについての会話だったんだ。でも、これは技術だけじゃなくて、方法論や使われる言葉にも関係してる。「早く作って壊す」とか「YAGNI」、それから「デザインパターン」や「抽象化」みたいな。君が言うように、視点が違うんだよね。でも、業界としての最大の懸念は、これらが単に「同じくらい有効な」視点じゃないってこと。文字通り、ソフトウェアの異なる段階で、成功したソフトウェアはほぼ全てが通過しなきゃならないものなんだ。私のキャリアの多くは、「やる気のあるチームが作ったヒップなアプリ」から「利益を上げる信頼性のあるソフトウェア」への移行を経験してきたチームで過ごしてきたけど、これは本当に痛い。5人のメンバーが全ての詳細を把握していて、深刻なバグを修正したり数日で機能を出荷できる状況から、技術や問題領域、スキルレベル、意見がバラバラな100人のエンジニアにスケールするための明確な境界を持つものに移行するのは、本当に難しい。AIがこの問題を解決するとはまだ確信できないし、短期的には悪化させるリスクもあるんじゃないかと思ってる。

私は両方楽しんでるし、AIをバイブコーダーとは全然違う使い方してるよ。実装を生成するためにはほとんど使わないけど、ドキュメントやAPIを理解するのに、特にデバッグのためにはかなり使ってる。AIのおかげで、何がうまくいってないのかを理解するのにかなりの時間を節約できてるし、コードレビューでも助かってる。フルバイブコーディングは意図的に避けてるんだ。そうするとプログラマーとしてのスキルが錆びついちゃうと思うから。経験上、あんまり時間も節約できないしね。デザインが決まったら、実装が難しいわけじゃない。

彼は本当に何かを言おうとしていると思う。私はこれについてずっと考えてきた（HNでのLLMに対する持続的な懐疑心を理解しようとしている文脈で）、私が思いついたフレーミングは、トップダウンとボトムアップの開発スタイル、つまりコードを設計してから実装を埋めていくのか、コードを書いてアーキテクチャを進化させるのかってことだね。[1] https://www.klio.org/theory-of-llm-dev-skepticism/

私は両方楽しんでるし、AIをバイブコーダーとは全然違う使い方してるよ。実装を生成するためにはほとんど使わないけど、ドキュメントやAPIを理解するのに、特にデバッグのためにはかなり使ってる。AIのおかげで、何がうまくいってないのかを理解するのにかなりの時間を節約できてるし、コードレビューでも助かってる。こう感じていたし、今もそうだけど、ある時点で管理の変動がリアルに感じられて、新しい問題に苦しんでいる気がする。もし、実際にサービスが単一のプロンプトからデプロイされることになったらどうしよう。以前はAIにコードを書かせていたけど、デプロイやその周りのことに興味があった。今は、そういうことを本当にきれいにやってくれるサービスがあるから（私はエージェントのハイプにはあまり乗らず、主にブラウザのLLMを使ってた）。一方で、プロジェクトを作る自由を感じるけど、プロジェクトの喜びは完全に減ってしまった。私はまだジュニア開発者の一人だから、AIが知らないトピックでコードを書いたりプロトタイピングするのは素晴らしいと感じていた。まだ、生成されたコードをコピー＆ペーストしたり、エラーを見たり、自分で試したりしていたけど、AIがそれを全部やってしまうなら、どうなるんだろう。最近、AIに対してあまり興味を持てなくなっている。プロトタイピングにはかなり使ってきたけど、最近のサービスでの完全にループから外れたプログラミングは私には非常に不自然に感じる。AIのために何かを買うと、その「価値」を最大限に引き出そうとする感覚がある。おそらく、あいまいな用語を使ったり、非常に小さなテキストファイルを入力として持っていると（例えば「Y言語でXの代替をやって」）、アーキテクチャの決定を理解できなくなってしまう。おそらく、明確にアーキテクチャを定義する仕様駆動開発か、最近見たPrimagenがやっていたように、AIが特定の関数のコードだけを操作するような開発が必要になると思う（ファイルに対してもそう想像している）。今は、何を作ったのかわからないことが多いから、もっと楽しめるかもしれない。ブラウザを使って遊びながらシングルファイルプロジェクトでプロトタイピングすると、依存関係や関数名から、始まりと終わりでコードがどんな感じで使われているかのアイデアが得られる。少し長くなったけど、これを感じさせるのは、誰かと話していて、AIとサーバーのサービスを紹介したときに、彼らがプロンプトで何かを求めて、私がそれを書いたんだ。その後、AIに仕事をさせたけど、自分がどうアーキテクチャを考えるかも考えていた（それは食べ物を検出してBMRを見つけるもので、最初はAPIを使おうと思ったけど、難しいかもしれないと思って、AIビジョンモデルを使おうとした）。それで、何が最適かを考えて、Geminiの無料プランを使っていたら、実際にそれを超えてしまった（おそらく私のキーのレート制限でうまくいかなかったかもしれないけど、正直言って、私もそれを試しただろう）。だから、AIがコードを書くのが早くても、私が作るアーキテクチャの決定を誇りに思っていたのに、それも奪われてしまった。正直、AIのコードを読むのがあまり好きじゃないから、今の時点では自分でコードを書く方がいいかもしれない。手を動かして学ぶのもいいけど、公共の場で早く作るという態度には問題があって、楽しめなくなっている。プロジェクトにもっと積極的に関わるべきだと感じ

でも、LLMが「正しいこと」をするって信頼できないなら、どうやって責任あるビルダーになれるの？例えば、あるプロジェクトのために最高の候補者を選んだソフトウェアチームのリーダーだとしたら、あなたのアイデアや意図を実現するためにチームメンバーを信頼できるのは理解できる。でも、LLMエージェントにも同じ信頼を置けるのかな？よくわからない。たとえLLMが非常に信頼できることが証明できたとしても、AIエージェントが責任を持たない存在だから、状況は人間とは全然違う。

もしかしたら、中間のカテゴリーがあるかも：ソフトウェアのデザインが好きな人たち？俺は、コーディングも楽しむけど、システムデザインの方がもっと魅力的だと思う。それは、ただ問題を解決するように見える不透明なアーティファクトを作るのとは違うんだ。

これは例としてはあまり一般的じゃないけど、3ヶ月かけて「夜と週末」のプロジェクトとしてリリースしたものだ: https://apps.apple.com/us/app/skyscraper-for-bluesky/id67541... 2009年からモバイル分野で働いてるけど、主にデザイナーとして、その後プロダクトマネージャーとして。今はエンジニアリングとPMのハイブリッドな仕事をしてるけど、特に強いプログラマーではない。こんなに洗練されたものを作れるとは思ってなかったし、ましてや3ヶ月でなんて。コードベースは約98%がClaudeのコードだよ。