確かに、LLMが特定のオープンソースを勧めてくれたら一度使ってみようかなとは思いますが、
買い物向けの商品そのものを勧められると、本当に信じていいのかと思って、むしろもっと敬遠してしまいそうです。
まあ、いつかはこれも変わるのでしょうか。

知る人ぞ知る感じで使われていますね（笑）
宣言的な関数型言語で実現する再現可能なセットアップ

ロルコタをたくさん愛してください

ラーニングカーブがとんでもなくきついです。再現性を保証するぶん、高いレベルが求められます。
flake を使っても厄介です。

それに内部的には sqlite を使っているようですが、これも性能のばらつきがあって、一度環境を再現し直すのにかかる時間の fluctuation が少しあります。

できるらしいですが、私はできません（泣）

良いリーダー、マネージャー、チームメンバーとは何だろうか？ ときにはマネージャーである人が、同時に誰かにとってはチームメンバーでもあるのだから…

Electronで正常化してくださるので……

毎日のようにプロジェクトがあふれているので、せめてスクリーンショットでもあれば気になってすぐ使ってみそうです

どこでも人の営みはみな同じですね。 :)

Linuxが使えなくて 😭

そうですね〜。こんな議論を生み出して考えさせる文章というだけでも、意図は十分伝わっていましたね。

IDE も PR もみんな死んだのに、コードは復活したんですね？

はい、現在は二つの見方がぶつかっていますね。主に語られているのは代替論で、ときどき出てくるのがこの文章のような楽観論です。
未来のことは誰にも分かりませんが、大勢を占める議論が代替論なのであれば、その反対側も見ておく必要はあると思います。

楽観論にもさまざまな論点がありますが、その中で古い理論の一つであるジェボンズの逆説を持ってきてみました。
現在の市場では、個人開発者の一人企業化によって、実際にシンプルなWeb紹介ページのようなものから単価が急速に下がっています。これによって、これまでホームページを一つ作ろうとは思っていなかった小規模事業者や中小企業でも、それなりに見栄えのするホームページを一つずつ持つようになってきています。
つまり、市場そのものは広がっているという流れで間違っていないと判断しました。特にSaaSが日ごとに次々と登場していて、知らないうちに価格競争も激しくなっているのが現実です。価格が下がれば導入する企業や個人は増え、市場自体は間違いなく大きくなると考えています。

その後の方向性は二つのうちどちらかでしょう。一人が管理するサービスの数を引き続き増やしていくか、あるいはもう一人の開発者が生まれてその需要を引き受けるかです。
人間が処理して管理できる量には明らかに限界がある以上、結局はその需要をさばくために、再びジュニア開発者（これまで市場で疎外されてきたリソースはジュニア開発者ですからね）を雇う流れに向かうのではないか、と予想していたということです。

もちろん、その時のジュニア開発者に求められる能力は今とはかなり大きく異なるでしょう。賃金という面でも過去と同じかは分かりません。また、その時期がいつ頃来るのかも正直よく分かりません。涙

そして、文章を読んでくださり、分析も丁寧にしてくださってありがとうございます。学びがあって良かったです。

ジェボンズの逆説の観点を含めるには、まず何を資源とするのかを設定する必要があります。
開発者需要の見通しを分析する文章なのですから、この文章における資源は開発者であるべきでしょう。

• ジェボンズの逆説が従来説明してきた産業（蒸気機関 <-> 石炭）とソフトウェア産業には多くの違いがあります。
  • デジタル財は非競合財であり、限界費用がほぼ 0 の産業です。つまり、固定費中心の産業です。
  • このような産業では、生産性向上は一般的に人員削減または凍結と、既存人材のレバレッジ強化という方向で進みます。
• ジェボンズの逆説が成り立つには、需要が価格に非常に敏感であり、コスト低下が需要の急増に直接つながらなければなりません。
  • ソフトウェア開発は開発者一人でやるものではありません。ボトルネックは「コーディングコスト」ではなく、企画、リスク、運用、組織、規制コストです。
  • これまでソフトウェアのコストが高くて作れなかったのではなく、「必要がなかった / ROI が出なかった / 運用できなかった」ために作られなかったケースが大半です。
• 生産性指標には錯覚があります。
  • 文章で使われている指標（コード生成量の増加、PR の増加、デプロイ量の増加）はすべて「活動量」の指標です。
  • コード量が増えても価値が増えるわけではありません。PR の増加はレビュー・検証コストの増加につながり、AI コードは品質・セキュリティリスクを高めます。
  • つまり、AI コードによって技術的負債、デバッグコスト、運用の複雑さが増大します。
  • したがって、生産性向上は活動量指標のように劇的には増えない可能性があります。
• 「ジュニアの崖」を認めながら楽観論を維持するのは矛盾しています。
  • 開発者は石炭と違って、ジュニアからシニアへ成長していく構造です。
  • ジュニアが減れば、将来のシニアも減ります。したがって、中長期的に開発者全体のプールは縮小します。
• 市場規模の成長と雇用の成長は同じではありません。
  • 特に AI は資本集約型産業であり、「人をより多く使う産業」ではなく「少ない人員でより大きな規模を作る産業」です。
• 開発者は人であり、人の賃金は石炭の価格とは異なる特徴を持っています。
  • 労働市場では賃金が完全に柔軟に下がるわけではないため、コスト低下が価格低下へ十分に転嫁されません。
  • 賃金には実際に下方硬直性があります。これは最低賃金、労働法、契約構造、組織内の公平性、士気・離職リスクなどが理由です。
  • つまり、生産性が上がると企業は賃金を下げるのではなく、採用を減らします.

「問題は、漠然とした感覚（vibe）があたかも精密な抽象化であるかのように錯覚させること」には共感します。抽象化こそ、Bottom-upでローレベルを理解した人にだけ可能なことですよね。

カナリア版ありがとうございます

動いていたものが動かなくなると不便なのは確かですが、動かすために x11 でやっていたあのスパゲッティのような継ぎはぎを取り払っただけでも、評価する理由としては十分です。
ただ、いまだにできない理由を探ってみると、結局は標準化されていないことが問題で、その期間が思ったより長くかかっているのも事実です。
おそらく2030年になっても、まだ完成には程遠いという声は出るでしょうが、x11 への回帰は不可能でしょう。
エコシステムが変わる混乱のさなかで、代替案もまた同じようなことを言われるでしょうし、復帰は慣れ親しんだエコシステムでの反発を招く気がします。

自炊はいいですね

以前どこかで、韓国語で「ドッグフーディング」の代わりに「家のご飯を食べる」という表現はどうかという提案を見たことがあるのですが、「家のご飯を食べる」も語感がなかなかいいですね

他の検証方法で代替できるかを見る必要があると思います。フロントに近いほど、ブラウザの動作によるE2Eだけでも問題なく動作すると検証できるでしょう。しかし、バックエンド、そしてインフラに近いコードであるほど、コードレビューが必須になると思います。そうでないと、目に見えないトランザクションの開始と終了や api コールが飛ぶなどの副作用を検証するのが難しいでしょうから。