LLMが自分のソフトウェアエンジニアリングのキャリアを侵食しており、何をすべきかわからない
(human-in-the-loop.bearblog.dev)- LLMベースの開発ツールは、設計ドキュメント作成、実装計画、コード作成、デバッグにまで関与し、10年間積み上げてきた決済・金融バックエンドの専門性による差別化を弱めている
- 金融・決済領域のドメイン知識は、PCI準拠、複式簿記台帳、エスクロー、照合、決済ライフサイクル、銀行振込の冪等性といった経験に基づく競争力だったが、モデルがシステム構造のつながりを捉え始めたことで最初の衝撃を受けた
- Claude Code、Codex、MCP、DataDog MCP などによってデバッグ自動化が拡張され、スタックトレースと Sentry の文脈だけで一部のバグを解決し、その後は分散システムのバグの90%をワンショットで処理するようになった
- 残る柱であるコード品質とアーキテクチャも「taste」に縮小され、人間が読みやすい
A・B等級のコードベースよりも、LLM が扱うC・D等級のコードベースを許容する流れになっている - 長期的な雇用可能性を守るには、LLM が簡単には得意になれない領域へ専門性を移す必要があるが、研究職への転向は居住国、応募競争、家族事情、RSI の可能性によって制約されている
経歴の背景
- ソフトウェアエンジニアとしての専門経験は10年で、デバッグがしやすかったという理由から Web フロントエンドで始めたが、その後バックエンドへ転向した経歴がある
- 偶然のきっかけで金融、簿記(bookkeeping)、決済処理ドメインのソフトウェア開発を担うようになり、Product Manager やステークホルダーと近く率直な関係の中で高い自律性を経験した
- PCI準拠(PCI compliance)、複式簿記台帳(double-entry ledgers)、エスクロー(escrows)、照合(reconciliation)、決済ライフサイクル(payment lifecycles)、銀行振込の冪等性(bank transfer idempotency) などのドメイン知識を蓄積した
- ドメイン専門家になるというキャリア戦略は、ドメイン専門家への需要増加の兆しがあった分野で専門性を差別化する明確な選択だった
崩れ始めた最初の柱: ドメイン固有の知識
- 昨年、金融分野の会社に転職したが、以前の会社も決済や金融の要素は強かったものの、金融そのものを中心とした会社ではなかった
- 新しい会社はAI を全面的に受け入れており、ChatGPT と Claude Enterprise のアカウントを初日から提供し、調査・探索・コーディングに AI を使うよう奨励していた
- ただし、本番環境に入るすべてのコード行は自分でレビューし、責任を負わなければならないという条件付きだった
- 最初のプロジェクトは、ひどく乱れたレガシーなオンライン決済システムの作り直しで、過去の構築経験があったため任されることになった
- コーディング前に書く Design Docs は、エンジニアと Product Manager の双方が読める必要があり、技術的な深掘りよりもアーキテクチャ視点が求められる文書だった
- 最初の Design Docs は最小限の AI 支援で書き、当時は LLM を「stochastic parrots」と呼んでいたが、今ではその見方は維持していない
- マネージャーからのフィードバックは、コードは良いペースで出しているが Design Docs の作成に時間がかかりすぎており、AI をもっと使うべきだというものだった
- 当時のモデルは今ほど優秀ではなかったが、文章作成と意思決定の速度を上げるには十分な効果があった
- 長年かけて積み上げてきた実装上のトレードオフ、アクワイアリング(acquiring)の仕組み、二重請求を防ぐための冪等性の構造化に関する知識が、価値低下を起こした瞬間だった
- モデルには依然として調整が必要だったが、システムをどう構造化すべきかというつながりを捉えられるようになっており、これは長年の実務経験を経て初めて頭の中に形作られる最も難しい部分だった
- Web 上には解説記事、技術文書、ドメインに技術ツールを適用するブログ記事が大量にあるため、モデルはそれらを学習データとして取り込めるのだろうと考えた
- 人間が引き続き際立てる領域はデバッグだという期待が残っており、本番環境でのレースコンディションや分散システムのデバッグ経験が長期的な雇用可能性の根拠だった
崩れ始めた二つ目の柱: デバッグと分散システム
- LLM は文書作成や実装計画の支援に長けるようになった後、コード作成も上手くなり、2025年後半の Claude Code hype と Codex の登場でその流れがさらに広がった
- それ以前から日常的にユニットテスト作成には LLM を使っていたが、実装全体を任せるほどには信頼していなかった
- コード作成により多くの AI を導入する流れは自然な次の段階であり、コーディングと同じくらい本番デプロイやユーザー満足度を好んでいたため、受け入れ可能な交換だった
- LLM はコード作成に長けるようになったが、モデルや人間が残した混乱をデバッグすることはできなかったため、ロボットを調整する以上の役割はまだ残っていた
- MCP、エージェント型ワークフロー、Claude 4.5 の登場以降、デバッグという柱も揺らぎ始めた
- Claude 4.5 はスタックトレースといくらかの文脈だけでバグの約60%を解決し、ほとんどの場合は Sentry MCP が有効な Sentry リンクだけで十分だった
- ときにはもっともらしいが完全に間違った解決策を生成することもあった
- この時点で機械への疑いをやめ、以前なら丸一日かけてデバッグしていたようなバグを Claude Code が一発で解決する場面を経験した
- その後 4.6、4.7、GPT 5.5、Opus 4.8、DataDog MCP の登場により、CLI が分散システムのバグをワンショットで解決する状態になった
- 以前には解決できなかったバグ、丸2日フルタイムのデバッグが必要だったはずのバグ、分散観測性が不足した分散システムのバグまで対象になった
- 奇妙なレースコンディション、予想外のコーナーケース、サードパーティ統合の問題、文書化されていない API のエッジケースなど、バグの90%をワンショットで解決する
- 依然としてコードをレビューし、ロボットを調整する人は必要なため雇用自体は維持されているが、既製品のエンジニアになってしまった状態だ
- 金融・決済ドメインの専門性、デバッグの直感、分散システムの知識は、他のシニアエンジニアが LLM を調整して再現できる、プロンプト化可能な知識へと変わってしまった
- ジェネラリストにもスペシャリストにも役割があるという従来の教えとは異なり、市場は皆をジェネラリストにしていく流れにある
- 全員がジェネラリストになり、需要がそれに追いつかなければジェネラリストの価格は下がるが、現実には需要も減っている
まだ崩れていない三つ目の柱: コード品質とアーキテクチャ
- まだ残っている柱はコード品質とソフトウェアアーキテクチャであり、現在では「taste」という言葉で矮小化される領域だ
- キャリアを通じてリファクタリングが好きで、良いコードを重視し、スプリントの中でそのための時間を交渉してきた
- DDD、Hexagonal、Clean Architecture のようなテーマで、トレードオフやコードベース構造を議論することを好んできた
- エージェントはコードベースを整った状態に保つには非常に弱い道具だ
- 調整しなければ循環依存の問題がすぐに発生する
- 重複コードの追加、不要なコメントの挿入、純粋関数と副作用の混在、SOLID 原則の無視
- この能力は人間の雇用可能性を守るべき領域のはずだが、業界はこれを「taste」という言葉に縮小し、コード整理の重要性が低い世界へ移動している
- 人は依然として、循環依存グラフを持つスパゲッティコードベースを防ぐためにエージェントを調整する役割を担っている
- 何かを直そうとすると壊れてしまう
F等級のコードベースは望まないが、CやD等級なら今や許容範囲になっている - もはや
AやB等級のコードベースが必要なくなっているのは、コードベースが人間に読まれるためではなく LLM に扱われるために作られつつあるからだ - ソースコードがもはや人間ではなく機械に読まれるために書かれるのなら、対象を機械に切り替えるという選択もありうる
- コード品質とアーキテクチャの知識もまた価値低下を起こしており、本を読み、実地で練習し、エンジニアと議論し、ADR を書くことに費やした時間が無駄になりつつある
では、これから何をすべきか
- 当面は（少なくとも今の会社では）雇用を維持できると見ているが、長期的な見通しは不確実だ
- 長期的には、10年、専門外の経験まで含めればそれ以上を投じて身につけたものの価値が、少しずつ下がっている
- 最後の専門性の柱さえ「taste」に縮小された状態だ
- 約8か月前、現在の会社で（会社側の説明では AI とは無関係の）レイオフがあり、解雇された優秀な元同僚たちは今もなお求職中だ
- その多くが同じ問題、つまりドメイン専門性だけではもはや差別化できない状況に直面している
- 会社はいくつかの職種を再び採用中だが、ドメインへの習熟はもはや強い差別化要因ではなくなっている
- 以前は「Software Engineer - Area」という形式で募集していたが、今では「Software Engineer」とだけ書き、チーム配属はオファー受諾後に行っている
- 深いドメイン経験を積む機会がなかった優秀なエンジニアにとっては、より良い就業機会が生まれた変化でもある
- 一方で、生涯をかけてドメイン知識を集めてきた優秀なエンジニアも、同じレーンで競争することになった
- 長期的な雇用可能性を守る唯一の選択は、LLM が簡単には上手くできない領域へドメイン専門性を移すことだ
- 大学に戻って数学、統計、高度な Machine Learning を学び、frontier lab の研究職に応募する選択肢も考えている
- 居住国には frontier lab がなく、存在する少数の研究所にも応募が殺到している
- 家族の事情で他国へ移るのが難しい状況だ
- 移動できるようになる頃には、RSI(recursive self-improvement) によって研究者が不要になっている可能性もある
- 木工の趣味を仕事に変えることまで考えるほど、途方に暮れていることを吐露している
1件のコメント
Hacker Newsの意見
何だって？ 一日中LLMを操ってはいるが、金融プロダクトの責任者になることに同意することは絶対にない
最初の柱はまだ残っている。著者は自分の影響力を分かっていないのかもしれないが、差し戻されたPRという証拠を見ると、自分が深く理解している領域の外に出たとき、エージェントがでたらめを言っているのかもう見分けられなくなることを分かっている。著者が言及した分散システムへのアクセス権まで持つうちの最上位エージェントでさえ、しょっちゅう間違え、視野が狭く、相変わらず愚かなことをする。結局、チームのエンジニアたちの専門性がそれを再び軌道に乗せる
Mythosは、うちのコードベースの一部が特定の規制に違反していると自信満々に判定し、今のやり方で運用すれば深刻なリスクだと言ってきた。しかし事実ではなく、規制要件を幻覚していただけだった。それが分かったのは、そのコードをすでに人間の法務顧問がレビューしていたからだ。これが現時点で利用可能な最先端モデルだという。コードを書く補助として生成AIは多用しているが、中期的に見ても、こうしたツールに依存してコンプライアンスが求められる金融プロダクトを実際に作ることはできない。それは完全に狂気だ。多くのFinTech企業が速度向上のためにエージェントを使っているのは事実だが、人間が実際に深く確認しないまま製品リリースに使えば、とてつもないリスクを背負うことになる
LLM以前は、ほとんどの会社で優秀なエンジニアと平凡なエンジニアが一緒に働く余地があった。LLM以後は、「トップ」エンジニアだけが生き残れる。もはや平凡なエンジニアは必要ないからだ。HNの性質上、この記事を読むエンジニアの大半は、自分が会社・都市・国の基準で上位10〜5%だと思っていて、だからLLM導入の影響を受ける「平凡な」エンジニアではないと考えるだろう。統計的には、おそらく間違っている可能性が高い。結局は自尊心の問題だ。あなたはロックスターではない可能性が高く、LLMが最終的にあなたの仕事を奪うかもしれない。いつものように勝者は企業と役員だけで、私たちの大半は鎖の一番末端にいるのだから、被害を受けることになる
自分の場合、開発者が一部をバイブコーディングしていて、要件や自分のコードへの深い理解がないため、何度も往復しないと直らない。これを人間の問題だと言うこともできるが、自分が見ている純効果はこうだ。複雑なケースでは、以前の「そこそこ長いPR作成時間 + そこそこ長いレビュー時間」が、「非常に短いPR作成時間 + より長くなったレビュー時間」に置き換わったように見える。こういうケースで実際に得があるのか分からない。時には機能的には正しいコードでも、中間関数が多すぎて冗長で、今後のレビューにも影響しそうだ
自分も同じ懸念を持っているが、「提供速度とROIに見合う価値があるのだから心配するな」といった形で、しばしば無視されたりはぐらかされたりする
個人的に接しているすべてのFinTech企業は、昨年から開発者向けのAIアカウントのようなものを持っていた。Jane Streetのようなところでさえ、社員がブログを書いて、たいていはエージェントを指揮していると述べている。あなたの会社があとどれくらい持ちこたえられると思う？
「AI は X を 80〜100% の精度でできないから、私たちの仕事は安全だ」というコメントをよく見かける
あまり悲観的に聞こえたくはないが、モデルは急速に改善している。3年ほど前に現在の状態を説明して、「モデルが1つのプロンプトで約30分のうちに完全な MVP アプリを作る」と言ったら、SF のように聞こえただろう。今のモデルが抱える、ハルシネーション率の低減、コンプライアンス保証、きれいなコードベースの維持といった障害は、解決がまだ遠いようには見えない。特定情報の取得も、複数の MCP サーバー/RAG によってすでに部分的には可能になっている。ソフトウェアエンジニアの未来が心配だ。こうした欠陥が解決されたら、この職業はどこに居場所を見つけるのだろうか。AI モデルに仕事を委任する役割だろうか？ 残念ながら、それは何年もの専門性を必要としないので諸刃の剣だ。AI の出力をレビューすることか？ 理解できない各行について説明しろと言えば済む。人間の計算手がデジタルコンピュータに置き換えられたように、さらに大きな 解雇の波 を目にすることになる気がする。複雑な数学計算を頭の中でやるのは面白い挑戦かもしれないが、コンピュータよりはるかに遅く、ミスも多い。同じように、手でコードを書くことは楽しい「挑戦」に見え、AI は 現代の電卓 のように見えるようになると思う
https://youtu.be/5eqRuVp65eY?si=3fLT6S5q2OIUcu6r
多くのことは今後も大きく改善し続けるだろう。ただ、技術が生んだ急激な混乱の近現代史を見ると、繰り返されるパターンがある。雪崩や鉄砲水のように、こうした急激な変化は、ある特定技術における1つ以上の重要なブレークスルーから始まることが多い。初期の変化速度は速く荒々しいが、新たに開けた低い果実を取り尽くし、新しい領域で新たな障壁や摩擦にぶつかるにつれて、次第に鈍化していく。こうした時期の初期には、直近の異常な変化率をそのまま未来に外挿する予測の精度は低い。突然の極端な爆発は、長期トレンド線へ回帰する傾向がある。現在の LLM の混乱は、2010年以降の研究が2017年の Transformer 論文 で積み上がり、その周辺研究を急速に促進したことに由来すると見ることができる。だとすれば、今は LLM の急激な爆発局面の中盤、あるいは後半にいるのかもしれない。すべての LLM 応用を押し上げる根本的で広範なブレークスルーの速度は明らかに鈍っており、最近の大きな発見の多くは、特定領域への拡張、最適化、チューニング、製品化にある。明日また Transformer 級のブレークスルーがないという意味ではないが、歴史的に見て ブラックスワン は群れで現れることはまれだ
顧客は今のようにソフトウェアツールを買うのではなく、必要なソフトウェアをすべて社内で作るか、プロンプトエンジニアのコンサルタントに作らせることができる。非常に違う世界になるかもしれない
それとも世界中に1人創業の会社が700社ほどあるだけで、残りはみんな働けなくなるのか？ マトリックスか？
Claude 3.5 が出たときと比べても、生産性はそこまで大きく伸びていない。すべての LLM に無制限でアクセスできるが、その大半はゴミで、節約できることよりも作業が増えることのほうが多い。このツールで得をするのは、低品質な成果物 を素早く量産する人たちだけだ。これに同意しないなら、あなたもそういう人だ
私のキャリアパスは著者と驚くほど似ている。奇妙なことに、著者が崩れた最初の柱だと見ている部分が、今ではいちばん健全に見える
LLMは私たちの事業特有の文脈で繰り返し失敗する。地域の税法、会計手続きの細部、私たちの台帳実装の特殊性といったものだ。リファクタリング、言語間変換、既存コードのバグ追跡には優れているが、私たちのドメインを反復・拡張する場面では、微妙に間違っている箇所が常に多い。私が働いた会社が、参入障壁を築くためにあえて複雑な領域を扱っていたからかもしれない。複製するための本が世の中になく、ノウハウが社内に残ることで事業が成り立っている会社だ。また、設計文書をAIで素早く作れと管理者が勧めるFinTechがあるなら、お金を扱う事業をするにはあまりにも不注意に見える。特に小さな取引が大量に発生する場合、数百万単位が誤って配分されるのは非常に起こりやすい。こうしたバグは本当に扱いづらい。ロジック修正は第1段階にすぎず、その後に不変データベース内の誤計算データを修正し、規制手続きと顧客コミュニケーションに対応しなければならない。修正内容は、新機能や可観測性が考慮しなければならない落とし穴になる。たとえば「2月2日のデータにスパイクがあるのは、Xインシデントのせいだと覚えておけ」のようなものだ
いくつもの物理シミュレーションベースの製品を作っているが、純粋に第一原理に基づいている。ところが、能動的な調査、思考、検証なしに任せると、数百桁レベルで遅い計算コードを作ったうえで、ばかげた代替経路や近道を入れ、結果として役に立たない計算にしてしまう。こうしたことはたぶん95%くらい起きる。監督は非常に重要で、アーキテクチャ思考はまだ外注できない。外注できるのは実行だけだ
もちろんシニアソフトウェアエンジニアがここに詳しいことは多いが、必須ではない。従来は、エンジニアが業務の90%ほどをビジネス専門家に聞かずに処理できると、摩擦のない生産に役立っていた。しかし、まさにその「伝統」が終わったというのが元記事の核心だ。新しい世界でのシニアエンジニアの仕事は、そのドメイン専門性を自分で持つことではなく、エージェントがそれを持つ、あるいは獲得できるようにし、それが検証可能な形で正しいと保証することだ。高度なビジネスドメイン専門性が自分を安全にしてくれるとしがみつくシニアエンジニアは、移行していないジュニアと同じくらい、やがて行き止まりに置かれるだろう
深い語彙を持っているため、実際以上によく知っているように聞こえる。コードを書いて目に見えるエラーをデバッグするのは非常にうまいが、それは半分くらいテスト装置のおかげでもある
核心となるアイデアは、文書をLLMに与え、LLMが多くの質問をすることで曖昧さや誤解の可能性を解消することだ。Skillsを一度見てみることを勧める。本当に役立つ。 https://www.youtube.com/watch?v=6BB6exR8Zd8
うまく整理されたclaude.md/agents.mdファイルで問題を解決できた。そこにsupermemory.aiも実装し、新しく下した決定が、新しいセッションを始めるたびにAIエージェントに常に想起されるようにした
Steve Jobsの悪名高い「アイデアは安い」という言葉をいつも思い出す
実行こそがすべてであり、最前線のLLMが実行を解決するなら、今やアイデアが豊かさへの入口になる。しかし、豊かさそのものが「つなぎ止める力」を保証するわけではない。よく見落とされるのは、人間がその仕事にとどまろうとする意志と気にかける心だ。多くの人は、何かを作り、維持し、所有するほどには気にかけていないし、そもそも望んでもいない。V1はより速く出せるようになるかもしれないが、その後も継続して注ぎ込めるだろうか。良い例がAI音楽ツールのSunoに見られる。今ではかなり良い結果を出す。多くの人が自分だけの小さな世界で遊んで、すぐに飽きて去っていき、少数の多作なクリエイターだけが残って、それを「仕事のような」環境に変えていく。委任と実行の規模や経済性は変わったのかもしれないが、それでも考慮すべき要素はまだ多い
音楽の素養が限られている自分ですらそう感じるので、音楽家ならもっと批判的になる可能性が高い。最初の数回は印象的で、メロディも中毒性がある。以前はバックで不自然に聞こえる部分があったが、その大半は直された。しかし数十曲を超えると、いつも似たように聞こえ始める。どれも総じて凡庸で、曲が物語を語らず、企業広告の背景に流れる音楽のように感じる。プロンプトをより正確に書いてもあまりうまくいかず、曲を面白くする細部はほとんど無視される。最も興味深い結果は、むしろバグのように軌道から外れさせたときに出た。まったく異なる2つのジャンルを混ぜてくれと頼んだら、以前に聞いた記憶のない不穏な感じの結果が出た。しかし、それをさらに作り込もうとするといつも難しく、また凡庸な結果に戻ろうとし、細かな指示を無視する。Sunoはリミックスはできる。コードと似ている。LLMは、すでに動いている何かを別の言語でも動くように移すポーティングには非常に優れている。しかし、アイデアしかない状態だと独創的な部分で失敗する。LLMにアイデアをきちんと実装させようとすると、あまりに多くの指示を与える必要があり、自然言語の曖昧さと格闘することになって、実質的には自分でコードを書くのと似た状態になる
十分に押し込み、実際に動くコードを得られるシステムを整えれば、実行を解決できる。だが、それこそがエンジニアリングだ。現時点の素の状態では、エンジニアリングを置き換えるにはまだほど遠い。3年後には可能かもしれない。動きが速いからだ。しかし今日この瞬間に「より良いRustコンパイラを作って」と言って、椅子にもたれて結果を受け取ることはできない
曲自体は自分でも気に入っていて、プレイリストで聴く価値はあるが、Sunoのアルゴリズム上では大きな反応は得られなかった。他の場所でもあまり宣伝しなかったし、投稿してみても「いいね」が数件ついただけだった。失望はしていない。自分のために音楽を作っていて、共有は副次的な効果にすぎなかったからだ。ここから得た結論は、人々に自分の作ったものへ関心を持って楽しんでもらうには、多くの作業が必要だということだ。マーケティングしなければならないし、人の前に持っていかなければならないし、注目させなければならない。また、映像や物語やペルソナ、何らかの雰囲気のようなものと結びつけて、好きになる理由を与える必要があるとも確信している。「定着」させるには、同じオーディエンスに対してそれらすべてを繰り返し、彼らが慣れるようにしなければならない。だから持続性が必要であり、売ろうとしている相手を本気で気にかける必要がある。人々が定着する前に、まず自分が定着していなければならない
https://en.wikipedia.org/wiki/Sturgeon%27s_law
スタージョンの法則は「すべてのものの90%はクズだ」と述べる。この警句は、アメリカのSF作家・批評家であるTheodore Sturgeonが、ジャンルの価値を擁護する中で生み出したものだ。Sturgeonは、どの分野でも作品の大半は低品質であり、したがってSFだけがとりわけ劣っているわけではないと考えた
自分の印象では、一度に生成するタイプのツールとして使われているように見える。音楽には詳しくないが、アーティストには中間段階、トラック分離、楽器のカスタマイズなど、自分の知らないさまざまな要素が必要な気がする。そういうものがなければ、プロの作業には使いにくいと思う
この文章には完全には同意しない。バイブコーダーが中程度の複雑さのシステムを設計・開発・実装しながら、すべてを爆発させずに済ませることはできない
Claudeのようなアプリケーションをうまく使ううえで大きな部分を占めるのは、コンピュータサイエンスの概念に対する概念的理解と経験だ。バイブコーダーには絶対にないものだ。もしそれがあったなら、そもそもバイブコーダーではなかったはずだ
「何をすべきかわからない」なら、波に乗ればいい
ウェブサイト/ウェブアプリが波だったときもそうしてきた。私はインターネット以前にソフトウェア業界に入ったが、ずっと乗り換え続けてきた。新しい技術を学ぶのに遅すぎる年齢なんてない。新しい波は新しい種類の仕事と労働者を生み出す。その一人になればいい。獣にまたがり、道具を使いこなせ。同じゲームがまたやってきただけだ
安定して需要のあるスキルがあるとすれば、それは新しい仕事、新しいプロセス、新しい人など、何であれ 頭の中で構造化する能力 だ。私は試作機械工として働きながら、この能力を鋭い道具として理解し、磨いてきた。馴染みのない人向けに言えば、試作機械工とは、毎週の短い納期の中で厄介な部品を作るために必要なことをやり切る人のことだ。金属でも、プラスチックでも、何でも扱う。プロセス、工作機械、材料に素早く慣れることに長けるようになる。そうしてしばらく続けると、新しい情報を非常に速く吸収し、多くの人よりずっと速く正確に仕事を理解できるようになる。誰でも始められる。好奇心を持って何かを作ればいい。そしてもっと作れ。作ったものを共有し、他の人が欲しがるものを作れ
90年代と00年代には、「オブジェクト指向プログラミングがすべてを変える」という波があった。それまで何百回も成功裏にやってきたことを、今度はオブジェクト指向でやる、という話だった。飛行機関連のコードを書くのか？ 大学では、飛行機のすべてをこなす全能の飛行機オブジェクトを買えばいい、という話を実際に聞いた。で、オブジェクト指向は万能ではなかったのか？ コード生成だ、Ruby on Railsを回してみろ、2秒でウェブサイトができる。コード生成はあちこちにあった。変な方向へ進んだかと思えばTDDが出てきた。TDDをやらないなら牢屋に入れるべきなくらい悪いエンジニアだ、という実際の会話を見たことがある。いや、TDDじゃなくてBDDが解決策だそうだ。Lean、いやAgile、いや小文字のagile、でも最初はそれだった、いやScrum、いやXML、待てそれはその前の10年だ、JSON、そしてついにSAFe。そして今は「このチャットボット見た？」だ。どの反復も、注意していれば良いものをもたらす。だが同時に大量の誇張と不安も連れてくる。実験して学べばいい。私にとって変わらなかったことが一つある。ほとんどの人は、自分の夢が実現したときの結果を慎重に考えるくらいなら死んだほうがましだということだ。それが引き続き真実である限り、人々は自分の代わりに 誇張された流行のドラゴン に乗ってくれる誰かに、これからも金を払い続けるだろう
この低品質な成果物を量産する工場の流れ、いや「AIネイティブ」な流れはこうだ。「うわー、チャットボットを言いくるめて、自分ではまったく理解していないものを作らせた。俺って仕事がすごくできる！」。ものづくりの参加賞みたいなものだ。何か別のものが作って、私はよく理解もしないまま手柄だけ持っていく。自分の努力には複利的な見返りがない。学んだ教訓もない。理解も積み上がらない。将来のイノベーションにつながる洞察もない。差別化もない。ただ気が狂うほど虚空に向かって叫び続けて、スロットマシンが「十分よく見える」低品質な混ぜ物を吐き出したら、翌日また同じことを繰り返す。それがゲームなら、私は降りる。他の人が楽しむのは結構だが、ここに何らかの熟達があると思うのは妄想だ。この道具で「成功」する唯一の条件は、気にかけるのをやめて降参することだ
前にも貼ったが、もう一度貼る価値がある
LLMの利用に非常に積極的な会社でDevOpsの仕事をしている。段階はだいたいこうだった。LLMに「いろいろ」やらせてみる、さらに多くをやらせる、複数エージェントを動かす、再び単一エージェントに戻しつつツールを作らせる、そして人間とLLMの両方が使える 決定論的ツール に行き着く。理由はこうだ。デプロイでもテストでも、決定論的ツールは二値の答えを返し、再現可能だからだ。障害が起きたら、人間が実行できるツールにいつでも戻れる。しかも速い。単純なスクリプトなら30秒未満で動くが、「もっともらしいでたらめ」はいつも2〜3分かかるようだった。結局、この文章に戻ってくる。https://spawn-queue.acm.org/doi/10.1145/3194653.3197520。つまり「作業リストを作り、各作業のスクリプトを書き、スクリプトを関数として組み合わせ、その関数がシステムになる」ということだ。付け加えると、LLMを好き放題にさせると、喜んでコードを書く。テストを追加して、そのテストが機能するか確認することもできる。昔から人間のコードにもそうしてきたはずだ。コードも読める。コードを読むと、動くコードを作りながらも完全に狂ったことをやっている場合がある。人間もそうではあるが、それは別の話だ。結局のところ、できあがるシステムが筋の通ったものかどうかは、今でも確認しなければならない。もっと簡単に言えば、コーディングは死んだかもしれないが、ソフトウェアエンジニアリングは健在で元気に走り回っている
大規模LLMに何でもやらせることはできる。可能だし、実際にそうしている。だが、費用は莫大で時間もかかる。代わりにAIでツールを作って、プロセス内の可能な限り多くの作業を決定論的に処理させ、AIにはそのツールを使わせれば、はるかに速く安く回せる。おまけに、最終的には高価なクラウドAIを捨てて、小型/中型の ローカルモデル で回すこともできる
筆者の未来像が正しいなら、有能なソフトウェアエンジニアは安泰だろう
ドメイン知識は、良いエンジニアリング原則をどう適用するかを学ぶより、はるかに速く学べる。主な競争力がドメイン知識であるエンジニアは、おそらくエンジニアリング自体ではそれほど優れていないかもしれない。それでも、積み上げてきた ドメイン知識 を必要とする業界の別領域で仕事を見つけることはできる
簡単に得られるドメイン知識だと傲慢に振る舞った優秀なソフトウェアエンジニアたちが、数多くの ERPシステム を台無しにしてきた。ITの非常に大きな部分は、文字通りビジネスルールをシステムに入れることだ
それでも、良いソフトウェアエンジニアリング慣行に従わない「専門」ソフトウェア開発者を今でも見かけるし、コードレビューもしている。主な競争力がドメイン知識のエンジニアがエンジニアリングに優れていないかもしれない、という話は、ドメイン知識のないエンジニアにも同じように当てはまる。少なくとも私の経験ではそうだ。単に運が悪かっただけかもしれないが
価値あるドメイン知識とは、昨日の知識ではなく今日と明日の知識だからだ。ドメイン知識が重要な分野では、それはエンジニアリングと深く絡み合っている。Jeff DeanにUnreal Engineをゼロから開発させたりはしないだろう。そうだとしても、ドメイン知識の専門家が完全には内面化していない、あるいは十分に実践していないソフトウェアエンジニアリング原則は多い。ドメイン知識に価値がある限り、この状態も続くだろう。ソフトウェアエンジニアリングもまた1つの ドメイン だからだ
専門知識を得ることに比べれば、方法論 のほうがはるかに速く改善できる。前者はアプローチの問題なので、強制して素早く引き上げることができる。後者はその人の学習傾向、能力、その時点で使える時間に左右され、合理的な支援以上に強制することはできない。また自己蓄積的な性質があるため、初期の学習曲線はずっと急だ
Claude CodeとOpus 4.7を使っているが、生成されるコードは間違っているというより、多すぎる傾向がある
特定の機能を考えて、それをコードに最もうまく収まる形で入れるやり方には、今でも価値がある。Claudeはしばしばスタックの1層、たとえばプレゼンテーション層を選んで、そこに押し込む。数週間後に同じデータが別の場所でも必要になると、Claudeはサービス層のコードを再利用できず、ある種の「移植」を行う。人間が注意していないと、コード量は2倍になり、ロジックは重複する。ClaudeのようなAIツールが近いうちにこの点で良くなるとは思えない。私の職場では、すでにコスト節約のためにOpus 4.7の利用を減らせという圧力がある。誰かが「簡単なバグ修正」にはもっと小さなモデルを使おうと言っていた。たまにはうまくいくだろうが、実際にどれほどの頻度で事前に簡単なバグ修正だと分かるだろうか？ コストが上がれば、このツールで「すべてのコード」を書かせようという関心は薄れる気がする。人々がより安くて効果の低いモデルに移れば、そのコードをレビューしないで済ませようという圧力も消える可能性が高い。最終的にどうなるかは見てみないと分からないが、筆者が恐れているほど劇的には変わらないのかもしれない
AIに本番コードの行数を半分に減らし、再利用できる別のライブラリがないか見てくれと言うだけでも、驚くほど効果がある。重複を見つけて取り除くリファクタリングボットも作れそうだ。今は標準では提供されていないが、不可能かどうかは明らかではない
ただし未解決の問いは、コードが多すぎることが本当に問題なのかという点だ。これらのツールはもう生活の一部だ。問題をより速く解いたりデバッグしたりできて、ソフトウェアのバグが減るなら、それは多すぎるコードではなく、ちょうど良い行数なのかもしれない
fooBar()とfooBarExtended()の2つの関数がある状況があった後者は現在の問題に必要な追加パラメータと機能を持っていた。ところがClaudeは、その関数を呼ぶ代わりに、最初の関数へ同じ拡張パラメータを追加し続けようとした。そうするなと言った後でも、後になってまた同じ提案をしてきて、本当にいら立つことがある
業界の未来をどう見るにせよ、職人の木工 で職人のソフトウェア以上の職業的成功を見つけるのは難しいと思う
自分で作った家具を売ってみろと言われたことがあるが、私の答えはいつも同じだ。趣味を仕事に変えるという失敗を一度やっていて、もう二度とその失敗をするつもりはない。少なくともソフトウェアは、まだかなり金払いがいい
一緒に働いている人の中に、デッキ、庭、キャラバン、物置、フェンスのようなものを作る人がいるが、本当によく稼いでいる。もちろん公平を期して言えば、その人は腕前もずば抜けている
ドア枠が腐って、木工職人に交換品の製作費として4,000ドル払った。ドア自体を交換するなら、簡単に2万5,000ドルはかかるだろう。手彫りのドアが多い主要な歴史地区に引っ越せば、そこそこ稼げるかもしれない
しかし、手作りのソフトウェアにお金を払いたい市場の割合は、正確に0%だ
木工ではなく農業だ。土地を手に入れて、自分で食べるものを育てなければならない。経済にまったく参加しないことが唯一の生存法だ