それ、なんか分かる気がするな。 > 「AIが出る前は、両方のグループが毎日同じことをやってた。手でコードを書いて、同じエディタや言語、プルリクエストのワークフローを使ってた。クラフトを愛する人たちと、動かすことにこだわる人たちが隣同士に座って、同じ製品を出して、見た目は区別がつかなかった。作業のモチベーションは見えなかったけど、プロセスは同じだったから。だからこそ、AIにコードを書いてもらうことを喜ぶ人もいれば、自分が楽しんでた部分が大幅に減ったことに不満を持つ人もいるんだろうね。」Kellan（明らかに「動かす」グループのメンバー）も同じようなことを言ってる。 > 「その喪失感は、エージェンシーを感じたくてテックに入った私たちの世代には、感情的に理解しづらいこともある。ウェブは技術としては客観的にひどかったけど、本当に素晴らしかった。プログラミングが美的に楽しいから入ったわけじゃないし。」

本当の分かれ目は、質と基準だと思う。みんな受け入れられる基準が違うし、エンジニアとしての役割もその好みを反映してる。私は一つのコードに何時間もかけて、何度も繰り返しながら、自分が気に入る形になるまでやるけど、他の人はそれに価値を見出さないこともある。「動けばそれでいい」って考えの人もいるし、私たちはそれぞれ違った形で価値があるんだよね。それに、モデルの進化のスピードもある。多くの人が昨年の意見を持っていて、状況はかなり変わった。使いこなすためには努力も必要だし。「デフォルト」の出力は平均的な質だけど、ちょっと工夫すれば高品質な出力が簡単に得られる。みんなが懐疑的でいるのはいいことだと思う。深く考える必要があることや、新しい形でアイデアを結びつけることもたくさんあるし、私の経験ではLLMはそれが得意じゃないからね。

その議論は「ちょっと優しすぎる」気がする。二元的じゃないし、モチベーションは複雑で、時には両方の感情が共存することもある。私がなぜテックに入ったのかを考えると、いくつかの理由が見つかる。 - 問題を解決するのが好きだから。昔やってた特定の問題がなくなったのは悲しいけど、新しい問題があるのはワクワクする。 - 自分のスキルを使って他の人を助けるのが好きだから。今はそのやり方があまり効果的じゃなくなったのは悲しいけど、新しい形で知識を使えるのは楽しみ。 - 自分が違いを作れることをするのが好きだから。これも両方の側面があるね。ほとんどの人が似たような例を挙げると思う。

昔のことに対して悲しみを感じることは全くないな。ソフトウェアエンジニアリングが、プログラミングに情熱を持っていたオタクたちのものから、お金のためだけにやってるテックブロスに変わったのが一番悲しかった。ウェブの理想主義はずっと前に失われて、今はザッカーバーグみたいな apex 爬虫類がいる沼になっちゃった。ずっと前から利益第一になってる。私が感じる二つの感情は、恐れと興奮。機械にすぐに取って代わられるんじゃないかっていう恐れ。そして、今作れるものや、向かっている機会に対する興奮。これが一番楽しい経験とは言えないけど、興奮が少しバランスを取ってくれる。もしこの津波に完全に飲み込まれるのではなく、乗りこなそうとする緊急性を感じていなかったら、悲しみを感じるかもしれない。

分かれ目は決して見えなかったわけじゃないし、常に少なくとも三つのグループがあった。「動かす」人たちも、当時は何も動かせなかった。AIの有無にかかわらず、維持できないような馬鹿げたコードを作ってた。彼らは自分が何をしているのか分からないカウボーイだから、責任転嫁をして、たくさんの人におべっかを使ってる。「クラフトを愛する」人たちも、無限に無駄なことをして邪魔してた。彼らは今、AIを受け入れてるけど、それは自分が何をしているのか分からない理由として「クラフト」を使ってただけなんだ。今は少しだけ生産性が上がったかもしれないけど、チームの他のメンバーと議論する代わりに、自分自身と議論できるからだね。経験豊富で実践的な人たちは、常にその穴埋めを強いられてきた。彼らが意見を持てるなら、他の二つのグループがあまりダメージを与えないように、範囲を狭く保つだろう。彼らのAIの使い方は、昔と変わらずGoogle検索に限られてる。

