Don’t You Mean Extinct? Evolving Software Engineering in the Age of LLMs

The day your dinosaur got rendered

In Jurassic Park, CGI dinosaurs didn’t just show up on screen—they changed the ground rules of filmmaking. The story goes that before full digital muscle took over, teams proved a photoreal textured T. rex could chase under real lighting. For a craftsman built on stop-motion, that demo felt like a funeral announcement. “I feel extinct,” is the line that stuck.

That same emotional beat happens in software when new tools suddenly outperform familiar workflows. It shows up as pessimism in comment threads and late-night worries: Is becoming obsolete the default fate of every programmer? The interesting twist is that this fear isn’t new. Different eras call it different things—CGI, mobile-first, now LLMs—but the pattern is the same: a wave arrives, and your job changes shape.

Why LLMs make the anxiety louder

An LLM, or large language model, is a neural network trained to predict the next piece of text (or tokens—small chunks of text) given prior context. A prompt is the input you provide (instructions plus context) to steer the model’s output. When an LLM answers, it’s not “looking things up” in the way a search engine does; it’s generating plausible continuations based on patterns it learned.

That’s why two terms matter immediately in engineering work:

• Hallucination: the model confidently outputs something untrue or unsupported.
• Context: the information you include (codebase snippets, requirements, constraints) that the model uses to decide what to generate.

When tools get better at generating code, the fear becomes personal: What if the value people pay for is the exact skill that just got automated? Coding style debates and tool wars can hide a deeper truth: value shifts toward problem-solving, architecture, and verification. The dinosaur wasn’t “better at moving”—the whole production process became different.

Learning LLMs without surrendering your engineering instincts

The most dangerous posture is either denial (“these tools don’t matter”) or surrender (“the model is the author”). A healthier posture is evolution: invest time to understand how the new beast behaves so you can steer it.

A concrete learning path helps because LLMs feel mysterious until they don’t. Andrej Karpathy’s “from scratch” style lectures are a good example of that mindset: they turn abstractions into something you can reason about step by step. Separately, Sebastian Raschka’s Build a Large Language Model (From Scratch) (released by Manning / No Starch Press in March 2024) is useful because it treats the internals as craft, not magic.

A key idea to carry into daily work is this: LLMs don’t replace understanding; they raise the consequences of missing it. You can generate a lot of code quickly—so you can also generate a lot of bugs quickly.

Writing code with LLMs: accelerate output, protect quality

LLM-assisted development often starts as code generation: you provide intent and context, and the model produces code, tests, or refactors. That can feel like going from “hand-carving” to “casting a mold.” In a small prototype, that speed can be transformative.

But in a real product, the hard part is not producing something; it’s producing something correct and maintainable. “Full-vibe-code” becomes risky when the generated output is:

• internally inconsistent with existing architecture,
• missing important edge cases,
• sprinkled with accidental complexity,
• or subtly wrong while still looking reasonable.

This is where discipline returns. Reading the codebase and understanding the architecture (how components fit together) is still non-negotiable. LLMs may claim they understand the project; engineering practice tests that claim.

A practical quality loop for AI-generated changes

A reliable workflow turns “generation” into “drafting,” then into “delivery.” The loop looks like this:

1. Read the diff: a diff is the text showing what changed between versions.
2. Apply the change intentionally: verify that the model’s idea matches the system’s constraints.
3. Run the tests and checks: unit tests (small automated checks) and linters (style/static analysis tools) catch many classes of errors.
4. Review for design, not just syntax: naming, layering, error handling, and performance tradeoffs.

That workflow is less about being suspicious of the model and more about treating the model like a fast junior who needs guardrails.

Code review in the age of agents

A pull request (PR) is a proposed change you submit for review before merging into the main codebase. In the old world, reviewers looked for correctness the way you’d inspect a careful handwritten draft.

In the new world, AI-generated code adds two review burdens:

• Intent review: does the change solve the real problem, or does it only satisfy a prompt?
• Constraint review: does it respect existing design boundaries, performance expectations, and security rules?

When tools can write large patches quickly, the reviewer’s job becomes more strategic. You’re not only checking whether the code compiles—you’re checking whether it belongs in the system.

Commit messages: your human narrative for future reality

Commit messages are the short “why” that survives long after the generated code fades into the background. They are also the one place where agents can assist without replacing judgment.

A widely used convention—popularized by Chris Beams—captures a few habits that reduce confusion later:

- Separate the subject line from the body with a blank line.
- Keep the subject line short (commonly 50 chars) and wrap the body at 72.
- Use imperative mood: “Add feature,” not “Added feature.”
- Put reasoning and context in the body (the code explains the how).

When code is AI-assisted, commit messages become even more important because diffs can look confident while still being wrong in subtle ways. The commit history turns into an audit trail of intent.

The hidden cost: context switching and cognitive load

One of the strangest side effects of using multiple agents is that it can increase mental fatigue even when typing less. Context switching means rapidly moving attention between tasks, mental models, and code areas. Cognitive load is the amount of mental effort required to hold details in working memory.

Programming already contains interruption costs. Add multiple concurrent agent threads, and the brain spends more time reloading “what we were doing” than producing value. Even if each change is fast, the total workflow can get heavy.

This is why evolution isn’t only technical—it’s behavioral. The best AI workflows don’t maximize parallel threads; they maximize clarity. Fewer simultaneous targets often lead to higher-quality reviews, cleaner diffs, and fewer “why did we do this?” moments.

Evolving instead of fearing extinction

The extinction story is a warning about what happens when a craft identity meets a capability jump. But it can also be a roadmap: those who adapt don’t abandon craft—they re-focus it.

In the LLM era, the center of gravity shifts toward:

• translating requirements into precise engineering constraints,
• verifying generated output with tests and deep code reading,
• reviewing PRs like systems designers, not line editors,
• writing commit messages that preserve intent,
• and managing cognitive load so quality doesn’t collapse under multitasking.

LLMs are another tool in the long line of retoolings that reshaped software. The teams that thrive are rarely the ones who resist the wave or worship the wave. They’re the ones who ride the wave—understanding it well enough to steer.

Conclusion

“Don’t you mean extinct?” asks a joke question, but the underlying lesson is serious: obsolescence is a feeling, not a destiny. Each generation gets new machinery—CGI, mobile-first, now LLMs—and the real survival skill is evolution: learn how the tool works, keep verification tight, and let your engineering judgment remain the source of value.