好奇心の部分には同意するよ。私はCSのバックグラウンドはないけど、好奇心からプログラミングを学んだんだ。それがきっかけで、実際に企業が使うプロダクションアプリケーションを作ったし、これがAI時代の前の話。今はAIがいるから、まるで自分のアシスタントエンジニアがいるみたいで、ワクワクするものを作る手助けをしてくれる感じ。

エンジニアは問題に気づいたら戻ってきて修正するか、誰か修正できる人を探すよ。でもAIは、君のコードベースをめちゃくちゃにしながら、ハッピーな絵文字を送って、完全にメンテナンス不可能な状態に持っていくんだ。

私はこの「好奇心」のキャンプにしっかり入ってるよ。ここ15年くらい（？）HNを読んできた。CSを中退してアートの学位を取った。キャリアは別のところにあるけど、その過程でシステムを理解することが趣味だった。いつかすべてを止めて「本当のエンジニアリング」を学びたいと思ってたけど、結局やらなかった。代わりに、自由な時間に企業ソフトウェアアーキテクチャ、プログラミング言語デザイン、コンパイラ最適化、オープンソースの政治についての難解な記事を何百（何千？）も読んできた。私には持ってない暗黙の知識がたくさんある。持ってないって分かってるのは、他の分野ではその知識を持ってるから。自分が「本当のエンジニア」であることについて知らないことがあるってことも分かってる。でも、味覚は知ってる。どんな質問をすればいいかも分かってる。魔法の言葉や答えを探す場所も知ってる。私みたいな人にとって、これは狂ったような黄金時代に感じる。アイデアには困ってないし、今は手や目、いい週にはトークンが足りないだけだ。

でも、誰もが言わないのは、エンジニアのほとんどが書けないようなコードを静かに何百回も書いていることだ。こういうことが起こるのは、a) ランダムで、b) 滅多に起こらないから？

一つの問題は、開発者たちが過去数十年にわたって、Googleに関連するキーワードをいくつか入力するだけでオンラインで問題の解決策を探すように訓練されてきたことだよね。でも、AIを最大限に活用するためには、まるでイギリスの王室に正式な手紙を書いて背景を説明するかのように、しっかりとプロンプトを作るべきなんだ。基本的な英語のライティングスキルと、自分の考えを明確にまとめる能力が、エンジニアリングにとって必須のスキルになってるんだよね（でも、実際には多くの開発者がこれを欠いている）。

でも、それが問題なんだよね。時にはすごく信頼できるものが、他の時には全然ダメになることもある。自分自身や同僚を見ていて、LLMを使うことで早く燃え尽きたり、認知負荷が高くなったりするのを見てきた。もうただコードを書くんじゃなくて、何をする必要があるかを考えて、他の誰かが書いたコードのように見直すことになる。LLMは迅速なプロトタイピングやボイラープレートにはすごく役立つけど、私自身も毎日使ってるけど、Claudeが犯すミスの量は無視できないと思う。

K字型の労働力の話は鋭いね、あなたが正しいと思う。好奇心旺盛な人たちは少数派だけど、彼らが常に物事を前に進めてきたんだ。AIがそのギャップをもっと見えるようにしただけだね :) あなたのCodexのケーススタディ、コンテンツクリエイターとの話は面白い。生物学の博士号とライティングの修士号を持って内部ツールを作るなんて…まさに「今は何でも学べる」って言ったのはこういうことだよ。私の職場には博士号や教授がたくさんいて、物事が進んでいることに本当にポジティブな気持ちを持ってる。彼らは深い専門知識を持っていて、今は必要なツールを作れるようになったんだ。面白い時代だね。ぜひそれを書いてほしいな。