でも、これは純粋な二項対立じゃないよ。私はずっと両方の側面を持っていて、仕事のためにエージェンティックなコーディングを少しずつ取り入れることで、家でのサイドプロジェクトで「伝統的」なプログラミングをするための新しい頭のスペースができた。アイデアを考えるワクワクするフェーズが好きだし、製品を動かすパズルを組み立てるのも好きだし、クラフトに誇りを持つことも好きなんだ。

何かを楽しむことと、それから満足感を得ることは別物だと思う。コーディング自体を楽しんでいるわけじゃないけど、何かを解決したときの感覚は好きだ。仕事の一環として新しいパズルを解くことが、年齢を重ねるにつれて脳の可塑性を保つのに役立つと思ってる。Claudeからそれを得られるかどうかはわからない。

> 誰もプログラミングをするためにPerlが美的に楽しいから入ったわけじゃない。今でも定期的にPerlに感動していたのを覚えてる。美しさにはこだわってなかったけど、難解だとされていることを知っていて、読んだり書いたりできることに誇りを感じていた。だから、そう、Perlのプログラミングは楽しかった。

「クラフト好きと、物を動かす人たちは隣に座って、同じ製品を出荷し、見た目も区別がつかなかった。」絶対に違うよ。オープンソースやエージェンシーの開発者としてのキャリアからの観察に基づくと、どのキャンプにいるかはコードの質を見れば一目瞭然だった。例外は少ないけど、物を動かすタイプは脆弱で、ハッキーで、短期的な視点の仕事を生み出す傾向があって、解決するよりも多くの問題を生むことが多かった。そして、彼らの貢献の質が低いために、FOSSプロジェクトへのコミット権を失うのを何度も見てきた。「誰もPerlでプログラミングするのが美的に楽しいから始めたわけじゃない。」Cで何かを達成しようとするのと比べると、Perlは本当に夢のような言語で、当時の他の一般的な言語に比べて、Perlの持つ柔軟性と表現力が好きで、ウェブ開発に惹かれる多くの開発者がいたんだ。幸運なことに、私たちのために言語設計やツールも進化したしね。

> ウェブは技術としては客観的にひどいもので、実際には素晴らしいもので、誰もPerlでプログラミングするのが美的に楽しいから入ったわけじゃない。古い学校のPerlコーダーとしては、それは違うと思う。Perlを好む人はたくさんいたよ。「TIMTOWTDI」は実際の利点として売り出されていたしね。Perlは、ほとんど誰もやらないようなことに対応している。例えば、「unless」の中のネガティブな「if」とか、コードの後に条件を置くこととか。だから、こんなことができるんだよ：frobnicate() unless ($skip_frobnicating); これは、機能的には同じだけど、if (!$skip_frobnicating) frobnicate(); よりも読みやすいかもしれない。最初の方法では、プログラムの通常のフローを先に示してから、「稀な特別モードならこれをスキップできる」って後から付け加えている。使い方次第では、確かに何か特別なものがあると思う。Perlの最大の問題は、素晴らしいアイデアから始まったのに、十分に進化しなかったことだと思う。いろんなものが後から付け加えられて、みんなが少しずつ違うやり方で追加した結果、実際には脆弱なコードベースができてしまった。

