プログラマーのアイデンティティ危機

216日前原文(hojberg.xyz)

概要

プログラミングの クラフトマンシップ と アイデンティティ の重要性。
MITの ハッカー文化 とその歴史的意義。
AIやLLM の普及によるプログラマーの役割変化への懸念。
自然言語プログラミング の問題点と精度への疑問。
深い理解 と 創造性 を守るための課題。

プログラマーという生き方とVimの聖域

プログラマー、 コーダー、 ハッカー としての自己認識。
Vimエディタ を作業場・聖域と捉える日常。
好奇心で 技術を磨き、自己成長 を楽しむ姿勢。
フロー状態 での創造的没頭。
INSERTモード で思考とコードが直結する感覚。

MITとハッカー文化の起源

1950年代後半の MIT で誕生した実験的・反体制的な文化。
Flexowriter や“Tixo”といった初期の計算機でのプログラミング体験。
The Right Thing （完璧なプログラム）を追求するハッカーたちの姿。
Tech Model Railroad Club などによるデジタル魔術の追求。
知識共有 と「ハッカー倫理」の継承。

プログラミング文化の進化と危機感

ハッカー文化の遺産 が現代にも息づく現状。
AIやLLM の台頭によるプログラマーのアイデンティティ喪失への懸念。
Specification Engineering への役割変化とその空虚感。
創造性やスキルの軽視、職業価値の低下への危機感。
ツール選択の自由 が管理職に奪われる違和感。

LLMと自然言語プログラミングの限界

Fortran の進化との比較によるLLMの本質的な違い。
LLMの不正確さ と自然言語指示の曖昧さ。
形式言語 による精度と信頼性の重要性。
Dijkstra による自然言語プログラミング批判の引用。
AIエージェント開発 における厳格さの形骸化。

深い理解と創造性の喪失

AI生成コード のレビュー軽視と理解不足。
所有感・主体性 の喪失と断片的な注意力。
Peter Naur の「Programming as Theory Building」による理論の重要性。
没入と試行錯誤 による良い設計の発見。
AIエージェントによる摩擦のない開発 が質の劣化を招く危険性。

LLM時代のプログラマーの課題

認知的負債 の増大とチームコラボレーションの低下。
コードレビュー の負担増加と責任転嫁の問題。
人間同士の協働 よりもLLM依存が進む職場環境。
管理職や経営層 による人間的つながりの希薄化政策。
クラフトマンシップと創造性 を守るための新たな課題。

Hackerたちの意見

彼らがコーディングに興味がなさそうなのに、なぜプログラマーになったのか不思議だ。問題を解決するためだ。コーディングは手段であって、目的ではない。 > エディタの慎重な設定や、ドットファイル、開発環境の調整は、あなたには楽しいかもしれないけど、価値を加えているわけじゃない。それは偶発的な複雑さで、私は喜んで他の人に任せる。

└

まさに私の考えそのものだ。エージェントを使って自分のためにシンプルなプログラムを作るとき、私はやりたいことをすべて慎重に指示する。バックエンドのことについては、詳細なプレーンテキストの指示や仕様を何ページも書くことが多い。その後、修正してユーザーインターフェースをデザインする。最終的な成果物を楽しむし、自分のニーズに合ったプログラムをデザインするのも好きだけど、実装するのはあまり得意じゃない。集中するのが難しいから。

└

世界のほとんどの仕事の目的は「問題を解決すること」だよね。じゃあ、なぜソフトウェアを選んだの？

└

コーディングは手段であって… > 価値を加えないじゃあ、内在的な価値はどうなるの？HNのプログラマーたちは、心の底ではMBAになりたいだけのように見える。

└

「価値を加えない」っていう話には注意が必要だよ。それを論理的に追求すると、「存在は価値を加えない」って結論に至るから。

└