これも私の経験だよ。また、シンプルさを追求せず、アーキテクチャを考えない人たちは、非常に不安定で更新や強化が難しい巨大なモンスターを作り上げることになる。彼らは通常、自分たちの混乱を解決するために別のエンジニアを探すんだ。新しいエンジニアにとっては、簡単な方法はアーキテクチャを整えて、Claude Codeで一気に作ることなんだけど、彼らは自分たちの混乱に囚われていて、それを手放せない :(

ちょっと優しく言おうと思うんだけど、これはすごく軽薄で、人々はこれを不快に感じたり、嫌悪感を抱くかもしれない。すべての抵抗や懐疑心を無関心に丸め込もうとするのは、もしかしたらAI批判者をさらに遠ざけることが目的なのかもしれないね。そういうことなら、そのまま続けて。だけど、もし本当に仲間の態度に困惑しているなら、「自分には何が足りないのか？」（「好奇心」？）じゃなくて、「彼らは何を見ているのか？」とか「彼らは何に関心を持っているのか？」って聞いてみたらどうかな？もしかしたら、彼らは仕事の性質の変化に対して熱心じゃないのかもしれないし、「自動化の自己満足」が進むことを心配しているのかもしれない。特に「何百回も」まともなコードを書くのに対して「何かバカなこと」を一度書く割合があるから、たまにその「バカなこと」が彼らを通り過ぎて、AIの利点を全部消し去ることを恐れているのかも。もしかしたら、彼らは「典型的なコードがほとんどのエンジニアよりも優れている」とは感じていないのかもしれないし、「学び」がほとんど一時的なものだと感じているのかもしれない。去年の「プロンプトエンジニアリング」のアドバイスが今でも通用するのはどれくらいある？選択肢はあるし、彼ら（私たち？）を恐れや愚かさ、あるいは「無関心」から古い方法にしがみつくラダイトとしてレッテルを貼るのは簡単だけど、本当に理解したいなら、あるいは誰かの考えを変えたいなら、ぜひ彼らが本当に考えていることを聞いてみて、耳を傾けてみて。

でも誰も、ほとんどのエンジニアが書けるよりも優れたコードを静かに何百回も書いていることには触れない。あなたの経験は、私の正反対だよ。私は、LLMが完璧に一発で成功するって言ってる人が常にいる。友人グループや同僚、さらにはここHNでもそうだ。大手テック企業も同じことを言ってることが多い。ごめん、でも誰も成功について話さず、失敗にだけ集中しているって言うのは全く誠実じゃないよ。あなたはそのグループが少数派だと言ってるけど、すべての証拠は逆を指し示している。もし人々がそれが役に立つと信じていなかったら、LLM企業はそんなに成功していないはずだ。

もしかしたら、今は実行が安くてアイデアが高いのかもね。個人的にはこの逆転に満足してるよ。

AIのハイプを語ってる連中が、自分の10個のOpenClawインスタンスが動いてるって言ってるのを見るのはちょっと面白いね。で、何をしてるのか聞くと、いつもはっきりした答えが返ってこない…でも、エージェントコーディングは好きだよ。ソフトウェアの蓄積されたゴミを処理してくれるから。

それは分かる。どう読まれるかも知ってる。でも、誰でもノートパソコンとサブスクリプションがあれば、週末にプロダクションソフトウェアを出せる時代だから、アーキテクチャやアイデアがもっと重要になってくるんだ。投稿の技術的な詳細は本物だよ。ただ、何を共有できるかはまだ言えない。受け入れるか、受け入れないかだね。

境界線はスコープだよ。エージェントにフルスタックアプリを作ってもらうつもりはない。そうなると、幼稚園児のように世話をしなきゃいけなくなって、正直、自分でやった方が早いから。エージェントの使い方は、集中して文脈に基づいて、一度に小さなタスクに焦点を当てることなんだ。例えば、依存関係グラフを受け取って、トポロジカルソートして、特定のノードが変わった時に影響を受けるノードを返す関数が必要だとする。それはスコープが明確だよ。エージェントがそれを書いて、私がレビューして、終わり。でも、Postgresで接続プールのリークをデバッグしている時、負荷の下で接続が解放されないのは、リトライループの中でトランザクションが開いたままになっているからだ。そんなのをエージェントに任せるつもりはない。私たちのシステムはもう分かってるし、どのサービスが問題を起こしているか、ORMレイヤーも、接続ライフサイクルが管理されている場所も知ってる。エージェントを適切にガイドするために必要な文脈を書くのにかかる時間は、コードを開いて自分でトレースするのにかかる時間よりも長くなるだろう。それが境界線だよ。提供する必要がある文脈がタスク自体よりも大きいなら、自分でやった方がいい。タスクが明確に定義されていて、出力が簡単に検証できるなら、エージェントに任せればいい。でも、筋肉の記憶の話は本当だよ。新しいことを学んだり、まだ理解していない領域を探る時は、まだ手書きでコードを書くことがある。AIは不慣れな領域で直感を育てるのにはひどくて、理解できない出力を評価できないからね。でも、日常的なスキャフォールディングやボイラープレート、繰り返すことに関しては、私は手書きしないよ。人生は短いから、50回目のRESTハンドラーを手書きするのは無駄だよね。

ちょっと単純化した例を考えてみて。君はパン屋を経営してるとする。10人がいて、月に1,000斤のパンを作ってる。今、新しい半自動オーブンが導入されて、同じ量のパンを5人で作れるようになった。実際、最近の多くのパン屋でそういう状況があるんだ。でも大きな違いは、パン職人は形や材料がほぼ100%正確に再現されることを信頼できるってこと。何度オーブンを使っても、毎回同じようにね。オーブンの「最適な使い方」を考える必要もないし、「以前の10倍の量を焼く」なんて主張もしない。半自動オーブンは本当にちゃんと機能するんだ！これに近い体験を提供できるLLMを見せてほしい。

ちょっと単純すぎるかな。パン屋は製品の種類を増やしたり、他のことをして仕事を増やすことができるよ。実際、これはテック企業でも同じことが起こると思うんだ。

もしかしたら、パン屋はパンだけじゃなくて、ケーキやサンドイッチを作ったり、近くの町への配達を増やすかもしれないね。

もう一つの話だけど、もし100人のエンジニアがいて、そのほとんどを解雇して5人のスーパーAI加速エンジニアだけを残したら、競合が50人のエンジニアを残している場合、競合はまだ10倍の速さでイテレーションできる。だから、結局は人を解雇しても、遅れをとるリスクがあるんだよね。

ソフトウェアを作る行為を工場のライン作業に還元するのは無理があると思う。特にアムダールの法則を考えるとね。

ソフトウェアを書くのは、需要が固定された小さなパン屋みたいじゃない。常に作るべき機能や改善点が、キャパシティを超えてあるからね。良くも悪くも、ソフトウェア製品は決して完成しないんだ。

ソフトウェアに関しては、月に2,000個のパンを生産するって考え始めてる。今、ソフトウェアは供給に制約があったことに気づいて、組織はどのアプリやUIを作るかを非常に戦略的に考えなければならなかったんだ。今は、何でもアプリになり得るから、以前は見落とされていたビジネスユニット向けにもっとターゲットを絞ったフロントエンドを作れるようになった。

同意するよ。俺も時間が経つにつれて怠けてきた。でも、コードを作るコストがすごく安くなったから、初めてプロダクションに出すときに完璧であることがそれほど重要じゃなくなった。すぐにゼロから書き直せるしね。「メンテナンス性」のハードルもかなり下がった。AIがひどいコードを維持する能力と持続力を持ってるから。多くの人が俺に反対するだろうけど、俺は手動でプログラミングするのが得意だし、もうそれをする必要を感じない。人のために何かを作りたくてこの世界に入ったんだし、AIのおかげでそれがもっと効率的にできるようになった。そう、コードの品質に対する純粋主義的なアプローチを手放さなきゃいけなかったけどね。

10年前にこれらのAIがあったら、フレームワーク開発者/エンジニアになる代わりに、作りたいものに集中できたのに。特にテストが組み込まれたフレームワークは、今やガードレールとしてさらに重要だと思う。

本は、知識を暗記できない精神的に弱った人のためのものだ。 - ソクラテス

これにはちょっと異議を唱え始めてる。少なくとも、普遍的な真実かどうか疑問に思い始めた。例えば、「学び」というのは、間違ったアドバイスを何度も試して、やっと成功するための練習みたいなことが多い。AngularアプリがクライアントとSSRの両方で安全に動いている絶対パスを取得する方法には明確な答えがあるけど、そのタスクを達成するために間違った方法でやっている人がたくさんいる。こういう場合、LLMは最初から正しい答えを教えてくれることが多いし（それによって間違ったことを教えようとする過程での「ノイズ」が少なくなる）、その答えがどう適用されるかを説明してくれることも多い。私たちは過去30年間、「学ぶ」ということの意味を、検索エンジンが学びのインターフェースだった頃に多くの真実を持つバケツに精練してきた（その前は教科書を読むことだった）。この言い回しは、労働組合の仕事での「年功序列」や似たような形のゲートキーピングのように聞こえることもある。とはいえ、確かに「長い」方法で何かを学ぶことが、私たちの長期的な記憶や理解を価値ある形で広げることもある。だから、LLMを使うのはまだ私にとって難しい選択なんだ。経験が多い人にとっては、二つをより自信を持って区別できるから、選択はそれほど難しくないと思うけど、LLMを通じて学んだり達成したりすることが常に自己破壊的な道だとは思わなくなった。

結局、経済とその人自身、そして自分に対する態度に行き着く。深く学ぶ価値があるものもあれば、場合によっては簡単で早い解決策が求められることもある。最近、AIを使った「学び」のいくつかは、昔のCliffs Notesを使うこととあまり変わらないんじゃないかと思ってる。時にはCliffs Notesの要約を得ることで、論文を仕上げる方法や、退屈な/挑戦的な本（『緋色の手紙』、合ってる？）を素早く読み終える方法になることもあった。そして、場合によっては要約を読む方が本そのものよりも良いこともある。でも、みんなが同意できると思うけど、もしCliffs Notesだけを読んでいたら、自分の教育を台無しにしているだけだ。それは別の、もっと深い問題で、一部の人は自分に投資することに全く興味がない。彼らは最小限の労力で最大の報酬を得て、楽しむことを望んでいる。人が自分自身や成長、発展に興味を持つようにすること、好奇心を招くこと、それは時代を超えた問題だね。

私の解決策は優先順位をつけること。人生の中で全てを学ぶ時間は十分にないからね。深く学びたいことを選んで、苦労して取り組む。そして、あまり気にしないことについてはAIにお任せ。

これについては複雑な気持ちだ。片方では、LLMが少なくとも表面的には「ピンとくる」説明を見つけるのを楽にしてくれると思う。確かに、以前は利用できたけど、教科書にお金を払わなきゃいけなかったり（なんて素朴）、検索結果の5ページ目に出てくるウェブサイトにあったりした。短期的には、そういう外部的な要因が学習者にとってプラスになるかもしれない。一方で、学ぶことは行動することだ。少しでも難しくないと、それはおそらく学びではない。これは厳密にはLLMの問題じゃなくて、YouTubeの教育者に対しても同じ問題を抱えている。数学や物理の問題の素晴らしい視覚化を見ていると、学んでいるように感じるけど、実際には問題解決の筋肉を使っていないから、何も賢くなっていない。そういう体験を何度もしたことがある。誰かがLLMにELI5を頼んで、それを会話に活かそうとしたけど、返ってきた抽象的なものは彼らには深い意味があるように感じるけど、実際には役に立たないし間違っている。

作者が言いたいことはそうじゃないよ。毎日何回も、特定のコードや一般的な技術についてLLMと会話してる。これは同僚と同じ会話をするのにすごく似てる。確かに、LLMが間違えることもあるけど、そのために自分でコードを見たり、外部のドキュメントを探したりして、説明が正しいか確認してるんだ。重要なのは、LLMが僕のためにコードを書いてるわけじゃないってこと。説明をしてくれて、僕はそれを自分の仕事に応用できる検証可能な事実や概念的な枠組みを得てるんだ。

物事がこんなに変わっている中で、将来何が価値を持つかは不確かだね。

今はLLMのおかげで学ぶのがすごく早い。ウィンドウズのAPIを学びたいなら、もっと早く学べるよ。

大学の終わり頃に友達が言ってたことを思い出すな。「知ってることを全部学ぶのに年間1万2000ドルだけだよ」って。あんまり真に受けない方がいいけどね。

AIは、何も学ばずに実現するオプションを提供してくれるんだ。もし学ぶことが目標なら、学びを加速する手段もあるよ。

もっと早くHCOLに引っ越していれば、もっと早くあなたのようになれたのに。終わりまでにもっと時間がかかると思ってた...

僕はリストラされた開発者で、今は全く新しい仕事を探してるんだ。正直、AIと関わるのには全然興味がない。つまらなそうだし、その考え方もなんか気持ち悪いんだよね。

テック業界で働いてるけど、最悪なのはAIが支配するために集まった悲惨な要素を目の当たりにすることだね。いくつかの要因があって、ほんとに落ち込む。1. 経済的生産性と、会社が成功するための意味が、良い高品質な製品を作ることから切り離されてしまった。今や株式市場が最終目標だ。2. AIは開発者が自分のコードを理解することが良いという考えを強く拒否しようとしている。これは客観的に間違ってるけど、開発者を代替しにくくする無形のスキルだから、経営陣が必死になってるんだ。3. 開発者が個々に力を持ちすぎて、AIは労働力の力を削ごうとする現代の試みのように感じる。4. 短期的な利益のために長期的な生産性を犠牲にすることは常に可能だった。シニア開発者であることは、このトレードオフを理解し、後で自分を困らせるようなものを「今すぐ」出すように経営陣からの圧力に抵抗することを意味する。5. AIが長期的に時間を節約する唯一の方法は、自分で書いたのと同じくらいその出力を理解しない場合だ。コードや大規模なアーキテクチャを理解することが重要だよ。長期的な生産性の高いコードを書くことを望むなら、余分なステップを導入してしまったから、逆に時間を浪費してる。6. 残念ながら、多くの開発者は良いコードを書くことに興味がない。適当なものを出しても、クビにならなければそれで十分。もう製品を作ることなんて誰も気にしない。AIは以前よりもずっと少ない労力で悪い仕事をさせることができる。7. これらのどれも機能していない。AIはプロジェクトを早く進める原因になっていない。良い高品質なAIプロジェクトは存在しない。コードの質は下がっている。オープンソースソフトウェアもひどいことになってる。パフォーマンスが重要でなくなる文化の延長だ。WindowsはすべてがReactコンポーネントでできていて、それぞれが個別のウェブブラウザだから、最終製品の質なんてもう関係ない。ソフトウェアはどんどんひどくなっていく。これらの企業は自分たちの製品に本当に関心を持っていないから。AAAゲームはその良い例で、WindowsやDiscord、Googleの製品、IBM、Intel、AMDのソフトウェアも同様だ。これらの問題の多くはアメリカの問題で、あちらの経済状況や狂ったベンチャーキャピタリズム、労働組合潰しが影響してる。EUがもっと独立してソフトウェア競争相手になり始めると、アメリカのテック市場は絶対に崩壊すると思う。

現在、どうやって生計を立ててるのか教えてもらってもいい？

テクノロジーの世界から離れてよかったと思ってる。もうこれをやりたくないから。じいちゃんが、コンピュータを使い始める前にエンジニアリングから離れられてよかったって言ってたのを思い出す。俺が使ってた技術は楽しい技術だったけど、君たちが使ってるのは楽しくない技術だね。

AIの使い方についてブログを書いてる人たちは、みんなこんな感じだね。うーん、なんでだろう！

それな。俺も似たような感じでLLMを使ってて、知識のある同僚みたいにアドバイスを求めたり、何かを確認したりしてる。コードベースの変更は自分でやりたいし、テストも自分で実行したいんだ。エージェントが効率を上げるかもしれないけど、それは危険な道だよ。エージェントにコードベースをいじられたり、再度いじられたりするのを一日中見てるのは嫌だ。自分でやるのが楽しいから、AIが登場する前ほどではないけどね。

俺はストレートな質問をして、ストレートな答えを探す。1行ずつ、1ファイルずつ。LLMを問い詰めるときは、ソクラテス式の方法も使ってる。引っかけるような質問はなし、クリーンなセッション/コンテキストで、誤解されやすい言葉も使わない。これがうまくいってる。必要な情報はそこにあるから、引き出すだけなんだ。少し前にこの方法を使った演習があって、プロジェクトをコーディングしながらRustを学びたかったんだけど、AIは学びを加速するのにめちゃくちゃ役立った。全然関係ないこと、他の言語からのイディオムや慣習を翻訳することも知る必要があったし、特定の問題を解決するためのRustのイディオムについてももっと知りたかった。だから、解決策を書かせるんじゃなくて、一つずつ丁寧に質問したんだ。そのおかげで、何週間、いや、何ヶ月も節約できたし、今はRustも少しはできるようになったよ（まだ学んでるけど）。

プロンプトはこれからも残ると思う？SQLは長い間生き残ってるけど、サーブレットはそうじゃない。アセンブリから高級言語に移行したし、Flashはダメだった。だから、プロンプトがどれくらい続くかはわからない。今は素晴らしく見えるけど（当時のFlashやサーブレット、アセンブリのように）、別の技術が出てくると思う。おそらく、裏でプロンプトに基づいてるけど、今のプロンプトとは見た目が違うものになるだろう。プロンプトは残らないと思う。単なる一時的な「技術」だよ。

仕事は、名前を付けたり、説明したり、指示を出したりして、それらのパーツをフローチャートプログラミングに似た形で組み合わせることになる。それが人々が苦手なことだよ。人々が有限状態機械の概念や状態とロジックの違いを（直感的にでも）理解できないなら、LLMはコード生成ツールというよりも、むしろ願いの井戸（雰囲気）みたいなものだ。技術的な知識の問題もある。ソフトウェアは抽象の層でできていて、その下にもすでに抽象がある。それを知らないと、問題解決能力が制限されるよ。

あなたのエージェントクラスか、他にいいと思うもののリンクを教えてくれない？

最終的には、英語を超えた何かしらの言語を開発するかもしれないね。もっと正確で形式化されたもの。そうすれば、LLMは俺たちが言ってることを完璧に理解できるようになる。LLMはその形式化された言語に基づいてコードを生成できるし、Googleドキュメントもいいけど、俺たちが作るその形式化された言語に合わせたエディタを想像してみて。