Your AI Agent Isn't an Engineer: The Art of Thoughtful Anthropomorphism

Hey everyone, today I'm going to talk to you about why you should stop referring to your AI agent as a "software engineer" and the art of thoughtful anthropomorphism. Now, these are a lot of convoluted terms, but really what I'm just trying to say is: how to do better developer marketing and developer relations for your AI agent and other AI-related tools.

My name is Rizel Scarlet, and I am a staff developer advocate at Block, where I focus on all things open source and all things AI. Prior to this, I worked at GitHub, basically doing the same thing, but for GitHub Copilot.

Now, I want to know about you as well. I know we're virtual, but please interact with me. Raise your hand if you've ever been personally victimized by the question, "Will AI replace software engineers?" Ugh, it's such an eye-roll.

Or it can trigger different responses. You might have the people that are rolling their eyes and they're like, "I know Cobalt, and I'm going to stick to Cobalt. I'm not learning anything AI. I do not care." And then you have the people that are like, panicking.

They're like, "Oh my gosh, oh my gosh, oh my gosh, I need to learn AI. I need to do all the AI courses. I need to sign up for all the AI jobs. I don't want to be left behind."

Now, it does seem like a hypothetical or frivolous concern, but companies are making hiring decisions based on AI productivity. For example, Salesforce's CEO recently announced plans to reduce hiring software engineers and support engineers because he saw a 30% boost in productivity from AI.

And now, let me tell you guys my response as a developer advocate in AI. My response has always been: upskill and adapt to the changing economy. After all, you don't want to be that person that is still driving a horse and buggy when everybody's moved on to a car.

And I genuinely do believe AI is a helpful tool. I've used it to help me understand new technologies and quickly prototype ideas. However, on the inside, I've wrestled with this question: why do we keep framing AI as a replacement for developers and human beings?

So we're going to kind of dig into that. We're going to talk about my spicy take a little bit. We're going to talk about anthropomorphism—what it is, how it's affecting our industry, why it's a problem. And we'll talk about a framework to do some authentic AI marketing, or developer marketing, and how to really appeal to developers in a way that still builds trust but doesn't compromise your integrity.

So let's talk about my spicy take,right? AI replacing software engineers. Where in the world did this narrative come from? I think we, our industry—we, developers, and marketers, and developer relations folks—we helped to shape this narrative, unfortunately. I think we were, like, kind of leaning into a lazy marketing strategy that prioritized quick wins over sustainable adoption.

Basically, we wanted to tell VCs and executives, "Buy our product," but it's much harder to tell them to buy our product when they are already paying engineers $300,000, $400,000, $500,000, and now we're like, "Buy them this extra toy."

They're like, "Absolutely not." But we're like, "Oh, you know what? Actually, you can get rid of some of those engineers in place of my tool. My tool will help you to cut those costs, increase productivity, and I know that's what you're all about."

And that's where we start leaning into anthropomorphism. Now, many of you might be like, "Anthro-pro-mer? What?" Allright, anthro—meaning relating to humans—really just means assigning human traits to non-human entities. And it's really not inherently problematic or bad. In fact, it's a really common practice, and it makes digital experiences more familiar, more intuitive.

It gives us, like, that psychological, emotional connection to a digital tool. For example, we have eBooks. Some eBooks have, like, page-turning animations and page-turning sounds, even though there's no paper. There's no actual pages. And then electric cars have pre-recorded engine sounds.

And this is something that Sunil Pai talked with me about briefly on BlueSky, where he kind of just pointed out that electric engine case to me when I was complaining about AI tools being framed as humans. He's like, "This is going to happen.

It's very similar to how electric cars have these pre-recorded engines, even though they don't have a combustion engine. It's just to make the driver, the user, feel familiar, feel connected, and be like, 'Okay, I think I know how to use this.'

There's, like, a familiar affordance to operating the tool." But AI is kind of different because for a long time it's been so based in academia and only for the PhD folks who have a—who had a dissertation and all this big stuff.

