In 1993, Jurassic Park came out and revolutionized the use of CGI in films^[1]. To the public the experience was magic. But for some of the people in the movie industry, it was a rude awakening.

Director Steven Spielberg had hired stop-motion master^[2] Phil Tippett^[3] to bring the film's full-body dinosaurs to life using his go-motion technique. Spielberg was highly skeptical that computer-generated imagery (CGI) could realistically depict a dinosaur. But Dennis Muren and the digital artists at Industrial Light & Magic (ILM) worked on a proof-of-concept using CGI. They rendered a fully textured, photorealistic T. rex chasing a herd of Gallimimus in full sunlight.

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’^[4].

I did seem like everything that I had built up until that time was like, "We are not going to do that anymore"^[5].

Phil Tippett

Tippett, who had already selected a crew of thirty and was gearing up for the massive go-motion assignment, was understandably devastated by the turn of events. The Making of Jurassic Park

I have been thinking of this anecdote a lot lately. I see a lot of pessimism around programmers. The anxiety of becoming obsolete is particularly palpable online^[6][7].

The best way to avoid becoming extinct is to evolve. I liked zkmon's take from Hacker News.

Ride the wave. You rode it when websites/webapps were the wave. I came into software industry before internet, kept changing my horse. You are never too old to learn new tricks. The new wave create new kind of work and workers. Be one of them. Ride the beast, master the tools. It's the same game again.

zkmon (Hacke Nnews)

While the current episode reminds zkmon of the mid-90s web, it makes me think of the field of Computer Graphics in the early 2000s and the rise of "Mobile First" in early 2010s. Every generation of programmers will likely have seen a form of r-evolution. This is indeed the same game again. Life is flux^[8]. LLMs are yet another tool. To evolve is to invest the time to learn how it works and how to best use it.

The best resource I found to learn how LLMs work is Andrej Karpathy's channel. The man obviously cares deeply about LLMs and really wants you to get them. His series of videos so far is 25 hours of pure gold.

A nice follow-up is the book Build a Large Language Model (From Scratch) by Sebastian Raschka. There are many drawings in full-color with rare Now Draw the Owl moments. This is a really good book.

Writing every line by hand is no longer the norm. Those who refuse to use an LLM will fall behind because they won't be able to produce as much - and I know several developers who refuse to use agents. John Carmack recently had an interesting take about coding.

“Coding” was never the source of value, and people shouldn't get overly attached to it. Problem solving is the core skill. The discipline and precision demanded by traditional programming will remain valuable transferable attributes, but they won't be a barrier to entry.

Many times over the years I have thought about a great programmer I knew that loved assembly language to the point of not wanting to move to C. I have to fight some similar feelings of my own around using existing massive codebases and inefficient languages, but I push through.

John Carmack

Even though I am not writing code, I am still indirectly producing code. And there is considerable discretion about what one can generate. If I go "full-vibe-code" and let an LLM run, I can produce 1000x what I used to and find myself with an indecipherable mess. Is that a bad thing? If I work on a prototype or a small personal project, it does not matter. But for everything else, code quality still matters tremendously. LLMs may claim they still understand the project and suggest solutions, but I have seen them fail spectacularly and hallucinate.

It remains important to be able to read the code and understand the architecture. It may sound like a given, but I have seen many developers fail to do so. As a result, I reduce my velocity by iterating over my PR until it reaches the same level of quality I would have produced "by hand". Every time I notice something I don't like, I add it to my ~/.gemini/GEMINI.md/~/.claude/CLAUDE.md so the agent can emulate my style. Over the past months, I have added quite a few lines like the following.

- Don't use magic numbers or strings. Use a const or even better, an enum when appropriate.
- Reduce code indentation. Avoid Arrow Anti-Pattern. Leverage early return and continue.
- Use enums instead of boolean for function parameters. .
- Respect layering. Don't punch holes through the layers.
- Let the reader of the code breathe. Add empty lines between logical blocks of code. 
  Add a small, to the point, comment to explain *what* the block does and *why*.

The greatest difficulty I have encountered is "context switching". Working on multiple projects / independent features allows me to drive multiple agents simultaneously. It is quite a mental gymnastics to keep up. I have seen reports of "mental burnout" and I have also personally experienced increased mental fatigue. This is definitely something to monitor.

