絶滅したと言いたいのではありませんか？

2026年7月13日原文(fabiensanglard.net)

概要

Jurassic Park の制作現場で起きた技術革新と、 CGI導入による職業的危機感 のエピソードを紹介。 プログラマー やクリエイターが時代の波にどう適応すべきかを論じる。 LLM（大規模言語モデル） 時代の学び方・働き方・コード品質への向き合い方を解説。 コードレビューやテストの重要性、小規模チームによる開発の可能性も取り上げる。変化に対する モチベーション維持 と、進化し続けることの重要性を強調。

ジュラシック・パークと技術革新の衝撃

1993年公開の Jurassic Park が CGIの映画利用を革命化
Steven Spielberg 監督は当初、 Phil Tippett のゴーモーション技術を採用予定
ILM（Industrial Light & Magic） の Dennis Muren らが、 CGIによる恐竜のリアルな表現 に成功
Tippettは「 絶滅した気分だ」と語り、従来技術の終焉を痛感
30人規模のチームを率いていたTippettは、 大きなショック を受ける

プログラマーと「絶滅」への不安

AIや新技術の台頭 で、 プログラマーにも強い不安感 が広がる
「 時代の波に乗ること＝進化」が生き残るための鍵
Hacker Newsのzkmon の意見：「新しい波に乗り続けること、学び続けることが重要」
各世代ごとにプログラマーは進化を経験、変化は恒常的
LLM（大規模言語モデル） も新たなツールとして受け入れ、学ぶ姿勢が必要

LLM時代の学び方・働き方

Andrej Karpathy のYouTubeチャンネルがLLM学習に最適
書籍「 Build a Large Language Model (From Scratch)」もおすすめ
コードを書く際、LLMの活用が標準化、使わない人は生産性で遅れを取る
John Carmack の見解：コーディング自体より 問題解決力 が本質的価値
LLM活用で大量のコード生成が可能 だが、品質維持のための工夫が必須
- コード品質維持のための自己ルール をGEMINI.mdやCLAUDE.mdにまとめる
- 例：マジックナンバー禁止、インデント削減、enum活用、レイヤー分離、論理ブロック間の空行追加など
複数プロジェクト同時進行による「コンテキストスイッチ」疲労 にも注意

LLM時代のコードレビューとテスト

コードレビュー水準の向上、質の高いコミットメッセージが求められる
- 7つのルール（件名50文字以内、命令形、空行挿入、ピリオド禁止等）
PR（プルリクエスト）の分割・整理も容易 になり、品質への要求が高まる
LLMによる自動初期レビュー や、GEMINI.md/CLAUDE.mdを活用したカスタムチェックが可能
テスト自動化も容易化、ユニットテスト・CIテストの重要性が増す
依存ライブラリを避け、自作実装をLLMに依頼する選択肢 も広がる

小規模チームと開発の可能性

少人数チームでの開発力向上
- 90年代のような4人チームでプロ品質ソフト開発が現実的に
- 過去に断念したプロジェクトも復活可能
- 例：SilpheedビデオフォーマットのリバースエンジニアリングやIkaruga、Zeldaの解析
LLMを活用し、未知のコードベースやアーキテクチャの理解が容易化
- llama-cpp、OpenCode、ollama、vLLMなどの研究
- Tenstorrent、Etched、MatX、d-Matrix、Cerebras Systemsなどハードウェア動向にも注目

モチベーションと進化の継続

学習意欲の維持が最大の課題
- 成功事例やストーリーがインスピレーション源
Phil Tippett のその後
- 「絶滅」ではなく、 Dinosaur Supervisor としてJurassic Parkに貢献
- Dinosaur Input Device (DID) をILMと共同開発し、アナログな動きをデジタル化
- 1994年アカデミー賞視覚効果賞受賞、 Tippett Studio も多くの映画に貢献し続ける

まとめ：変化を恐れず、進化し続ける

新しい技術やツールへの適応が生存戦略
自己進化と学習の継続 が最大の武器
「絶滅」ではなく「進化」 を選択することが重要

Hackerたちの意見

この記事は大体好きなんだけど、>「LLMを使わない人は遅れを取る。なぜなら、同じ量を生産できなくなるから」っていうのは、ちょっと馬鹿げてて無駄に攻撃的な意見だと思う。何に遅れを取るの？「同じ量」って何のこと？自分は人生で生産量で評価されたことなんてないし、遅れを取ってた同僚も仕事を失うことを恐れてなかったよ。

└

