Calling an AI agent a software engineer encourages companies to treat it as a replacement for human developers and creates expectations the tool cannot meet.
2
Anthropomorphism can make AI tools easier to understand, but names and descriptions should not imply that agents think, reason, or work independently like people.
3
Trustworthy AI developer marketing explains how the system works, gives developers control, demonstrates real use cases, and supports users with clear documentation and open collaboration.
Summary
Rizel Scarlett argues that the industry helped create fears about AI replacing software engineers by marketing agents as human workers. That framing may make products easier to sell to executives, but it alienates developers, encourages companies to view AI as a one-to-one substitute for talent, and sets expectations that agents cannot meet. Scarlett explains that anthropomorphism can make unfamiliar tools feel approachable, as with page-turning effects in ebooks or engine sounds in electric cars. The problem starts when human language hides limitations such as hallucinations, missing context, and non-deterministic output. Her framework for thoughtful anthropomorphism asks teams to understand how their tools work, choose names such as "co-pilot" or "agent," focus on augmentation, publish information about the system, preserve developer control, show real demos, write useful documentation, and support open communities. The goal is marketing that makes agents approachable without misrepresenting what they do.
The replacement narrative came from a sales shortcut
Scarlett argues that developers, marketers, and developer relations teams helped create the idea that AI will replace software engineers. She says the industry chose a lazy marketing strategy because it is difficult to persuade executives to buy another tool while they already pay engineers large salaries. Selling the tool as a way to remove engineers makes the financial case simpler. She connects this framing to the question of whether AI will replace software engineers, which produces eye-rolling from some developers and panic from others. Scarlett still sees AI as useful for learning unfamiliar technologies and quickly prototyping ideas, but she questions why those benefits are so often presented as a reason to replace people.
Anthropomorphism can make unfamiliar tools easier to use
Anthropomorphism means assigning human traits to non-human entities. Scarlett says it is common and is not automatically harmful. Page-turning animations and sounds in ebooks make a digital object feel familiar even though there is no paper. Electric cars can play engine sounds for a similar reason. These cues give users a familiar way to understand a new tool. AI is harder because its academic history, complexity, and black-box behavior make its capabilities and limits difficult to grasp. Human descriptions can lower that barrier, but the description needs to stay close to what the system actually does.
Human descriptions can damage trust when they imply independent thought
Scarlett points to phrases such as "You've Got a Friend in Claude," the introduction of Devin as an "AI software engineer," and ChatGPT's use of the word "thinking." She says this language can mislead users into believing an AI can think, reason, and work independently like a human. The result is that developers may expect a tool to perform like a mid-level software engineer. AI systems are non-sentient, learn patterns from historical data, can miss context, hallucinate, and produce non-deterministic output. When the product falls short of an exaggerated promise, developers become irritated and the company loses credibility.
Scarlett says the useful value of an AI agent is parallel work. An agent can automate boring tasks, speed up prototyping, and help with debugging, leaving developers more time for creative problem solving and higher-impact contributions. She describes modern developers as people with several responsibilities, including parenting, maintaining projects, and teaching. An agent can complement those responsibilities as part of a developer toolkit. Calling it a replacement misses the way developers actually work and turns an assistant into a threat to the people expected to adopt it.
Developer-facing teams need to understand the agent's mechanics
Scarlett's first recommendation is to understand how the product works well enough to explain its behavior and troubleshoot it. She asks developer relations, marketing, communications, sales, and executives to become "customer zero" by using the product extensively before and after launch. That learning should include the fundamentals of large language models, the difference between co-pilots and agents, tokens, context management, tool calling, limitations, and the agentic loop. In her example, a user requests tests, the language model selects tools such as Cypress or Playwright, creates a plan, executes tool calls, checks the result, and revises the plan when necessary.
Names should describe assistance rather than pretend to be human workers
Scarlett recommends using anthropomorphism sparingly and choosing nonhuman names when possible. She specifically prefers terms such as "co-pilot," "agent," and "assistant" over titles such as "AI engineer." GitHub Copilot's name works for her because it suggests that the tool helps the user do the work while the user remains in control. She also demonstrates the limits of an agent with Code Name Goose playing tic-tac-toe. Goose takes a screenshot, sends information to the language model, chooses a move, and uses a tool to act, but it struggles and ultimately loses. The imperfect result is part of the honest description.
Transparency and control give developers reasons to trust the tool
Scarlett recommends open sourcing a product when possible. If that is not possible, teams should publish white papers and explain the system at conferences. She recalls people speculating about how GitHub Copilot worked while its implementation was not public, including claims that it searched repositories and stole code. Clear information can prevent others from inventing an explanation. Developers should also be able to choose their language model, adjust the agent's verbosity and behavior, inspect debugging logs, and connect the product to APIs and extensions. She cites Code Name Goose's open source design and its connections to Model Context Protocol servers as examples.
Real demonstrations and useful community resources beat broad promises
Scarlett says teams should show what an agent can actually do through short videos, GIFs, blog posts, and live demonstrations. Examples include creating a test suite, converting code between languages, turning wireframes into user interfaces, and generating documentation comments. Live demos can include troubleshooting, which helps audiences see how the presenter handles failure. She also asks teams to provide installation guides, prompt playbooks, and information about data use. Open communities on GitHub Discussions or Discord let users share working prompts. She cites cursor.directory, a community collection of prompts and Cursor rules, as an example of users helping each other replicate useful patterns.
"We're actually missing the real value here, right? The value of AI agents is so you can work in parallel."08:40
Who should watch
You market, document, sell, or advocate for an AI agent and need language that developers will trust.
Your team is describing an agent as an engineer or autonomous worker, and users are reacting with skepticism or unrealistic expectations.
You are building an agent and want practical ideas for explaining its loop, exposing controls, writing documentation, and supporting a user community.