So when there's this complexity and black-box nature, it's harder to grasp some of the capabilities and limitations. So what we decided to do is, like, "Oh, you know what? Let me just give it some human-like descriptions." Like, we're saying, "Claude is a friend.

You've got a friend in Claude." This is a sign or advertisement that was at the airport. Or when Devin was first introduced, it was introduced as an AI software engineer. And when you use ChatGPT, sometimes you get a little signal.

Instead of it saying "loading," it says, "Oh, ChatGPT is thinking. It's reasoning." Okay, and you're probably like, "So what's the problem? We're making it familiar for folks. What's wrong with that?" And I think it's self-sabotage. Because it's misleading users to believe that AI can think, reason, and work independently like humans.

Because of that, we're alienating developers. We're setting these really high, unrealistic expectations of our tools, and we're missing the real value proposition of AI agents. So let's dig into the idea about alienating developers. When AI is marketed as an engineer, decision makers view it as a one-to-one substitute for human talent.

And this is counterproductive because developers are AI-powered users. In fact, according to a 2024 Stack Overflow Developer Survey, 76% of the developers said that they either currently use AI or they plan to integrate it into their workflows. So why would you have these people who are excited about and wanting to use the product, and then on the flip side, you're telling them, "It's going to take your job.

Use it more and it'll get better, and then eventually it'll steal your job"? That doesn't make sense. And don't take my word for it. I found this article by Wired called "Game Developers Are Getting Fed Up with Their Bosses' AI Initiative," and in it they pointed out that 52% of companies have now adopted generative AI in their games, but 30% of the surveyed developers expressed negative sentiment.

And then there were these two quotes that really stood out to me. One was, someone said, "I have a PhD in AI. I worked to develop some of these algorithms used by generative AI, but I feel a deep regret for how naively I offered up my contributions."

Like, dang. And another person said, "We should use generative AI to help people be faster at their jobs, not lose them." That's my point as well. And on top of that, it creates these unrealistic expectations,right? If AI is marketed as working just like human, as mid-level software engineer, users expect it to perform at human levels.

But the reality is, AI is non-sentient. It's trained on historical data patterns. It sometimes misses context. It sometimes hallucinates. It sometimes has non-deterministic output. These are just some of the limitations, not throwing shade at AI. This is just sometimes what happens in reality.

And then developers get upset or irritated. They're like, "That's not what you marketed it as. You said it was perfect. You said it was probably even better than me." So now your company risks losing credibility, and so does your product.

Because developers are really focused on authenticity. They really want authentic marketing. They don't want you to say, "This is the biggest, bestest, most performant tool," if it's not,right? Here's the thing about, like, setting all these unrealistic expectations. We're actually missing the real value here,right?

The value of AI agents is so you can work in parallel, where it's automating boring tasks for you. It's doing faster prototyping or allowing you to—it's allowing you to do quicker debugging. That way you can do more creative problem solving and make more high-impact contributions to your company.

And I think it's going to get a little bit worse because we're entering these years of the agent,right? Some people are dubbing 2024 and 2025 as the year of the agents. And for folks who might not know what an AI agent is, people are describing it kind of like a butler or an assistant.

It does things for you. Again, anthropomorphism here,right? It can execute shell commands. Maybe some of them can create calendar events for you. Some of them can just build whole applications. And because of its behavior, it makes anthropomorphic marketing a little bit harder to avoid.

But we've seen the effect that it can have. So how do we stand out and get adoption of our tool, but still build trust with developers? I've come up with this framework that has worked for me with many AI tools.

So this is my framework for thoughtful anthropomorphism. Because at the end of the day, we need a little bit of it, but we can do it in a more authentic way,right? First off, we need to understand how it works.

We need to thoughtfully name our tools. We need to focus on augmentation over replacement. We need to be transparent. We need to emphasize developer control, show, don't tell, encourage good documentation, clear documentation, and also foster open collaboration. So let's dive into each of these very quickly.

