業界の未来についてどう思っても、職人の木工でプロとして成功するのは、職人のソフトウェアより難しいと思う。市場のほんの一部、もしかしたらその一部のさらに一部だけが、手作りの品にお金を払う意志があるけど、現代的でレトロなもの（スチームパンクなキーボードとか）だとボーナス。手作りのソフトウェアにお金を払う人はゼロパーセントだよ。

何を木工って言うかによるかな。デッキ（庭やキャラバンなど）を作ったり、物置やフェンスを作ったりしてる人と一緒に働いてるけど、彼は本当にうまくやってるよ（正直、すごく上手いしね）。

カスタム家具やキャビネットはすでにかなり厳しい市場だし、木工はプログラマーの趣味として一般的だから、もし多くの人が本気でやり始めたら、市場はすぐに供給過多になると思うよ :)。自分が作った家具を売ってみたらどうかって言われたこともあるけど、趣味をキャリアに変えるのは一度失敗したから、もう二度と同じ過ちを犯したくないし、少なくともソフトウェアはまだそこそこ良い給料をもらえるからね。

手彫りのユニークな形のドアがある歴史的な家を持ってるんだ。ドア枠が腐ってしまって、木工職人に4千ドル払って交換してもらった。ドア自体を交換するのには簡単に2万5千ドルかかるよ。だから、手彫りのドアがある歴史的なエリアに引っ越せば、そこそこいいお金が稼げるかもね。

layoffs.fyiを見てみて。彼はすぐに解雇される可能性が高いよ。もし明日じゃなくても、AIがもっと良くなるまで数年待つことになるだろう。これは一方通行の道、下り坂なんだ。木工じゃなくて、農業だ。土地を手に入れて、自分の食べ物を育てな。経済には全く参加しないこと。それが唯一の生き残り方だよ。

ドメイン知識は良いエンジニアリングの原則を適用するよりもずっと早く学べる。1週間前にドメインの専門知識が本当の防壁であるというスレッドがあったよ: https://news.ycombinator.com/item?id=48340411

それは未来に対してかなり楽観的な見方だね。俺はドットコムバブルの崩壊を覚えてるし、その後の数年もね。2002年から2003年には、ソフトウェアエンジニアの失業率が40%くらいだったんだ。実際、それがもっと高くならなかったのは、業界を離れて配管工（や他の職業）になった人が多かったから。今回はもっと悪化すると思う。ドットコムバブルの崩壊では、ビジネスじゃないところに資金が流れて、資本市場がほとんど機能しなくなったんだ。でも今はそうじゃない。確かにAI企業には大量のお金が流れ込んでるけど、変化はもっと構造的なんだ。他の業界も同じような経験をしてる。1980年代には、いくつかの業界が意図的に壊されたり、オフショアに移されたりして、未だに回復してないところもある。これには社会的、経済的、政治的な影響が続いてると思う。テクノロジーの分野でも同じことが起こるなんて、みんなちょっと甘く見すぎだよ。

「ドメイン知識は、良いエンジニアリング原則を適用するよりもずっと早く学べる。」それが普遍的に正しいとは思わないな。簡単に身につくドメイン知識に自信を持ちすぎてる優秀なソフトウェアエンジニアが、ERPシステムの失敗を招くことが多いんだ。ITの世界には、ビジネスルールをシステムに組み込むことが全てっていう部分がたくさんあるからね。

ドメイン知識は、良いエンジニアリング原則を適用するよりもずっと早く学べる。部分的には同意しないな。大まかなドメイン知識はすぐに学べるけど、その知識を微妙に磨いて、特にユニークで「ソフトウェア開発ハウス」とは考えられないような組織に対して複雑さを考慮するのは、何年もかかることもある。なのに、まだ「プロフェッショナル」なソフトウェア開発者が良いエンジニアリングプラクティスを守ってないのを見かけるよ。 > ドメイン知識が主な競争優位性のエンジニアは、エンジニアリングがそれほど得意じゃないかもしれない。ドメイン知識がないエンジニアにも同じことが言えるよ、少なくとも俺の経験では。もしかしたら、単に運が悪かっただけかもね…

