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

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

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

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

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

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

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

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

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

これに関する本が「Peopleware」っていうのがあるよ。だから「あなたの問題が全部技術的でありますように」って言うのが好きなんだ。技術的な問題をコードで解決するのは、ほとんどの場合そんなに難しくないから。ほんの一部の最先端のケースを除いてね。

これは確かに良い指摘だね。AIが潜在的な解決策の複雑さを見積もるのが得意で、ユーザーに警告するのも簡単に想像できる。例えば、チェスではAIはもう人間よりもずっと優れているし、ポジションの評価みたいなタスクでもそうだ。この記事は主にLLMに焦点を当てているけど、ここでは「AI」を広い意味で使ってるよ。

「いいえ」と「もちろん」の間には、「これが言いたかったこと？」っていう50のニュアンスがあるよね。例えば、この年配の男性が「データベースをダウンロードできるウェブページを作って」って頼んできたんだけど、彼が言いたかったのは非常に限られたCSVエクスポートだったんだ。チャットGPTが彼の指示を理解できたかどうか気になるな。これは比較的分かりやすい例だったし。

同意するよ。AIと僕の大きな違いは、「いいえ」と言うタイミングを知っていること、そして言葉にされていないストーリーやニーズ、価値を掘り下げることだね。

「ノーと言う」以外の資産は、「これがどう進んでいくのか、ビジネスがどうなるのか見えてきたから、次の部分が楽になるようにXの方法で柔軟に/拡張可能にしておこう」ってことだね。

クラシックな「要件バグ」の素晴らしい再定義だね。ソフトウェアは完璧に実装できるけど、要件が意味をなさない、技術システムの現実を考慮していないと、混乱が起きる。AIが「ギフを求めたけど透明性をサポートしていない」といった問題に対処できるようになると思うけど、「ロゴを中心から等距離にある四角にして」っていう要件を書く人は100%いると思う。編集: そう、ギフじゃなくてjpg、やっちゃったタイプミス + 自動修正。

スタートアップの世界では、エージェンシーの仕事が盲点になっている人が多い気がする。テーマのチョップショップを超えたものだってことに気づいていないんだよね。地球上の大企業は、常にエージェンシーと契約しているし、外部の契約者が彼らの最高の仕事をすることもある。例えば、HugeはGoogle製品で3つのWebby賞を受賞している。

開発者の最大の資産は「ノー」と言うことだ。AIもそれを学ぶかもしれないけど、競争するAIがいる限り、どちらかが「イエス」と言うと思う。人間と同じようにね。俺の経験では、これが仕事の中で最も難しい部分だけど、多くの開発者が楽しんでるわけじゃないし、責任だとも考えてないと思う。開発者がほぼプロダクトマネージャーであることには常に需要があると思う。多くのプロジェクトの成功は、ステークホルダーを個人的に理解することにかかってるからね。

ところで、最近フリーランスの仕事はどこで探すのがいいんだろう？口コミ以外で。

「いいえ」と言うだけじゃ誰にも役立たないよ。むしろ「それはできるけど、X週間かかるし、費用やパフォーマンスはこれくらいかかる」っていうバリエーションの方がいい。そうすると、両者にとって有意義な会話が生まれるかもしれないし、リクエストが実際にどう良いのか理解できるかもしれないよ。

もしかしたらあなたの言い回しを誤解したかもしれないけど、十分な文脈があればAIはあなたが何をしたいかをかなり正確に判断できると思う。実際、これが人々が警鐘を鳴らしている恐ろしいことだと思う。十分な監視があれば、組織はあなたを世界で信頼性高く特定できて、かなりの文脈を構築できるようになるんだ。たとえAIグラスをかけていなくてもね。そして、その文脈があれば、AIがあなたが何を望んでいるかを推測するのは合理的なタスクになる。もしかしたら、その組織が望む最終状態に導く一連の出来事や行動を推測することもできるかもしれない。これは主にその一つの主張に対する反応だけど、あなたの全体的なポイントとは少し外れているかもしれないね。

よく言ったね。AIがエリートな人間の能力に匹敵するまでのタイムスケールがないかのように語られることが多いけど、それは妄想的な悲観主義に思える。

記事はほとんど間違ってるよ。企業はもう以前ほど新卒を採用してない。もしAIがアーキテクト以外のことを全部やってるなら（これは間違った主張だけど、まあ置いといて）、当然企業はAIシステムを設計・監督するエンジニアが少なくて済むようになる。

いや、AIはまだアーキテクトにはなれないよ。ここでの混乱は、アーキテクチャと計画の区別がつかないこと。計画は、関心事を解決策にマッピングし、リソースに応じて解決策の提供をプロジェクトする能力のこと。AIがそれを正しくできるとは思えない。人間の資産が商品であっても、簡単なことじゃない。計画に基づいて行動することをタスク実行って呼ぶ。アーキテクチャは、相互に関連するシステムのデザインとアート。競合する計画や協力する計画の層が関わってくる。AIには絶対にできないことだよ。一つの層での大きな幻覚が、他の層を破壊したり置き換えたりする可能性があって、それは壊滅的に高くつく。だからこそ、本物の人間がこの仕事をしていて、常に監査されているんだ。

