これについての私の仮説は、AIを嫌う人たちが同じ理由を挙げているのは、単に目的地に着くのが楽しいからじゃないってこと。むしろ、彼らは「旅」が得意だと思っていて、その旅を他の人と比べられると思ってるんだよね。別の見方をすると、彼らは自分の旅をもっと簡単に共有したり、仲間を助けたりできるのが好きなんだ。そういう部分が好きな人もいる。だけど、比較する相手は同じ旅をしている他の人じゃないから、仲間意識が薄れてる。さらに、他の人はもうその旅を楽しめなくなってるから、なんか「孤独」な感じがする。誰もが手作業で楽しむために自分のコードを書くのを止めるわけじゃないけど、他の人とその旅を共有する要素が減ってきてるんだよね。

数ヶ月前の私もそうだった。コーディングして問題を解決したいけど、AIが全部やってくれる。私は問題解決をもっと下の段階に移すことで乗り越えた。AIを問題を解決するために指示を出すチームだと思えばいいんだ。

でも、比喩を少し押し進めると、モーターボートがある湖で漕いでいるのはまったく違う体験だよ。うるさいし、常に波が立ってる。私たちは孤立しているわけじゃなくて、エコシステムの一部なんだ。子供の頃、ニューイングランドの湖は帆船でいっぱいだった。帆船レースもあった。今は完全にポンツーンボートばかりで、帆船は見当たらない。

ある意味、ディーゼルエンジンが帆船への情熱を奪ったって言ってるようなもんだね。帆船でキャリアを積んできた人が、船の rigging を仲間と一緒に整えて有意義な旅に出ることに意味を見出していると、急に自分のスキルや情熱が歴史的な好奇心に縮小されると、帆船への愛が少し減るかもしれない。他の船乗りは、もう一日中 rigging を登ったり、デッキをコーキングしたりしなくて済む「楽な」新しい仕事を好むかもしれないけど、今度は別の問題が出てくる。貨物トン数あたりの必要人数が少なくて済むからね。そして、ディーゼルエンジンのメカニックたちは新しい市場に大喜びしてるんだろうね。（この比喩は、AIとディーゼル船と帆船の相対的な有用性について何も主張していないよ。）

同意するよ、私もおじさんだし。個人プロジェクトでは自分の好きなことをやってる。石や木を手作業で彫るのも好きだし、ただそれが楽しいから。仕事では、ハイプが一部の人が楽しんでいた最後の部分から活力を奪ってる。完全なコントロールが楽しいからね。個人的には、仕事って他の誰かが望むことをやるだけで、自分を喜ばせることじゃないと思ってる。

まあ、私はそう思ってる。AIが嫌いなわけじゃないし、むしろ楽しいと思ってる、ちょっと違うけどね。旅を楽しむだけじゃなくて、旅が一番好きなのは確かだけど。みんなが目的地に到達できるようになると、旅への興味が減っちゃうんだよね（これ、分かるかな）。AIに対する愚痴じゃなくて、私は毎日AIを使ってるし、役に立ってる。ただ、AIがいることで楽しさが減ったのは確かで、これを説明する唯一の方法は旅と目的地の対比なんだ。

モーターボートがもっと早くて安く川を渡らせるのに、彼は客をボートで渡らせてるわけじゃない。趣味と「生計を立てるためにすること」を比較してるね。今週59歳になったけど、また仕事に行くのが楽しみだよ。毎日クラウドを使ってるし、クラウドをチェックして新しいことを学んでる。もう「UI担当者」がいなくても、すぐにデモできるものが作れるようになった。（私は「UI担当者」じゃなかったけど。）毎日目が覚めた瞬間からずっとコーディングしてるわけじゃないし、それはメンタルヘルスにとって最悪だったと思う。あと2年以内に引退する予定だから、この新しい仲間と楽しんでるよ。この36年間で避けてきた落とし穴は、解決策に恋しないこと。問題に恋をするんだ。クラウドはその問題を私ができるよりずっと早く解決してくれる。

会社がモーターボートを使うように強制してるから、もう漕ぎ舟は使えない。趣味として漕ぐのは続けられるけど、仕事が本当に楽しめるものであったのはラッキーだった。今はそれがストレスになってきてるから、趣味や興味に時間を見つけるのがすごく難しくなってる。

