- ソフトウェアの難しさはコード入力よりも、給与・交通のような現実のルールを理解してドメインモデルを作ることにあり、コードはその理解の産物だった
- エージェント型AIはドメイン理解がなくてもソフトウェア生産を可能にし、ボトルネックを「作れるか」から「正しいと判断できるか」へ移した
- 配車担当者、臨床コーダー、保険数理人のようなドメイン専門家は、コードを知らなくても出力が法務・請求・運用ルールに合っているかを判定できる
- 汎用エンジニアはアーキテクチャと信頼性を検証できるが、臨床コーディングのように正解がドメイン知識に結びついた領域では、もっともらしい誤りを見逃すことがある
- 最も価値のある能力は、生成されたコードの健全性と出力の真実性をあわせて検証する判断であり、熟練エンジニアにはドメイン専門性への投資がより重要になる
コードを書くことではなく、ドメイン理解が本質
- ソフトウェア開発で難しいのはコードを書くことではなく、まずドメインの動作モデルを頭の中に組み立てることだった
- コードはその理解を書き写した**転写(transcription)**であり、理解を獲得する過程そのものが本当の仕事だった
-
具体例
- 給与システムをリリースする前に、差押控除(garnishment)、税引前控除、給与期間が賃金率変更の時点にまたがるときに発生する処理を理解する必要があった
- 公共交通アプリをリリースする前に、GTFSフィードとは何か、tripとrouteはなぜ違うのか、「定時」のバスがどうしてなお間違いうるのかを学ぶ必要があった
Agentic AIが断ち切ったつながり
- Agentic AIはモデル構築とソフトウェア生産のあいだのつながりを断ち切り、モデルなしでもソフトウェアを作れるようにした
- これは職業全体が成り立っていた前提を崩す
- 昨年の見方では、このツールは判断力を持つシニア開発者を増幅するものだったが、これは正しい一方で不完全でもある
- 実際に観察された変化は、中心的な制約が「作れるか」から**「正しいと判定できるか」**へ移ったことだ
二つのタイプの人物比較
-
ドメイン専門家（ソフトウェアの背景なし）
- 配車担当者、臨床コーダー、保険数理人などで、スタックトレースは読めず、ハッシュマップとリストの違いも説明できない
- しかしエージェントが生成したスケジュールを見れば、どのドライバーもその勤務を法的に行えないことや、そのコードの請求が決して支払われないことをすぐに見抜ける
- 10年間、入力と出力の中で生きてきたため、与えられた入力に対する正しい出力を知っており、不足していたコード生産能力をエージェントが正確に補ってくれる
- 彼らが持ち込むのは、エージェントには与えられない**正解(ground truth)**だ
-
ドメイン経験のない強力なジェネラリストエンジニア
- 何でも設計でき、信頼性・テスト・午前2時でもシステムが崩れないようにする方法を知っている
- しかし臨床コーディングに投入されると、もっともらしく見える誤答と正答を区別できない
- エージェントはコンパイルでき、書いたテストにも通るが、微妙でコストの大きい**誤った請求ルール(billing rule)**を生成する
- エンジニアには**オラクル(oracle)**がないため、ソフトウェアがうまく作られているかは検証できても、それが正確かどうかは検証できない — 正確性が、彼の頭の中に持っていないドメインによって定義されるからだ
片側の経路だけが崩れた非対称性
- エージェント以前には、エンジニアには配車担当者にはなかった経路があった — 専門家について回り、仕様を読み、運用環境で失敗を経験しながらドメインモデルをゆっくり習得できた
- この経路は多くの分野で**キャリアラダー(career ladder)**そのものだったが、ドメイン専門家には、信頼できるソフトウェアを学ぶために何年もかかる作業という対等な経路がなかった
- Agenticツールは、この二つの経路のうち片方だけを崩した
- ドメインモデルをコードに移すエンジニアの強みは、いまや**安価(cheap)**になった
- 何が正しいかを知るドメイン専門家の強みはそうではなく、プロンプトで到達できるものでもない
- 何千件もの給与計算をこなしてきた人の**暗黙知(tacit knowledge)**を収めたスキルファイルは存在しない
二つの層をどちらも検証できる人材
- 新しい世界で最も価値のある人は、二つのスキルをともに備え、両方の層で検証できる人だ
- 生成されたコードが堅牢であることを知り、同時にそのコードが出す答えが真であることも知っている
- ルールを知っているからこそ「ドライバーは11時間を超えてはならない」をエンコードしたテストを書けるし、何をテストしているかを知っているからこそ、そのテストが意味を持つと判断できる
- エージェントは転写を担い、人は**二度の判断(judging, twice)**を担う
経験豊富なエンジニアのための賭け
- 今後数年をどこに投資するかを考える熟練エンジニアにとって、これが賭けるべき方向だ
- 明確なアイデアをきれいなコードに変える**機械的スキル(mechanical skill)**の価値は劇的に低下する
- それでもなお希少なのは、何らかの実世界のドメインに対する深く検証されたモデルであり、それを確保しなければならない
- 産業、金融商品、規制体系、物理プロセスのいずれかを選び、かつてプログラミング言語やフレームワークを学んだのと同じようにそのドメインを学ぶこと
- これはエージェントが代行できない部分であり、いま最も大きな価値を持つ部分でもある
7件のコメント
でも、これはコードをあまりにも軽視しすぎているとも思います。
ソフトウェア開発そのものも一つのドメインであり、それをうまくやること自体が専門技術なんですよね。
AIが作るソフトウェアは機能的には解決してくれても、完成させてはくれず、そこを埋める人が必要であるのと同じように
私は xguru さんの考えに少し反対の意見があります。
Excel を例にしてみます。一般的に会社の業務をするうえで必要なレベルがあり、それを超えるとたいていはあえてそれ以上学ぼうとはしません。Excel を狂気じみるほど使いこなす人もいますが、それは本当に例外的なケースですよね。
コードの場合も――今はそうではありませんが――もしかするとそうした二つの流れに分かれていくのではないかと思いました。本当に複雑な製品を作る少数派と、自転車に乗るように使う大多数です。
えっ？ Excelをうまく扱える人を軽視しているわけではないですよね。
でも、コーディングすること自体の価値が下がったという話は、軽視しているように感じるのですが。
自転車に乗るように使うからといって、複雑な製品を作る人に「あなたの価値は大したことないですよ」と言うべきではないと思います。
ご指摘の点には同意します。
複雑なソフトウェアと呼べるような技術やコードは減っていくだろう、という話でした。AIで手軽に書けるものが増えるのであれば。
GeekNewsの要約版の表現を借りるなら、エージェントが代わりに担えないコードは日に日に減っていくように思います。
Hacker News の意見にあった
という意見と同じですね。
その部分では暗黙知がほとんど消えた状態で、最上級のドメイン専門家がエージェントを設計してモデルに組み込まれていくため、、、今はドメイン知識の重要性が強調されていますが、1年後にも同じ主張をしているかは分かりません。暗黙知は結局、少しずつプロンプトへ移っていく状況であり、モデルはユーザーがプロンプトに追加した暗黙知を選別し、再びモデルに注入していくはずです。暗黙知を内蔵したエージェントモデルには価値があるでしょうが、これさえも市場で取引されるようになると思います。その分野でさらにドメイン知識が豊富なエージェント。
1年後には、オーケストレーションを超えてエージェント経営（会社のように）が評価基準になるのではないかと予想しています。
Hacker News のコメント
個人レベルでAIをどう使うべきかを誰も分かっていない、ということを認めるまでに、あとどれだけ長広舌が必要なのか分からない
最初は優れた開発者で、なおかつAIの使い方を学べば十分だと言い、次はアーキテクチャ設計能力だと言い、その次はセンスがすべてを分けると言い、今ではドメイン専門家だけが重要だと言っている
AIの改善または停滞が安定的で予測可能な状態になるまでは、こうした解釈は今後も無意味で、たいていは間違っている可能性が高い
できることの基準を大きく引き上げるので、結果として難しくなる。個人開発者がはるかに難しいプロジェクトを引き受けられるようになり、結局のところ制約は常に時間であり、AIは与えられた時間の中でより多くのことをできるようにしてくれる
しかし、その時間内に達成できること自体がはるかに難しくなった。理解しなければならないことはずっと増え、AI以前の慣れた安全地帯の外へ大きく踏み出さなければならない
以前なら、不慣れなシステム領域だったり新しいライブラリを学ぶ必要があったりして、コードベースのリファクタリングや小さな機能のリリース準備に数日かけるのは受け入れられていた
コーディングエージェントのおかげで、その学習曲線をずっと速く登れるようにはなったが、それでも自分で登らなければならない。そして入ってくる情報量ははるかに多い
非技術系のバイブコーダーに仕事を奪われるのではと心配しているなら、正しい対応は、彼らよりずっと良いソフトウェアを作ることだ。そのためには、より高いスキル、より大きな野心、より多くの経験が必要で、簡単ではない
これまでで最もしっくりきた比喩は、現代の電動ドリルドライバーと、ドライバーや手回しドリルのような旧式の道具との比較だ
旧式の道具に比べれば、非常に短い時間で驚くような結果を出せる
例えば「一日がかりの床の固定を1時間で終えて、その合間に何度もタバコまで吸えた」みたいな驚きの逸話があり得る。ネイルガンを使っていれば半分の時間で終わっていたかもしれないが、後でその床を簡単に剥がすのは難しく、費用も2倍くらいかかっていたかもしれない
オンプレミスのLLMも複数使っていて、ほかのモデルにもアクセスできるので、いつかはこの比喩をブランドの違いにまで広げることになりそうだ
ただ、それで新しい仕事を探すことになるとは思わない。電動ドリルドライバーは大工や現場作業員ではなく、人がいなければ役に立たない
20年後にはClaudeとの共作ゴミを片付けているだろうと思う
https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
2018年に、コーディング経験がまったくなかった人が、特定のニッチ市場を知っていたという理由だけで、1か月コーディングして、かなり良いお金を生むツールを作るのを見た
コードの一部を見せてもらったが、私の最初のプログラムと同じくらいひどかった。それでも現実の問題を解決していた
例えば「スポーツがうまくなるには完全な左右対称性が必要で、これは胎児期の発達の安定性と強く相関する。対称性が高いほど完全な発達だ」と言う
その後数年して、Bruce Leeは片脚がもう片方よりかなり短く、Usain Boltにも同様の非対称な発達がある、という話が出てくる
すると彼らは例外事例だと言って、最初の主張をひっくり返しながら一般則は影響を受けないと取り繕う
ただ面白いものを作ればよくて、うまくいくかもしれない
最近、バイブコーディングでほぼ作られたアプリをレビューした。所有者は、ほぼリリース準備が整っており、簡単なチェックだけ必要だと言っていた
見てみると、データベース設計がめちゃくちゃだった。動く機能もあれば、動かない機能もあった。欠けている部分と、なぜ壊れるのかを説明した。元の記事のように、その人はドメイン専門家だった
先月だけで数十億トークンを使っており、ツールは急速に良くなっている。しかし、ドメイン専門家にAIを与えたからといって、ソフトウェアエンジニアが不要になるわけではない
ドメイン専門家はAIでソフトウェアを作れるし、ソフトウェアエンジニアはAIでドメインを学べる。両者は異なる専門性を持ち込む
ドメイン専門家たちがコーディングエージェントを使い始めるときに、安全に守るためのガードレール、検証、プロンプトライブラリ、エージェントと手動レビューを作る仕事になる
社内向けのT2/T3カスタマーサポートやサポートエンジニアに少し似ている。日常的な問題を100%自分で解決するというより、危険なポイントや奇妙なエッジケースを捕まえ、設定がすべて正しいことを確認する役割だ
もちろん、横断的な関心事も多く扱うことになる
ただし、新しいアイデアを素早く試し、深掘りするためのツールとしては素晴らしい。好奇心があるなら、優れた学習加速器にもなり得る
一日中Claude Code(Opus 4.6、最大努力設定)を使っていても、どうすればそうなるのか分からない。その使用量が本当に見返りを生んでいるのかも気になる
私がよく分かっていないだけかもしれないが、本当にどうやってそうなるのか分からない
最近経験したとても良い例がある
釣り旅行の最中で、私が取り組んでいる無料アプリ(https://oceanconnect.ca)が仕事の助けになるかもしれないので、船長に一度見てみる気があるかと尋ねた
私は海で人々が海洋データをどう使うのかをよく知らない。何を知りたがっているのか、なぜそうなのかもよく分からない。人々がデータをどう使うのか、私たちがそのデータで何ができるのかについての質問や情報が次々と出てきて、まったく準備ができていなかったし、その視点を得られたのは本当に素晴らしく興味深かった
モデルはそれが抽象化しているシステムそのものではなく、モデルを開発する知識は、それを使う知識とはほとんど関係がないのだと改めて思い出させられた
この人は水上で気象データをどう使うかについて膨大な知識を持っていた。ある意味では私よりもデータをよく知っていて、本人がそれに気づいていなかったりデジタル表現を理解していなかったりしても、もしプログラミングさえできれば、自分のような人たちのための有用なアプリをはるかに上手く作れそうだった
こういう人たちがLLMを前にしてアイデアを画面に落とし込めるなら、本当にすごいものを作れるだろうと思った。いつか資金ができたら、毎日海に出る人たちにインタビューして製品を磨き込みたい。そのドメイン知識は非常に特殊で、複雑なドメインで何十年も生きてきた人たちは、絶対に予想できないことを知っている
この記事で描かれているソフトウェア・ジェネラリストにもドメイン専門性はある。そのドメインはソフトウェアだ
今、優れたジェネラリストのソフトウェアエンジニアなら、AIを避けるために何か無作為な別のドメインへ飛び込んだりはしない。ソフトウェアが自分のドメインであり、そのドメインが拡張され変形していく間も、引き続きその中にとどまることになる
おそらく良い知らせは、西部で最高のスプレッドシート職人の会計士であっても、検証を行うには結局ある程度のプログラミング経験が必要だという点だ
LLMに「このコードは何をしていて、Yのとき常にXになるのか」と尋ねることはできるが、それは検証問題を別の検証問題の中に入れ子にしているだけだ
本質はそもそもコードではなかった
この5年間、ベンチャーキャピタルとプライベートエクイティ向けのソフトウェアを作ってきたが、この記事は本当に刺さった。コードを書くことは私の仕事の中で断然いちばん簡単な部分で、企業顧客が実際に必要としているものを理解するための金融工学と繊細な文脈のほうが難しい部分だ
私たちは、できるならシニアのファンド会計士を雇ってプログラミングを教えたいと冗談を言っていた。問題は、そういう人がほとんどいないことだ。エンジニアにファンド会計の細部を、ソフトウェアに落とし込めるほど理解させるのも難しい
実際、私のキャリアの半分くらいは、「チケットやエピックを閉じるだけのドメイン知識はあったが、結局多くの技術的負債を残した」ものの後始末だった
たとえばドメイン知識があっても人はミスをするし、より良い方法を知らないし、フィードバックを反映しなかったり、さらに悪いことにコーディングエージェントが書いた内容を再確認しなかったりするので、PRは非常に注意深くレビューしなければならなかった
「技術的には正しいが、あまりにひどく書かれていてタイムアウトしたり、マネージャーやDBAに怒鳴られたりするもの」をリファクタリングすることも多かった
本当に優れたソフトウェアエンジニアには、ドメインを学ぶ能力と意志があるが、学べる方法が用意されていなければならない。会社やチーム、同僚がそれを可能にしてくれた場所もあれば、口では重要だと言いながら、結局JIRAや会議中に非IT部門の人が漏らす話から推測するしかない場所もあった
この5年ほどの大きなパラダイムシフトは、ほとんどの会社が人に限界まで働くことを期待し、そのせいで重要な会話をする余裕をむしろ奪って逆効果になっている点だと思う
文化が大きな変数だ。少なくとも隣で短く話したり会議を気軽に設定できたりする場所もあれば、きちんと議論する時間を求めるにはchange.orgに請願でも出さなければならないのではと思うような場所もあった
それでも核心は正しい。結局、要件はコードより重要だ。すべての要件が満たされ、チームが設計判断を承認したにもかかわらず、実装中ずっと席を外していた人が戻ってきて、書き方が気に入らないという理由だけで機能が遅延した場所もあった
そうしているうちに、いつの間にか「バッチプロセス」が %numberOfRecord%*10 件の挿入を実行し、誤って設計されたデータモデルのせいで追加の問い合わせまで行い、しかも最悪のやり方でSQLアップサートをしていることに気づく。つまり、まずDBから取得し、存在しなければ挿入するレコードを追加する、という形だ。それでもデータ層のクエリパターンを見直すのではなく、「パフォーマンス改善」の名のもとに、ますます怪しいことを続けていく。キャリアの中で一度以上見たことがある
AI対応の助言のように見える非常に一般的な文章を読むたびに、ソフトウェア業界は建設業界に似ていると思い出す
決して整然とはせず、完全に最適化されることもなく、常にカスタムであるほかない。好み、文脈、地域性が極端に異なる現実に合わせなければならないからだ
ときどき良いツールや原材料が現れることはある
ソフトウェアの本当の堀は、システムとドメインの両方について広範な知識や経験を実質的に要求しないことにある、と考えていた
センスとネットワーク効果を複製するほうがはるかに難しい。実際、バイブコーディング以前であっても、人材と資源が豊富なベンチャー投資のスタートアップが市場で地位を築くことはまれだった
だから20代の人でも複数分野の専門家と競争できた。今の反発は、他の成熟産業でよく見られる「業界経験X年」の人たちが生まれてきたことによるものだと思う
アナリストとして働いており、私たちのグループでは、強い技術力、つまりソフトウェアエンジニアリング能力を持つアナリストが約20%で、残りは従来型のアナリストやドメイン専門家だ
この1年で、非技術系アナリストが開発部分にAIモデルを活用し、社内ツール開発の生産性が上がるのを見てきた
以前はほぼすべてがTableauで開発されていた。開発者ではない人が動くツールを作るための、最もアクセスしやすい方法だったからだ
数日前にも、私たちのグループのあるアナリストが作業中のツールを発表したが、基本的にはTableauレポートをより柔軟なアプリに移植したものだった
こうしたBI企業は大きな苦境に陥ると思う。特に、ヒストグラムのような単純なものですらほとんど描けないようにしているTableauのような会社はなおさらだと思う
私の友人は電気工学者で、最近 FIDEチェスレーティング 2000 を超えた。30年間チェスを指していて、高校時代にはチェスクラブも作った。大学ではマイクロコントローラを扱う中で、少しプログラミングを学んだ程度だ
私はコンピュータサイエンスの学位を持つインフラ／運用寄りの何でも屋に近く、30年間趣味でプログラミングをしてきた。Lichessのレーティングは、調子のいい日でも1000だ
私たちはチェスボット大会をやってみた。オープンブックで、AIでプログラミングしてもよく、オープニングブックやエンドゲームテーブルなど何でも持ち込み可の自由対決だった。私は彼を完全に圧倒したが、実際の盤上チェスでは20年間で2回しか勝ったことがない
彼は現実の対局なら無作為なプレイヤーの99%に勝つだろうし、私はたぶん20%くらいにしか勝てない
自分が正確に何を言おうとしているのかは分からないが、今ではドメイン知識がすべてではないのかもしれない、という気がしている。あるいは、ドメインそのものが変わったのかもしれない
君は彼にプログラミング勝負を挑んだのであって、はるかに経験豊富なプログラマである君が勝ったということだ。AIが使えたとしても、この場合は君のドメイン知識が決定的だったと見る