Given how much better the tools are, I have much higher expectations during code reviews.

There is little excuse for poor commit messages now. There are many guides about how to write a good commit message. Here is the best one I ever came across. It takes 1 minute to ask an LLM to summarize it and transform it into directives that one can add to their GEMINI.md/CLAUDE.md.

When you write a commit message, follow these 7 rules:
Rule 1: Separate the subject line from the body with a single blank line.
Rule 2: Limit the subject line to 50 characters (72 is the absolute hard limit).
Rule 3: Capitalize the first letter of the subject line.
Rule 4: Do not end the subject line with a period.
Rule 5: Use the imperative mood in the subject line (e.g., "Fix bug," "Add feature," 
        not "Fixed" or "Adds"). Test formula: It must complete the sentence: "If applied,
        this commit will [your subject line here]".
Rule 6: Wrap the body text manually at 72 characters to prevent Git formatting issues.
Rule 7: Use the body to explain what and why vs. how. Assume the code explains the how;
        the message must explain the context and reasoning. 

Since authoring code is much less of an effort, I expect SWEs to take much more care into designing elegant solutions. I have little scruples in asking for improved code clarity/code simplicity if the PR is a mess.

The same goes for PR code size. It used to be tedious to break a PR into smaller, easier-to-review, parts. This is no longer the case and I have no problems asking an author to break down their PRs unless they have a good reason for it.

Many code review tools now have integrated LLMs. You can create your own preferred prompt to automatically perform a first pass. For codebases I own, I have added the content of my GEMINI.md/CLAUDE.md which I can trigger with one click. Before sending a PR for review, the first thing I do is ask for the LLM to criticize/look for mistakes. This avoids wasting the reviewer's time on the other end.

Writing tests used to be a pain. This is no longer the case. It is ok to request unit tests/CI tests for each PR. These have never been more important since large refactors are becoming increasingly common. Human and LLM review may miss stuff but good tests should catch breakages.

It is more ok to refuse to take dependencies now. It used to be the go-to solution to avoid writing anything moderately complex. As recently as this morning, I asked an LLM to write a Levenshtein distance function instead of adding a dependency to my project.

We can accomplish more with smaller teams. We may not be far from the '90s model, when a team of four could produce professional software. I was able to revive projects I had abandoned because I deemed them too time-consuming or complex. Last month I completed the reverse engineering of the Silpheed video format and I am making good process on Ikaruga for Dreamcast and Zelda: A Link to the Past on SNES.

The LLM scene is fascinating. And amusingly the very subject to study is also a great tool to help keep up. An LLM will help to dive into any codebase and give pointers about the overall architecture. I have been enjoying reading how llama-cpp, OpenCode, ollama, and vLLM work. There are also many hardware solutions, like Tenstorrent, Etched, MatX, d-Matrix, or Cerebras Systems that are super interesting to follow.

Reading research papers was difficult at first since I have always had a difficult relationship with mathematics notation. LLMs helped to catch up with shortcomings. Having a buddy offer their opinion, and double checking it, helps a lot to ramp up.

Most importantly, there is the problem of finding the motivation to learn. There are many good reasons to avoid making the effort, among them stories of people finding success by moving on.

To keep on going or not is a decision that belongs to each of us. It is the result of a process involving conviction and inspiration. While the former comes from within, I sometimes find the latter in success stories. This takes me back to the anecdote at the beginning of the article. I did not pick Phil Tippett's story randomly. While many know the misquoted "Don't you meant extinct?" part, what happened next is less notorious.

^	[ 1]	Breathing Life into the Dinosaurs of Jurassic Park
^	[ 2]	"Master", as in Return of the Jedi, Dragonslayer, and Robocop to name only a few.
^	[ 3]	The Making of Jurassic Park
^	[ 4]	The oral history of the Dinosaur Input Device
^	[ 5]	The Making of Jurassic Park | Full Documentary
^	[ 6]	LLMs are eroding my software engineering career and I don't know what to do.
^	[ 7]	Do developers feel real fear of AI taking their jobs?
^	[ 8]	Heraclitus: Life Is Flux
^	[ 9]	The oral history of the Dinosaur Input Device
^	[10]	The 66th Academy Awards | 1994
^	[11]	Tippett Studio