もう街で馬車を乗り回せない。

モーターボートが漕ぎ舟への情熱を奪ったと言ってるようなものだね。これは実際に起こることで、比喩が明らかに君に不利に働いてるよ！川や湖でカヌーや漕ぎ舟を漕いでるとき、モーターボートが通り過ぎると、魚が驚いたり、波で揺らされたり、2ストロークの排気ガスで臭くなったりして、体験が明らかに悪化する。モーターボートがいなくても、それを支える環境が大きくて侵入的なんだよね。

すごく同意！AIを制約してるんだ。常に依存関係を増やそうとしたり、不要なコードを作ったり、テストを広げすぎて無駄になっちゃうから。何を作りたいかは頭にあるし、今はそれを効果的に実現するためのワークフローも整えた。自分の仮定についてたくさん質問もするし、「私たち」（私とAI）がそれぞれ単独で作るよりも良い解決策を見つけてるんだ。

みんなが「LLMは広い文脈やアーキテクチャに集中させてくれる」って言ってるのを聞くけど、私の経験ではアーキテクチャは個々のコンポーネントの小さな決定で成り立ってる。複雑なシステムを書くとき、プリミティブやインターフェースを正しく使うことは、実際にそれを使ってみることで得られる摩擦を経験することが大事なんだ。コードが「無料」なら、使ってみないから悪いシステムを書けちゃう。LLMが粗い部分を抽象化しちゃうからね。私はLLMの初期導入者のチームと一緒に働いてるけど、彼らのアーキテクチャには未知の未知がたくさんあって、自分たちでコードを書いていたら考え抜いていたことだと思う。あちこちにインピーダンスミスマッチがあるけど、古いコードをラップするためにもっとコードを生成するだけなんだ。これがシステムを脆弱でメンテナンスしづらくしてる。新しい問題じゃなくて、以前にもこういうミスをする人たちと働いたことがある。でも、時間が経つにつれて、ほとんどのシステムがスラッジの層を重ねていくように見える。泥をボールに追加するのがどんどん安くなってるからね。

もしかしたら私の経験だけかもしれないけど、私はシステムプログラマーじゃなくて、今勉強中なんだ。システムプログラミングの概念はそんなに難しくないと思う（例えば、今日はログベースのファイルシステムについて読んでる）。でも、実際の実装やコーディング、システムを組み立てることが一番楽しい部分だと思う。私だけかもしれないけど、システムプログラミングでは、理解したと言う前に、すべての部分を実装しないといけない気がする。

私の経験は全く逆だったよ。プログラミングの知識はゼロで、3週間前までパーケットファイルが何かも知らなかった。始めた深い研究プロジェクトを見直しているときに、非効率な部分に気づいたんだ。USDAのフィトケミカルデータベースは公開されてるけど、16個のCSVファイルに分かれていてリンクも不明瞭だった。そこで、PubMedやChEMBL、特許のデータを使って、単一のフラットテーブルを作るアイデアが浮かんだ。普通、こんなプロジェクトは私みたいな人には完全に不可能だった—プログラミングのハードルが高すぎるから。Claude Opus 4.6のおかげで、問題のアーキテクチャに完全に集中できた。どのデータを、どこから、どんな形で、どのターゲットに向けて使うか、すべての決定は私がした。実装はClaude Opusがやってくれた。多分、あなたたちの「旅 vs. 目的地」の議論には私のことは考慮されてなかったと思う。私にとっては、目的地は以前は手の届かないもので、AIが私が実装できなかった部分を引き受けてくれたから、旅が可能になったんだ。

「少なくとも私がやりたいことに関してはそうじゃない。」って、具体的に教えてくれる？

同意するよ。だけど、これはアーティストやミュージシャン、（最近では）作家たちが長い間直面してきた同じ状況だってことを忘れないようにしてる。運が良い少数派でない限り、プロセスを楽しむことができないと、成果を得るのは難しいからね。純粋なコーディングや多くのコード問題解決の分野も、同じ状況に陥るだろうね。

「間違いから本当に学ばない、ずっと嘘をつくデジタルのジュニア開発者を扱う」って、ほんとその通り！