SWEsは、コード生成モデルが全くコードを書くことができることに本当に驚いていると思うし、ましてや上手に書けるなんて。私の推測では、このことに対する多くの不安は、「私はコードが書けるから賢い/特別だ」と思っていたのに、機械がほぼ同じ仕事をできるようになったことで、完全に不安定になっているからだと思う。それに共感するけど、私自身はそうは感じていない。この「実行者対創造者」という二項対立が時々出てくるのが本当に嫌いで、コード生成モデルが完璧でないと思っている人は何も作りたくないかのように扱われるのが嫌だ。私は本当に良いものを作りたいし、コード生成モデルの現在の過熱波が良いものを作るのを難しくしているのが嫌だ。私は仕事でいくつかの大きなものを作るためにClaude Codeを使っている。質問を投げかけたり（「これはどこで起こるの？」「問題Xがある、3つの潜在的な原因を教えて」など）、PRを投稿する前にレビューしてもらったり、コードレビューのボットが実際のハイゼンバグを見つけたりしている。これらのすべてにおいて成功は混在しているけど、それでも全体的には役に立っていると思う。もし今働いている場所でClaude Codeやそれに類するものを使えないと言われたら、イライラするだろう。ただ、私は以下のことに関しては役に立たなかった： - ブラウンフィールドプロジェクトでの全体的で複雑な機能の構築 - システム的なバグの解決 - システム設計/進化 - 機能/製品の設計と計画 - シニアエンジニアのコードレビューの代替 それがこれらのことをやったと自信満々に言ってくるけど、実際にその出力をレビューするために精神的に苦労すると、失敗していることに気づく（この分析を行うには専門家である必要がある）。今、もしかしたらそれは許容できる方法で失敗しているのかもしれないし、わずかな修正が必要なだけかもしれないし、一発で変更を成功させることができるかもしれない。そういうのは良いケースだ。もっと厄介なのは、完全に明らかに失敗する場合だけど、本当に悪夢なのは、完全に失敗するけど、気づかない場合だ。それに時々は（これらのことの一部）をできることもある！でも、一貫性がないから、成功が失敗に対する警戒心を下げることが多い。精神的な苦労は本当にある。モデルが従うべきアーティファクトを生成/レビュー/確認するのは重荷だし、生成されたコードも重い。コードレビューはさらに面倒で、コードの背後に人間の思考がないから、著者のメンタルモデルを構築できない。コード生成モデルに自分の作業を修正させたり、別のアプローチを取らせたりするのは、非常に運次第だ。自分でコードを修正するには、生成されたコードの何千行も読む必要があるし、また人間がいない状態で何が起こっているのかのメンタルモデルを構築する必要があるから、それは時間がかかって疲れるプロセスだ。私はまた、二次的な影響についても懸念している。しばしば必要とされる深い精神的集中に切り替えるのが非常に難しい（ほぼ痛みを伴う）、その瞬間に多くの人がLLMに手を伸ばすのを見てきた。最初は少しずつ、次第に完全に。APIドキュメントをGeminiのプロンプトにコピー＆ペーストして説明させる人を見たり、コードの構文エラーを見つけられずにChatGPTに修正させる人を見たりしてきた。私だけがこれを観察しているわけではないと確信しているし、もっと注目されるべきだと思う。--- SWEsが似たような方法で失敗しないとは言っていない。私は、実際の影響を持つ巧妙な欠陥がある人間のPRを承認したり、作成したりしたことがある。ChatGPT以前に、必要以上に10倍も大きなPRを「レビュー」するように頼まれたこともある。コードを盗用したり、Stack Overflowを常にコピー＆ペーストする人を見たこともある。違いは、私たちはこれらのリスクに対してプロセスを構築していることだ。コーディングパターン、PRのサイズ制限、型システム、解雇、ばかげた量のユニットテスト、CI/CD、設計文書、ステージング環境、赤/緑のデプロイ、QAリストなど、すべてが含まれている。私はそれが大嫌いだ！それは私の欠点を常に思い出させて、リリースされたコードのドーパミンのスカッシュまでの時間を遅くする。私はこのすべてを切り捨てる最初の人になるだろう。Claudeを、レビューしなければならない圧倒的に長いPRのリストに向けたい。でも、まだ大きな欠陥があるからできない。コードレビューのボットは明らかな問題を見逃し、システム/バグ/機能について十分な文脈や知識を持っていないため、十分に包括的なレビューを行えない。プロダクションでバグを修正したり、すでにデプロイされた機能/修正を修正したりする必要があるので、時間の無駄になるだろう。これらのモデルは、SDLCの他の部分で人間を適切に置き換えることはできない。でも、デザインやコードレビューのような厄介なことがコード生成モデルの速度を制限しているから、業界はそのすべてを「再考」している。モデルの欠陥については考慮せずに。「再考」とは、LLMにすべてのコードレビューを任せることを考えているか、まったく行わないことを意味している。これを表現する唯一の方法は、無謀な無視だ。これはプロフェッショナルではなく、倫理的でもない。だから、私の悲しみは「技術」についてではないと思う。それが失われたとは思わないし、もしそうであっても気にしないだろう。私の悲しみは、

