LLMの時代にプログラミングを楽しみ続ける方法

2026年9月26日原文(discourse.haskell.org)

概要

AIやLLM（大規模言語モデル）による開発現場の変化に対する不安や課題の整理
楽しみながらプログラミングを続けるための具体的なワークフロー提案
LLMの活用範囲と人間の役割のバランス
精神的・社会的な側面の重要性の強調
LLM活用時の注意点や持続的なスキル維持の方法

LLM時代の開発者としての生き方

AIバーンアウト や、 低スキルな他者やLLMに仕事を奪われる不安 の増加
コード品質の低下 や、「自分の」コードへの失望感の広がり
倫理的な問題は本稿の主題外
Haskell など好きな言語で「書く楽しさ」を感じる開発者の存在
LLMによるコード生成で 楽しさが減少 するリスク

コードを書くことの意義

コードベースの主導権維持 には、自分で書き続ける必要
スキル維持 のためにも、手を動かす習慣の継続が重要
LLM生成コードは 人間にとって読みにくく、保守が困難
生産性向上は「コード生成」ではなく、「周辺業務の自動化」で実現

LLMの効果的な活用方法

計画立案や情報整理 など、「退屈な作業」をLLMに任せる
- 例：会話記録から TODOリスト作成、テスト結果の整理
- 重要な意思決定は人間が担当
リサーチ業務 もLLMと並行して自分でも行う
- LLMの調査結果は 必ず根拠や出典を明記 させる
- 最終判断は自分 で行う

人間が「コーダー」であるべき理由

「計画は一緒に立て、 実装は自分で行う」ワークフローの推奨
LLMには コードベースの調査・TODO提示・注意点の指摘 などを依頼
全体像の把握や計画の質向上、スキル維持に効果
自分の得意な働き方 を中心にエージェント（LLM）を活用

コーディングエージェントの適切な使い方

リファクタリングや単純作業、ルーチンワークに限定
- 例：FIXMEの解消、類似ケースの追加、モジュール整理
複雑な設計や重要な部分は自分で実装
LLMの「コピペ的」生成に注意し、 抽象化や設計力を意識

レビューサイクルの重要性

自動レビューエージェント による成果物の品質担保
LLM生成物は 必ずレビュー を通す
自分のコードもレビュー してもらうことで、バグや抜け漏れの早期発見

フロンティアモデルへの依存リスク

環境負荷や信頼性の問題、ブラックボックス化の懸念
自分が責任を持てる範囲でLLMを活用
小規模モデルやオープンソースモデル への移行性を意識

トークン切れ問題への備え

トークン不足による作業停止 のリスク
「自分のせい」ではなく「サービスの問題」と認識
オフラインでも進められるTODOリスト の確保が重要

LLM生成テキストへの注意

LLM特有の「意味不明な文章」 は精神衛生上有害
人間同士のコミュニケーション を重視
LLM生成物は 自動レビュー後のみ読む、疲れたら休憩

プログラミングは社会的活動

PRやコミットメッセージなどの人間同士のやり取り を大切に
完全自動生成のPRは避ける
LLM生成文は ツール出力として添付 し、主文は自分で記述

持続可能な開発スタイルの提案

LLMを「 有機肥料」的に活用し、 無理なく生産性向上
好きな言語での開発 を続けるための知恵と工夫
楽しさと生産性の両立 を目指す持続的なワークフロー

Hackerたちの意見

プログラミング中にLLMを使うのは全然気にしないよ。少なくとも俺の使い方だと、自分の経験や知識、センスが活かされてる感じがするから、適当にやるよりも良い結果が出ると思う。ただ、同僚たちの使い方にはちょっとイライラしてる。肉の代理と話すのは楽しくないし、間違った問題を解決するような巨大なPRが来るのも嫌だ。半分の人が頭をオフにしてるみたい。早く作れるけど、正しいものは作れてないんだよね。

└

俺も同じ感じだよ。昇進した気がするけど、自分の効率的なチームを管理することになって、すごくマイクロマネジメントが必要なんだ。経験がない人が作ったものを見たことがあるけど、俺は自分のビジョンをもっと早く実現できると思うし、小さな機能を実装するのにどれだけ時間がかかるかに悩まされることもない。正直、プログラミング自体を楽しんでたわけじゃないから、最終的に何が得られるかが大事だったんだよね。