100%同意だわ。ここ10年ほどで、プロとしてテクノロジーの世界に戻ってきた。昔からコンピューターが好きだったけど、最初の10年くらいは人道支援の仕事をしてたんだ。すごく興味深い分野だけど、日常は超退屈だった。コーディングに戻るのは、まるで帰ってきたみたいな感覚。得意だし、本当に楽しんでる。問題解決の部分が、脳をすごく刺激してくれるんだよね。私も全く同じ気持ちだよ。仕事の楽しみを奪われてるし、大規模な解雇の影が業界にかかってるのも辛い。少なくともOPは60歳だけど、私はあと25年も働かなきゃいけないし、どうしたらいいのか全然わからない。もう全部嫌だ。

おお、わかる！私の気持ちとは正反対だね。逆に、私は仕事がすぐに本番環境に行かないとイライラする開発者で、コードレビューでは防御的になっちゃう。確かに、プログラミングの楽しさの一部は、物事がどう動いているかを理解して、それを分解して自分のニーズに合った形に再構築することだよね。でも、これは通常、コードの小さな部分や自己完結型のライブラリ、アーキテクチャの基盤に限られると思う。そのレベルでは、人間の入力や指示がまだ重要だと思う。あとは、すべてのパーツをつなげたり、明らかなロジックを書いたりする地味な作業があるけど、これは喜んで他の人に任せられる。最後に、最終製品やそれを使う人の体験を考えて選ぶ選択肢があるけど、これは全然パズルを解くことじゃなくて、クリエイティブな仕事で、到達すべき結果が決まってるわけじゃない。私は、そこに早く到達できるツールがあって嬉しい。

15歳からコーディングを始めて、今でも大好きだよ。最近は主に中小企業向けのカスタマイズアプリケーションを一人で、時には小さなチームと一緒に作ってる。営業も自分でやってるよ、対面でね。私にとって、LLMを使わないことは生産性を大幅に犠牲にすることになる。でも、私が使う方法はとても構造化されてる。アプリケーションの作業は、要件の評価から始まる：アクターの特定、ユースケースの定義、ビジネスの制約を理解すること。それからオブジェクトやフローを設計する。可能な限り、かなり厳格な公理や制約でシステムを形式化する。その後にLLMが登場して、主に実装の機械的な部分を手伝ってくれる。私の経験では、結局は人間が全てを担ってる。思考、モデリング、システムに対する責任は人間のもの。LLMは実装を早く進める手助けをしてくれるだけ。私が働いているセグメントは、LLMによる仕事の置き換えの影響を受ける最後の方だと思う。私のクライアントは、中小企業でカスタマイズされた内部システムが必要なところだから、急に自分たちのソフトウェアを作り始めることはない。実際に必要なのは、ビジネスを理解し、モデルを定義し、システムに対する責任を持つ人だ。LLMは実装を手伝うけど、その部分は仕事の中で難しい部分ではなかった。

これは100%私の経験だ。私はパズルを解くことや、物事を整理してまとめることが楽しい。ビジネスのニーズを満たすための最終結果にはあまり興味がない。楽しいのは作ること、理解すること、成長することなんだ。やりたいと思っていたプロジェクトの中には、本当にやりたくないコンポーネントや依存関係があった。それが理由で、商業環境で実行可能になるまでやらなかった。今はLLMのおかげで、自分のジュニア開発者が面倒なことを処理してくれるから、過去30年間考えていた楽しいことがやっとできるようになった。先週の例なんだけど、90年代の大きなCコードベースを再利用したかったんだけど、現代のコンパイラはCの見た目がどうあるべきかについて違う考えを持ってる。コンパイラのエラーから、各ケースで何をすべきかは明らかだけど、何百ものソースファイルを手動で確認する気分じゃなかった。だから、ローカルで動いているqwenコーダーをyoloモードでコンテナに入れて、1週間忘れてたら、コンパイルできるコードベースが出来上がってた。差分はすぐにレビューできて、手動で介入が必要なケースはほんの数件だった。

