Don't You Mean Extinct?

By Fabien Sanglard — July 10, 2026

In 1993, the cinematic landscape was forever altered by the release of Jurassic Park, a film that pioneered the integration of CGI into mainstream cinema [1]. However, for some industry veterans, this innovation felt less like progress and more like a threat.

Steven Spielberg had originally commissioned Phil Tippett, a legend in the realm of stop-motion [2, 3], to animate the dinosaurs using his specialized "go-motion" technique. Spielberg himself had been doubtful that computer-generated imagery could ever truly capture the realism of a prehistoric creature [4].

That doubt vanished when Dennis Muren and the team at Industrial Light & Magic (ILM) produced a CGI proof-of-concept.

"I went down with [visual effects supervisor] Dennis Muren when he presented the T-Rex test to Steven and Steven went, ‘Wow, that’s what we’re going to do,’ and he asked me how I would feel and I said, ‘I feel extinct’" [5].

For Tippett, who had already assembled a thirty-person crew for the go-motion task, the realization was crushing: everything he had built his career upon was suddenly unnecessary [6].

The Cycle of Technical Obsolescence

This story resonates deeply today. The fear of becoming irrelevant is a constant, particularly within the digital sphere [8, 9]. Many of us have experienced this "r-evolution" multiple times.

As one user, zkmon, noted on Hacker News, every generation of developers eventually faces a paradigm shift. To survive, one must invest the effort to understand the new mechanics and master their application.

Mastering the LLM Shift

To understand the current wave of Large Language Models (LLMs), I recommend these resources:

• Andrej Karpathy's YouTube Channel: An exceptional resource driven by a genuine desire to help others understand LLMs.
• "Build a Large Language Model (From Scratch)" by Sebastian Raschka: A great follow-up featuring clear, full-color illustrations (with very few "now draw the owl" leaps in logic).

The New Paradigm of Programming

The era of writing every single line of code by hand is the gold standard no longer the norm. Developers who shun LLMs or refuse to use AI agents will inevitably lag behind in productivity.

It is crucial to realize that "coding" itself was never the primary source of value. While the precision and discipline of traditional programming remain vital transferable skills, they are no longer the primary barrier to entry.

I recall a brilliant programmer who loved assembly language so much that he refused to transition to C. I occasionally fight similar urges when dealing with bloated codebases or inefficient languages, but I force myself to adapt.

Balancing Velocity and Quality

Even when I am not typing the code myself, I am still the architect. However, there is a dangerous temptation to go "full-vibe-code."

If I let an LLM run wild, my output increases by a factor of $\approx 1000x$, but the result is often an indecipherable disaster. While this is fine for a quick prototype, professional software requires rigorous quality. LLMs can hallucinate or lose the thread of a complex architecture.

To maintain my standards, I follow a specific workflow:

1. I iterate on my Pull Requests (PRs) until the quality matches what I would have written manually.
2. I maintain style guides in ~/.gemini/GEMINI.md or ~/.claude/CLAUDE.md to train the agent.

Example style directive: Add a small, to the point, comment to explain *what* the block does and *why*.

The Cost of Adaptation

The biggest hurdle hasn't been the technology, but the context switching. Managing multiple agents across different features can lead to significant mental fatigue and burnout.

Code Review in the AI Era

Because the tools have improved, my expectations for code reviews have risen. I now expect Software Engineers (SWEs) to spend less time on the "how" and more time on the "why" and the overall elegance of the solution.

The Art of the Commit Message

I use LLMs to transform summaries into strict directives. For instance, a high-quality commit message should follow these rules:

1. Separate subject from body with a blank line.
2. Subject line: Max 50 chars (72 absolute limit).
3. [Rule 3 & 4 omitted in original]
4. Use imperative mood (e.g., "Fix bug" NOT "Fixed bug").
   - Test: "If applied, this commit will [subject line]"
5. Wrap body text at 72 characters.
6. Focus on context and reasoning; the code explains the 'how'.

The Pre-Submission Checklist

I no longer accept "messy" PRs on the grounds that they are hard to break down; LLMs make splitting PRs trivial. Before I submit my own work, I run this checklist:

• Ask the LLM to criticize the code and hunt for mistakes.
• Verify that the architecture remains sound after refactors.
• Ensure the PR is broken into small, reviewable chunks.
• Apply style guidelines from CLAUDE.md / GEMINI.md.

While human and LLM reviews are powerful, they aren't infallible...