nexus/sreweekly/markdown/512/05-the-picture-they-paint-of-you.md

# The Picture They Paint of You

- **期号**: SRE Weekly Issue #512（2026-04-12）
- **作者**: Fred Hebert
- **链接**: https://ferd.ca/the-picture-they-paint-of-you.html

## 简介

Fred Hebert surveyed how AI coding assistants vs. AI SRE tools are marketed and found a stark divide: coding assistants are framed as partners that augment engineers, while AI SREs are  framed as replacements for low-value work. The implication is that the people building and buying these tools see incident response as grunt work to be automated away — and that says a lot  about how decision-makers perceive the role.

## 正文

## The Picture They Paint of You

I keep noticing that the way AI SREs and coding agents are sold is fairly different: coding assistants are framed as augmenting engineers and are given names, and AI SREs are named “AI SRE” and generally marketed as a good way to make sure nobody is distracted by unproductive work. I don’t think giving names and anthropomorphizing components or agents is a good thing to do, but the picture that is painted by what is given a name and the framing brought up for tech folks is evocative.

This isn’t new; because [people already pointed out how voice assistants generally replicated perceived stereotypes and biases](https://scholar.google.com/scholar_lookup?title=Alexa%2C%20tell%20me%20about%20your%20mother%3A%20the%20history%20of%20the%20secretary%20and%20the%20end%20of%20secrecy&publication_year=2020&author=J.%20Lingel&author=K.%20Crawford)—both in how they’re built but also in how they’re used—all I had to do was keep seeing announcements and being pitched these tools to see the pattern emerge. [Similar arguments are currently made for agents in the age of LLMs](https://abiawomosu.substack.com/p/they-built-stepford-ai-and-called), where agents can be considered to be encoding specific dynamics and values as well.

And so whatever I’m going to discuss here is a small addition to the existing set of perspectives encoded in existing products, and one that is not inclusive (eg. Sales Development Representatives, through AI SDRs, also join all sorts of professions, craftspeople, and artists on this list). I’m using AI SREs and Coding Assistants because I think it’s a very clear example of a divide on two functions that are fairly close together within organizations.

### The observations

Here’s a quick overview of various products as I browsed online and gathered news and announcements from the space. The sampling isn't scientific, but it covers a broad enough set of the players in the current market.

#### AI SREs

| Vendor | Product Name | Framing | Comments | 
|---|---|---|---|
| [bacca.ai](https://web.archive.org/web/20260205110719/https://www.bacca.ai/) | AI SRE | “cuts downtime before it cuts your profits”, “stop firefighting, start innovating”, “frees your engineers from the grind of constant troubleshooting” |  | 
| [resolve.ai](https://web.archive.org/web/20260221182125/https://resolve.ai/product/ai-sre) | AI SRE | “Machines on-call for humans”, “Removing the toil of investigations, war rooms, and on-call”, “Operates tools and reasons through complex problems like your expert engineers”[🔗](https://web.archive.org/web/20251122195813/https://resolve.ai/product) | Their [AI SRE buyer’s guide](https://web.archive.org/web/20260204153508/https://resolve.ai/resources/ebook/ai-sre-buyers-guide) also provides framing such as “engineering velocity stalls because teams spend the majority of their time firefighting production issues rather than building new capabilities.” | 
| [Neubird](https://web.archive.org/web/20260213060424/https://neubird.ai/) | AI SRE, Hawkeye | “No more RCA Delays”, “No more time lost to troubleshooting”, “no more millions lost to downtime, delays, and guesswork.” | The name Hawkeye, a superhero product name, is used in press releases and one of the FAQ questions, but is otherwise absent from the product page. There is a closing frame on a video that uses the words "AI SRE Teammate." | 
| [Harness](https://web.archive.org/web/20260221184703/https://www.harness.io/products/ai-sre) | AI SRE, AI Scribe, AI Root Cause Analysis | “Scales your response, not your team”, “Reduce MTTR”, “Standardize first response”, “Let AI Handle The Busy Work While Your Team Solves What Matters” | Their FAQ explicitly compares human and AI SREs by stating “Traditional SRE relies on manual processes and rule-based automation, while AI SRE uses machine learning to adapt, predict issues, and automate complex decision-making at scale.” | 
| [incident.io](https://web.archive.org/web/20260113001845/https://incident.io/ai-sre) | AI SRE | “resolves incidents like your best engineer”, “The SRE that doesn't sleep”, “No need to stall the whole team”, “Keep builders building”, “AI SRE does all the grunt work [postmortems] too.” |  | 
| [Rootly](https://web.archive.org/web/20260215142821/https://rootly.com/ai-sre) | AI SRE, Rootly AI | “AI SRE agents and your teams resolve incidents together”, “your expert engineer in every incident”, “quickly identify root causes and the fix—even if you don't know that code” | In late 2025, [the page instead had a framing](https://web.archive.org/web/20250806112712/https://rootly.com/ai-sre) of “Detect, diagnose, and remediate incidents with less effort” with no reference to teamwork | 
| [cleric.ai](https://web.archive.org/web/20260221192205/https://cleric.ai/) | Cleric | “investigates production issues, captures what works, and makes your whole team faster”, “Skip straight to the answer”, “Unblock your engineers”, | One of the few with a name, possibly a DnD support role reference. | 
| [AlertD](https://web.archive.org/web/20260221192527/https://www.alertd.ai/) | AI SRE | “AI Agents For SREs and DevOps”, “Stop losing hours to scripting and tool switching”, “Unite SRE and DevOps tribal knowledge with AI agents”, “Best-practice AI agent guidance for next steps by your DevOps and SREs”, “Share AI dashboards and insights to act smarter, together”, “Work smarter with your AI” | This is one of two products my summary search revealed with a framing that tries to *help* SREs and DevOps instead of having a focus on replacing them. | 
| [AWS](https://web.archive.org/web/20260221192841/https://aws.amazon.com/devops-agent/) | DevOps Agent | “your always-on, autonomous on-call engineer”, “resolves and proactively prevents incidents, continuously improving reliability and performance”, reduce MTTR […] and drive operational excellence.” |  | 
| [Ciroos](https://web.archive.org/web/20260218151029/https://ciroos.ai/) | Ciroos | “Become an SRE superhero”, “increase human ingenuity”, “AI SRE Teammate for site reliability engineering (SRE), IT Operations, and DevOps teams”[🔗](https://web.archive.org/web/20260221192928/https://ciroos.ai/faq) , “extends the capabilities of every SRE team” | Other product that aims to *help* SRE and DevOps teams. Name is relatively human. The automation model described in the FAQ repeats certain myths, but it’s far more transparent and more grounded than others in this list. | 

*Disclaimer: I have not tried any of the above; this list is built from the products’ own pages.*

Of all of these, only a few mention possible teamwork, and only two of these do so by being a teammate to your SRE staff. Every other one of these instead frames the work as either less important or as worth replacing, sometimes very explicitly. Some have names that refer to superheroes or DnD support classes, most are just named after the role they aim to substitute.

#### Coding Assistants

| Vendor | Product Name | Framing | Comments | 
|---|---|---|---|
| [Anthropic](https://web.archive.org/web/20260221115532/https://claude.com/product/claude-code) | Claude Code | “Built for builders / programmers / creators / …”, “Describe what you need, and Claude handles the rest.”, “Stop bouncing between tools”, “meets you where you code”, “you’re in control” | Human name, emphasizes aspects of delegation | 
| [Google](https://web.archive.org/web/20260217124358/https://codeassist.google/) | Gemini code assist | “Uncap your potential and get all of your development done”, “Experience coding with fewer limits”, “Accelerate development”, “[offload] repetitive tasks”, “reduce code review time” | Name is the latin word for “twins”; framing seeks both augmentation but some delegation. | 
| [Zed](https://web.archive.org/web/20260220214456/https://zed.dev/) | Zed (Editor) | “minimal code editor crafted for speed and collaboration with humans and AI”, “AI that works the way you code”, “fluent collaboration between humans and AI” | Not technically a coding assistant, but an environment to collaborate with them | 
| [Github](https://web.archive.org/web/20260221142922/https://github.com/features/copilot) | Copilot | “Command your craft”, “accelerator for every workflow”, “stay in your flow”, “code, command, and collaborate”, “Ship faster with AI that codes with you” | The naming fits a role that is collaborative, and both it and the positioning try to articulate collaboration while you lead. | 
| [Cline](https://web.archive.org/web/20260219181524/https://cline.bot/) | Cline | “Your coding partner”, “Collaborative by nature, autonomous when permitted”, “fully collaborative AI partner”, “Make coordinated changes across large codebases” |  | 
| [Windsurf](https://web.archive.org/web/20260217232640/https://windsurf.com/editor) | Cascade, Editor | “most powerful way to code with AI”, “limitless power, complete flow”, “saves you time and helps you ship products faster”, “removes the vast amounts of time spent of boilerplate and menial tasks so that you can focus on the fun and creative parts of building.” | Not technically a coding assistant for the editor side, but also provides agents. | 
| [Cursor](https://web.archive.org/web/20260220093030/https://cursor.com/) | Cursor (editor) | “Built to make you extraordinarily productive”, “accelerate development by handing off tasks”, “reviews your PRs, collaborates in Slack, and runs in your terminal”, “develop enduring software” | Also not a coding assistant, but has tabs to interact with them. | 
| [OpenAI](https://web.archive.org/web/20260213164900/https://chatgpt.com/codex) | Codex | “Built to drive real engineering work”, “reliably completes tasks end to end, like building features, complex refactors, migrations, and more”, “command center for agentic coding”, “Adapts to how your team builds”, “Made for always-on background work” | This is one of the few AI coding tools orients itself into a more definitive substitutive role, even if it stills pays lip service to working with your team. | 

*Disclaimer: I have tried some of the above, but not all; this list is built from the products’ own pages.*

You can see from the tables above that each of these tools has a more distinct name, with some being a person’s name. The vast majority of these are framed as tools that aim to augment an engineer or a team, to make them more productive, let them do more within their roles.

### So what are the implications here?

The way these products are presented paints two very distinct pictures (even if exceptions exist in each category):

1. Software Engineering work is perceived as valuable work; the engineer is in control and deserves more power, more control, more productivity. The AI exists to be a partner, a teammate, or an assistant.
2. Software Reliability Engineering work is a hindrance; teams need to be distracted less by these tasks and instead focus on more valuable work. Human limitations—such as needing to sleep—need to be overcome. The AI exists to replace or be a substitute to the worker.

These models potentially replicate and project to the rest of the world the ways these roles are perceived internally.

For example, I’ve written in the past about how I see [incidents and outages as worthy learning opportunities to orient organizations](https://ferd.ca/ongoing-tradeoffs-and-incidents-as-landmarks.html); this framing necessarily perceives SRE as doing important work you wouldn’t want to ignore. The vision behind AI SREs is the opposite. Incidents and outages are one-off exceptions to paper over and move on from, rather than a structural and emergent consequence of what you do (and how you do it) and from which you should learn.

This sort of thing is interesting because it can also be indicative of the split between what practitioners think of their work (learning from incidents is a necessity), and what decision-makers above them may think of the work and function (these postmortems are grunt work).

Much like [AI assistants shaped after secretaries were described as showing a vision that mimics the relation between servants and masters](https://catalystjournal.org/index.php/catalyst/article/view/29586), the way we frame AI tooling for all types of workers exposes the way *their* builders think about that work.

But it’s also a signal about how the *buyers* feel about that work. In case the role sold is one of a partner or teammate, you need to sell this idea to both the employee who’ll work with the tool, and to the employer who will pay for it. When you sell technology that *replaces* a role or function, then you only need to speak to the person with the money.

The implication then is that what these tools project is a mix of how the role is perceived on either side of the transaction. If, as an employee, you feel like the tools are only doing part of the work you value, that may imply few people with power or influence actually value it the same way you do.

This does not mean organizations can fully succeed in the substitution effort. Time and time again history has shown that *part* of a role can be automated and centralized, and the rest of it will be piled onto fewer individuals who will do the hard-to-automate bits and will then coordinate the automation for the rest of it—something called [the left-over principle](https://www.kitchensoap.com/2013/08/20/a-mature-role-for-automation-part-ii/).

As automation capacity increases and as organizations transform themselves to make room for it all, the dynamic evolves.

It’s already pretty clear to me that the vision many builders and buyers have of SREs is often a very reductionist and unflattering one. The role hasn’t yet gone away, possibly because there’s more to it than builders and buyers believe. I figure the evolving portrait of software engineering is equally incomplete at this point, depending on the complexity of the system you’re trying to create and control.

### What are they now painting?

Just for fun, I also looked at how the frameworks that promise to automate all code generation are framed. Codex in the table above is inching that way, but the portfolio grows.

Anthropic is introducing [agent teams](https://web.archive.org/web/20260219045316/https://code.claude.com/docs/en/agent-teams) where the teammates are *below* you. You are directing a team lead that in turn directs teammates. The discourse is one of *control*, where collaboration is delegated to agents, which you can still *manage* more directly. [GasTown](https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04) puts you in the seat of a product manager, and the entire development team is abstracted into deeper hierarchies. [Amp](https://web.archive.org/web/20260213164921/https://ampcode.com/) is also about coordinating agents (of various skills, roles, and costs) while targeted to developers still, but doesn’t drive the analogy as hard.

The enthusiasm is there, and more reports are coming around the *Software Factory* approach, such as [StrongDM experimenting with code that must not be reviewed by humans](https://simonwillison.net/2026/Feb/7/software-factory/) or the [outcome engineering manifesto](https://web.archive.org/web/20260217211224/https://o16g.com/) which imply that the future is in being a high-level controller around large groups of faceless agents, which you must constrain and provide enough information to in order for them to act well.

The trend is seemingly moving away from a partnership between the software engineer and their automation, and into a view that reminds me far more of Taylorism. Maybe that shift is happening because that’s generally what comes to mind when people think of automating production away from manual work.

These products are conceptualized by analogy. Take a pattern you know, and replicate some key properties in a different space. This is an absolutely normal way of exploring new areas, of transferring understanding from one domain to another.

I get that spitting code fast is valuable for many. But if we believe workers can bring more to the table than Taylor did, then this vision is limiting. If we believe that this doesn’t apply because the agents are not that capable, then reductive anthropomorphism isn’t fitting either. In both cases, we should demand and seek better analogies, because a better representation of work as we do it should result in better tools.

That’s because as much as an analogy can be a lever, it can also be a straitjacket. When you’re stuck inside a model, you interpret everything in its own terms, and it becomes much harder to adopt a different perspective or to break out of the oversimplification. And once you’ve made sense of the new space well enough, you ideally don’t need to rely on the analogy anymore: your understanding stands on its own.

In accepting the Taylorist software factory frameworks or AI SREs built while framing the work as low-status, we also—at a social level—tacitly amplify these representations and give them validity. This is necessarily done at the cost of alternative designs, by settling the space with products conceived as poor caricatures of actual work. It lacks respect and is conceptually weak.

We keep being told it has never been cheaper, easier, or more accessible to create new stuff. This should give everyone involved more time to explore the problem space and learn. Yet here we are.

The picture they paint of you says a lot. Just not about you.