In this podcast, I chat with two professors — Nupoor Ranade (Carnegie Mellon) and Jeremy Merritt (James Madison University) — about how AI is reshaping the technical writing profession from the academic side. We discuss dropping enrollments, misconceptions about what tech writers do, historical parallels to past disruptions, agentic AI and organizational restructuring, the cyborg model of human-machine collaboration, and how academics and practitioners can bridge the divide to solve real problems together.
An artist’s conception of Amazon’s Leo satellite constellation. The satellite internet initiative sits in the same division as Amazon’s new phone project, raising the question of whether Amazon could eventually provide its own wireless connectivity. (Amazon Illustration)
When Reuters reported Friday that Amazon is working on a new smartphone, the reflexive reaction was obvious: Didn’t they already try this? And didn’t it go spectacularly badly?
Yes, on both counts. The Fire Phone, which launched in 2014 when Jeff Bezos was still running the company, lasted 14 months and led to a $170 million writedown.
It was packed with gimmicks, including a 3D display and a camera feature that recognized products and let you buy them on Amazon. It might have been the biggest example of Amazon failing to live up to its legendary mantra of starting with the customer and working backwards.
But dismissing Amazon’s new effort, codenamed “Transformer,” as a sequel to that disaster misses the point. This isn’t Amazon trying to redo 2014. It’s Amazon looking at the AI landscape and betting that the shift to AI is going to fundamentally change what a mobile device is, and that the dominant smartphone makers might not be the ones leading that charge.
The AI opening: Apple and Samsung together command about 40% of global smartphone sales, but their recent devices have been incremental upgrades, not breakthroughs. Neither company is at the forefront of AI in the way that OpenAI, Anthropic, Microsoft, and Amazon itself are.
A growing number of companies are already trying to exploit that gap. OpenAI is working with former Apple design chief Jony Ive on a dedicated AI device. Meta is pushing its Ray-Ban smart glasses as an alternative to pulling out your phone.
Earlier attempts at standalone AI gadgets, like the Humane AI Pin and Rabbit R1, rivaled the Fire Phone as flops in their own right, but they demonstrated the potential of AI devices.
That’s where Amazon may see an opening.
Project details: The phone is being developed by a group called ZeroOne inside Amazon’s devices unit, which has a mandate to create “breakthrough” gadgets, according to Reuters.
It’s headed by J Allard, the former Microsoft executive behind Xbox and the Zune music player, who joined Amazon in 2024, as GeekWire first reported.
The phone is envisioned as an AI-driven personalized device that syncs with Alexa and could potentially bypass traditional app stores altogether. That concept feels increasingly plausible in an era when AI agents can act on a user’s behalf without opening an app.
The company, for the record, isn’t commenting on any of this. The project is still early, the timeline is undefined, and Reuters noted that it could still be scrapped.
The connectivity question: Amazon hasn’t even approached wireless carriers yet, according to the report.
But that detail actually raises an interesting question. Amazon’s Leo satellite internet initiative, formerly known as Project Kuiper, sits in the same Devices & Services division as the new phone project, all under the umbrella of Panos Panay, another former Microsoft executive. Those satellites could provide wireless connectivity directly to devices, potentially bypassing traditional carriers altogether.
There’s no indication the two efforts are connected, but it would make a ton of sense.
And then there’s Amazon Sidewalk, the company’s existing mesh networking protocol that uses Echo and Ring devices to create a low-bandwidth wireless network.
Between satellites overhead and Sidewalk on the ground, Amazon has been quietly building out the infrastructure that could support a device like this without ever involving a traditional carrier.
For the new phone project, Amazon has explored both a conventional smartphone and a stripped-down “dumbphone” with limited features, according to the Reuters report. It has considered positioning a simpler version as a companion device that customers would carry alongside their existing iPhone or Galaxy. One inspiration is reportedly the Light Phone, a minimalist handset with a camera, maps, and not much else, selling for about $700.
During the original Fire Phone development, two internal teams debated the direction: a low-cost, stripped-down device vs. a high-end phone packed with features, as noted in a great “Version History” podcast by The Verge. Bezos sided with the high-end camp, and it failed.
This time, Amazon appears to be hedging by exploring both paths simultaneously.
The Jassy factor: It’s also worth reconsidering the conventional wisdom that this kind of hardware bet is out of character for Amazon under CEO Andy Jassy, Bezos’ successor. Jassy has spent much of his tenure streamlining the company and cutting projects that weren’t working.
But the goal of that effort isn’t to avoid big bets, it’s to clear out bureaucracy and make Amazon more nimble and deliberate when it makes them. Creating a dedicated hardware group with a “breakthrough” mandate and staffing it with a veteran product leader is evidence of that.
Ultimately, the fact that Amazon is willing to revisit its most painful hardware failure shows how seriously it takes the idea that AI has the potential to change what a mobile device can be.
This piece was adapted from a discussion between Todd Bishop and John Cook on this week’s GeekWire Podcast. Listen above, or subscribe in Apple, Spotify or wherever you listen.
This week on the GeekWire Podcast: Amazon is working on a new smartphone, code-named “Transformer,” more than a decade after the Fire Phone debacle, according to Reuters.
We dig into the connection to a past GeekWire scoop: former Microsoft Xbox leader J Allard joined Amazon’s devices team in 2024, and he’s now leading a group called ZeroOne with a mandate to create “breakthrough” gadgets. Is this an AI-native device? A companion to your iPhone? J Allard’s shot at redemption? Maybe all of the above.
Then: Microsoft shakes up its Copilot team, shifting Mustafa Suleyman to a narrower role and unifying consumer and enterprise AI under a new leader. Todd has strong feelings about Microsoft’s history of cutesy consumer tech, from Clippy to Mico.
Plus: Todd’s adventure using Claude CoWork to browse LinkedIn (and the stern warning he got in response). We also discuss King County Metro’s slick new tap-to-pay feature catches the transit system up with the modern world, the upcoming opening of cross-lake light rail, and round things out with an Amazon Treasure Truck trivia question.
This keeps coming up in real conversations, and it usually surfaces right when decisions start to matter. Someone says they are "in GCC," and from there the assumption creeps in that Azure Government is somehow already in the picture. That leap feels small in the moment, but know it is not. The reference and assumption snowballs into bad architecture, wrong scoping, and uncomfortable conversations when compliance teams start asking harder questions. People are not being careless here. The way...
My gut reaction has often been to compare WebAssembly to Kubernetes. Flash back to over four years ago: Then, I put this concept to the test by comparing WebAssembly to Kubernetes in an article.
Not long after the article’s publication, I attended a workshop generously hosted by Cosmonic to use the WebAssembly cloud and learn how to deploy applications with WasmCloud. I got my first hands-on experience with WebAssembly.
As Cosmonic CTO Bailey Hayes helped me play around with WasmCloud during the workshop, I really thought, “Wow, I can deploy things without having to change the underlying infrastructure, essentially anywhere I want, with just a CPU instruction set through a single endpoint.” I did that by setting up microservices with WebAssembly, in that case with WasmCloud, all simultaneously with just one command line. Boom — it was there everywhere. I thought, “Well, maybe that could be something. Isn’t that what Kubernetes is supposed to do? Plus, it’s simple.”
As I learned more about WebAssembly, I realized that wasn’t really the case — they are two different things. Still, I had that inkling in the back of my head. Then came Helm, supporting WebAssembly modules directly. I thought, “Oh, here we go again. We can run WebAssembly modules with Helm; maybe we won’t need Kubernetes.” Wrong again.
This has been part of my learning journey, but it helped me realize that now, with Helm 4 supporting direct WebAssembly modules thanks to the Extism WebAssembly plugin, the isolation previously missing in Helm 3 is provided. You can implement many policy considerations, multi-language elements, and other features in these modules and deploy them on Kubernetes.
So no, WebAssembly is not going to replace Kubernetes, and that is missing the point of the concept: WebAssembly is almost always an extender of existing systems. In this case, you use WebAssembly through Helm to deploy, manage, and distribute workloads to a theoretically infinite number of endpoints that can run a CPU instruction on Kubernetes.
That was the topic of the talk “Helm Meets WebAssembly: Secure Extensibility Without Replacing Kubernetes,” which I gave this week in Barcelona at the Wasm I/O conference as the co-presenter with Shivay Lamba. Lamba had to cancel his trip due to geopolitical issues that disrupted his flight from India, but delivered his part of the talk via video.
As Lamba said during his talk, the Existim plugin provides a lightweight framework for building WebAssembly-based systems. To lock these rules in place, instead of simply running the code, Helm 4 uses a built-in tool — with the help of Extism — to instantly build an invisible, isolated sandbox inside of its own system. Helm then drops the plugin’s code into this safe box. In this environment, the plugin is completely blind and disconnected from the actual computer, Lamba said.
“Helm takes the command you have typed, packages the data up safely, and slides it into the sandbox to be executed so the plugin can start working. Since the plugin is isolated, it cannot directly touch your computer’s hard drive or the internet,” Lamba said. “If the plugin needs to download a file to do its job, it must formally ask the host function standing outside of the sandbox. If the security rules specify that the plugin is allowed to download a file from github.com, then the host guard will go out.”
However, if the plugin tries to access something that it does not have permission to reach, the guard will immediately block it, Lamba said. “Once the plugin finishes its work, it packages up the final result and sends it back to Helm. As soon as Helm gets the result, it immediately destroys the sandbox — which is the WebAssembly module — and wipes out any temporary files that the plugin was using,” Lamba said. “In this way, with the help of Extism, Helm ensures that plugins only get what they need to do their jobs and absolutely nothing more.”
Little protection, big protection
My demo partially failed. I did manage to show with Helm 3, the WebAssembly plugin (Extism in this case) is not “sandboxed.” A simple script with my full permissions that lists my home directory and other info is listed. Obviously, you do not want that.
It’s an unbounded security risk:
The “executable not found” error is exactly why the Extism provided protection is so important. Helm 4 refuses to run the plugin because it can’t find the secure sandbox runner.
It would rather fail than run the code insecurely:
Once I restored the secure path, the “guard” went back up and protected the system:
There you have it. Our talk shows how and why the Extism Wasm plugin improves supply chain and runtime security through mandatory signing and verification, clearer provenance, while still keeping Helm “batteries included” for default behavior.
Again, no, it is not going to help WebAssembly replace Kubernetes, but it will help make Kubernetes through Helm more secure and computationally efficient.
Log in
