Zach Lloyd predicts that 2026 will be the year engineering teams move coding agents off individual laptops and into cloud systems.
2
Cloud agents need environments, hosting, visibility, human handoff, and APIs that let people and agents manage their work programmatically.
3
Agent orchestration will support parallel coding tasks, scheduled automations, and applications that launch agents to handle specific work.
Summary
Zach Lloyd argues that coding has shifted from writing code by hand to writing prompts and guiding agents. As engineers run several agents at once, laptops become a limiting factor, while team leaders lose visibility into the work, security exposure, and agent availability. Lloyd expects teams to move agents into the cloud so they can run longer tasks, work in parallel, and continue when a laptop is offline. He describes the infrastructure required: defined environments, cloud hosting, run tracking, recorded artifacts, human handoff, and programmable APIs. His Warp demonstrations show parallel formula implementations, shared team visibility, scheduled named agents, and a GitHub issue triage app that launches agents to fix issues. He also describes a future where agents coordinate with each other to execute plans for difficult tasks.
Coding has shifted from typing code to guiding agents with prompts
Lloyd says he spent most of his career opening an IDE and writing code by hand. During the previous year, he switched to writing by prompt, while still shipping software at Warp. He says he has not written code in the last six months. In his view, coding changed during 2025 from manually writing code to prompting an agent, with the engineer staying present to guide the work. The current pattern is interactive: an engineer describes a bug or feature, watches the agent work, and continues the conversation while the agent makes changes.
Running several agents exposes the limits of individual laptops
At Warp, Lloyd says the team works in a codebase of about one million lines of Rust and may have four or five checkouts on a laptop, with agents running in them. The immediate problem is capacity when multiple agents run at once. A team-level problem follows because work on individual laptops is hard for others to see. Managers cannot easily understand agent adoption or identify security holes. Laptop-bound agents also stop when the laptop is off or disconnected from the internet.
Cloud systems let agents run longer tasks and work in parallel
Lloyd expects two forms of agent work to grow. One is a long-running, single-agent task that can exceed its context window and begin forgetting earlier information. The other involves several agents working together on a task. He says both patterns need infrastructure. Cloud execution also supports agents that run while an engineer is away from the computer, which removes the laptop as the place where every task must start and finish.
Agent automations can handle recurring engineering work
Lloyd describes release documentation as one example. When Warp releases, an agent examines the codebase and documentation, then prepares a pull request document for updating the documentation. Another agent runs weekly to find feature flags guarding dead code that the team no longer intends to turn off, and removes them. These recurring jobs are a reason to run coding agents away from individual laptops. The work becomes a scheduled engineering process rather than a conversation that depends on one developer's local session.
Cloud-agent infrastructure needs visibility and a human handoff
Lloyd lists the building blocks for running agents in the cloud. An environment defines the toolchain and code the agent can access. Hosting gives the agent a computer to use. Teams also need visibility into what agents are doing, including when they run as part of an automation or application. He says people must be able to inspect a run, guide it, and take over when the agent completes only 80 percent of the work. Warp's Oz product records agent activity and artifacts so a person can return to the run later.
Programmable agent runs allow agents to orchestrate other agents
Lloyd says a cloud-agent system should expose APIs, SDKs, and a CLI for launching agents, configuring environments, and retrieving artifacts and conversation history. These controls should work for human programmers and for agents that need to launch or manage other agents. He describes this as a programmer-first approach. The goal is to provide the primitives for multi-agent systems instead of limiting teams to a fixed workflow.
Shared run tracking turns agent work into a team activity
In the demonstration, Lloyd launches cloud agents to implement spreadsheet formulas beginning with different letters. He starts several jobs and shows that they can run at the same time while keeping a similar interface to a local agent. The Oz web app displays runs across the team, including work started by Lloyd and by teammates. It also shows artifacts such as pull requests and the record of how a change was produced. Lloyd can open the same run on the web or phone and steer it while away from his computer.
Named agents and embedded agents extend orchestration beyond chat
Lloyd shows named agents built from version-controlled skills. Examples include analysing customer feedback and checking for fraud. These tasks can be scheduled across a team, and their runs can produce pull requests. He then demonstrates Power Fixer, an internal app for triaging Warp's GitHub issues. Oz automatically finds duplicate issues, while a triager can launch an agent from the app to fix a selected issue. In this model, an agent becomes a programmable feature inside an application.
"The way to think about what we've built here and the way that we're approaching this is like it's a set of APIs for running and managing agents in the cloud."25:14
Who should watch
You are running several coding agents locally and are beginning to hit laptop capacity or context-window limits.
Your engineering team needs a shared view of agent runs, artifacts, security exposure, and work that continues while developers are offline.
You are building scheduled engineering automations or an application that needs to launch agents through APIs.
