ハクソク

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

人間の介在者は疲れている

2026年7月17日原文(pydantic.dev)

概要

  • LLM（大規模言語モデル）を活用したプログラミング は便利でありながら、開発者に新たな負担や不安定さをもたらす現状
  • Pydanticチームの現場視点 から、AIツール時代の開発者体験を率直に記述
  • 人間の報酬系（reward function）問題 や孤独感、仕事の満足度低下について提起
  • 従来のスキルや専門性の進化、新たに求められる能力について考察
  • AI時代の開発現場で何が生き残るか、そして今後の方向性について提言

LLM時代のプログラミングがもたらす現実

  • LLMを使った開発 は「便利さ」と「不安定さ」が共存する現状
  • 課題を無視すれば燃え尽き症候群 に陥る危険性
  • Pydantic では、開発者向けに信頼性向上ツールを開発しつつ、自らも「奇妙な体験」を実感
  • AIがプログラマーを置き換えるか否か という議論ではなく、現場の率直な声を重視
  • 現場のエンジニアとしての実感 と、役立つかもしれない考え方の共有

創造の原体験とAI時代の違和感

  • コーディング初学時の「宇宙の布に手を入れる感覚」 という創造的な快感
  • 自己流で獲得したソフトウェア工学の原則 は「教科書」ではなく「傷跡」として身につく
  • 低コード・ノーコードツールの約束 は過去にもあったが、今回は現実とのギャップが劇的に縮小
  • 現実が追いついたことで逆に不安定さが増幅

「コードが自動で書かれる」時代の本音

  • AIによるコード生成の監督・レビュー作業 が増加し、従来よりも疲労感が強い
  • Pydanticの同僚Douweの体験 ：毎朝AIが生成したPRを大量にレビューしなければならない現実
  • AIにレビュー自体を任せる誘惑 と「自分は何のためにここにいるのか？」という自己疑問
  • 計画をAIに実行させるための指示書作成 に多大な時間を費やすも、意図が伝わらず不合理な出力が多発
  • 「監督者疲労」 ：AIの出力を監視し続けることで生まれる新しい疲弊

報酬系の崩壊と孤独感

  • 従来のコーディング は「理解」「解決」「コンパイル成功」など小さな達成感が連続
  • AI支援で満足感が減り、監督・修正の負荷だけが増大
  • 人間の報酬系（reward function）が壊れている と認識すべき段階
  • LLMとのペアプログラミングは極めて孤独な作業 であり、チームのコミュニケーションが希薄化
  • 成果物の質に対する責任感や満足感が薄れがち

作業強度の罠と並列化の限界

  • AI活用で作業開始件数は激増 するが、完了件数は「人間の脳」というボトルネックで変わらず
  • 「もう一つだけプロンプトを…」という終わらない作業ループ
  • 並列処理の誘惑 と「本質的な進捗は脳のキャパシティで決まる」現実

スキルシフトと専門性の蒸留

  • 「味」「ニュアンス」「成熟した設計判断」などの人間的スキルが差別化要素に
  • LLMをうまく活用できる領域は、自分自身が深く理解している分野
  • 自分の専門外ではAIの出力も質が下がる傾向
  • 過去のコードレビューコメントからルールを抽出し、LLMに継承させる新たな知的作業
  • 専門性が「死ぬ」のではなく「蒸留」される

進化するエンジニア像と今後の展望

  • AI活用時代でもエンジニアリングの本質は変わらず
  • 本当に希少なのは「人間の注意力」「設計判断力」「システム全体を俯瞰する力」
  • AI自動化で「コードを書くこと自体」は難しくなくなったが、「良いコードとは何か」を判断する能力が重要に
  • 「置いていかれる恐怖」や「スキルの陳腐化」への不安は現実的
  • 今感じている不安や不満は個人の問題ではなく、現場全体の構造的な課題
  • Pydantic開発チーム自身も「新しい報酬系」の模索中

まとめ：LLM時代の開発現場に必要なもの

  • 変化を受け入れつつも、コアスキルを見極める成熟した姿勢
  • AIとの協調における「人間らしい判断力」と「新しいワークフロー」への適応力
  • 孤独感や達成感の減少を解消する「新しい報酬系」設計の必要性
  • 現場のリアルな声を共有し合い、共感しながら進むコミュニティ文化
  • 「エンジニアの終焉」ではなく、「進化の途上」だという前向きな視点

Hackerたちの意見

投稿の要点には感謝して同意するけど、Claudeの文体があちこちに出てるのが気になるな。誰かのAIが書いた記事を読むのは、やっぱり疲れるよね。

