'Developers Won't Trust Someone Who Can't Build With the Tool,' Says Anaconda's Brian Turcotte

Let's start with you. Who are you, what do you do, and what does your company build?I'm Brian Turcotte, a founding Developer Relations Engineer at Kilo, which was recently acquired by Anaconda. Kilo is an open-source AI coding agent available as VS Code and JetBrains extensions, a CLI, Cloud Agents, and Code Reviews. It's model-agnostic, so developers can choose from 500+ models, including the latest frontier and open-weights releases.At Kilo and Anaconda, I lead product launches and create educational videos, technical walkthroughs, and written and visual content for our blog, social channels, and website. I also partner with AI model providers on promotional events and help improve our documentation. On the community side, I host live webinars, discussions, and meetups that bring Kilo users and the broader open-source community together.What does DevRel actually mean to you? Is it marketing, engineering, product, or something else entirely?I think it's primarily a marketing function, but when your audience is developers, the lines between marketing, engineering, and product blur, so in practice the role covers a lot of ground. Developers tend to tune out traditional marketing that leans on emotional appeals. What works is community and product. Builders want to hear from other builders, so a vibrant community signals that a product is worth their time. Builders also need the best tools, so the product's value has to be clear and well articulated through demos, technical content, benchmarks, and real user stories.That's why a strong DevRel person is usually a product expert. They work closely with engineering to create the best content, and they pass feedback from the community back to the team. A developer audience won't trust someone who can't build with the tool they're promoting, and that's why DevRel can't be reduced to marketing alone.DevRel works in both directions: you speak for the company to developers, and for developers inside the company. How do you balance the two, and when have you pushed back on your own team for developers' sake?The cool part about DevRel is that both sides of the job, our internal engineers and the external market, are essentially the same people. They're all developers who want the best tools, so alignment usually isn't the hard part. Our engineers literally use Kilo to build Kilo, so they have every reason to make it the best tool possible.The balancing act shows up more with the community and the broader industry. AI moves so fast that developers' needs shift from week to week, if not day to day. A new model drops, a new workflow catches on, and suddenly what people want from their tools looks different. That means we have to keep a constant pulse on the community and the industry, figure out which shifts are real and which are just noise, and bring those signals back to the team quickly. And because there are always more requests than roadmap, part of the job is making sure people feel heard, even when the answer is "not yet," and being transparent about why. Tell us about your community. Who's in it, how big is it now, and what helped it grow?It's mostly builders: people who make software for a living, open-source contributors, folks working on side projects, and more and more people who are newer to coding and using AI to learn faster. Kilo won over a lot of experienced developers because we're open source and model-agnostic. Developers value both, but most tools don't offer them, especially not together.There are over 5 million Kilo Coders now, about 27,000 GitHub stars, almost 20,000 people in our Discord, and around 100,000 followers across socials. X and Discord are where a lot of the day-to-day happens. People share what they're building, report bugs, and answer each other's questions. Our engineers are in the Discord almost daily too, chatting with builders, answering questions, and fixing issues.Beyond that, we do a lot of webinars, livestreams, and meetups, mostly just to talk shop with users. And I think a lot of it was word of mouth. Developers told other developers.What's a launch or campaign you ran that you're proud of? What happened, and what did you learn?I'm very proud of our record on Product Hunt. Over the past year, we've launched Kilo's Code Reviewer, iOS app, VS Code extension, and several other products. Every one of them hit #1 Product of the Day, and many went on to #1 of the Week and Month.The awards weren't really the achievement, though. They were validation that the launches went well. Each one came from a lot of coordinated work: videos, blog posts, social posts, partner activation, and community support, all orchestrated and executed by our DevRel team.In a product-led world, the product is the marketing. How do docs, onboarding, free tiers and sample apps fit into your DevRel work, and what's one change that measurably improved developer adoption?I agree. For developers, the first few minutes or hours with a tool can decide whether they stick with it, so docs, onboarding, and the free experience matter a lot.With onboarding and the free tier, the goal is to get people to their first "oh, that's awesome" moment as fast as possible. Being model-agnostic helps here, because people can try Kilo with free models without committing to anything, and they can bring their own keys if they already have a provider they like.One change that made a measurable difference was letting people use free models in Kilo without signing in or creating an account. Instead of relying on sign-up walls and email reminders to keep people around, we trusted the product to do it. We saw a nearly 20% increase in usage of our VS Code extension the week we removed that sign-up wall.What's unique about AI is how fast it moves. Kilo looks almost unrecognizable month to month, which is a credit to our engineers keeping pace with the frontier. But it also means DevRel infrastructure like docs, demos, and onboarding has to iterate just as fast. As a DevRel engineer in AI, you can't just be good at making content. You have to build systems that let you update it as soon as the last piece ships.What's your favorite piece of content your team has shipped, and why did it work?One of my favorites is "The IDE Isn't Dead," a blog post I wrote for HackerNoon (wink, wink). I wrote it around the time we launched the latest version of Kilo for VS Code, when there was a lot of hype about CLIs, especially claims that they were replacing the IDE.I love CLIs too (I use the Kilo CLI all the time), but another tricky thing to navigate in AI is the hype-driven, often misleading news and social media cycle, especially the "X is dead because of Y" trope. Innovation doesn't have to mean extinction, and we proved that when Kilo for VS Code 7 landed #1 Product of the Month on Product Hunt. The article hitting #1 on HackerNoon for several weeks was the cherry on top!How do you measure whether DevRel is working? What do you track, and what do you ignore?That part is definitely tricky. First, because a lot of its impact is hard to attribute. A developer might watch a video today, lurk in the Discord for a month, and then finally try Kilo when a friend brings it up. Second, because DevRel covers a lot of different functions, and those shift with business needs, especially in a wild industry like AI.The big one I pay attention to is usage. After a launch or a big piece of content, are more people actually installing Kilo, running tasks, and coming back the next week? Signups are nice, but retention is what tells you the content set the right expectations and the product delivered. I also watch the community. Are people answering each other's questions in the Discord? Are they sharing what they built, opening issues, or contributing on GitHub? When the community starts carrying itself, that's a great sign.Qualitative feedback matters a lot too. If developers mention a specific video or post when they tell us how they found Kilo, or if feedback we bring to engineering turns into a fix or feature the community then celebrates, that tells me the loop is working.What I try to ignore (or at least not obsess over) are vanity metrics, like raw impressions or follower counts on their own. A post can go viral and do nothing for adoption, while a niche technical walkthrough with a few thousand views can bring in a bunch of power users. I'd prefer the second at the end of the day, but the first can be fun too."Talk is cheap. Show me the code." Linus Torvalds wrote this on the Linux kernel mailing list in 2000. How does that idea shape the way you reach developers?That's a timeless quote. It's basically the DevRel playbook for devtools. Developers don't want to hear how great your tool is. They want to see it work, ideally on something that looks like their own code.So most of the content we make is show, not tell. Instead of a feature announcement that just lists what's new, we'll do a demo of using it and building something real with it. Our webinars and livestreams often have live builds and demos too, which was a little nerve-wracking at first (AI doesn't always cooperate on camera), but I learned that developers trust a live build far more than a polished, pre-recorded one. Plus, prepping for something live is the fastest (albeit scariest) way to become a product expert, in my opinion.Kilo being open source is us taking that quote rather literally, too. If someone doubts how Kilo works, they can go read the code, and plenty of people do! And since our engineers use Kilo to build Kilo, the product itself is kind of the ultimate demo.The same goes for comparisons. With all the hype in AI, it's tempting to make big claims, but I'd rather put Kilo next to other tools on a real task and let people judge for themselves.There's a well-known saying that "developers are allergic to marketing." Do you agree? How do you reach developers without it feeling like marketing?Totally agree. And that just boils down to the fact that in software, something either works or it doesn't. With other consumer goods, the outcome can be more subjective. That's why there's a dissonance when you try to use traditional marketing in the devtool space. A tool either helps developers build better or it doesn't.But that doesn't mean there isn't an art and a language to capturing developers' interest. There certainly is, and it comes mainly from getting on their level, both in the product and in the community. There's a lot of noise in the industry right now, and a lot of hype-based, developer-bait marketing. So there's a balance between amplifying your message enough to cut through that noise and still using earnest, transparent language to articulate the value of what you're offering.Understanding which specs, features, and behaviors developers will value comes easiest when you use the tool daily and keep your ear to the ground on the latest innovations. Likewise, being active in dev communities (both yours and others) helps you pick up on trends and latent product demands before they go mainstream.Over time, this builds a voice and a mental model for what appeals to developers, and for the needs that haven't surfaced in the mainstream yet. That's how you build a groundswell. But again, it all comes back to the product, so pick a good one!Kathy Sierra argues in Badass: Making Users Awesome that the goal is to make users awesome, not to make the product look awesome. How does that idea show up in your work?That's a great way to look at it, and I think it's especially relevant to Kilo. Kilo is all about maximizing and valuing the human part of development: offloading the mechanical work of coding to AI so humans can apply their judgment, taste, and direction to whatever they're building.For DevRel, that means articulating this in practical terms and giving users the resources and direction to experience it themselves. So things like demos, blogs, social posts, webinars, and videos are all subtly optimized for usage and enablement. The goal is to get people understanding and using the new, cool stuff as soon as possible, so their great experience becomes the marketing and the signal, not just our word for it.How did you first come across HackerNoon, and is there a story you've read or written here that stuck with you?I first came across HackerNoon a couple of DevRel jobs ago, when I was looking for ways to reach a reliable external audience. I read through the published content, did some research, and connected with a rep. I learned that HackerNoon had accomplished something very difficult: building a loyal, engaged, and very large audience of real developers.I've posted on HackerNoon many times since then, and it's become one of my favorite platforms for getting the word out. I especially appreciate the editorial side, where content only makes the site if it's up to par.One article I really enjoyed writing here was "The IDE Isn't Dead". I mentioned it earlier in this interview, but I think it's especially relevant to AI marketing, because it pushes back on the black-and-white "X is dead" framing that's so common in AI news.Whose DevRel work do you admire most, whether people, companies or programs, and what do they do that others should copy?It sounds cheesy, but the honest answer is my team at Kilo. I've worked with some incredible, crafty, and hacky marketers there, like Job Rietbergen, Brendan O'Leary, Arkadiy Kondrashov, Darko Gjorgjievski, Ari Messer, and Olesya Elfimova, and I've learned a lot from all of them.This team was especially good at creating and fostering developer groundswells, and at taking a marketing function from 0 to 1 in a very short time. I think that came from a fundamental understanding of what developers want, combined with out-of-the-box thinking and creative campaigns, or what our co-founders Scott Breitenother and Emilie Schario would call "Big Swings."In AI, you can't produce content on a conveyor belt. It has to be dynamic, unique, and topical, while still retaining reliability and earnestness. The Kilo team has been exceptional at striking that balance, and I think that is reflected in our brand awareness and social capital.