生産性の逆説への答えは、技術の進歩がシステムの複雑さを増して、技術自体の効率向上を相殺しているってことかもね。

いい引用だね。特にビジネスの観点から見ると、ほぼ真実だと思う。俺はコードをクリエイティブな表現、つまりアートの一形態として見てる。コードを書くのが好きなのは、自分や他の人にとっても読みやすくてエレガントな方法で解決策を表現できるから。ちょっと浅いけど、エレガントに書かれたコードを読んだことがあるなら、その良さはすぐにわかるはず。

でも、コードが簡単に置き換えられるなら、なんでそれが負債になる必要があるの？何か問題が起きたら、次の世代の「プログラマー」がAIにコードを再生成させるだけじゃん。

昔の人たちがMS FrontPageを使ってウェブサイトを作っていた頃を思い出すなぁ。HTMLは90%が無駄なコードだったよね。

アーキテクトが抱える問題の90%は、システムの要件や制約を理解し、それを表現すること、そしてそれが他のものとどう絡むかを理解することだよ。つまり、プロンプトを書くこと、答えを理解すること、反論することとかね。

それは、大部分の「アーキテクト」が実際にはあまり優れていないからだよ。ITインフラを実際に運用する知識がほとんどない候補者を面接したことがあるけど、彼らはそれが重要だとは思っていなかった。アーキテクトの役割を求めていて、ターミナルやYAML、データベースなんかには触れたくないって言ってた。彼らは真剣に、図表ツールやExcelで働きたいだけだと言ってたよ…。アーキテクトはマネージャーみたいなもので、実際には人々が想像するよりずっと難しいし、実際にその仕事をできる人はごく少数なんだ。

これが願望的思考ってやつだね。著者は自分のアーキテクチャスキルに誇りを持っているから、代替不可能だと思っているんだろう。もし彼らが最適化が得意だったら、最適化が代替不可能だと思うだろうね。

建築家って何？ああ、パワーポイントを書く人のことね。ちょっと話が逸れちゃった。

ちょっと違った視点で考えてみたいな。LLMは問題に対する中庸な解決策を生成するのが得意だと思う。なぜなら、それがトレーニングコーパスの大部分だから。一般的な「ベストプラクティス」を生成するんだよね。定義上、ほとんどの人間のアーキテクトよりも優れていることが期待される。一方で、彼らはトレーニングコーパスの外にある問題を解決するための第一原理からの推論が苦手だ。パフォーマンスに敏感なプラットフォームのような分野では、中庸な解決策が間違っていることが多くて、LLMには常に利用できるわけではないコンテキストや知識を使って設計作業をする高いスキルを持った人が必要なんだ。データベースカーネルを設計するのにLLMを使うことはできるかもしれないけど、それは比較的ナイーブなものになるだろう。なぜなら、トレーニングデータが最新の技術に近いことをするためには足りないから。