I found this interview on the JetBrains YouTube Channel really interesting: Zig 2026: No-AI Policy, $670K Foundation, Left GitHub & Why Zig Isn’t 1.0 – Andrew Kelley Explains

Some developers really love to code. They share their code and they mentor others to share their code as well. The entire process is a challenge for them. It’s their passion. It’s their craft. And for these guys they aren’t casually dumping their entire development experience for the latest automated AI system to come along.

Here’s Zig Software Foundation lead Andrew Kelley during the interview:

“I love computers. And I love learning about what people are doing with them. And there’s a sense of mystery and magic that you can get from reading someone’s explanation of a project that they did that took them a very long time. They had to learn lessons, and they had to increase their skill as a programmer and as a user of computers in order to accomplish this goal. And when you read a blog post like this, it’s brilliant. It captures the imagination. It makes you think about what you could do yourself. It teaches you something. It connects you to them emotionally.”

And that’s why Andrew bans the use of AI on his Zig projects.

Instead, he’s seeking that close connection with his contributors. He’s seeking excellence and discovery from the many procedures involved in software development. I picked up on this attitude right away because I’ve interviewed many engineers about the value of contributing. Many of them hold remarkably similar views to Andrew, and they talk at length about the importance of contributing to the community.

Here Andrew explains it beautifully:

“The main point of doing code reviews and having contributions, instead of us just doing all work ourselves, is mentorship. The whole point is that a contributor can become a core team member eventually or a more valuable contributor. This will help the project because we’ll have more people who can contribute to Zig skillfully. And it will help their resume because they’ll be a better systems programmer, and they can then take those skills elsewhere.”

But the contributions Andrew used to get from developers using AI were “garbage and had no value whatsoever,” he says. That’s pretty strong language. But Andrew has very high standards and would prefer to engage developers directly on their contributions during the code writing, review, and integration process. That’s where he builds valuable, long term relationships where contributors become more skilled, the core team benefits, and the product maintains the highest quality possible. AI, he says, only gets in the way of that process.

Education is also a big reason for why Andrew holds this view.

“This policy just makes sense because the Zig project is also an education project. That’s part of our mission statement. We’re providing guidance and education to students. So we’re all trying to learn. We’re all trying to get better at programming. And so people who are sending AI pull requests, those people are not helping this goal. In fact, I think that they’re detracting from this goal. So, for our project, I think that the strict no AI policy is an appropriate policy.”

Many times websites bury their organizational mission statements down at the bottom of the page or tucked inside a nav element. But on the Zig Software Foundation site, it’s printed right at the top as the first item.

For developers using AI, Andrew says, it’s simply not worth investing in them. “They aren’t going to join the core team later, not a chance,” Andrew says. It takes too much time away from the reviewers, and the contributors don’t learn anything in the process and are less likely to stick around. Andrew isn’t just saying this, though. His team has tried taking AI contributions but it hasn’t worked out, and they still have hundreds of contributions that still need reviewing. So he’s speaking from his own experience. He’s actually quite thoughtful about the whole thing, so it’s hard to argue that he’s just making a mistake or that he’s blind to the emergence of AI.

So, what’s the lesson? Learn your craft. Learn it well. Go deep into the details so you can demonstrate your expertise so that it’s unmistakable to more advanced developers. And look at the entire process as a community building exercise. In other words, it’s personal. It’s more than just code. Don’t outsource that opportunity to a machine. And then you can build lasting human relationships with the core team via iterations about your code that you submitted yourself. That’s a powerful signal to send into the noisy world of software development. It’s also a simple technique that can be applied to any field you choose. All craftsmen in all trades know this.

Andrew’s position on AI may fly in the face of the current trend of developers embracing AI tools, so we’ll have to see how he and his project evolve as AI grows to pervade more levels of software development. So far, though, Andrew remains emphatic. And judging from many of his comments throughout the interview and how deeply he gets into system development, I bet he sticks to that view. At the end of the conversation, Andrew says he’s probably unemployable at this point and is best suited to be on his own. He’s clearly an entrepreneur at heart, and his standard is “uncompromising perfection.” Can’t argue with that.

And finally, here’s a shout-out to the JetBrains team for talking to Andrew, who said flatly in the interview that he doesn’t use JetBrains products because he only uses FOSS software. Even with advanced IDEs on the market, Andrew’s development set up remains simple and open: “It’s just a terminal and Vim.” Like I said earlier, he loves to code, And he seems as hard core about that as you can get. But the important bit for JetBrains is that they had him on at all. The interview has nearly 900K views in just three weeks, which is vastly more traffic than other recent videos on the channel. Most software vendors would never do this, no matter what traffic a guest could generate. Most vendor channels exist to simply sell products. But JetBrains with this decision demonstrates that they are also concerned with promoting excellence in software development and in building the overall software community. Good for them.