2026/09/26 18:41
LLM が支配する世界でプログラミングを楽しみ続ける方法
RSS: https://news.ycombinator.com/rss
要約▶
要約：
著者は、この投稿は 100% ヒトが執筆したものであり、倫理的な懸念、環境コスト、不透明な企業の支配（「テクノフイオダリズムの領主」）などの理由から、大手テック企業による最先端の大規模言語モデル（LLM）への依存を拒否していると明確に述べている。同氏は、所有権を維持し、スキルの低下を防ぎ、「LLM の砂漠」を生み出すことを避けるために、個人がコードを書き、検証する人間中心の開発ワークフローを提唱している。LLM は計画、研究のログ記録、クリーンアップタスク（例えばリファクタリング）、エージェント専用作業には有用かもしれないが、実際のソリューションの実行や Pull Request の説明のような社会的コミュニケーションアサートを作成させることには非推奨である。
推奨されるワークフローは、コーディングプロセスを人間が主導し、AI は付随的な仕事にのみ使用することであり、具体的にはエージェントで計画を立てつつもコードの実行は自身で行い、「まず計画し、その後にエージェントにコーディングさせる」というパターンを拒否すべきである。また、サービス障害時にシステムが存続するように、オフラインで実在するアサートを作成するワークフローを設計する必要があり、トークンの枯渇をユーザーの誤りではなくインフラ_FAILURE と扱うべきである。この持続可能な方法を導入した採用者は、AI に完全に依存している者（「バイブコーダー」）と比べてはるかに生産的であると報告しており（最大で 2 倍のスピード向上）、かつ単純な出力速度よりもメンタルウェルビーイングを優先している。
本文
LLM 時代における開発者のための持続可能なワークフロー
記事の主旨と免責事項
- ターゲット層: コード品質へのこだわりがある方、AI 生成コードに失望している方、あるいはそのリスクを懸念する方。
- 本稿の目的: 巨大言語モデル（LLM）の倫理的懸念を議論するものではなく、プログラミングの喜びを維持しつつ生産性を高めるための実践的な方法論です。
- 執筆声明: この記事は AI に生成されず、100% 人間によって書かれています。
巨大機械の中の魂：現状の課題
ソフトウェア開発における役割の変化について再考する必要があります。
- 役割の低下: 我々の役割は「創造的演者」から「機械の歯車」へと変化しています。
- ディストピア的状況:
- 仕様のみを与えられ、それを LLM に叩き込むことだけが残ります。
- 「トークン不足」と嘆くだけの受動的な立場になります。
- 言語への愛: ハスキー（Haskell）など、言語そのものの思考プロセスを楽しむ開発者は、LLM の介入によりその楽しさが失われる懸念があります。
- 生産性の罠: 見かけ上の生産性向上によって、本来の「コードを書く楽しみ」を奪ってはいけません。
重要: LLM を一切使わない（Abstinent）選択も素晴らしい選択肢です。しかし、環境やチーム事情により使用が必要な場合は、以下の戦略が推奨されます。
コード書き込みを続けるべき理由
コードベースを自分のものであるなら、必ずコードを書き続けてください。
- 「不毛の地」になるリスク: 全てを生成に委ねると、コーディングエージェントだけが存続するだけの無機質な環境に変わります。
- スキルの維持:
- 技能は練習しなくなると失われます。
- エージェント任せになると、短期間でもコーディング能力の低下（閾値）が起きやすく、戻ることが困難になります。
- 完全自動生成の限界:
- LLM は「人間が読みやすいコード」を完全に自動生成することはできません。
- 「バグだらけで原因不明な完全自動生成ファイル」に直面した絶望感から解放されるためにも、自分自身で書くべきです。
生産性向上へのアプローチ
- ** coding（コーディング）以外のタスク**: メンドくさい退屈な作業や調査はエージェントに任せます。
- 理想の範囲: 正しく実装しやすく、検証も簡単なタスクに限って自動化します。
計画（プランニング）のプロセス
LLM を**「自然言語でアクセスできる便利な簿記ツール」**として利用しましょう。
LLM の有効活用
- タスクリストの生成: ドメインエキスパート間の会話記録から実行可能な TODO リストへ変換。
- テストと修正方針: テスト結果の記録、欠陥修正方針の整理を自動化。
- ツール活用: TODO ツールや Markdown ファイル（Frontmatter 付き）で計画項目を管理。
重要な意思決定は人間が担う
- 判断力の委譲禁止: 「何か決める」という問いかけ自体も LLM に指示させず、最終判断は人間が行います。
- コンテキスト不足への対処:
- LLM が理解できない場合、関連文脈を提供できなかったか、あるいは人間が疲れている可能性があります。
- 同じ問題に迷った場合は、画面から離れて独想し、明確な方針を策定してから再び取り組むべきです。
調査・リサーチの実践法
エージェントに調査タスクを依頼する際、以下の点を意識してください。
- 最も賢明な選択: コーヒーを淹れること（休憩）。
- 並行作業: エージェントだけでなく、自分自身で検索エンジンを使って調査を行う。少なくともエージェントが知る範囲の内容は把握しておきましょう。
- 技術的負債の防止:
- 「調査結果を受け入れ、事実として扱う」だけでは恥しいほど技術的負債になります。
- ドメインについてエージェントよりも深い理解を持つ必要があります。
検証のための指示
- 資料の参照: エージェントに利用したリソースへのリンクを添えて書き留ませてください。
- 根拠の確認: 変な提案が出た際、「どの資料のどこにその記述がありますか？」と問いかけ、50% の確率で過ちを発見します。
- 最終判断: 残り 50% は自分自身で読み込み、良い意思決定を下す立場になります。
あなたこそが開発者（The Coder）：ゲームチェンジャーなワークフロー
典型的な誘惑は「先に計画し、その後エージェントにコード生成を任せる」ことですが、これを拒否してください。
推奨ワークフロー
- 一緒に計画する。
- あなたがコードを書く。
- LLM の活用:
- コードベースの研究。
- 現在の TODO リストの提示。
- 編集が必要な箇所のリストアップ。
- 潜在的な落とし穴や背景調査のリマインド。
このワークフローの利点
- 楽しみの維持: プログラミングが好きであれば、それを続けられます（仕事を楽しめます）。
- コードベースの可視化:
- 「vibe coding」による奇妙な生成物への驚きを防ぎます。
- LLM による粗悪コード（Slop）への書き換えや、セッション中の位置付けの喪失を防ぎます。
- 早期発見: 悪い計画やアイデアをコーディング開始前に発見できます。
- スキル向上: 良いプログラマーとしての資質を維持・向上させられます。
エージェントの位置づけ
- 適応する方向: エージェントを「あなたの作業方法」に適応させましょう。逆に自分がエージェントに合わせて適応するのはやめましょう。
- 担当範囲: 嫌いな incidental な（付随的な）作業を任せておけば十分です。
コーディングエージェントが役立つ稀なケース
以下のユースケースにおいてのみ、エージェントの活用が効果的です。
- クリーンアップ作業: リファクタリング、ルーターンワーク。
- リスクの低い改善:
の解決、モジュール再編案の実装。FIXME - 代替品への置き換え: メンテナンスされていないライブラリをより優れたものに置換。
- 緊急時の仕上げ: 監督エージェント（Supervisor Agent）に「I'm afk, finish this」と指示し、翌朝に完了した機能を引き取る。
注意すべき落とし穴
- 抽象化の欠如: 「残り 7 つは派生なので完了してください」と指示しても、LLM は型クラスのインスタンス生成などを理解せず、膨大なコードをコピーしてしまいます。人間としての目標はより読みやすい合理的なコードを目指すことです。
- 結合（Couplings）への依存: LLM に「全ての落とし穴を見つける」ように頼るのではなく、コードベースが悪く組織化されていないかを検討すべきです。
検証サイクル（Review Cycle）の重要性
AI 画像生成のように、「ジェネレーター」と「判別器」が協力して良い結果を生むという考え方を適用します。
- 原則: LLM が生成したアーティファクトをそのまま受け入れず、必ずレビューする。
- 計画段階でも同様: 論理的な穴（例：TODO の整合性）を見つけるのは疲れますが、それを検出するための「レビューエージェント」を追加すべきです。
- 人間によるレビューの活用:
- 些細な指摘（Nits）から真のバグまで発見できます。
- 回避策として、「細かい指摘は自分で修正してください」と指示する方法もあります。
フロンティアモデルについて：過大評価に注意
ネット上の「vibe coder」がフロンティアモデルを推奨するのは、論理的帰結ですが、依存すべきではありません。
- 環境コスト: 膨大なエネルギーを使用（推測に基づく不透明な情報）。
- 責任の所在:
- より賢いふりをされたものへの信頼は困難。
- 生成したコードに対する責任は常に人間にあります。機械に責任を押し付けるのは馬鹿げています。
- リソース効率: 最も洗練されたモデルはトークンを最も消費するため、セッション内で完遂できないリスクがあります。
- 将来性: ワークフローで必要ない場合、オープンソースモデルへの置き換えとテック封建領主からの解放のチャンスになります。
結論: LLM に膝を曲げるには遠く及ばず、以下を満たすまで代替することはできません。
- 人間開発者よりもはるかに優れた能力を持ち、
- リソース消費が少なく、
- 複雑な状況においてより信頼性が高く、
- アライメント（目標整合性）があり、
- 結果に対して責任を持てること。
トークン枯渇への対処法
トークンを使い果たして仕事が止まるのは「サービス障害」と捉え直しましょう。
- マインドセットの変化:
- 「買い過ぎ」ではなく、「技術的故障」または「計画不能な変数」として対応。
- LLM 企業はトークン利用の約束を果たしていないため、リスク管理が必要です。
- 準備事項:
- トークンの節約（セットアップ、コンテキストサイズの最適化）を徹底。
- それでも不足する場合は、「技術的な故障」と捉え、オフラインでも作業できるように大きなアセットをキャッシュしておく。
- 常に動作可能な TODO リストを持ち、速く駆け抜ける楽しみを楽しみ、完了後にクリーニング作業を行わせる。
LLM ゴブリン（無意味な文章）と精神衛生
LLM が生成したテキストは人間のそれとは異なり、過度に摂取すると精神的健康に有害です。
- 摂取制限: 無意味な文章を避け、特に大きなビジョンや興味深い話題については人と話しましょう。
- 読みの対象: エージェントが「端（edges）」を削った後のアーティファクトのみを読み、完全に自動化されたレビューの結果だけを鵜呑みにしない。
- 休むこと: 頭が回らなければすぐに休憩を取りましょう。「価値を生産している」と思っている間でも同様です。
仲間の人々：コミュニケーションの重要性
プログラミングは基本的に社会的な営みです。
- コミュニケーションの本質:
- PR や Issue の作成は、他者との対話であり、過去の自分自身への手紙でもあります。
- 人間との対話がソフトウェア開発の柱です。
- 注意点: 完全に生成された PR を他人に送りつけることは避けましょう（過去に失敗例あり）。
- エージェントの役割:
- エージェントは文法が正しい PR ボディを作成できますが、それは「コミュニケーション」ではありません。
- ツールの出力として扱い、自分で書かれた文章で補足し、必要なら
タグなどで管理してください。<details>
私の旅路：結論と展望
以上のワークフローにより、私は LLM 支援なしよりも生産性を向上させました（倍近く）。
- 持続可能性: 「vibe coder」が畑に工業化学薬品を垂れ流すようなものに対し、私の方法はより持続可能と考えられます。
- 夢の実現: ハスキーでの生計を立てるという夢は、LLM に頼らずとも実現可能です。
- 核心: ここに書いた全ては、プログラミングを楽しみ続けるために学んだことです。それは機能しています。