Don't You Mean Extinct?

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

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

Phil Tippett[6].

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[7] around programmers. The anxiety of becoming obsolete is particularly palpable online[8][9].

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[10]. 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