└

これはAIだとは思わないけど、企業スタイルに合わせるために編集やレビューを経てるんじゃないかな。LLMはそういうのを学習してるし。

└

「書く気がないなら、読む気もない。」

└

「そうじゃない」 - 3つのマッチがDashline - 現在、はい、これはAIが書いたものだね。

└

ほとんどAIが書いたと思うけど、平均的なAIの記事よりも人間の介入が多かったから、いつもほど気にならなかったな。

OPとは違って、私はClaudeを使って仕事や自分のプロジェクトで素晴らしい時間を過ごしてるから、私にうまくいったことをシェアするね。他の人にも響くかもしれないし。私の経験から言うと、「エージェント」の誘惑を避けて、LLMをコード生成器として扱うのがいいと思う。一度に一つのセッションを実行して、計画を立てて、それを満足いくまで繰り返す。そして、その計画を実行するように指示して、様子を見守る。スクロールを読むほどではないけど（時々はやるけどね！）、各ステップが終わるたびに何をしたか見直して、改善点や修正点を提案して、次のステップに進ませる。そうすれば、コードの状態をかなり把握できるし、全体の時間も大量のコードを一気に書いてチェックするよりは長くならないよ。もしワンショットのワークフローに近いものが欲しいなら、計画段階でより詳細に進めて、アーキテクチャの詳細だけでなく実際のコードも説明させるといいよ（特にシニアエンジニアなら、他の決定に大きく影響する重要なコードの部分が何か分かると思う）。それに、リファクタリングは以前よりもずっと安くなってるから、もし何かが理解しづらいと感じたら、止まってLLMと一緒に作業して、見た目が良くなるまで調整すればいい。要するに、一つのLLMが一度に一つのことをやるようにして、そのプロセスに関与し続けるのが大事だよ。

└

私もそう思う。Vibeコーディング（たくさんのループがあっても）は、アシスタントのように使って出力に近づくよりも、燃え尽きやすいと思う。

└

これに同意する。俺もClaudeと接する時は同じようにしてる。最初に詳しく話し合って、それから実行する感じ。最初はガイドとして足場を使うのもありかもね。このプロセスを「Claudeの禅」として書き留めておいたんだ。https://github.com/ctomkow/claude/blob/main/README.md 最近、レガシーコードを新しいアーキテクチャにリファクタリングするのがうまくいくようになった。ずっと後回しにしてた仕事なんだけど。編集：Claudeと一緒に作業するのに数ヶ月かかったけど、これがうまくいくプロセスにたどり着いたよ。Claudeに自由に動かせると、避けられない混乱や苦労が出てきて、ストレスがたまるからね。手動コーディングをしたい時は自分でやって、もう手動コーディングがうんざりになったらClaudeに任せると、コードベースをコントロールしてる感覚が保てるよ。

└

残念ながら、段階的なアプローチは他のユーザーによるレビューのステップでは役に立たない。彼らはまだそれを一括で受け取って、新しい目で見なきゃいけないから。

└

俺は2つの作業ストリームの間を行ったり来たりできるけど、それ以上になると脳がコンテキストスイッチで疲れちゃう。

└

すごく理にかなってるね。俺も似たようなことをやってるよ。エディタとは完全に別のチャットがあって、必要なコードの部分だけを貼り付けて、考慮すべき制約やアイデアを追加するんだ。満足したら、コードをエディタに戻して、名前を変えたり、さらに改善したりすることもある。時には、もう明確な場合や楽しそうな時は自分でコードを書くこともある。自分でやることが大事だと思うし、プロジェクトに対するつながりを感じたり、深い理解を得たりするために、時々は自分でやることが重要だと思ってる。

└

別のアプローチでも素晴らしい時間を過ごしてるよ。モバイルアプリのために大量のコードを生み出してる。大変だけど、コンテキストの切り替えは簡単じゃない。3〜5の会話を追いかけたり、デバイスに何をデプロイしたか、何をテストする必要があるか、どんなフィードバックを提供しなきゃいけないかを覚えておくのは大変だよ。でも、終わった時には結果に誇りを感じて、何かを達成した気分になる。一般的な考えとは逆に、vibecodeはまだまだ大変な作業だよ。たくさんのQA作業、UXの決定、デバッグや調整、アーキテクチャの懸念を考慮すること、リファクタリングすべきかどうかを考えることもある。コードは基本的に自動で書かれるけど、アプリは自動で作られるわけじゃない。ビジネスや市場調査、App Store最適化も忘れちゃいけないしね。

Hacker Newsで議論の続きを見る