AIコーディングがあぶり出した開発者たちの悲しみと分断

• AIコーディングツールの普及は、開発者のあいだに以前から常に存在していたものの見えにくかった動機の違いを表面化させている
• コードを書く行為そのものにある職人的な満足感を失うことへの悲しみと、コードを取り巻くエコシステム・キャリア環境の変化に対する悲しみは、互いに異なる種類の喪失感である
• 1980年代からプログラミングをしてきた開発者の視点では、AIコーディングはC64 BASICからアセンブリへ、関数からシステム設計へと続いてきた抽象化段階の自然な延長線にある
• 数十年にわたってコードを読みレビューしてきた経験は、AIが生成したコードの品質を判断する感覚と判断力として今なお有効である
• どの種類の悲しみを感じているのかを認識することが重要であり、職人的な喪失と文脈的な喪失ではそれぞれ異なる向き合い方が求められる

---

哀悼の始まり

• James Randallは1980年代、7歳のときからプログラミングを始めた開発者で、発見の感覚や粘り強く何かを突き止める体験が**「圧縮」**されたと表現している
  • 完全に消えたわけではないが、圧縮の過程で何かが失われた
• Nolan Lawsonは「We Mourn Our Craft」という文章で、より直接的に喪失感を表現している
  • コードを手で練り上げていた感覚、午前2時にデバッガでバグを追っていた体験、「自分が作った」という誇りを恋しく思うようになるだろう
• こうした感情は実際の喪失に対する本物の感情だが、読み進めるうちに互いに別のものを悼んでいるという感覚がずっとあった

分断の本質

• AIコーディングは、開発者のあいだに以前から存在していたものの見えにくかった分断をあぶり出している
• AI以前は、両方の陣営が同じやり方で仕事をしていた。同じエディタ、同じ言語、同じプルリクエストのワークフローを使っていた
  • 職人志向の開発者と結果志向の開発者が隣り合って座り、同じ製品を出荷していても見分けがつかなかった
  • 仕事への動機は見えなかった。プロセスが同じだったからだ
• いまや分かれ道が生まれた。機械にコードを任せて何を作るかを指揮するか、それとも自分の手でコードを書くかを選ばなければならない
  • この選択の瞬間に、そもそもプログラミングを始めた理由が初めて可視化される
• 大学時代の数学・計算機科学の授業にも同じ分断があった。証明や定理そのものが好きな人と、応用するときにだけ興味を持つ人たちだ

私の悲しみは違っていた

• この18〜24カ月、実際に悲しみと適応の期間を経験してきた
• 新しいツールを理解できないのではないかと恐れていたが、実際には理解できた
• AIが作ったコードの品質を見極める能力を失うのではと心配したが、数十年にわたってコードを読みレビューしてきた経験は蒸発していなかった
  • 何かがおかしいときには今でも気づけるし、目利きはそのまま残っている
• パズルを解く楽しみが終わってしまうのではと恐れたが、実際には一段上に上がっただけだった
  • C64でバイトを並べていたこと → 関数を書くこと → システム設計へと続いたキャリアのすべての転換と同じパターンだった
  • いまやパズルは、アーキテクチャ、構成、アシスタントを指揮する領域へと移っている
• ほとんどの恐れは現実にぶつかって維持されなかったが、それでも一部の悲しみは残っている

残っている悲しみ

• HTMLを手で書かなくなることではなく、開かれたWebのエコシステムそのものに対する悲しみ
  • AIのコモンズ学習、人々のインターネット体験を形作る主体のさらなる集中化こそが現実の喪失である
  • 個人的な生産性向上とは無関係に消えない問題だ
• キャリア地形の変化に対する悲しみ
  • 30年以上続けてきたWeb開発は、もはや最も熱い分野ではない
  • モバイルアプリがその一部を奪い、AIエンジニアリングが現在は主導的な位置を占めている
  • うまく転換できつつあるとは思うが、不安は本物であり、まだ終わっていない