ジェネAIをクラフトの精神で使うこともできるよ。例えば、オープンソースソフトウェアを使ったり、実装したり、拡張したりする必要があるときは、エージェントIDEに読み込んで「どうやってやるの？」とか「どうしてこうなるの？」って質問をすれば、しっかりした基盤に立てるんだ。

そして、自分の変更を元に戻すのが大事だよね？

> パズルを解くのが終わったのかと思ったけど、そうじゃなかった。レベルが上がっただけだね。クラフトもレベルアップできるし、実装についての決定、どのアルゴリズムを使うか、どう組み合わせるか、何をテストするかなど、基本的にはより高いレベルでシステムを作り上げることができる。似たような意味で、コンパイラが登場してアセンブリコードの手作り感は失われたけど、今はクラスやアルゴリズムの作成もある程度失われつつある。でも、システムを作ること自体はまだできる。何をどうやって動かすか、そして最も重要なのは「なぜ」それをするのか。

これにはAIはいらないよ。数十年も前から検索エンジンや良いオンラインリソースがあったし。

この手の話はよく聞くけど、ほとんどが結果を追い求める人たちからだね。結果を追い求める私には響かない。木工が好きなのは、前に存在しなかったものを作るのが楽しいから。CNCルーターや3Dプリンターを使うのも全然気にしない。プロセスには興味がないけど、結果にはこだわる。でも、結果の質には深くこだわる。コードの美しさには興味がないけど、15年前よりもアプリが起動するのに時間がかかるのは気になる。私のHomePodが、妻が買い物リストに何かを追加するたびに、5回に1回はiPhoneとの接続に問題があるって言うのも気になる。証券会社のウェブサイトが壊れてて、テクニカルサポートに電話しなきゃならなかったのも嫌だった。彼らはそれが壊れているのを知っていて、旧バージョンに戻すためにパラメータを追加する必要があるって言われた。Claudeのデスクトップアプリを使ってると、時々クリックできないボタンが表示されるポップアップが出るのもイライラする。AI支援のコーディングについては、十分な経験があるから自分なりの意見がある。コーディングは質の高い製品を作るためのボトルネックじゃない。問題を理解することが一番のボトルネック。何を作るべきか、何を作らないべきかを知ることが重要。次に大事なのは、周りの人たちを納得させること（これにはさらに時間がかかることもある）。その後は、完璧になるまで何かを繰り返し改善すること。時にはアニメーションがちょうど良く感じるまでイージング値を調整することもあるし、パフォーマンスにこだわることもある。時には、既存のアプリをバグがない状態にするまで進捗を止めることも。AIはこれらにはあまり役立たない。少なくともあまり。コーディングに費やす時間は、理解し、診断し、完璧にするための時間だから。コードじゃなくて、製品のために。AIは一時的なツールを作るのには役立つし、慣れないコードベースや、何らかの理由で速度が重要なコードベースでの作業には役立つ。検索やラバーダックにも役立つ。これらのことは私の生産性を向上させると思うけど、全体で10%くらいの効果かな。

> AIはこれらにはあまり役立たない。少なくともあまり。コーディングに費やす時間は、理解し、診断し、完璧にするための時間だから。コードじゃなくて、製品のために。実際、ここでもかなり役立つことがある。AIにコードを書かせたり編集させたりすることはほとんどないけど、情報収集や、考えもしなかったエッジケースを見つけたり、依存関係のコードを掘り下げたり、アイデアや代替アプローチを見つけたりするのにはいつも使ってる。私の使用法の90%は、情報収集を手伝ったり、批評したり（異なるペルソナで複数のレビュースキルを持っていて、複数のLLMを使ってる）、洗練させたり、レビューしたりすることだ。製品関連のことでも、クライアントの多くは複雑なビジネスロジックを持っている。マルチテナントの会社の倉庫ソフトウェアの話で、各プロセスが drastically 違って、複雑さがすぐに膨れ上がる。異なる情報源（古いJiraタスク、Discordのダンプ、Confluence、コードベースなど）をつなげるのに役立つ。そして、手動でブラウザを操作して最も珍しいパスをテストするのと同じように、アプリケーション内でエッジケースを反復的にテストして見つけることもできる。この支援がなければ、私はもっと少なくて済んだと思う。なぜ人々が最も力を与えない部分（コード）にそんなに焦点を当てるのか理解できない。実際、そこはすぐに複雑さが膨れ上がったり、あまりにも多くのコンテンツや編集で圧倒されたりして、質を維持するためのエネルギーを持てなくなることが多い。