でも、それが売り文句なんだよね。自分で考えなくてもいいボット。もし人々がまだ自分で考えなきゃいけないなら、何の意味があるの？

そうだね、AmazonがAWS SDK MCPをリリースして、数年待てば粗い部分が整ってくると思う。そうなれば実現可能になるはずだし、実際にそれをやってる業界があるからね（VercelやNetlifyなど）。

AIは建築できない。AIは建築をシミュレートできるだけ。多くの場合、AIはコードすら書けない。

開発者であることは別の意味を持つようになる。 そうでもないよ。プログラミングは機械に何をするかを説明することだからね。やり方は年々変わってきたけど、機械語を書いたり、パンチカードを使ったり、フレームワークを組み合わせたり、ボックスを描いたりするようになった。でも、核心はいつも同じ。自分が何を求めているのかよくわからない人から曖昧な要求を受け取って、それを機械が信頼できるように実行できる具体的なものに変えること。プログラマーたちは、これを最も効果的に行う方法がコードであることを見つけ出してきた。GUIは表現力が足りないし、英語は曖昧すぎたり冗長すぎたりするから、プログラミング言語が必要なんだ。電子コンピュータが存在する前から、数学のように専門的な言語があったのも同じ理由だよ。LLMはプログラミングの進化の一歩に過ぎないけど、プログラマーの役割は変わらない。機械に人々が求めることをさせること、プロンプトを使ったり、絵を描いたり、コードを書いたりしてね。コードがまだ主流であると思う。LLMは過去のことを繰り返すのが得意だけど、自然言語の説明を使ってオリジナルのものを書くのはかなりフラストレーションが溜まる体験だよ。プログラミングしているなら、少なくとも何かオリジナルな要素がある可能性が高い。そうじゃなきゃ、既製品を使えばいいわけだしね。今はハイプサイクルのピークにいるけど、いずれ落ち着くよ。新しい技術が出てくると、何かは必ず変わるからね。

もし「AI」を「LLM」として読むなら、そう、LLMは建築できないし、今後もできるとは思わない。10倍のパワーを与えても、今のスケーリングの限界を超えても、LLMは建築には根本的に向いていない。中小規模のコードの整合性すら難しい技術だからね。例えば「ユーザー名を検証する必要がある」と言って「ユーザー名検証ルーチン」の新しいコピーを作り出すことが多すぎる。これがうまく自動補完されるから。でも、そうすると7つ目の「ユーザー名検証ルーチン」ができちゃう。以前に何度もやったことがあるから、7つはどれも同じじゃないし、これは彼らの現在の病理の中でも特に分かりやすい例だよ。「建築」のゴールポストを動かしているのは、現代のLLMの文脈に「建築」がフィットすると思っている人たちだと思う。今のLLMはひどい建築家だよ、役に立たないどころか、インターンよりもひどい。インターンはまだ理解していないデザイン手法を模倣するかもしれないけど、それでもLLMが出しているものよりはマシだよ。次世代のAIが何になるかはわからないけど、システムの象徴的な地図を構築し、その地図を直接操作して、コードに反映させることができるAIが何を達成できるかは難しいところだね。でも、今はそれを実現する方法が誰にもわからない。試みが足りないわけでもないんだけどね。

次のホットなYCスタートアップは…UMLダイアグラムでAIをトレーニングすることだね :)

ちょっと時間がかかったけど、WixやWebflow、SquareSpace、WordPressは結局たくさんの作業を自動化したよ。

デザイナーも同じことだよ。「今は誰でもSquarespaceやWebflow、Framerでウェブサイトを作れる」って言うけど、テンプレート市場があって、テンプレートは - そう、デザイナーが作ってるんだよね…

70年代には、ビジネスマンがSQLみたいな高級言語を使って開発者を不要にするっていう記事が書かれてたんだよね。60年代はCOBOLだった。

プログラミング言語の歴史を振り返ると、時間とともに「自然言語」の方向に進んできたことがわかるよね。最初は1と0から始まって、次にアセンブリ言語に進化した。あの頃は、アセンブリ言語が高級言語だと考えられていたんじゃないかな。今の流れが続けば、今日の高級言語も近い将来には低級言語になってしまうかもしれない。アプリを書くのにアセンブリ言語を知っていることが重要じゃないのと同じように、そうなると高級言語を知っていることもあまり重要じゃなくなるよね。システムアーキテクチャは引き続き重要だけど。

AIのハイプに乗りすぎてる企業は、ディスラプションを招くことになると思う。俺は逆の立場だね。AIを無視してる企業は厳しい状況になるよ。

AIが作るシステムやその推論は、時間が経つにつれてまるでエイリアンが作ったかのように理解不能になるリスクが高いんだ。ソフトウェア開発には大きな社会的側面があって、私たち開発者は現代のソフトウェア開発について大体同じ認識を持ってる（今は例えば20年前や40年前とは違うけど）。AIがほぼ独りでやっていると、そのやり方も進化するけど、ソフトウェア開発に参加してその変化を追う開発者がいないと、どうなるかわからない。AIがソフトウェア開発をどう進めているかを見守り、方向性を示す専門家は少数必要になるだろうね。そうしないと、避けられない失敗事例を分析して修正することができないし、AIのやり方が人間にとって理解可能なものに保たれなくなる。AIがそこまで能力を持つようになると仮定すると、これは長くて複雑な移行になるだろうね。