エディタやドットファイル、開発環境を設定することは、作業環境に慣れることで価値を加え、ツールのスキルを磨き、ニーズに合わせた生産的なスペースを作るのに役立つ。ビルドスクリプトを修正するための頼りにされる人になるのは誰だろう？数十年もGitを使っているのに、使い方が全く分からない人が結構いるのは驚きだよ。他の人にとっては、マージコンフリクトのクソを任されるのは役に立たないよね。彼らはツールについて何も学ぼうとしないから。

└

でも、それは価値を生まない。ビジネスマシンの歯車に自ら甘んじる人を見るのは悲しい。

└

問題を解決するために。コーディングは目的を達成する手段であって、目的そのものではない。プログラミングの目的は問題を解決することではなく、その結果として問題が解決される。

└

コーディングは目的を達成する手段であって、目的そのものではない。> それがあなたにとって楽しいかもしれないけど、価値を加えてるわけじゃない。あなたに反対してるわけじゃないけど、その発言は主観的であって客観的な真実ではない。多くの人は基本的にコーディングのプロセスを楽しんでいて、問題が残っていない仮想の世界やUBIがあっても、ずっと続けるだろう。

└

著者は「問題解決」やより良いツールについて、LLMがなんとなく違う感じがするっていう点でいいこと言ってると思う。Fortranはより良いツールだけど、コンパイラを通じてアセンブリコードに再現可能に戻すことができる。LLMは英語を何らかのコードに変換する非決定的なコンパイラみたいに感じるね。

この記事は本当に面白かった。LLMプログラミングについて、まさに私が感じていることと同じだ。プログラミングが大好きで、著者が言ったように、私の趣味なんだ。どこかで、仕事で趣味をやることができないのがちょっと残念に思ってる。今は根本的に違う何かになってしまった。

ありがとう、著者。このエッセイは私の一日を良くしてくれた。最近の私の考えに共鳴する。仕事でAIを使おうとしたけど、大抵は残念ながらAIがやったことを消して、自分でやり直してた。共感できるポイントがたくさんある。AIに考えることを任せるのは、私のキャリアにとって最悪のことだ。AIはせいぜい平凡なテキスト生成器だし、著者を攻撃する人たちがエッセイのメッセージと無関係な批判をするのが面白い。

└

僕にとって一番最悪なのは、実はLLMベースのコーディングが得意なこと。新しい世界に夢中な同僚たちは、完全にAIのクソを生み出して、タスクを終わらせるのに時間がかかっている。一方で、僕はソフトウェアアーキテクチャを知っているから、重要なコーナーケースを考慮するようにLLMに頼めるし、実際に強みを発揮できる。さらに、僕はコンテキスト管理が得意なんだ。神経多様性のおかげで、僕とは違う考え方をする存在と仕事をする練習を何十年もしてきた。LLMに対して機械的な共感があるのは、人間と混同しないから。だけど、同僚たちはLLMが自分の考えを読み取れないことにすごくイライラしている。とはいえ、LLMはどんどん良くなっている。僕のアドバンテージは長続きしないだろうし、AIのクソが増えれば増えるほど、コードベースのAIのクソに対処するためにLLMが必要になる。悪循環だね。誰もそのコードが何をしているのか分からなくなる。すぐに僕の仕事は機械の神々に祈ることだけになりそう。

正直に言うと、私は年を取っている。1995年にCorporate™のためにプログラミングを始めたとき、今とは全く違うキャリアだった。アサイラムを運営している狂人たちについて何を言おうとも、私たちはそのやり方が好きだった。エンジニアは自分の聴衆を知っていて、技術スタックを把握し、「業界」で何が起こっているかを理解していた。最終的には、彼らが主導権を握っていた。自分のコードは自分のプライベートな砂場だった。リリースごとに書き直したい？どうぞ。波括弧を新しい行に置きたい？TABを使いたい？（いいね！）どうぞ。それはあなたのコードで、あなたが所有している。壊したら、自分で直す。ユニットテストはなし（それをパラメータチェックと呼んでいた）。コードレビューもなし（正式なものはなかったけど、同僚のオフィスでアプローチを話し合ったり、APIをホワイトボードに書いたりしていた）。バグが見つかったり知られていたら、ただ直すだけだった。正式なプロセスが始まっていたかもしれないけど、狂人たちにとっては任意だった。管理側はどう感じていたか想像できるよね。基本的に開発者を信頼しなければならなかった。結局、管理側が勝ったけどね。もし私がAppleを辞めたことを後悔しているか聞かれたら、そうじゃないと答える。90年代のAppleで働いていたのは懐かしいけど、そのAppleは二度と戻ってこない。言いたくはないけど、業界自体も「カウボーイコーディング」の時代には戻らないと思う。それは楽しかったけどね。

