Build Like It’s 1996

Every once in a while, a new technology resets how we build. Roadmaps and best practices stop being useful. Roles blur. Everyone’s learning in real time. That’s what working with AI feels like today.

It’s not the first time this has happened. In the ’90s, game developers faced the same kind of uncertainty – figuring out how to build 3D worlds without clear tools or patterns. There were no playbooks, no tutorials, no engines to license. Teams like Epic and id Software just started building and figured it out as they went.

We’ve been here before

You can’t build a clear product roadmap the same way you could in the pre-AI era because it’s harder to imagine what’s possible. And to imagine, you have to build. Early game developers weren’t starting from a blueprint – they were figuring out what their engines might do and how to build them by continuously experimenting and iterating. Similarly, when working with AI, we often don’t know what the product should do or how it should work until we’ve started prototyping.

“We were making up our own ideas as we went… the whole thing was a learning process. There was no book on how to build a 3D game engine or game.” — Tim Sweeney on building Unreal

Unreal engine

The engine and game didn’t emerge from certainty – it emerged from experimentation, play, and continuous iteration. That same instinct—to explore first and understand later – is what makes designers especially suited to this moment.

Designers are well set up to lead

Early game development blurred roles. Programmers were also level designers. Artists pushed engines beyond what the engineers intended, and their experiments further shaped the tools. The most valuable people weren’t specialists – they were builders with taste.

Today, tools like Claude Code and Loveable enable a similar dynamic. Designers no longer need to wait for PRDs or engineering bandwidth. They can build, test, and explore ideas end-to-end.

John Carmack – co-creator of Doom – also emphasized trusting feel over theory:

“Sometimes you just have to code it and see how it plays. You can’t logic your way to the answer.”

This is a vibe-first way of building. Designers are already trained in this skill – they’re used to navigating ambiguity and iterating on what feels right. Now, they can do it with fully functional prototypes, not just static mocks.

Figure it out by building

The best AI product ideas haven’t been discovered yet – and they won’t show up on a roadmap. They’ll emerge through curiosity, scrappy prototypes, and fast feedback loops.

“I was always the guy saying: let’s just try it. We can make another version tomorrow.” — John Carmack

This “let’s just try it” mindset is exactly what this moment calls for. The tools are fast enough that we can quickly build proof-of-concept prototypes – without needing to worry about production-quality code. Designers can explore dozens of ideas and, just as importantly, iterate on the ones that show promise.

Some of the most enduring ideas in software have come from this kind of open-ended exploration. In Doom, explosive barrels were originally just background props – until someone noticed that clustering them created chain reactions. That unplanned moment of fun became a deliberate mechanic and a signature part of the game. It wasn’t planned – it was discovered.

Doom

Following a hunch

The same kind of exploration shows up in our day-to-day work with AI.

Recently, I had a hunch: what if we visualized a conversation with Fin on a canvas, and let users tweak the inputs – segment, topic, replies – to see how Fin would respond in different scenarios? So I built a simple prototype. It wasn’t connected to real data – just a mock interface to explore the idea.

It wasn’t a roadmapped project. But using it gave me a real sense of how much more efficient the experience could be. Instead of restarting a new conversation each time, you could tweak variables on the fly, compare different paths, and explore edge cases without friction. It made the idea tangible in a way a spec or static design never could.

The prototype didn’t ship, but it changed how I think about the problem and how we might approach it in the future. That’s the point: some things don’t become clear until you build.

For designers, this is the time to lead – by staying curious, building what you can’t yet define, and following what feels promising.