リスク許容度、モチベーション、根気、そして忍耐。これが防御線だ。AIの前も今も変わらない。

AIの視点から見ると、いくつかのドメインは浅い（チェスみたいに）、いくつかは深い（ここは自由に埋めてね）っていう解釈もできると思う。

実際にチェスをプレイすることが、効率的なゲームツリー探索アルゴリズムを書くことと、いくつかのシンプルな原則を超えて何の関係があるの？君は彼にプログラミングコンテストを挑んで勝ったけど、君ははるかに経験豊富なプログラマーだった。彼がAIを使えたとしても、君のドメイン知識が決定的な要因になったんだ。

正直、これが俺の経験でもある。LLMは他のドメインを探求するのを簡単にしてくれるけど、一つのドメインのマスターにはなれない。専門的なドメイン知識はまだ必要なんだ。それでも、新しいアイデアを試したり、深く掘り下げたりするための素晴らしいツールにはなるし、好奇心があるなら学習を加速させるのにも役立つよ。

完全に同意だね。

自分が目指しているのは、基本的にはプラットフォームエンジニアになることだと思う。仕事はガードレールやバリデーション、プロンプトライブラリを作ること、そしてエージェントや手動レビューを行うこと。これでドメインの専門家がコーディングエージェントを使い始めるときに安全を確保するんだ。ちょっとT2/T3のカスタマーサポート（またはサポートエンジニア）に似てるけど、内部的な役割だね。危険なポイントや変なエッジケースを見つけて、全てが正しく設定されているか確認するのが仕事で、ルーチンの問題を100%自分で解決するわけじゃない。もちろん、クロスカッティングな問題にもたくさんの余地があるよ。

ドメインの専門知識とQAのマインドセットが組み合わさることでSWEを置き換えることができるけど、一貫したQAのマインドセットは珍しいね。

先月だけで数十億のトークンを使ったよ。Claude Code（最大限の努力でOpus 4.6）を一日中使ってるけど、これがどう可能なのか本当に理解できない。これって使い方が報われてるの？自分の理解不足かもしれないけど…どういうこと？

聞いたことないの？今適応しないと取り残されて、二度と働けなくなるよ！Copilot？それは去年の話。エージェンティックエンジニアリング？もう遅れてるよ！

全体的には同意だけど、職業によってはドメイン知識を蓄えたり秘密にしたりする傾向が出てくると思う。例えば配管工はパイプのフィッティングを変える方法を商業秘密や知的財産として守ろうとするだろうね。

LLMは、あなたの武器の一つとして追加するツールだよ。全能ではないし、他のツールと同じように注意が必要。今のところ、僕のアナロジーで一番しっくりくるのは、現代のドリルドライバーとドライバー/ブレースとビットなどの比較かな。古い道具に比べて、短時間で素晴らしい結果が得られるんだ。「1インチ間隔で床を1時間で全部ネジ止めした」とか「タバコ休憩をたくさん取った」とかの「すごい」エピソードもあるよ。（本当は、半分の時間で釘打ち機を使えたけど、将来的にその床を簡単に上げることはできないし、たぶん倍のコストがかかるだろうね。）いくつかのオンプレミスのLLMを持っていて、他のもアクセスできるから、最終的には…ブランドにアナロジーを広げると思う。新しい仕事を探すつもりは全然ないよ。ドリルドライバーは、使う人がいないと大工や現場作業員にはなれないからね！

僕はお金を生むソフトウェアを書いていて、AIはそのソフトウェアをもっとお金を生むように手助けしてくれるんだ。

20年前のOOPの盛り上がりを覚えてる？みんながGoFの本をざっと読んで、理由もわからずにパターンを使っていた頃のコードベースの掃除を、今でも続けているよ…。僕の予測では、20年後にはClaudeが共著したものを掃除していると思う。

AIが基本的に安定して予測可能な改善や停滞の状態になるまでは、こういった意見は無意味で、ほぼ完全に間違っている可能性が高いよ。AIについて覚えておくべき小さなこと：技術はまだ機能していない間はAIと呼ばれる。信頼できるようになったら、適切な名前を付けて、別のものがAIになるんだ。

