At my first startup, I met a guy who made Flash content. Animations, interactive banners, little games for websites. This was the early 2000s, when Flash was everywhere and Macromedia was still its own company. He wasn’t a programmer. He was a designer who had figured out how to make things move.

One day he showed me a Frogger game he’d built entirely in Flash. It worked. The frog hopped, the cars scrolled, the logs floated, and you could die and restart. It was a real game. But when he opened the project file, there was almost no code. He had built the entire thing using keyframes on the timeline.

When the frog reached a certain position, a keyframe would trigger. That trigger would send the playhead to a different part of the timeline where a new sequence would play out. The whole game was a web of jumps between frames — a giant state machine built out of animation tools. Collision detection was just two things being on the same frame at the same time. Game over was a jump to a specific spot on the timeline. Restart was jumping back to frame one.

I didn’t understand it then. I still don’t, not really. My brain wants to see loops and conditionals and functions. His brain saw sequences and transitions and moments in time. He thought about the game as a series of things that happen, and he used the only tool he knew to make those things happen. It worked.

Logic doesn’t care about syntax

That Frogger game taught me something I didn’t fully appreciate until years later: the product is the only thing that matters. Nobody playing that game knew or cared that it was built on keyframes instead of ActionScript. It ran. It was fun. It worked. The implementation was invisible, as it should be.

What we do as developers is assemble logic. We take a set of conditions, outcomes, and rules, and we wire them together into something that behaves the way we intend. Code is one way to do that. Apparently, Flash timelines are another. The medium is incidental. The thinking is the work.

I spent years believing that the way I expressed logic was important. That writing clean, idiomatic code was the real skill. And it is a skill. But it’s a skill in service of something deeper. The deeper thing is the ability to look at a problem, break it into pieces, and figure out how those pieces connect. You can do that in Python, in a spreadsheet, in a visual editor, or on a whiteboard. The people who are great at it would be great at it in any medium.

The best developers I’ve worked with

Over twenty-something years in this industry, I’ve worked with a lot of developers. The best ones were rarely the ones with computer science degrees. Some of them had degrees in music, or English, or nothing at all. One of the sharpest engineers I ever worked with had been an architect. Another started as a photographer.

What they had in common wasn’t technical knowledge. It was a way of thinking. They were organized. They could hold a complex system in their head and reason about it without getting lost. They were creative, not in the artistic sense, but in the problem-solving sense. They could see three possible approaches to a problem and intuit which one would hold up over time. They were thoughtful. They asked good questions before writing any code. They cared about the people who would use what they built.

The CS grads who struggled weren’t dumb. They knew algorithms and data structures and Big O notation. But they often over-engineered things, or got stuck on theoretical correctness when the problem called for pragmatism. They’d reach for the elegant solution when the simple one would have shipped a week earlier.

The best work I’ve ever seen came from people who spent most of their time not writing code. They were sketching on whiteboards, asking questions, poking holes in assumptions. When they finally did write code, it was almost an afterthought — a transcription of thinking they’d already done. The code was simple because the thinking was thorough. That’s not a skill you learn from a textbook. It’s a skill you develop by building things and caring about the people who use them.

The great equalizer

This is why AI changes everything, and not in the way most people think.

The common fear is that AI will replace developers. Maybe it will replace some of the mechanical work. But the more interesting thing it does is remove the barrier between having an idea and building it. For decades, the bottleneck has been the translation layer. You had to know a programming language. You had to understand frameworks, tooling, deployment. You had to spend years accumulating the technical knowledge just to get to the starting line.

AI demolishes that barrier.

The Frogger guy couldn’t write code, so he used keyframes. It was ingenious, but it was also a workaround. He had the thinking but not the tools. Today, he wouldn’t need the workaround. He could describe the game he wanted to build and have AI generate the code. He could iterate on it, test it, refine it, all without learning ActionScript or JavaScript or anything else. His ability to think through game logic, which was always the hard part, would finally be enough.

That’s the real shift. AI doesn’t replace thinking. It removes the tax on thinking. It levels the playing field between the person who has twenty years of syntax memorized and the person who just understands how things should work. The architect who thinks in systems. The designer who thinks in states. The musician who thinks in patterns. They all had the mental models. They just didn’t have the vocabulary. Now they do.

The best developers were never the best typists. They were the best thinkers. AI just makes that obvious.