コードの質と製品の完全性を混同してるみたいだね。これらの問題は開発者ではなく、ビジネスの決定によって引き起こされている。AIがもっと多くの人に自分のものを作る手助けをするかもしれないという点は良い指摘だね。

> コーディングは質の高い製品を作るためのボトルネックではない。私もそう言ってる。10倍エンジニアの話は、以前に90%以上の時間をコーディングに費やしていて、今はAIが生成できるから一桁になった場合にしか意味がない。もし以前に20-30%の時間をコーディングに使っていて、残りの時間を問題解決や良いUXについて考えていたのなら、AIのコーディング支援は数学的に10倍エンジニアにはならない。せいぜい2倍エンジニアにするかもしれない。これを考えると、自分の成果について何かを気づいたかもしれない…私はおそらく異常に優れたコーダーなんだ。子供の頃からやっているから、コードを書くことや読むことはほぼ第二の自然になっている。若いティーンエイジャーの頃、コードを書くためだけにノートパソコンを持って旅行に行くこともあったくらい、そんな人間だった。だから、どのチームにいても、常に最強か、あるいはその一人だった。コードで何かをする方法を考える必要はほとんどなかった。コードが私にとって大きなボトルネックだった時期を思い出すのは難しい。でも、出荷の速さでは他の誰よりも早くはなかったけど、出力の質は常にずっと高かったと思う。それは、他の人たちがコードを書くことに多くの時間を費やして、PRできる何かを作ろうとするのに対して、私は常に最高の結果を得るためにもっと多くの時間を考えたり反復したりしていたからだ。今の問題は、私が働いている人たちの中には、コードすら読めない人もいて、彼らが1日に何千行ものコードを吐き出せることだ。だから、チームの他のメンバーに追いつくために手を抜かざるを得ない。6-12ヶ月前は、チームの人たちからコードを書く手助けを求められることが1日に少なくとも2-3回あったけど、今はみんなAIに聞いてる。数ヶ月間、コーディングに関する質問をされたことがない。正直言って、これがイライラする。コードの中に悪い決定があちこちに見える。例えば、変更が難しいのは悪いアイデアだから。ウェブサイトのページがモバイルやデスクトップであまり見栄えが良くない場合、以前なら良いレスポンシブデザインを考え、適切なブレークポイントを実装する必要があった。でも今は、Claude Codeにモバイル用の全く異なるページを作ってくれと頼むだけで済む。人間にとっては大きな労力だけど、そんなことを良いアイデアだと思うような愚かな人でも、維持しやすく実装しやすい何かをするように強いられるだろうけど、AIには関係ない。動くんだから。AIは「ノー」と言わない。コードの質が低下しているのはわかってる。Claudeが書いていることを理解していない人からのランダムなバグが見えるけど、彼らがAIに修正を頼むことができるなら、それは重要なのか？ > これらのことは私の

> 木工が好きなのは、今まで存在しなかったものを作るのが楽しいから。CNCルーターや3Dプリンターを使うのも全然気にしないよ。プロセスにはこだわらないけど、結果にはすごくこだわる。でも、結果の質にはめっちゃ気を使ってる。じゃあ、他の人に外注しちゃえばいいじゃん？そうすれば、自分は何もやらなくて済むし。