最近、AIツールがソフトウェア開発を難しくしているという考えが固まりつつあるんだ。なぜなら、AIはできることのハードルを劇的に引き上げるから。個々の開発者は、今ではかなり挑戦的なプロジェクトに取り組むことができるようになった。最終的な制約は常に時間で、AIはその時間内にもっと多くのことを成し遂げる手助けをしてくれる。でも、その時間でできることはずっと難しくなる。もっと多くのことを理解しなきゃいけないし、AI以前の快適ゾーンから大きく外れなきゃならない。数日かけてコードベースをリファクタリングしたり、小さな機能を出す方法を考えたりするのは、以前は許容されていたけど、今はそれが難しくなっている。コーディングエージェントのおかげで、その曲線をもっと早く登れるけど、それでも登らなきゃいけないし、情報の量もずっと多くなる。非技術系の雰囲気でコーディングする人たちが自分の仕事を奪うことを心配しているなら、正しい反応は、その雰囲気のコーダーたちよりもずっと優れたソフトウェアを作ることだよ。それには、もっとスキル、もっと野心、もっと経験が必要なんだ。難しいよね！

なんか、観客や素人がプロスポーツを判断するのに似てる気がする。これを引用しないでほしいけど、要点を伝えたいんだ：彼らは、スポーツで成功するためには完璧な対称性が必要だと言うけど、それは子宮内の発達の安定性と強く関連している。対称性が高いほど、完璧な発達になるってね。数年後には、ブルース・リーの片足がもう一方よりもかなり短いとか、ウサイン・ボルトも似たような非対称な発達をしているってニュースが出てくる。そして、彼らは最初の主張をひっくり返して、「彼らは例外だから一般的なルールは適用されない」と言い出すんだ。だから、興味のあるものを作ってみて、うまくいくかもしれないよ :)

安定した状態は、システム思考者/エンジニアとドメイン専門家のペアプログラミング構造で終わると信じたいな。誰かがリンクリストがマップよりも良い時を見つける必要があるし、もう一人は臨床試験のコーディングが請求、監査、患者へのアプローチの前に行われるべき時を見つける必要があるんだ。

どれだけの持論を展開すれば、人々が個々のレベルでAIをどう扱うべきか全く分からないことを認めるのだろう？ 誰も何をすべきか分からないなら、話すことが正しいアプローチだよね。

よく分からないけど、ドメインの専門知識があってもスキルがないと、すごくテクニカルデットが溜まるポイントがあるよね。実際、私のキャリアの約半分は「ドメイン知識があって、チケットやエピックを閉じるには十分だけど、テクニカルデットが多い」っていう状況に対処してきた。つまり、私の仕事のかなりの部分は、こんな感じだった。 - ドメイン知識があっても、人間だからミスをしたり、フィードバックを受け入れなかったり、最悪の場合はコーディングエージェントが書いたものを二重チェックすることを拒否したりするから、PRを細かくレビューすること。 - 「これをリファクタリングして、技術的には正しいけど、書き方がひどすぎてタイムアウトになったり、マネージャーやDBAが叫んでる」っていう状況。

私たちはいつも冗談で、シニアファンドアカウンタントを雇ってプログラミングを教えたいって言ってるけど、問題はそういう人が全然いないことなんだ。エンジニアにファンド会計の細かいところを理解させて、こういう会社のためにソフトウェアを作るのは難しい。真に優れたソフトウェアエンジニアは、ドメインを学ぶ意欲があるけど、学ぶ方法が必要だよね。そう言うのは、いろんなレベルでそういうことをやってきた会社にいたからなんだ（たまに会社自体、たまにチーム、たまに同僚）。逆に、すべてが口先だけの会社にもいたことがある。そういうところでは、JIRAにあることや、IT以外の人が会議で言うことからしか情報を得られないことが多い。 ベンチャーキャピタルとプライベートエクイティのためにソフトウェアを作ってきた5年間、この記事には本当に共感する。コードを書くのは、仕事の中で一番簡単な部分だし、顧客が私たちに何を求めているのか、その背後にある金融工学やニュアンスを理解するのが難しい。特に過去5年間での大きなパラダイムシフトは、多くの会社が人を骨の髄まで働かせることを期待していることだと思う。それが逆効果になって、重要な会話ができなくなってしまう。文化も大きな要因で、少なくともサイドコンバセーションやミーティングが簡単にできる会社もあれば、ちゃんと話すためにchange.orgの請願書にサインしなきゃいけないような会社もある。結局、君の言う通りだね。要件はコードよりも重要だ。私がいた会社では、「正しい」という人の定義が、すべての要件が満たされていても、実装されている間ずっと不在だった人が書いたものの書き方が気に入らないから、機能が遅れたこともあった。 次のことを知ったら、「バッチプロセス」が%numberOfRecord%*10の挿入を持っていて、設計が悪いデータモデルのせいでSQLのアップサートを最も間違った方法でやっていることが分かる（つまり、DBから取得して、存在しない場合に挿入するレコードを追加する）ってことがある。そして、データレイヤーのクエリパターンを見直すのではなく、「パフォーマンスを改善する」ためにますます疑わしいことをやり続けるのを何度も見てきた。

空いてるよ。コーヒーでも飲みに行こうか。