When I say, "Understand how it works," I know you're not the engineer that built it. You're probably the developer relations, social media marketer, communications executive, somebody that's a salesperson, somebody that's trying to get people to adopt the product and be aware of it.

So you don't really know exactly how everything works, but it's your responsibility to learn, in my opinion,right? Become customer zero before that tool goes out to the public. Use the product so much. Even when it's out to the public, keep experimenting with it because they're going to keep adding new features to the product.

And invest time into learning the fundamentals of AI. Understand, like, what LLMs are and their capabilities, the differences between co-pilots and agents. Understand core AI agent operations, how tokens work, how context management works, so that it's easier to help troubleshoot people's errors.

Tool calling—understand what that is and all of the limitations that come with an AI agent. And understand the agentic loop. Many agents have different agentic loops. There's, like, some specific recipes for them, but here's an example of one agentic loop,right?

And this is one I'm most familiar with, where a user makes a request. So let's pretend me, I'm the user, and I'm like, "Hey, AI agent, I want you to generate some tests for my web application." And then my AI agent says, "Oh, Rizel wants to generate tests."

So it goes to my LLM, which could be Claude Sonnet 3.5, or it could be GPT-4.0, or whatever. And it's like, "Oh my gosh, Rizel wants to generate tests, and here's the tools that I have. Help me out."

The LLM comes up with a plan. They're like, "Use the generate test tool, maybe Cypress or Playwright, and you know what you need to do? You need to create this folder, create these files, import these dependencies, and start creating a test suite."

And then the agent says, "Yes, sir, I can do it." It executes those plans and tool calls. And then it goes back to the LLM and it's like, "Does this lookright?" If it looksright, it goes and delivers the results to me, Rizel.

And if it doesn't lookright, the LLM and the agent go back and revise the plan again, and it waits for the next request from me. So here's me playing with an AI agent, just so you can get an idea of how it works.

This is codename Goose that my company made. I actually played tic-tac-toe with it. So what happens is I say I played, it takes in that information, brings it to the LLM. The LLM tells it to take a screenshot and decide on where it's going to play and how it's going to play.

So it takes a screenshot with the screen capture tool that it has, and it decides, "Okay, I'm going to use HTML, and I'm going to make my moveright here." So it takes a bit because it's communicating with the LLM at the moment.

So we'll see that happen. And

there it goes. It put an O. Now, AI again. It's not that smart. I ended up winning. So that you can see, like, it's not all perfect. There were moments when we were watching this where it was struggling.

It was like, "Oh, I wasn't able to get the screen capture," and it had to try again and revise its plan on how it was going to do that. So let's talk about thoughtful naming as well. We want to—at least for me,right?

I say, "Use anthropomorphism sparingly, only when needed. Try to choose non-human names and avoid titles like AI engineers," because that's really going to throw some developers off where they're like, "This doesn't act like a real engineer. It's making mistakes," even though engineers make mistakes.

I prefer if you use, like, clear terms like co-pilot, agent, assistant. I really think GitHub Copilot, even though this is not an agent and now it's moving into an agentic mode, they really went off when they pioneered the term co-pilot.

They really, really did. Because they thought about the fact that, hey, it's not doing the work for you. It's helping you do the work. You're the person controlling it. And so, like, co-pilot, I thought, was a really appropriate term that everyone else has picked up.

And then we want to talk about focusing on augmentation over replacement. I wrote this blog post called "The Average Developer is a Multitasker." And here's the thing: an agent helps you to work in parallel. Because modern-day developers, we have multiple roles.

We're parents, we're maintainers, we're instructors on the side. And we should be—instead of saying, "Oh, this is completely going to replace a developer," it's going to complement their responsibilities and be part of a developer's toolkit. Next, we want to talk about transparency.

Oh my gosh, I think this is so important. I'll tell you a story why. First off, I think you should consider open source when possible. If not, try to publish white papers and go to conferences and talk about how it works.