ドメイン知識は、良いエンジニアリング原則を適用するよりもずっと早く学べる。ほんとに？俺は逆の意見だな。専門的な知識を得るよりも、方法論を改善する方がずっと早いよ。前者はアプローチの問題だから、強制したり早めたりできる。後者は、その人の学習の好みや能力、当時の状況に依存するから、合理的な支援を超えて強制することはできないんだ。それに、早い段階では急激に成長する傾向があるから、自己強化的なんだよね。

貴重なドメイン知識の開発と取得は、難しくてリスクが高く、高価で遅いプロセスなんだ。だって、貴重なドメイン知識は昨日のものじゃなくて、今日のもの、明日のものだから。ドメイン知識が重要な分野では、それはエンジニアリングと深く絡み合ってるから、ジェフ・ディーンにUnreal Engineをゼロから開発させることはないよね。とはいえ、ドメイン知識の専門家が完全に内面化したり、適切に実践したりしていないSWEの原則はまだたくさんあって、ドメイン知識が価値を持つ限りそれは続くと思う。ソフトウェアエンジニアリングもまた別のドメインだからね。

ドメイン知識は、良いエンジニアリング原則を適用する方法を学ぶよりもずっと早く習得できるよ。どんなドメインを考えてるの？

残念ながら、ソフトウェア関連の業界はみんなLLMやコード生成を取り入れてるね。銀行やフィンテック、保険もそう。みんな同じような懸念を抱えてるけど、そういうのは「心配しなくていい、納期やROIがそれだけの価値があるから」と軽くあしらわれちゃうんだよね。

え？俺は一日中LLMを操縦してるけど、金融製品の舵を取るなんて絶対に無理だよ。君の特定の雇用主がどれくらいこの状況を維持できるかは分からないけど、俺が個人的に関わってるフィンテック企業は、昨年から開発者向けに何らかのAIアカウントを持ってるところばかりだよ。ジェーンストリートみたいなところでも、従業員がブログを投稿してる（そのうちの一つは約60分前にHNのフロントページに載ってた）けど、彼らは主にエージェントを指示してるって言ってる。君の特定の雇用主はどれくらい持ちこたえられると思う？

チームのエンジニアたちの専門知識が、プロジェクトを軌道に戻すんだ。でも、どうして同僚たちがあなたより「専門家」じゃないって確信できるの？以前のLLMがあった頃は、99%の企業で優秀なエンジニアと普通のエンジニアが一緒に働く余地があったんだ。LLMが登場した今、もう「普通の」エンジニアは必要ないから、残るのは「最高の」エンジニアだけだと思う。ここはHNだから、この記事を読んでるエンジニアはみんな、自分が会社や街、国のトップ10-5%にいると思ってるだろうし、だから自分がLLMの影響を受ける「普通の」エンジニアじゃないと思ってるんだろうね。統計的には、たぶん間違ってるよ。結局、これはエゴの問題なんだ。あなたがロックスターじゃない可能性が高いし、LLMが最終的にあなたの仕事を奪うことになるよ。いつものように、ここでの勝者は企業と経営者だけ。私たちのほとんどは、チェーンの最後のサルで、結局損をするんだ。

バーナーアカウントで投稿してるから、自分を特定されないようにね：私は規制された製品のフィンテックで働いてる。Mythosにアクセスできるんだけど、Mythosが私たちのコードベースの一部を特定して、特定の規制に準拠していないと自信を持って主張したんだ。それによって、私たちは大きなリスクを抱えているって。でも、実際にはそうじゃなかった。もちろん、規制が何を要求しているかを幻覚で捉えてしまったんだ（問題のコードはすでに人間の法律顧問によってレビューされていたから）。これが（いわゆる）最先端のモデルなんだ。私たちはコードを書くのにたくさんのgenAIを使ってるけど、実際に準拠した金融商品を構築するためにこれらのツールに頼ることは、短期的にはあり得ないよ。完全に狂ってると思う。確かに、多くのフィンテック企業がこれらのエージェントを使って加速してるけど、実際に人間が掘り下げずに製品を出荷するために使ってる人は、リスクの世界に自分をさらしてるんだ。

一日中LLMを操縦してるけど、それがずっと続くとは限らないよ。多くの企業が「AI工場」にお金を投資してて、ソフトウェア開発を自動化する方向に進んでるんだ（つまり、LLMを操作するためにJiraのチケットやリニア、トレロのカードを使うってこと）。