└

100%同意。今はビジネスのクソ野郎と雰囲気コーダーのスクリプトキディばっかりだ。全てがクソになった。

└

僕も同じ頃に始めた。ユニットテストはなかったけど、ISO 9001の要件でコードレビューはあった。だから、差分をレーザープリンターで印刷して、3人を会議室に集めてそれを見てもらい、実際に変更にサインさせてた。これは、鋼鉄工場やオフショアの油田などで大きな産業制御を行うRTOSのためのものだった。プロジェクト管理は、40フィートのガントチャートをレーザープリンター用紙に印刷して壁に貼っていた。ウォーターフォールの甘い音。

└

ゲーム開発をやってみて。今でもそんな感じだよ。

└

それを言うのは嫌だけど、業界自体が「カウボーイコーディング」の時代には戻らないと思う。楽しかったけどね。業界が戻るとは思わないけど、カウボーイのための隔離された環境はあるかも。私がWhatsAppにいた時（2011-2019）、かなりカウボーイ寄りだったけど…今は違うと思う。私見だけど、適切さは本番前にエラーを検出するコストと、本番後に検出した時のコストによる。エラーを早く検出するより、修正コストを減らす方に重きを置いてる。一方で、恥ずかしいエラーを作らないようにはしてるから、テストすべきことはちゃんとテストするようにしてる。

└

2000年代後半に始めた頃は、キャリアパスや専門性がもっと明確だった。シスアドとプログラマーには違いがあった。今は、自分でシスアドやオペレーションをやりながら、機能も提供しなきゃいけない。遊びでシステムのスキルを磨いてたけど、仕事ではわざと避けてた。アメリカの企業の現実では、ベンダーのドキュメントやトレーニングがどれだけひどいか楽しめないから。

LLMのことはちょっと置いといて、僕が書くコードの中には、すごく丁寧に作り込んだものもあるんだ。自分が誇りに思える構造で、コードの一行一行に自信がある時だけコミットする感じ。全体を把握してるし、どんな決定にも理由がある。改善の余地がないってくらい完璧なコード。だけど、ほとんどのコードはそうじゃない。大体は何かを終わらせるために書くから、基準には全然届かないことが多い。でも、たまにそういう丁寧に書ける時があって、それがすごくやりがいがあるんだ。そういうコードを書くのが一番好き。LLMに戻るけど、あのモードでコードを書くのは、今まで以上に簡単で、今まで以上に難しいと感じる。心理的にそのモードに入っていられれば、望む結果を早く得られるし、基準も高くなるから簡単なんだ。でも、そのモードに入るのが今まで以上に難しい。LLMが生成したコードをサラッと流し読みするのは簡単で、見た目も良いし動くけど、実際は悪いコードなんだ。最初は少しだけ悪いかもしれないけど、どんどんひどくなっていく。時には最初からあまり良くないコードが出てきて、それを十分に注意せずに受け入れると、次の出力がさらに悪化する。気づいた時にはもう手遅れで、自分が汚してしまった上に、そのコードの専門家も育てられないってことになる。

└

