Don't Fall into the Anti-AI Hype

Don’t fall into the anti-AI hype A few days ago I read a piece by antirez, the creator of Redis, about how he sees AI, programming and the act of “creating.” He said, unusually bluntly: “AI isn’t just going to change how we write code; it has already changed code itself.” Honestly, it hit a nerve. These aren’t the words of someone riding the hype. They come from someone who wrote Redis and pushed systems to their limits, looking back and giving a calm response to this era. It reminded me of the post a few days earlier about the creator of Linux starting to use vibe coding too. At first antirez actually hoped this transformation would go a bit slower, but now he frankly admits that this force has already rewritten how we work across the board. His whole essay barely talks about how powerful AI is, and it isn’t urging people to embrace it or not. It’s a reminder that if you treat AI as a tool that replaces thinking rather than one that amplifies it, what you lose in the end won’t just be technique. His core points are very clear: You don’t write code to produce output; you write it to understand. Tools can change, but you can’t lose your feel for the system. If you no longer know why something is written the way it is, you’ve really just outsourced the responsibility. What he writes about is a bit hardcore, but not in a showing-off way. It’s the details only an old-school engineer cares about: an intuition for performance, sensitivity to data structures, an obsession with error boundaries, and that occupational disease of “I have to know what this code is doing.” These abilities don’t transfer automatically just because LLMs exist. If anything, they’re easier to obscure. What really keeps the essay from being mocked by the crowd is that he doesn’t stop at statements of values. He makes his position clear through what he actually does. He lists several recent pieces of work where he let an LLM take part: an editing framework with UTF-8 support, fixing a race condition in Redis’s tests, having an LLM generate a pure-C BERT embedding library, even letting AI complete a Redis Streams change he designed himself, in twenty minutes. Done the traditional way, these might have taken weeks or longer. antirez isn’t anti-AI. He’s further ahead than most people. But he hasn’t handed over the right to understand. He always keeps hold of “why this system is designed this way, and what the trade-off is.” That makes a striking contrast with the current environment. People chase speed, chase output, chase ten demos a week. Prompts can be outsourced, logic can be fuzzy, as long as it runs. But in the long run, the people who last have never been the ones who produce the most. They’re the ones who have a feel for the system and know what they’re sacrificing and what they’re keeping. This essay made me think about a lot of what I’m doing now. Whether it’s writing, building products or running a knowledge platform, I’m fighting the temptation of “can it be a bit faster?” But the more that’s true, the more I care about whether understanding can be kept, whether people can know what’s happening behind these tools, instead of being left with only the feel of operating them and the tools themselves. AI really will lower the barrier to entry; I completely agree. Last year AI greatly increased my own productivity. But a lower barrier doesn’t mean depth can disappear along with it. On the contrary, depth will become a scarcer and more distinctive kind of value. What’s really worth worrying about has never been “will people use AI?” It’s whether, when programming becomes pure assembly, we still know what we’re sacrificing; and when understanding is no longer encouraged, whether we’re accumulating skills or accumulating dependence. Push it out one more layer, and it isn’t just an engineers’ problem. As knowledge concentrates more and more in the hands of the big companies that can train and control the latest models, whether technological progress also becomes a concentration of power is itself something worth discussing again and again. I take this essay as a reminder. It made me realize again that in this era, once you hand over your thinking, it’s hard to get it back. That’s a problem I’m facing right now too. If you’re an engineer, a product person, a founder or leading a team, this one is really worth saving. In the future, not just programming but product design and institutional design may all have to rethink the next step on the premise of “how much understanding is left.”