• この悲しみの核心は、コードを書く行為そのものを懐かしんでいるわけではないことだ
  • コードの周囲にある世界が変わっていくことへの悲しみである
  • RandallやLawsonの悲しみは職人技そのものに向けられているが、この文章の悲しみは文脈と理由に向けられている

どちらも間違っていない

• Kevin LawverはLawsonへの応答記事で、過去に固執するよりも職人技と情熱を再び別の方向へ向けるべきだと主張している
• 単なるノスタルジー対プラグマティズムという枠組みを超えて、自分が感じている悲しみの種類を認識することが実際に役立つ
• 職人的な喪失を悼んでいる場合、「とにかく適応しろ」と言われても解決にはならない
  • その満足感を別の場所で見つけるか、仕事の手触りが変わることを受け入れる必要があるかもしれない
  • これまで職人技そのものに生計が成り立っていたこと自体が幸運だったのだ
• 文脈的な喪失を悼んでいる場合は、より実行可能な対応ができる
  • 新しいツールを学び、自分が望むWebのために努力し（たとえ小さなWebであっても）、悲しみながら同時に適応していくことができる
• Nolan Lawsonの表現を引用すると、「新しい世界を祝福もしないし、抵抗もしない。太陽は昇り、沈み、私は無力なまま軌道を回り、私の抗議ではそれを止められない」
  • それでも、悲しみと恐怖のなかにわずかな高揚感があるというのは正直な告白だ

コンピュータに仕事をさせる

• 1980年代にプログラミングを始めて以来、学んできたあらゆる言語は目的のための手段だった
  • コンピュータに自分の望むことをさせるための新しい方法だった
• AIコーディングはその延長線上にある最新の段階であり、断絶ではなくはしごの次の一段である
• ただし、そのはしご自体が変わっており、寄りかかっている建物も変わっているため、どこへ向かうのかを正確に知ることはできない
• 確かなのは、考えて作ったものが実際に動く瞬間の満足感は40年以上変わっていないということだ
  • コードがそこに至るまでの経路は変わったが、動いたその瞬間は同じである

[github88]

大げさに騒ぎすぎですね

[ahwjdekf]

Webプログラミングのようなものは、AIにやってもらえるのはとても良いことだと思います。

[brilliant08]

どうやら、他のプログラミングには何か崇高な価値があるようですね。

[onetoday]

HNは平均年齢層がかなり高くて、どこか時代に取り残された人たちのように感じることもたまにあります。
だから、こういうネガティブな文章（批判的というより）は読まずに流すことが多いです。

ちなみに、たまに自分でコーディングする楽しさを思い出すことがないわけではなく、
Web系だからこそ少しはやりやすいのかなという気もしますが、
コードをタイピングしていない期間が3か月を超えています。

何より、こういう開発の仕方がすごく楽しくて、若い頃のように自発的な残業もたくさんするようになりました。

[snisper]

AIのせいでそんなに悩むなら、使わなければいいのでは

[savvykang]

RADツールが出てきたとき、人々がどんなふうに反応したのか気になります

[GN⁺]

Hacker Newsの意見