└

半分の人が頭をオフにしてるみたい。 LLMは頭をオフにしたい人のためのものだよ。チームを改善したいなら、自分が模範を示してLLMの使用をやめるべきだ。頭をオフにするのが許されない環境を作らないと。部下たちは、君が望むようにLLMツールを使うことは絶対にないよ。LLMツールは、部下たちが使うように設計されてるんだから。

└

早く作れるけど、正しいものは作れてない。俺も同じだよ… 悪い決断をして、次のPRでその悪い決断を回避するための修正をして、また次のPRでその初めの悪い決断と修正を扱わなきゃいけなくなる… その繰り返しだよ。どこかの時点で、変更を手動でレビューするのが不可能になって、すべての修正や特別なケースを頭に入れながら考えなきゃいけなくなる。

└

少なくとも自分が使う方法では、自分の経験や知識、センスが活かされてる気がする。 > 逆に楽しめなくなったのは、同僚の使い方に悩まされるからだね。

最近（2日前）、超高速で推論が少ないモデル（gpt 6 luna low effort + fast mode）を使うと、すごく楽しめることに気づいた。そうすれば、ずっと手を動かしていられるし、20分も待たずに済むし、その間に勝手に決定が進んじゃうこともない。LLMは超高速で読むのが得意だから、コードの要約や再表現にも最適だよね。

└

それいいアイデアだね、俺も試してみる！LLMはすごく能力が高いけど、遅いのがイライラする。いつもいくつかのことを同時にやって、出力を何度も読み返したり、新しい指示を出したり、次の5分間はLLMが動いてる間にRedditやHN、YouTubeを見たりしてる。

└

ああ、そうだね。2月にこれに気づいたんだ。早くて安い方がいいよ、だって早いと集中できるから。忙しいマルチタスクはバカのやることだよ。

└

GPT 6 Lunaには悪い経験があったけど、5.6 LunaはReactとかでうまく動いたよ。やり取りをしながら進められるから、まるでチームメイトみたいで、ただ「できた！」って言って後で全部片付ける必要がないんだ。

└

そうだね、俺もそのことに気づいたよ。あの古典的な中断の漫画の逆みたいな感じだね。待ってると、文脈を失っちゃうんだよね。

LLMの使用は避けてる。お金をもらって働いてるときはそうもいかないかもしれないけど、暇な時間にはできるし、そうしないとプログラミング言語で考える能力が徐々に失われていくよ。これは他の認知スキルにも当てはまる：音楽を書くことや楽器を演奏すること、外国語を話したり読むこと、難解なクロスワードを解くこと、チェスや囲碁をすることなど。コンピュータがチェスを上手にできるようになったからって、プレイをやめるわけじゃないよね。大事なのは、自分で学んで、理解して、やることだよ。俺がやったことに基づいてアドバイスするなら、LLMを使わずに自分でプログラミング言語をゼロから実装して、それでプログラムを書いてみて。実装やその中で書いたコードは公開しない方がいいよ。俺の家でのプログラミングのほとんどは、自分がデザインして書いたLisp方言でやってる。Common Lispに似てるけど、微妙な違いがあって、いくつかの欠陥を回避しなきゃいけない。自分のLisp方言では、視覚的データフロー言語も実装した。コードサンプルはウェブサイトにあるけど、PNG画像だからLLMからは安全だと思う。言語はMIMDハードウェアで動くように設計されてるけど、実際には存在しないんだ。エディンバラ構文を使わないPrologも実装して、型チェックや制御された英語の実装のパースに使ってる。だから、LLMを使う誘惑や選択肢はなかった。これをやってる間に、LLMを使ってたら得られなかった多くのことを学んだよ。

└

これすごいけど、コードサンプルがPNG画像にあるからって、LLMから安全ってわけじゃないんだよね。今のLLMは画像からテキストを読むのがめっちゃ得意だから。

Hacker Newsで議論の続きを見る

ハクソク