Because this prevents misinformation spreading. Okay, let me tell y'all a story. When GitHub Copilot had first gone from, like, beta to public, there would be a lot of Twitter spaces of people discussing and trying to theorize, "How does this thing work?"

And I would be listening, but I wasn't on the stage, so I couldn't talk and explain. And it wasn't public information yet on how it worked. So I was like, "I don't even know if I can get up there and say it,"right?

So people would be like, "Here's what's happening." As you type, it goes out, searches through repos, steals code, comes back, and gives the code. And I'm like, "That's not how it works." So it's really good to get ahead of the narrative before people create the narrative for you.

The next thing I want to talk about is developer control. This is really powerful because it helps to build trust with developers. Give them the ability to customize the choice of their LLM, customize the behavior. Is it going to be verbose?

Like, the agent's going to be verbose? Is it going to be more concise? Allow them to see debugging logs and allow them to integrate it into their workflow through, like, connecting it to different APIs and stuff like that.

Again, I do think codename Goose is good at this. And I'll point out different tools that I think are good at things,right? Codename Goose just is good at this because, one, it's open source. Two, it connects to model context protocol servers, and we use those as extensions.

So you can connect it to, like, Figma or JetBrains or whatever, and I think that's cool. Now, another thing I think is really important, and a lot of companies miss, is showing and not just telling. A lot of times, companies overpromise, and you're like, "This agent can do everything for you."

And you're like, "What everything can it do?" And I haven't seen it happening, and I don't know how to make it work. So use short videos, GIFs, blogs to demo helpful things like test suite creation, converting code from one language to another, transforming wireframes into, like, UIs, or generating comments into different docs.

And this is scary, but go for the live demos. These are good teaching moments. I know AI doesn't always come outright, but it also allows the audience to see, "Oh, shoot. Is this how this person troubleshoots things when it's not working?"

And they don't like to see, like, the polished demos all the time. Sometimes you want to do, like, a little magic trick. But sometimes it's cool to be like, "Oh, they're struggling with this part. I've struggled with that part.

How do I navigate this?" So what I used to do a lot for GitHub Copilot that worked is I would do a simple demo where GitHub Copilot would help me to connect to Twitter's API and post, "I wrote this to you with Copilot, and I'm at XYZ conference."

Now, this was fun and memorable for people. People that were there would get excited. They would be amping me up when Copilot wasn't generating theright thing. And then all of a sudden, when it did, they're like, "Yay!" And then people that weren't at the conference would get a little bit of FOMO.

They'd be like, "How did Rizel write something with Copilot? Like, how did she write a tweet with Copilot? We want to know." Even one person from React Miami got it framed, the conference organizer. So you want something that people are remembering and making, like, feeling excited about.

Documentation. I think this one is a straightforward one where you want to have installation guides. You want to have prompt playbooks. You want to give people an understanding of how the data is being used so that they can feel more empowered to use your product.

And foster an ecosystem of open collaboration,right? Through GitHub discussions or Discord, you want to leverage this because it'll enable them to have more knowledge sharing. So you'll have people who are using the product and also kind of become developer advocates for you, where they're like, "Hey, this prompt worked for me.

Did it work for you?" And I think one company that—well, I know this is not by the company. This is done by the community. But it's so awesome that they've created this ecosystem where even the community just started this called Cursor.Directory.

I love Cursor's ID. They have the Composer agent. And Cursor.Directory is basically a collection of prompts that people liked for Cursor rules and have used. And other people can just copy them and use them. Sometimes you just want to see what works for other people so you can replicate it as well.

So just to go over the framework again, it's understanding how it works, using thoughtful naming, going for augmentation over replacement, focusing on being transparent, developer control, showing, not just telling, using documentation heavily, and fostering an ecosystem that is focused on open collaboration.

Now, I'll leave you with just a few words saying how we present AI shapes how the world sees it. So I would love for us to move beyond the narrative of AI agents replacing developers. Thank you. And you can go ahead and follow me at Blackgirlbytes.

Bye.