「その最初の柱はまだそこにある。著者は自分たちの影響を理解していないかもしれないが、私は元に戻されたPRの証拠を見て、深い知識の領域から外に出ると、エージェントのことをもうバカだとは言えなくなる。私たちの最も有能なエージェントは、著者が話しているような分散システムにアクセスできるが、定期的に間違っていて、しばしば視野が狭く、常に愚かだ。チームのエンジニアの専門知識がそれを軌道に戻している。もう一つの層があると思う。あなたにはドメイン知識がある、確かに。でももっと価値があるのは、さらに多くを見つけるための知恵だ。AnthropicやOpenAIがトレーニングデータに金融規制を入れたところで、AIシステムは未来を予測したり、複雑な状況でクライアントやパートナー、規制当局に手を差し伸べたりすることは決して学べない。」

1年前は同意してたけど、ギャップはどんどん小さくなってるね…これらのものは90%の仕事をこなせるし、残りの10%のために本当に会社に必要な人はどれくらい？前ほど必要じゃないよね。

複雑な要件のReg PRについてだけど、初期PRまでの時間がすごく短いのが見えてる。レビュー担当者と開発者の間でピンポンが始まるんだ。私のケースでは（すべてではないけど）、開発者が雰囲気でコーディングした部分があって、要件を深く理解してなかったり、コードを理解してなかったりするから、修正するのに何度も繰り返しが必要になる。これを人間の問題だと主張することもできるけど、私が見ているのはそのネット効果なんだ。複雑なケースでは、以前は適度に長いPR時間と適度に長いレビュー時間の合計が、非常に短いPR時間とさらに長いレビュー時間に置き換わったように思える。これらのケースで本当に利益があるのかはわからない。時には、コードが機能的に正しくても、冗長すぎる（例えば、中間関数が多すぎる）から、将来のレビューに影響を与えると思う。

LLMを一日中操縦してるけど、いいメタファーだね。飛行機は自動操縦ができる高度な機械だけど、最終的には人間が操縦しないといけないんだよね。

面白いことに、今年はAIの助けで税金の申告ができて、会計士はいらなかったよ。

会計士は、法律や規制、手続き、官僚主義など、計算機ができることを超えた専門的な知識を持ってるよね。これをソフトウェアエンジニアリングに当てはめると、確かにいいポイントだと思う…ただ、あなたが言いたかったこととは違うかもしれないけど。

今日のLLMなら、そうだね。でも、もし彼らが信頼できる方法で契約者レベルに達することができて、提供する企業が責任を持つ気があるなら（自信が高くて、他は保険でカバーされているから）、安いAIエージェントを雇って契約を果たすことができるかもね。設計、実装、デプロイ、運用、サービスやウェブサイトのメンテナンスを、以前のエンジニアのように。計算機は会計士の代わりにはならないけど、オンライン会計サービスは多くの場合そうだね。これも、AIがその信頼性に達すれば運営できるかもしれない。でも、今日のLLMではまだSFの話だね。

「計算機」って職業があったけど、もうそんなことはないね。 https://en.wikipedia.org/wiki/Computer_(occupation)

LLMはうちのビジネスの具体的な部分ではいつも失敗するんだよね。地元の税法とか、会計プロセスの特性、台帳の実装の詳細とかね。うちの会社も複雑な規制や特定のドメインに特化したシステム実装が多いから、AIはそれに苦労してたんだ。でも、整理されたclaude.md/agents.mdファイルのおかげで問題を解決できたよ。それに加えて、supermemory.aiも導入したから、新しく決定したことはAIエージェントが新しいセッションを始めるときに常に思い出せるんだ。

あなたは、社会の最適な状態はみんながプログラミングや論理を使うことだと言ってるけど、これらの発展の明らかな最終結果は、誰もそうしなくなることだよね。

もし実行がすべてなら、最先端のLLMが実行を解決するなら、アイデアは今や豊かさへの入り口だけど、豊かさだけでは「粘り強さ」は保証されない。彼らは実行を「解決」するわけじゃない。もし十分にプッシュして、実際に動くコードを得られるシステムを整えれば、彼らは実行を解決できる。今のところ、デフォルトではそれができるわけじゃない。もしかしたら3年後かも。彼らは速く進んでるけど、より良いRustコンパイラを作ってくれって頼んで、座って見てるだけで結果が出るわけじゃない。