• この記事は完全に誤解していると思う。「クラフト型（craft）」の開発者も結果を追求するが、長く持続し拡張可能な結果を目指している
  良いプログラマーの目標は、自分自身を不要にすることだ。昔はアセンブリでサイクルを数えビットを詰めていた時代もあったが、コンパイラを使うのが当たり前になった。CRUDアプリを手で作っていた時代もあったが、今ではフレームワークが代わりを担う。メモリ管理、型システム、高水準言語、ノーコード／ローコードのシステムなどはすべて進歩の一部だ。結局、プログラミングの目的は、コンピュータによって私たちがやらなくてよいことを増やすことだ
  本当の分断は、ソフトウェアを「改善可能で理解可能なもの」と見る人と、「他人が作った不可解な障害物」と見る人の間にある考え方の違いだと思う
  • この見方は好きだ。長くシステムを扱っていると、あらゆる細部が意味を持って感じられる。ひとつ変えれば全体にどう影響するかの勘も働く。でもAI時代のソフトウェアでは、こうした理解が不可能になるのではと心配している。あまりに多くのコードが自動生成され、全体像を把握しづらくなりそうだ。結局、修正が難しいならAIで作り直した方が合理的かもしれない。だから**モジュール性（modularity）**がさらに重要になると思う
  • ほぼ全面的に同意するが、最後の一文だけは例外だ。それは知能の問題というより、実際には後者の人たちは単純にレベルが低い場合が多いと思う
  • この区分は**ピルシグの「古典的 vs ロマン的」**な区分に近いのだろうかと気になる。前者は構造や原理を理解しようとし、後者は外見や感覚、効用を重視する
  • 「良いプログラマーは自分を不要にする」という言い方は昔はよく聞いたが、最近はほとんど聞かなくなった気がする
• 本当の分断は、技術の進歩が本質的に良いものだと信じる人と、歴史的に生産性向上が労働時間の短縮につながってこなかったことを知っている人の間にある
  8時間労働制は技術ではなく政治的闘争の結果だった
  • 本当の分断は資本所有者と労働者の間にある。資本家は、労働者の生産物の一部を相続した紙切れで食って生きている
  • こういう議論がHacker Newsで以前よりよく見られるのは興味深い。AIが開発者を置き換えるなら、賢くて意欲ある人たちが政治的に目覚めることもあり得る。歴史的に、企業が大きくなりすぎると最終的には国家のように扱われる
  • 極端な主張が多すぎる。結局、本当の分断は科学技術を支持する人と嫌悪する人の間にある
• もはや単にメカニカルキーボードで打つのが好きな人の問題ではない。本当の違いは、システムを理解し新しく作るのが好きな人と、それを他人に任せて結果だけ得ようとする人の違いだ
  ただし、その「他人」が人間であるなら、メンタリングや環境づくりによってその功績を分かち合うことはできる
  • 「本当の分断」がいつも『知的にも道徳的にも優れた私』と『劣った彼ら』という構図に流れていくのが面白い
  • 私はシステムを理解して新しく作るのも好きだし、AIに反復作業を委任するのも楽しんでいる。そんな私は存在してはいけないのか？ 同意できない
  • 開発者には二つの類型がある。A型はセキュリティ・テスト・CIまで丁寧に面倒を見るが、ユーザーからするとまどろっこしいことがある。B型はテストやデプロイには弱いが、ユーザー体験を重視する。どちらも必要だ。ただAIはA型の領域から先に代替しそうだ
  • 「Claude、この重いもの持ってくれ」みたいな感じだ
  • 人によって楽しさを感じるポイントは違う。私はパズルを解く過程が好きだ。計画より、その場のひらめきで解決する方が楽しい
• AI以前は、どちらのタイプも同じ仕事をしていた――同じエディタ、同じ言語、同じPRワークフローを使っていた。違いは動機だった。だから、AIがコードを代わりに書いてくれるのを好む人もいれば、自分が楽しんでいた部分が消えることを惜しむ人もいる
  Kellanの文章 “Code has always been the easy part” も同じ文脈だ。私たちの世代は、Webが与えてくれた主体性の感覚に中毒になって技術に飛び込んだ
  • 本当の違いは品質基準だ。変数名ひとつに何時間もかける人もいれば、「動けばいい」と考える人もいる。どちらにも価値はある。ただ、モデルの進歩は速いので、昨年の基準で判断すべきではない。デフォルト出力は平均的でも、うまく扱えばずっと高い品質を得られる
  • Perlプログラミングが美的に楽しくなかったって？ 私はPerlを扱えることを誇りに思っていた。読みにくい言語を自在に操る快感があった
  • Perlにはたしかに魅力があった。unless のような構文は流れを自然に表現できた。ただ、進化が止まったことで、皆がそれぞれ別のやり方で拡張し、脆いコードベースが生まれた
  • 私はコーディングそのものは楽しくないが、問題を解き切ったときの満足感は大きい。こういう思考の過程が脳の柔軟性を保ってくれていると感じる
  • これは二分法ではない。私は両方の混合型だ。AIが仕事のコーディングを代わってくれるので、家では伝統的なコーディングを楽しむ余裕ができた