記事は完全に誤解してると思う。「クラフト」コーダーも結果を追い求めているんだよ — ただし、持続可能で、基盤にできる結果を追い求めているだけ。私はこの業界にしばらくいるけど、私が知っている優れたプログラマーの目標は、自分を無用にすることだった。そう、手作りのアセンブリを丁寧に作るのは楽しかったし、サイクルを数えたりビットを詰めたりするのも好きだったけど、コンパイラを使うことに誰も私を説得する必要はなかった。基本的なCRUDアプリを書くのに多くの実りある時間を費やしたけど、今はライブラリやフレームワークで簡単にできるから、戻りたくはない。メモリ管理、型システム、高水準言語、設計ループの一部から完全に私を外すノーコード/ローコードシステムなど、すべて素晴らしい。コンピュータプログラミングの目的は、コンピュータに私たちがやらなくてもいいことをさせることだと思う。実際に見ている本当の分断は、ソフトウェアを根本的に改善可能で理解可能なものと見なす人たちと、他の人によって押し付けられた神秘的な障害物として見る人たちの間にある。奇妙なことに、第二のカテゴリーにいる多くの人は第一のカテゴリーの用語を使うけど、根本的には第一のカテゴリーが本当に存在するとは信じていない。（それも理解できる。第二のカテゴリーには驚いた。）これは知性や何かの問題ではなく、マインドセットや視点の問題だと思う。

> 知能とかそういうことじゃなくて、マインドセットや視点の問題なんだ。最後の文を除いて、君の言ってることには全部同意するよ。君の書いたことはすごく知的に見えるし、第二のキャンプにいる人たちの多くはこれに追いついてないと思う。

同じことを繰り返してるよ。君は、良いメンテナンスができるものを持つことが重要だと思ってる - 第一のキャンプよりもね。それが正しいってわけじゃないよ。この考え方は、真剣な再利用可能なライブラリやオープンソースツールにしか役立たない。ほとんどの企業のコードは、たくさんの探索と迅速な反復を伴う。コードの質はそれほど重要じゃない。誰もそれを見るわけじゃないし。クラフトコーダーがこの環境に自分のイデオロギーを持ち込むと、間違ったターゲットを最適化してるから、物事が遅くなり始める。

> 知っている優れたプログラマーの大半の目標は、自分自身を無用にすることだった。コーダーたちが自分たちは無敵だと思っているときに、このマントラをよく聞いたけど、今はあまり聞かないね。

それを言葉にしてくれてありがとう。

うん、この考え方すごく好きだな。システムにしばらく取り組んでいると、詳細がなくなる瞬間が来るよね。システムの動作のあらゆる側面が何らかの形で重要だと理解される。もしその詳細の一つが変わると、その変更がシステムやユーザーにどんな影響を与えるかがわかる。でも、AI後のソフトウェアの世界では、それが起こらないんじゃないかと心配してる。システムはほとんど見たことのないコードで溢れかえっていて、全てを理解するのは絶望的になると思う。もしバグを引き起こさずに変更するのが不可能なら、問題を理解するよりも新しいシステムをAIで作る方が合理的だよね。モジュラリティがもっと重要になるんじゃないかとも思う（物理的な建設でもそうなってるし、職人のような気まぐれな石膏から安くて効率的なドライウォールへの移行みたいに）。AIが信頼性を持って変更できないシステムは簡単に置き換えられるようになるかもしれない。

ふと思ったんだけど、分裂ってピルシグの古典的 vs ロマン的なものに似てるのかな？最初はほぼ機能性や事実を見て、骨の髄まで理解したいと思う人と、見た目や効用、感情を重視して、ただやり過ごしたいと思う人の違いみたいな感じ？

本当の分裂は、技術の進歩がそれ自体で良いもので、自然の法則によって常に生活を良くし、楽にすると思っている人たちと、歴史を知っていて、8時間労働日が蒸気機関から生まれたわけじゃないことを知っている人たちの間にある。実際の「自然な」結果としての生産性の向上は、労働量の増加だったからね。

本当の分裂は、私たちの労働で生きている資本所有者たちの間にある。通常は、自分が作り出すものの何パーセントを所有しているかを示す紙切れを相続しているんだ。

Hacker Newsでこういう考え方がもっと見られるのは興味深いね。AIが開発者を置き換えることの副次的な影響の一つは、賢くてやる気のある人たちが左に動くことかもしれない。成長のある一定のポイントを超えた後の副次的な影響を考えるのはいつも面白い。高い株価評価は、こういうことを考慮しないことが多いからね。例えば東インド会社の場合、会社は国のサイズまで成長し続けられる。でも突然、他の国はあなたをペットではなく外国の勢力として扱うようになる。