結果にはまだこだわってるよね：君の場合、その結果は解決したパズルだよね。AIがそのプロセスを楽しくしてくれる。例えば、Next.js用にすごく複雑なキャッシュハンドラーをゼロから作らなきゃいけなかったんだけど、特定の方法でJSONをチャンクごとにシリアライズする必要があったんだ（全部をメモリに読み込むんじゃなくて）。理論は知ってたけど、APIの詳細や他の面倒なことがあって、いつも大変だった。AIのおかげで、問題の理論にもっと集中できて、技術的な実装について考える時間が減ったから、プロセスがずっと楽しくてやりやすくなった。もしかしたら、私たちは抽象化の階段を登ってるだけなのかもね。初期の頃は、自分たちでガーベジコレクションのメカニズムやバイナリサーチアルゴリズムを作ってた。ライブラリを使い始めたら、もっと高いレベルで楽しみを見つけなきゃいけなくなった。将来的には、要件定義の範囲内でのパズルを解くことが楽しみになるかもしれないね。

楽しい部分は作ることにあり、理解や成長にある。これには私も同意するよ。間違いなく、仕事で一番好きな部分は、ただ「正しい」と感じる解決策を考え出すことだ。特に、その解決策が力任せや単純なアプローチよりもずっとクリーンなときはね。ちょっとチープに聞こえるかもしれないけど、本当に好きな感覚の一つなんだ。私は約15人のチームの中で最も経験豊富なエンジニアだ。ソフトウェアのクラフトマンシップを重視するようにしてるけど、共感してくれる人もいれば、そうでない人もいる。AIツールに依存しているように見えるエンジニアも何人かいて、彼らとのやり取りは苦労してる。彼らの中には、明らかに理解していないコードを押し進めようとしている人もいて、レビューもしていないから、成長がないことで失敗する準備をしていると思う。

それ、私も同じだよ。チャットボットと話しても全然楽しくないから、別の仕事を探してるんだ。

私はまだ好きなパズルを解くことができる気がする。高いレベルのアーキテクチャやデザイン部分が好きだからね。あまりタイピングしなくても済むし、スタブのソリューションを提供して、残りを埋めてくれるように指示できるから。

今日の面倒なところは、ライセンスに関係なく、AI企業が私のコードを盗んでモデルを訓練するから、公開できないってことだね。

エージェントプロセスをマスターすること もしフロンティアモデルがオープンウェイトだったら、やる価値があったと思う。今は、Claude CodeやGoogleのAntigravityみたいなツールをマスターするために時間を投資しても、何かの理由でそのエコシステムから外される可能性があるから、努力やスキルが無駄になってしまうかもしれない。

これがAIとコラボするための一般的なレシピとして役立つかもしれない： - 仕事を分けて、君が高レベルのクライアントコードを書いて、AIがライブラリやフレームワークのコードを書く。 - まずはクライアントコードの一部を書いてみる。 - 君のコードが動くように、ライブラリやフレームワークの初期バージョンを書いて、テストやドキュメントも用意する。これでAIに望む実装スタイルの情報を与える。 - インターフェース（API、DSL、または他のモジュール境界）を設計・定義するのに時間をかける。デザインをAIと話し合って、良い感じになるまで繰り返す。 - 各デザインの増分ごとに、AIに実装、テスト、ドキュメントをさせて、その後クライアントコードを適応させる。あるいは、先に自分のコードを変更して、AIにインターフェースや実装を変更させて動かす。 - 繰り返しの間に、生成されたテストを少なくとも勉強して、実装について話し合う。 - 繰り返しは小さく保ち、次の変更に進む前に完成した機能をコミットする。 - TODOリストを作って、新しい決定と矛盾する古いデザインは気にせずに捨てることを恐れない。（これは一回限りのプログラムの変形だけど、デザインツールとして。）そうすれば、クライアントコードとライブラリ/フレームワーク層の明確な分離ができて、前者と後者のインターフェースは君が持ってるけど、低レベルの実装は持ってない（これはすべてのサードパーティコードや自分が書いていないコードに当てはまる）。もちろん、低レベルのコードを書くのが好きなら、これは君には合わないだろう。でも、ビジネスの文脈では、詳細なドメイン知識を持ち、プロダクト部門とコミュニケーションをとるので、これは合理的な労働分担だよ。（そして、低レベルのコードへのインターフェースを設計し続ける。）少なくとも私にはこのワークフローが合ってる。デザインや境界を正しくすることに時間をかけるのが好きだから、読みやすく意図的（時には美しい）なクライアントコードが生まれる。プロセスの中でクリエイティブな要素も保たれるし、エンジニアがAIコーディングエージェントの単なる管理者になってしまうこともない。