ビジネスはコストセンターにおいて質を重視することがあるけど、それがコストを下げるからだよね。

どこで顧客が品質を重視してないって印象を持ったのか分からないけど、彼らは品質をすごく重視してるよ。もし顧客が品質を重視してなかったら、スタートアップは最小限の機能しかない製品を最安値で提供するだけで成功してたはずだし、量で収益を上げられたはずだよ。

その最後の方の文をこう変えたいな。「品質を重視するのはエンジニアだけだ」とかね。ほとんどのエンジニアは、値段が合えば品質や倫理を犠牲にすることに喜んでるかもしれない。全員ではないけど、変な文化だよね。複雑な論理を扱えるエンジニアが育つ一方で、「ビジネスの最大の関心は常に利益」っていうのが時々問題を引き起こしてる気がする。

品質が差別化要因になることもあると思う。iPhoneが出たとき、Windows PhoneやSymbianを搭載した他の携帯電話はもっと機能があって安かった。でも、iPhoneはスムーズに動いて、競合よりも洗練されたUIを持ってたから成功したんだよね。

人々は、自分のデバイスが壊れたり、ウェブサイトの読み込みに12秒かかったり、メディケイドの登録が午前9時から11時の間で運が良ければできるようになったときに、やっと気にし始めるよ。今はまだ相対的に高品質で、なんとか動いてるけど、数十年後には「OpenAI」って言う間もなく劣化が進むだろうね。政府の税制がアップグレードできなくなったり、インフラが理由不明で失敗したり、今はどこにでもある低電力のデバイスが珍しくなったりする変なことが起こるだろう。すべてがサブスクリプションとインターネット接続を必要とするようになって、何も正常に動かなくなる。ずっとLLMと話さなきゃいけなくなるよ。

これには全然共感できないな。まず、成功したソフトウェア製品はどれも非常に高品質だった。Googleの検索は、良くて速かったから勝ったんだよ。成功したウェブブラウザもすごくよく動くし、大きなOSも同様だよ。iPhoneは素晴らしい製品だし、Facebook、Instagram、TikTokも、どんな意見があっても、バグが多かったり遅かったりする製品じゃない（特に全盛期にはね）。Stripeは素晴らしい製品を作ることで成長したし、成功したB2B製品も高品質だよ。Databricksにはあまり愛着はないけど、ちゃんと動くし、Oktaはすごく印象的だと思う。Notionもすごくよく動くよ。（反例もあるけど、例えばRipplingにはあまり感心してない。）品質を重視してないのに成功した製品の例はどこにあるの？

ビジネスは品質を重視したことがない。顧客は品質を重視することがあるけど、ビジネスは利益率だけを重視する。君の言ってることは、ニュアンス的にはかなり近いと思う。ビジネスはコードの品質を重視しない。彼らの主な目標は、顧客を獲得できるように製品を迅速に出荷することだから。もし競争が激しい分野にいるなら、品質はもっと重要になる。差別化された機能を出荷する必要があるからね。逆に、ゆっくり進む分野では、出荷スケジュールは遅くても大丈夫で、品質はあまり重要じゃない。とはいえ、顧客は「品質」を気にするけど、彼らの定義はかなり違うかも。主に「使いやすさ」としてね。ソフトウェアが a) 彼らの望むことを実現し、 b) 彼らの意見で「十分に速く」動けば、裏で何のコードが使われてるかなんて気にしないんだ。

顧客は、質がある時に質を重視するんだよね。もし供給チェーンのどこかで、誰かが安さを優先したら、それが全てになっちゃう。

僕のお気に入りの品質重視の会社についてのいくつかの事実を紹介するね：https://www.fractalaudio.com/ 彼らは、ギター用のハードウェアベースのアンプ/ペダルモデラー（例えば、バーチャルペダルボードやアンプ）を作っていて、定期的にアップデートがあるんだ。感触や精度の面では、ほぼ全ての競合を上回ってるし、Line 6（ヤマハの一部）みたいな大手とも競争できてる。僕の知る限りでは、かなり小さな会社で、20人以下かも。ほとんどの改善は、CEOがアナログシステムを正確にモデリングする理解をどんどん深めているからなんだ。彼らはスタートアップとしてやっちゃいけないことをほぼ全部やってるよ：* ほとんどがハードウェア会社 * Sweetwaterみたいなところを通さずに直接販売 * アーティストに宣伝してもらうための報酬を払わない * サブスクリプションなし * モデリングアルゴリズムへの無料でかなりのアップデートがたくさん * 製品を早く作るためにAIを使わない 彼らの差別化ポイントは、混雑した市場の中での「質」なんだ。これ、特別なケースじゃないよ。市場の一部はこうやって機能してるんだ。すべての市場のすべての部分が、底辺争いに巻き込まれているわけじゃないからね。