AWS recently put out a blog post, innocently titled AWS Chatbot is now named Amazon Q Developer. This presumably serves internal AWS purposes that may or may not resemble empire-building, but I posit that it serves no customers.
The article begins by telling us that “This update represents more than a name change—it’s an enhancement of our chat-based DevOps capabilities.” Here’s where that idea falls flat.
First, AWS Chatbot has historically been an explicit integration worked into Slack and (presumably) MS Teams environments that reports on specific, explicit things. I’ve made use of it for years, both with a ClickOps detector that reports when people make changes via the console in my environment, as well as reporting findings from the (excellent) AWS Cost Anomaly Detection service. This has been positioned to me, and I have used it, as very much a “just the facts, ma’am” reporting of explicit events happening within my AWS account. It further alerts me when custom CloudWatch alarms trigger, and reports AWS Health Events (such as when the cloud decides to no longer cloud for a time). The uniting thread across these diverse use cases is simple: in no way, shape, or form do I want any of these things to be editorialized.
Second, precision matters here and details matter. Amazon Q has improved significantly since its disastrous launch, to the point where it usually doesn’t lie to my face anymore—but when it comes to outages, security reports, alarm thresholds, and cost overruns, “usually” doesn’t cut it.
Furthermore, the change sacrifices communication clarity. When I talked about AWS Chatbot, it was explicitly clear what I was referring to. When I talk about Amazon Q Developer (I’m not even going to touch the completely different Amazon Q Business offering), it’s now unclear whether I mean:
- A chatbot in Slack
- The popup that shows up when you visit AWS’s homepage
- The more fully featured popup inside the authenticated AWS console
- The integration into IDE and other development environments
- The paid-for per-seat offering
- The macOS installable application
- The command-line completions that installable grants me
- The .NET application port from Windows to Linux
- The mainframe migration offering
- The VMware migration offering
- The Java version upgrade offering
- The no-code data assistant hiding somewhere in the console
AI systems are inherently fallible. AWS’s own responsible AI policy states: “If you use the AI/ML Services to make consequential decisions, you must evaluate the potential risks of your use case and implement appropriate human oversight, testing, and other use case-specific safeguards to mitigate such risks.” The trouble is that until now, I didn’t have to do that for alerts showing up in Slack. But now we’ve piled abstraction atop abstraction to the point where it’s no longer reasonably possible to understand what the computer is doing.
I’m not a Luddite, and I don’t hate AI—but I am asking just what all this is for. What previously unaddressed customer need is now being met in exchange for the cost of reasonable certainty?
An example given in the blog post is “What EC2 instances are in us-east-1?” It’ll presumably reply with something kinda accurate, but it won’t point out critical outliers.
- “None in us-east-1, but a bunch in us-east-2”
- “Also, you have a massive number of Fargate containers running”
- “Did you mean in the account that’s hooked up to Slack, or within your entire AWS organization?”
No customers that I can identify are being served by this. It’s a shame that AWS is increasingly putting its own product roadmap needs ahead of customer obsession.
If you need me, I suppose I’ll be turning back the clock six years and integrating SNS into Slack webhooks for the certainty factor.