最近2ヶ月の間にAIをもっと使い始めて、こんな感じの流れになった：1. 小さなことにだけAIを使って、すごく感心した 2. AIにもっと大きなタスクを与えて、上手く使う方法を見つけた 3. AIが自分のやりたいことをやって、最後にコードをレビューするフルエージェントモード 4. でも、結局は全てのコードを考え直さなきゃいけないことに気づいた。AIが思ってたほどのショートカットじゃないってこと（例えば、高レベルのプランを与えて、最終的なコードに満足できると思ってたのに） 5. またAIに小さなタスクを与えることに戻った。AIはリサーチや概念実証、"これが動くけど、本番では完全に受け入れられない"みたいな使い捨てコードにすごく役立つ。最終的な解決策に取り組む前にやる仕事だから。大きな視点でのコーディングは自分の手の中にあるけど、AIは関数のロジックを埋めたり、他の小さなことを手伝ったりするのが得意。

この作品、めっちゃ好きだった。ここでのコメントにも同意するけど、問題解決が焦点であって、コードそのものじゃないと思う。ただ、特定の深い思考を必要とする問題を解決する能力は、AIにその思考を任せることで時間と共に減っていくんじゃないかな。単に機能を求めるだけでは「問題解決」にはならないよね。

└

問題解決とクラフトの両方を楽しめると思うよ。もちろん、合理的な視点から見ると問題を解決することが重要だと同意する人もいるけど、彼らにとっては「楽しさ」が失われてる。一般的に、この記事が言うように「プログラマー」と自認する人たちは、問題解決やいじくり、ものづくりを楽しむ人たちだと思う。

僕にとって、一番重要なポイントはこれだと思う：> コードレビューをしている同僚たちは、今や品質管理の最初の層になってしまったことに気づいて、どんどん頭がおかしくなってきている。レビューを頼まれ、細かく分析することを強いられている。呼ばれてもいない関数や、幻のライブラリ追加、明らかなランタイムエラーやコンパイルエラーを指摘している。その間に、著者は「自分の」コードをサラッとしか見ていないのに、責任を取らずに「おっと、クロードが書いたんだ。バカなAI、ハハ」って感じ。LLMはブランドリーニの法則（「クソを反論するのに必要なエネルギーは、それを生み出すのに必要なエネルギーの桁違いに大きい」）を、もしかしたら過小評価させている。経験のない開発者が数分で何千行ものコードを生成できるようになると、システムを正しく保つ責任は、まだ人間の知性で推論できるレビュアーに移ってしまう。リトマス試験として、PRの追加/削除の行数の差を見てみて。LLMが書いたものはほとんどが追加されているけど、良いシニアエンジニアは追加する分と同じくらいのコードを削除することが多い。

└

良いシニアエンジニアは追加する分と同じくらいのコードを削除することが多い https://www.folklore.org/Negative_2000_Lines_Of_Code.html

└

個人的には、これは技術的な問題だと見られがちだけど、実際には人の問題だと思う。誰かが一度やらかすと、厳しいメッセージが来る。二度目があると、拒否されてマネージャーに送られる。プルリクエストをどう書こうが、最終的には自分の名前でサインしてるわけだから。もしそれがゴミみたいなものであれば、責任は自分にある。

└

問題は、クソみたいなことを指摘しながらも、ある程度は協調性を保たなきゃいけないことだと思う。「自分の」コードを明らかにざっと見ただけの著者が、責任を取らずに「おっと、クロードが書いたんだ。バカなAI、ハハ。」って言ってるなら、問題はすぐに消えるだろう。だから、あなたが指摘した問題は、むしろ社会的なものであって、LLM自体の問題ではない（とはいえ、彼らがしばしばクソみたいなコードを生成するのは事実だけど）。

└

今、バイブコーディングされた2つ目のプロジェクトに取り組んでるんだけど、動くとしても、どのREADMEを使うべきか分からないのがイライラする。たいてい冗長で、「Pythonの仮想環境をどうやって動かすか」とかが含まれてるし。

└

著者は明らかに自分の「コード」をざっと見ただけで責任を取らず、「おっと、クラウドが書いたんだ。バカなAI、ハハ。」って感じ。大きなチームでコードレビューはもうやらないけど、もしやっててこんなことがあったら、一度だけ許すかな。それ以外は、その人をクビにしようとするだろうね。それが無理なら、たぶん辞めると思う。ひどい経験になりそうだし。