ここでの絶対主義的な極端さはすごいね。とにかく全力で突っ込もう。実際の分かれ目は、科学と技術を支持する人たちと、科学と技術を嫌って子供たちがもっと死ぬのを見たい人たちの間にある。

世界における生成AIの最適な量はゼロだと思う。考えられるシナリオは3つ、どれも悪いけどね。1. 期待よりも弱いAI。大恐慌2.0。すでに行われた巨額の投資が実を結ばず、広範な貧困と苦しみが広がる。2. AIが期待通りに機能する。ディストピア。数人のトリリオネアが世界を完全に支配し、他の人々は奴隷にされるか、殺される。3. 期待以上に強力なAI。急激な特異点シナリオ。すべての生物の絶滅。もう抵抗するのは無理かもしれないけど、少なくとも試みるべきだと思う。

同じ人たちが1と2から利益を得て、3はただのファンタジーで、一般人の注意を1と2から逸らすために売られているって気づくかもね。なんて偶然なんだ。

AIが魔法のように見えるのは、テキストの応答がアクションやツールの呼び出しに変わるからだよね。AIは、プロンプトを満たすためにツールを呼び出す順番を決めてる。上で言ったタイプ2と3の真の知能は、構築、計画、トレードオフの分析、批判的思考、そして新たな予期しない問題を解決する必要がある。

私も似たような意見を持っていたけど、AIが第二の来臨として持ち上げられ始めた頃から、停電やデータ漏洩、お金が引き上げられる事例が続出するのを見てきた。今は？避けられない現実を待っているところ。AIは消えないし、私個人としては消えてほしくない。経験豊富な開発者にとっては強力なツールだからね。でも、私の意見では、市場は過剰な期待を修正するのが近いと思う。現実は、どれだけの嘘を受け入れられるか限界があるから、そろそろ現実に直面しなきゃいけない。ここ数年の約束は果たされていないし、大金持ちは結果を求めている。だから、2026年にまた別の（重要な）驚きが出てこない限り、必要な長期的成長を維持するための勢いはないと思う（つまり、大衆の受け入れという点では、このAIの時代はFacebookよりもAOLに近い）。

もう、ただ単にバカな機械式キーボードで文字を打つのが好きな人たちのことを気にするのはやめるべきだと思う。実際の違いは、システムを理解して新しいものを発明するのが好きか、誰か他の人にその部分を任せて、自分の成功を喜ぶだけでいいかってことだと思う。もちろん、他の人が人間の場合、メンターとして支援したり、成功と成長のための条件を作ったりした場合は、その功績を正当化できるけどね。

反対だな。開発者には2種類いるのは明らかだと思ってた。極端な例を挙げると、開発者Aは長くて時には退屈で、セキュリティを重視した徹底的にテストされたコードを書くし、CIパイプラインも作ってる。チケットが与えられたら、ユーザーの視点からは全く意味がなくても、指示通りに開発する。開発者Bはそのことを何も知らず、テストも書かず、セキュリティにも気を使わず、デプロイの仕方もわからないけど、ユーザー（他の開発者や未来の自分）が好きそうなことを考えて、それを作ろうとする。どちらも役に立っているけど、最初のタイプは通常もっと評価される（多分本当に重要だからだろうし、Bタイプの貢献は測りにくいから）。おそらくAIはAタイプには少し早く来たけど、Bタイプもすぐに続くだろう。今のところ、彼らはAIが面倒だけど重要な詳細を処理してくれるから、ちょっと楽しんでいる。

これは人々が楽しみを見つける場所について何も言っていないね。私はパズルを解くのが好きだ。計画するよりも好きだ。結局のところ、最高のものを作るために何でもするけど、それが何を伴うかによって楽しさは変わる。

「クロード、これらの重りを持ち上げて。」

