What 90s Game Dev Teaches Us About AI and the Future of Software Engineering

BJ Kennedy — Fri, 30 Oct 2026 20:16:27 +0000

While the speed of disruption from AI feels unprecedented, we can look to history to see what happens when a technical industry undergoes a massive, orders-of-magnitude jump in developer productivity.

If you want to see this playbook in action, look at the video game industry.

The Era of Floppy Disks and Bespoke Engines

In the early 1990s, when a studio built a new game, there were no ubiquitous off-the-shelf commercial game engines. Virtually every major title was built around a bespoke, ground-up rendering codebase. If your project fell behind schedule, you couldn't just hire a contractor who "knew the engine". The engine only existed on your studio’s hard drives.

Collaboration tooling was equally non-existent. Git didn't exist. Integrating your co-worker's code meant saving a file to a 3.5-inch floppy disk, walking across the room, physically handing it to them, and praying you didn't overwrite local changes. Want to ship on multiple platforms? You weren't tweaking build targets; you were manually rewriting C or assembly line by line for entirely different CPU architectures.

By today’s standards, the teams that created foundational genres were ridiculously small:

Final Fantasy (1987): Defined the JRPG—crafted by a core team of roughly 7 people at Square.
Wolfenstein 3D (1992): Practically birthed the modern FPS—built by a core team of just 6 people at id Software.
Quake (1996): Brought true 3D and client-server multiplayer to the genre—required roughly 9 core developers at id (a lineup that reads like a hall-of-fame roster of gaming legends) working 100-hour crunch weeks for nearly two years.

The Productivity Explosion

In the decades that followed, a firehose of productivity tools reshaped development:

Commercial engines like Unreal and Unity abstracted away lower-level graphics math so designers could focus on mechanics rather than writing custom texture-mapping routines.
Git saved us from email threads full of pathfinding_v2_FINAL_for_real.zip.
Cross-platform compilation allowed a single codebase to target PC, consoles, iOS, and Android simultaneously.

Fast forward 20 years from Quake, and even before the rise of LLMs, game development productivity had increased so dramatically that a single developer at a 48-hour game jam could routinely build a functional 3D prototype with technical feature parity to id's 1996 masterpiece.

The breakthroughs that once required an entire R&D phase on the project delivery timeline—true 3D rendering, baked lighting, a high-level scripting language, and client-server netcode—are now done the moment a developer clicks File -> New Project in Unity.

Jevons Paradox in Action

So, logically, game development studios should have shrunk, right? If one engineer can now do what required nine world-class wizards in 1996, the industry should need fewer people. Marketplaces full of cheap 3D assets should have put artists out of work.

The reality was the exact opposite.

Today, end-game credits for a AAA title routinely run for 30 to 40 minutes. Top studios employ teams of PhDs dedicated entirely to the procedural physics of how individual strands of hair, grass, and cloth react to wind. These hyper-specialized roles were completely unimaginable when John Carmack was writing raycasting algorithms. And while individual legacy roles disappeared (few people earn a living hand-porting assembly between custom chipsets today), the total workforce building games has expanded exponentially over the last three decades.

This phenomenon isn't a fluke. It's a classic economic principle known as Jevons Paradox: as technological progress increases the efficiency with which a resource is used, total consumption of that resource increases rather than decreases.

When you make software production 10x cheaper and faster, you don't get 10x fewer developers. You get 100x more ambitious software.

What This Means for AI and Software Engineering

Of course, this won't be a smooth, uninterrupted climb. Every tech paradigm shift brings market volatility: a wave of layoffs one year as executives try to pocket the efficiency gains, followed by a hiring boom the next when competitors use that same efficiency to ship vastly superior products. There will always be good times, bad times, and painful transitional jitters, but the trendline will bend upward.

We are about to see this exact paradox play out with AI and general software engineering. As AI tools lower the cost of writing syntax, we won't stop needing engineers. We’ll just build systems so complex, immersive, and context-aware that today’s software will look like Wolfenstein 3D by comparison.

I look forward to seeing what software roles we have in ten years that sound as absurd to us today as "Senior Hair Strand Simulation Engineer" would have sounded to Carmack and Romero in 1992.

The Power of Names: What Taborlin the Great Teaches Us About AI Prompting

BJ Kennedy — Fri, 16 Oct 2026 16:58:44 +0000

In The Kingkiller Chronicle, Taborlin the Great was a legendary wizard whose power was quite simple. He knew the names of things, and in knowing their true names, he commanded power over them. He could call the name of stone and demand it split in two. He could step off a tall tower and call the name of the wind, and the wind would carry him to safety.

While AI sometimes feels like a superpower in itself, it can also be incredibly frustrating. An image that seems clear and simple to describe in your head comes out looking like an artistic war crime when the model tries to interpret your prompt. The feature that seems straightforward in your application does not function at all as expected after implementation.

Furthermore, it can often be hard to even describe what makes the first implementation seem so off. I find this similar to how I feel at a wine tasting. While an aficionado can tell you all about the balanced, layered complexity of the wine, I simply know, "yes, I like this," and struggle to say why.

I believe this is why different people have such different experiences with AI and why the term "vibe coding" has become so overloaded. To some, it means blindly prompting off pure vibes with zero engineering rigor. To others, it just means directing an AI in natural language instead of typing every line of syntax yourself. In engineering work, I commonly hear, "The architecture of the code it generates is garbage," which comes from confusing the two.

Sure, it takes the path of least resistance. If you tell it, "implement code that gets data from Service A, transforms it, and loads it into our data warehouse", you're likely going to get entirely imperative-style code that does those steps in a giant, 500-line single god-method that would horrify the Chandrian themselves. No abstraction. Direct inline calls to the DB. It will not track historical changes or trends over time.

If instead you tell it to isolate side effects behind DAOs and service client classes, utilize IoC and DI for testability, and structure the warehouse around a medallion data model using Type 2 SCDs to track change over time, you'll get drastically improved, more maintainable results without significantly more effort. This comes simply by knowing the names of these basic patterns and knowing when to use them.

This doesn’t apply just to code. If you can picture an art style but don’t know what it’s called, you might ask for something like "old-timey storybook" and hope the model interprets that the same way you do. Learning that the look you’re after is Art Nouveau gives you a much more specific starting point. Technical documentation stops sounding like it was written with the flourish of the Edema Ruh when specifying that it should be written in Simplified Technical English instead of a more vague prompt like "keep it concise and unambiguous."

What I find about my own AI usage is that I’m now spending more time understanding these sorts of fundamentals in areas I'm not very familiar with. I’m studying art styles in order to better generate images. I’m studying writing styles in order to better generate prose fit to purpose. AI guides that study to help me learn the basic names, as I can now simply drop an image in and ask questions about the artistic style in a way I could never do before.

Taborlin the Great became a legend by learning the names of things to wield their power. AI gives us this superpower for far less effort. Although I'm still searching for the true name of Book 3. "Write 'The Doors of Stone.' Make no mistakes." unfortunately did not work very well.