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

Hey everyone. Today, I'm gonna 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 Scarlett, 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 wanna 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 COBOL and I'm gonna stick to COBOL.

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 wanna 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, 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 wanna 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 gonna kinda dig into that. We're gonna talk about my spicy take a little bit. We're gonna 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 [laughs] 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, kinda 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, 500.

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, "Anthropo- what?"

All right. Anthro meaning relating to humans. Really just means assigning human traits to non-human entities, and it's really not in- 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 e-books. Some, some e-books 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 gonna 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, 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, 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 decide 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, 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 a- 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 power 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 a product, and then on the flip side, you're telling them, "It's gonna 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 Initiatives, 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 was 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 risk losing credibility, and so does your product, 'cause 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, 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 fa- 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, uh, more hi- high impact, uh, contributions to your company. And I think it's gonna get a little bit worse because we're entering these years of the agent, right?

Some people are dubbing 2024 and 2025 the, as the year of the agents. And for folks who might not know what a AI agent is, people are describing it kinda like a, a butler, 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. 'Cause at the end of the day, we need a little bit of it, but we can do it in a, 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, an 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 pu- public, keep experimenting with it, 'cause they're gonna 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 copilots 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 a AI agent. And understand the agentic loop. Many agents have different agentic loops. There's, like some, um, 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, uh, 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 it, it, 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 look right?"

If it looks right, it goes and delivers the results to me, Rizel, and if it doesn't look right- 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 gonna play and how it's gonna play.

So it takes a screenshot with the screen capture tool that it has, and it decides, "Okay, I'm gonna use HTML and I'm gonna make my move, um, right 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 a O. Now AI again, [laughs] it's not that smart. I ended up winning. Um, 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... It 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 wanna, 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, 'cause that's really gonna throw some developers off where they're like, "This isn't acting like an, a real engineer.

It's making mistakes," even though engineers make mistakes. I prefer if you use like clear terms like copilot, 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 copilot.

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, the, the person controlling it.

And so, like copilot, I thought was a really appropriate term that everyone else has picked up. And then we wanna 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 'cause 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 gonna replace the developer," is it gonna complement their responsibilities and be part of a developer's toolkit?

Next, we wanna 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 the 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, 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 wanna talk about is developer control. This is really powerful 'cause it helps to build trust with developers.

Give them the ability to customize the choice of their LLM, customize the behavior. Is it gonna be verbose, like the agent's gonna be verbose? Is it gonna 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, 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, uh, companies overpromise and you're like, "This agent can do everything for you."

And you're like, "What, 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 the wireframes into like UIs or generating comments into different docs.

Um, and this is scary, but go for the live demos. These are good teaching moments. I know AI doesn't always come out right, 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 wanna 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 tweet 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 the right 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, and they'd be like, "How did Rizel write something with Copilot? Like, how did she write a tweet with Copilot?

We wanna know." Even one person from React Miami got it framed, [laughs]

the, uh, 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 wanna have installation guides.

You wanna have prompt playbooks. You wanna give people understanding of how the data's being used, um, 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 wanna, um, 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 have created this ecosystem where even the community just started this called Cursor Dot Directory.

I love the, love Cursor's ID. They have the composer agent, and Cursor Doc Directory is basically a collection of prompts that people liked for cursor rules and have used, and people can, other people can just copy them and use them.

Sometimes you just wanna 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, doc- 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 [REDACTED:username]. Bye.