誰が好きかどうかに関わらず、物事が変わっていることを理解して、 relevancyを保ちたい人たちはどうなるの？最終的な製品に気を使って、POCのデザイン決定で迷わない人たちは？AIに対する異なる視点を持つ人たちを、技術に抵抗する人たちよりも劣っていると考えるのは、もっとニュアンスがあることを理解している人がいるのでは？あなたは「正しい方法」を知っているかもしれないけど、世界が変わっていく中でそれに適応しようとしている人たちにとっては、この意見はあまり説得力がないよ。問題を自分なりに解決するのは自由だけど、これが唯一の「正しい」方法だと示唆するのは論理的じゃないし、AIで構築する人たちが「システムを理解するのが好きじゃない」と暗に示すのはおかしい。AIで何かを作ると、今まで作ったことのないものができるし、その過程で知らなかった技術やデザイン、ツールに触れることができる。そういうことについて質問もするしね。確かに、単純な質問に答えるために10時間も無駄にした人ほど深くは理解してないけど、それが特に価値があるとは思わない。

システムを理解するのが好きで、新しいものを発明するのも好き、そしてAIに単純作業を任せるのも喜んでやる人間として、あなたの言う通りだとしたら、私は存在しないべきなんだね。もちろん、私は反対だよ。

「本当の分裂」は、常に知的で道徳的に優れた私と、劣った彼らの間にあるのが面白いよね。

> AIが登場する前は、両方の陣営が毎日同じことをしてたんだよね。手でコードを書いてた。AIの前から分かれてたと思うし、これらの陣営は同じじゃなかった。常に「クオリティ重視」の人たちと「とにかく早く終わらせる」人たちがいた。前者は依存関係に対してより慎重で、より良い考慮をする。後者は汚いPOCコードを書いて進むし、小さな機能のために巨大なサードパーティのライブラリを追加したりする。どちらにも長所と短所がある。前者は航空宇宙や医療技術のような環境では優れているし、後者は製品会社やウェブで活躍する。後者のカテゴリは、AIに最も喜んでいる人たちで、最初から最後までエージェントに全てを任せることが多い。

私はその分かれ方を少し違った視点で見てるかもしれない。私にとっては、一部の開発者がAIによって完全に生成されたものであっても、自分で何かを作ったかのような満足感を得られるってことが大きい。公開リポジトリをクローンすることで同じ満足感を得られるかって言ったら、たぶん無理だろうね。自分が関わっていないことが脳に明確すぎるから。cmakeでプロジェクトを構築するのはどう？確かにもっと努力が必要だけど、根本的なプロセスは誰かが設計したものだってのは明らかで、満足感は得にくい。でもAIはそのプロセスを隠す層を追加するんだ。ある人にとっては、それが根本的なプロセスをマスクして、自分がまだツールを使っているように感じさせるのに十分なんだろうけど、他の人にはそうじゃない。

あなたの比喩が全然理解できないな。例えば、xyz機能を持つアプリを作りたいとするよね。調査した結果、xyz機能を含むアプリは存在しないことがわかった。でも、x機能、y機能、z機能のどれか、またはその組み合わせを持つアプリはたくさんある。全ての機能を持つアプリがないなら、自分で作るしかないよね。それには時間がかかるかもしれないし、特にMVP（最小限の製品）だけが興味の対象ならなおさら。LLM（大規模言語モデル）はMVPを作るための新しいツールなんだ。時間が限られているなら、LLMを使えばいい。xyz機能はそのトレーニングセットに含まれているから、うまくいくはずだよ。あなたの比喩は、abc機能をサポートするアプリを作る開発者にも当てはまると思うけど、すでにabc機能をサポートするアプリがあるのにね。うん、それはあまり面白くないと思う。あなたの何度目かのスネークのクローンは興味深くないよ。

> 私は知っているウェブを失ったことを悲しんでいる。手でHTMLを書くことではなく、オープンなウェブというエコシステムを悲しんでいるんだ。これらは言われているよりも関連性が高いと思う。創造を個人から企業所有のAIツールに移すことは、自分でウェブ上で書けることから、所有されたツールに従うか、主流から追い出されることを強いられることへの一歩なんだ。私たちはまだその二つの間のような状態にいるけど、DIYウェブは後ろに迫ってきていて、独自の生成AIの採用が進むたびにそれが加速している。