• 私は結果重視型だ。結果の品質を大切にしている。コーディングの過程より、完成した製品の出来にこだわる。だが最近のアプリは15年前より遅く、バグも多い。Claudeアプリでも、クリックできないボタンが出ることがある
  AIコーディングは生産性をせいぜい10％ほど上げるだけだ。本当のボトルネックは、何を作るべきかを理解し、納得させるプロセスにある。コーディングはそれを理解するための手段にすぎない
  • 私もAIはコードを書くより情報収集と検証に多く使っている。複数のLLMをレビュアーとして置き、互いに批判させる。複雑なビジネスロジックを扱うのに非常に役立つ。AIはエッジケース探索にも有用だ
  • コーディングがボトルネックではないという点に同意する。AIが10倍の生産性を生むというのはあり得ない。私はもともとコーディングが速い方なので、AIはあまり助けにならない。むしろ品質より速度を強いられる状況になっている。チームメンバーがAIで数千行を吐き出すので、コード品質が急落している
  • コード品質と製品の完成度を混同しているように思う。問題の大半はビジネス上の意思決定に起因している
  • 「結果だけが重要なら、なぜ自分でやらず外注しないのか」という問いも成り立つ
• 「HTMLを手で書いていたWeb」が恋しい。個人が直接作っていたDIYなWeb生態系が、企業所有のAIツールに置き換えられていくのが悲しい。今はまだその中間段階だが、オープンWebの衰退は加速している
• 生成AIも職人精神の延長線上で使える。オープンソースのコードを読み込ませて「なぜこう動くのか？」と尋ねるような、理解に基づく開発ができる
  • パズルを解く楽しさは消えたのではなく、一段上のレベルへ移動したのだ。いまやシステム全体の構造や理由を設計することが職人の領域になっている
  • もちろん、その結果はupstreamに貢献すべきだ
  • 実際のところ、こういうことは昔から検索エンジンでも可能だった
• 三つのシナリオはどれも悪い。①弱いAI → 大恐慌2.0、②予想どおりのAI → 少数の超富裕層による独占、③超強力AI → 人類の絶滅。理想的なAIの量は0だ
  それでも抵抗はしてみるべきだ
  • 私も以前はそう思っていたが、最近はAIブーム後の現実的な限界を見て、市場はもうすぐ調整されると感じている。今はAOL時代に近い
  • 真の知能は、単にテキストをツール呼び出しに変換することではなく、計画・批判・創造的な問題解決を含むはずだ
  • 実のところ、1と2のシナリオはどちらも同じ人々が利益を得る。3は大衆の目をそらすための幻想だ
• スタートアップで長く働くうちに、「職人精神」は捨てた。その代わり、AIコードレビューの欠如や大きすぎるPRがどれほど危険かは分かるようになった。これは職人精神ではなく、正確性と技術的負債の管理の問題だ
  • 問題なのは「結果を追う人」ではなく、手柄だけを取りたがって仕事は避ける人たちだ。彼らのコードが壊れても、もう別のプロジェクトへ移っている
  • 私の経験では、「職人精神 vs 結果」という構図よりも、建物全体をきちんと建てる感覚の方が重要だ。AIが下請け業者のように一部を担当するのは良いが、今は全体を丸ごと外注しているレベルなので成果物がひどい
• 開発者には二種類いる。コーディングが大好きで管理職にならない人と、チャンスがあればすぐ管理職になる人だ。AIの恩恵をより受けるのは後者だ
  • 人をうまく扱える人は管理職になるべきだ。そして第三の類型もある――システム設計が好きで、実装は他人に任せる人