ハクソク

世界を動かす技術を、日本語で。

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

2025年10月22日原文(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はせいぜい平凡なテキスト生成器だし、著者を攻撃する人たちがエッセイのメッセージと無関係な批判をするのが面白い。

Hacker Newsで議論の続きを見る