Of all of the announcements that stood out at the AWS Summit last week in Manhattan – and as always, there was a volume of announcements – surprisingly one of the most notable was Kiro for iOS. It’s clearly not the most important announcement of the event – that might be S3 Annotations, maybe Continuum or even Quick’s new agents. By contrast, an expansion of Kiro to iOS seems to be the mere migration of existing features from one platform to another.
Except that it’s significantly more than that.
Kiro’s news is important to AWS tactically, of course, but it also offers a lens for examining three macro trends – or four, if you include this quick take on spec vs vibe – within the wider market the product occupies.
Cloud or Local Sessions
As mentioned, the significance of Kiro’s iOS update was not the mere arrival of AI development features on Apple’s mobile platform. It was how AWS instead explicitly argued that development increasingly was going to be done in a remote cloud environment rather than locally on a developer’s machine. In their words, “as remote sessions become the default way to work with Kiro.”
The cloud vs local development tension is neither new nor an artifact of AI. Like so many historical trends in this industry, it has swung from one extreme back to the other. In the late 1960’s and early 1970’s, time-sharing – essentially networking in to remote mainframes, so inarguably cloud development – was the dominant model, if only because almost no one had access to a local environment to develop on. With the rise of personal computers, more and more workloads – development among them – shifted back to the desktop.
As networks got better, faster and more ubiquitous and remote hardware became exponentially more widely available, the idea of remote development returned. From Cloud9 (2010) to Eclipse’s Che (2014) to Glitch (2017) to GitHub Codespaces (2020), remote development began to ramp back up as more IDEs were designed to develop in remote rather than local environments. Developers were slower to come around, however, whether from frustrations with the limitations of remote environments, basic inertia or both.
The pendulum may have begun an arc back to online and away from local, then, but it was not swinging with any real velocity.
TabNine (2019), GitHub Copilot (2021), Cursor (2023), Windsurf (2024) and Claude Code (2025) were all local to begin with. But Devin (2024) was remote, as were Copilot WorkSpace (2024) and Claude Code on the Web (2025). Not that vendors are necessarily binary on the issue; many have support for both local and remote development.
But what AWS seems to be assuming is that over time, the pendulum will swing more aggressively back towards remote development – a new default. Which is interesting, because remote development comes with some obvious potential tradeoffs: will my code be as secure? Will any potential issues with latency irk developers? What if they need access to local resources?
But the potential attractions for developers are there as well. As the latter has become more removed from actual writing of code, the volume of typing required is drastically reduced. A twenty word prompt can output thousands or tens of thousands of lines of code. In which case, a physical keyboard is no longer a hard requirement. It used to seem like science fiction when Simon Willison would talk about coding from his phone. It no longer does. Workarounds like Claude’s Dispatch feature that allow mobile devices to leverage the resources of local hardware may feel a bit clunky and VNC-like, but the allure of actually developing while sitting on a train or walking through a park with no keyboard is strong.
Kiro, clearly, is betting that the benefits outweigh any potential downsides, because it not only was built for a second platform but with a bridge between the two – a bridge in the form of a remote dev environment. It will be interesting to see whether the rest of the market shares that confidence.
Open Weight Models
One of the key questions players in the frantic AI IDE race face is what the attach point is. What aspect of a given product do users latch onto? Vendors like Anthropic or OpenAI hope it’s the model, that developers are making decisions based on model first, everything else second. Vendors like Cursor or Microsoft, meanwhile, would prefer the reverse – that developers as they have from time immemorial will imprint on a particular harness (and incidentally, this is the best definition of that term that I’ve seen), and advantage it regardless of what models it may or may not have access to.
The absurd, unprecedented popularity – and capabilities, of course – of Anthropic and OpenAI models has lead to heavy usage of their tooling. The massive growth of Claude Code, for example, is a direct function of the November release of the Opus 4.5 model and its subsequent updates. Same for OpenAI’s Codex. Which implies that as long as these models maintain a distinct and accepted lead over lesser competitors, their harness strategy will benefit.
But what if they are unable to maintain that distance? And what if models become “good enough?” It’s been widely noted both here and elsewhere that open weight models are getting better, faster. Based on the trajectories, industry sentiment seems to be that in less than a year, there will be open weight alternatives that are legitimately comparable in performance to last November’s industry changing Opus 4.5 model. Historically, this hasn’t been an issue, because the frontier models are just enough more impressive than alternative models that are open, cheaper or both.
In using Fable for a variety of tasks here, however, it was more of a marginal improvement over Opus than another step function leap. Not what it was initially hyped to be. Not better enough to pay 2X Opus pricing, and certainly not enough to justify versus a low or no cost open weight Opus equivalent. And if the model ceases to be a control point, vendors with more ability, resources and viability in the community/harness/etc spaces than in the model world will be looking to insert themselves in between buyer and model thus dis-intermediating the seller of the latter. Almost three decades ago, IBM announced its intention to invest a billion dollars to improve an open operating system in a bid to disrupt Microsoft. Likewise, there’s a reason that large players like AWS and Microsoft are heavily partnering with existing open models, developing their own or both.
The Model vs Harness control point question will be even more interesting to monitor as we move along, clearly.
Access, Authorization and the Rest
It’s become something of a truism that even as AI has dramatically accelerated the act of writing code, its impact on everything that comes after that point is more mixed. Other than the literal interface for creating code and the model sitting behind it, there is a morass of different components, services and frameworks that are required to make a developer productive, and in most cases these have not been optimized for – and in some cases are unable to scale to – AI’s demands.
One common problem area is access. Even at an individual level, it can be difficult to manage what test data, code and infrastructure a given developer should have access to – as any AI tool user that’s ejected into YOLO mode rather than deal with the constant permission requests can attest. And that’s just people. At the scale that agent growth implies, it’s an exponentially more complicated problem. There’s a reason that both A2A and MCP exist and are widely adopted standards, if asymmetrically from a geographic standpoint.
The various harnesses do what they can to mitigate these challenges via mechanisms like tiered permission modes. But they’re complicated problems that are only growing more complicated. Local and remote development permissions are relatively understood at this point. But what about hybrids, such as when a cloud app needs to reach into a local machine for software or resources it doesn’t have access to? Or when a local app needs to leverage data housed in systems remotely hosted. Complicated as all of this is today, it’s only going to become more byzantine because the tools themselves are becoming murkier and less distinct and because they’re going to be asked to do more and more.
Short of YOLO mode, which no enterprise will run in and no individual should run in, most current approaches to problems of access, authorization and even basic integration are highly granular, coarse on/off permissions. There are not typically elegant tiers of informed and opinionated presets from a security or an integration standpoint. The experiences, in other words, are still primarily focused on a narrow band of developer activity: outputting code at velocity.
There may be no better illustration of how complicated the ecosystem around the IDE is, in fact, than the general inability to arrive at an industry consensus on what, precisely, a harness consists of. As products like Kiro evolve, then, part of what they’ll need to adapt to is what happens upstream and downstream of the act of writing code.
Disclosure: AWS, the Eclipse Foundation, Fastly (Glitch), GitHub, Google (Windsurf), IBM and Microsoft are RedMonk customers. Anthropic (Claude), Devin, OpenAI (Codex), SpaceX (Cursor) and TabNine are not currently customers.