└

選択肢は二つあるよ：すべてのくだらないコードを直そうとして燃え尽きるか、もしくは… コードの質なんて気にせず、給料もらいながら幸せに生きるか。まともな選択肢はカルトに入ることだね。すべてのプルリクエストを受け入れちゃいなよ。どうせGit blameには自分の名前は出ないし。CEOがAIを使えって言うなら、AIにレビューさせればもっといいよ。

└

なんか、10年前にジュニア開発者だった頃にこの段階を先取りした気がする。毎日、コードをガンガン書いて壊しまくるシニア開発者の仕事をレビューして、オフショアチームのプルリクエストに数十件のコメントを残してた。昼過ぎにはもう十分だったな。数年前にその会社を辞めてからは、無敵になったよ。もうLLMなんかに怖がらされない！

└

著者は明らかに自分の「コード」をざっと見ただけで責任を取らず、「おっと、クラウドが書いたんだ。バカなAI、ハハ。」って感じ。クソみたいなコードをレビューに出して同僚を怒らせた後は、ちゃんと注意を払うようになる。> LLMが書いたコードはほとんど追加的なもので、削除しなきゃいけないコードに気づかない限り、LLMに指示しないといけない。LLMがここでダイナミクスを本当に変えるとは思えない。「良いプログラマー」は、LLMの助けがあろうとなかろうと、同僚がレビューしやすい良いコードを提出するだろう。

└

LLMが書いたものはほとんどが追加的だね。Claudeがコードを削除するのにすごく消極的で、間違ってるって言ったコードでも消さないのに気づいたよ。例えば、こんな感じでfn: fn foo(bar)って出力するんだけど、いや、実際には「foo with a frobnitz」って言いたかったのに、結局こうなるんだよね。fn foo(bar) // 呼ばれない fn foo_with_frobnitz(bar)

└

これはLLMが関わるときの責任の所在についての広い問題だね。人間は正しいときはその成果を真似て自分の手柄にし、間違ってるときは責任を回避したがるみたい。数件の適切な訴訟があれば、このパラダイムは変わると思うよ。

人々がなぜAIチャットボットをこんなに簡単に信じているのかについての研究を読みたいな。私たちは権威ある専門家に対して、a) 迅速で b) 幅広い回答を期待する。ラジオ番組を聞いていて、「ドクター・ソー・エヌ・ソー」みたいな専門家が登場する時のように。彼らは「わからない、調べてから戻る」って言わないから、知識があるように見えるし、関連する検証を幅広く共有できる。LLMはこの体験を模倣して、広めで自信のある回答をすぐに提供する。私たちは人生の多くの経験から、こういった回答を信じるように訓練されてきたんだ。

確かに、これはコーディングのための高次の言語だね。Fortranほど正確ではないけど、可能性はずっと大きい。孤独の中で完璧に手書きした聖書の喜びを奪った印刷機を嘆く僧侶たちの姿が想像できるよ。

LLMはソフトウェアの複雑さに対する「軌道から核攻撃する」解決策のように見える。実際の問題に対処するのではなく、症状を治すためにもっと複雑で曖昧なものに手を伸ばしてしまった。著者はここでAIの核心的な動機を見落としてるね。AIを設計する会社に高スキルで高コストの「クリエイティブ」な労働者を集中させることで、他のビジネスはクリエイティブな労働者を解雇して、指示されたことをする産業の歯車に戻れるってことなんだ。企業が複雑で曖昧なものに手を伸ばしているわけじゃなくて、「AIを使えば複雑で曖昧なクリエイティブな労働者を排除できる」って言われているのが実情なんだ。これはほとんど全てのビジネスの複雑さを大幅に減少させることになる。古典的な物語「オズの魔法使い」の言葉で言うと、誰もカーテンの裏を見ようとしない。なぜなら、彼らにとって全てが楽だから。人間も企業も共通しているのは、誰かがその代償を払う限り、短期的な改善のために長期的な懸念を無視する意欲があるってことだね。

ハクソク