こういう意見が大嫌い。真実のように繰り返されて、発言者が望むことをしない人を見下す手段になってる。意見が違うのは全然構わないけど、そんなに脅迫的な口調で言う必要はないよね。多くのテック系の仕事は、単に出力量だけに焦点を当てていて、質（メンテナンス性、可用性、セキュリティ、何をしているのかを理解すること）があまり重要視されてない気がする。そういう場合は、LLMを使って何が起こってもいいけど、全ての仕事がそうじゃないからね。

└

これは友達のN=1の逸話だけど、彼のマネージャーは去年、チームの速度の期待値をほぼ倍増させたらしい。みんなが使わなきゃいけないのはClaudeコードだけで、それを使わないと恣意的な期待値を達成できない。逆に、自分のいる会社にはそんな期待はなくて、LLMがあまり役に立たないレガシーコードベースがある。

└

自分が今まで持っていたほとんどすべてのプロのコーディングの仕事では、プログラマーがもっとコードを書きたがって、変更をするのにどれだけ面倒くさいか、会議が多くて変更管理や要件に関する無限の官僚主義について文句を言ってた。一方で、ビジネス側はプログラマーの速度と出力を問題視して、ビジネスリスクと見なしていた。変化のスピードについていくのが大変で、ブレーキを踏むことが多かった。現実的に言うと、LLMがなくても、自分一人で働いて、会議や官僚主義がゼロの状態で、プロのプログラマーとしてやってきた中で、出力はおそらく約10倍くらいだと思う。自分の出力は、参加していたチーム全体の出力に匹敵することもあって、心のままにコードを書けるからだ。

└

そういう時代は過ぎ去っていくし、遅かれ早かれ新しい現実に直面することになるよ。

└

自分をペーパークリップ最大化者に変えない人は、ペーパークリップになってしまう。

└

何に遅れを取っているの？「どれだけ」生産できるの？ビジネスに影響を与える顧客にとって意味のある機能だよ。これは厳密に言って正しいと思う。LLMがコードを書くのが早いからじゃなくて、手動でほとんどのコードを書いていても、LLMをアシスタントとして使っている場合でも当てはまると思う。私の経験則だけど、プロジェクトのコストの大部分はコードを書くことから来るんじゃなくて、「問題」に対処することから来る。変なバグ、驚くべき挙動、仕様のあいまいさ、ライブラリの欠陥、謎のテスト失敗など、 intenseなデバッグが必要で、自分のコードじゃないかもしれないもののメンタルマップを作る必要がある。LLMはこういうのが得意だから、ビジネスロジックに集中する時間を増やしてくれる。これは私の経験でもあるよ。

└

これはマーケティングだよ。大手AI企業は何をしているか分かっていて、FOMOを利用して普及を促そうとしてる。一部の人は早い段階でそのアイデアに乗っかって、自分が特別だと感じてる。一方で、AIの使い方は簡単すぎて、ボタンを押すのと同じくらい簡単だから、それが全てのポイントなんだよね。30分で使えるようになるから、「遅れを取る」なんてことはありえないよ。バブルが崩壊する時に株を持ってない限りはね。

└

開発者の成果をコミット数やPRの作成・承認、スプリントごとのJiraチケット数で測る会社で働いてたんだけど、管理側はチケットに対して努力の見積もりを求めたりしないんだよね。正直、ちょっと落ち込むけど、システムをうまく利用する方法を学ぶと楽になるよ。自分用にちょっとした作業のチケットを作ればいいから。最近は、管理側が生成されたチケットをもっと注意深く見てるから、そういうのが難しくなってきてるって聞いた。チケットをスプリントに追加する前に、開発者がポイントを割り当てるようになるみたい。

└

他の人がパーティーで自分と同じくらい飲んでないとイライラする人たちを思い出す。なんか、自分の消費が問題に見えるかもしれないから、他の人にも同じように飲んでほしいって感じなんだよね。

└

電卓を使わずにスライドルールにこだわる人は、結局遅れをとるよね。生産性が落ちるから。 * 電卓や紙よりもスプレッドシートを使わない人も同様に、遅れをとる。生産性が下がるから。 * 馬車よりトラックを使わない人も、運べる量が少なくなるから遅れをとる。常識だと思うんだけど、攻撃的じゃないよね。

LLMについて学ぶのが一番いいと思うけど、普段は使わない方がいいかもね。新しいものの仕組みを全く知らないのを正当化するのは、古いものの方がいいから使わないって言うのを正当化するよりもずっと難しいから。

Hacker Newsで議論の続きを見る

ハクソク