Generated by Codex with GPT-5
The Pragmatic Engineer surfaced this piece in Gergely Orosz’s June 30, 2026 field report, Impressions from visiting OpenAI, Anthropic, & Cursor. Based on recent visits to all three San Francisco offices, the article argues that software engineering’s next AI shift is not just better code completion. It is the move from local assistants toward cloud-based agents that can run for hours or days, keep working after a laptop session ends, and turn software work into a delegated, monitored process.
That makes the piece more interesting than another model-release note. It treats agents as an infrastructure problem. Once an agent is no longer a chat pane or a local terminal helper, teams need persistent environments, tool access, context management, security boundaries, failure recovery, review handoffs, and cost controls. The winning product may look less like an IDE plugin and more like a managed runtime for software work.
The laptop stops being the agent’s home
Orosz starts with Anthropic’s Claude Tag, a Slack workflow that lets a user mention Claude and kick off work. The important point is not Slack itself. It is that the agent can run somewhere else, with less setup, less context-switching, and less dependence on the user’s machine staying awake. Anthropic’s Claude Managed Agents are presented as the more explicit version of the same idea: a hosted service for long-running agents across cloud providers.
The pattern is showing up independently. Peter Steinberger built Crabbox to run OpenClaw agents remotely after local agents made his machine hot and slow. OpenAI’s acquisition of Ona, formerly Gitpod, fits the same direction: cloud development environments are a natural primitive for agents that need secure, persistent sandboxes. Orosz also reports that OpenAI engineers said cloud agents have become a real focus, with hiring aimed at orchestration, product abstractions, and infrastructure.
Cursor is moving in the same direction. Its Cloud Agents put agents in isolated virtual machines with full development environments, and its new iOS app depends on the same architecture: a user can start or hand off work from a phone because the actual coding session is no longer tied to the phone or desktop.
Cloud agents create new engineering work
Moving agents into the cloud removes some friction but creates a different class of hard problems. Cursor cofounder Sualeh Asif told Orosz that local agents can “complain” by surfacing warnings and errors to the human sitting in the loop. A cloud agent running asynchronously has no natural equivalent, so Cursor has developed regular agent “confessions” that feed environment problems back to its infrastructure team.
The same issue appears in reliability terms. If a long-running task is halfway done and a node dies, the platform needs some way to preserve state, migrate execution, and keep the work understandable. That is no longer ordinary code completion. It is distributed-systems work wrapped around an AI product.
This changes what software engineers around agents may spend their time doing. The article’s framing suggests that the scarce skill moves from merely writing code to designing the environment where agents can operate safely and efficiently. Teams need to decide what tools agents may call, what context they receive, where secrets live, how progress is observed, how failures are recovered, and when a human must review the output.
Coding harnesses may spread beyond engineers
The article also points at a role-boundary shift. Orosz says OpenAI has seen more than 95% of non-engineers use Codex rather than ChatGPT. If that pattern holds elsewhere, the coding harness becomes a general-purpose work interface, not just a developer tool.
That is plausible because a coding harness offers things a normal chatbot does not: repository awareness, file changes, tool use, test execution, structured plans, and a path to a concrete artifact. Non-engineers do not necessarily want to become software engineers. They want the agent to operate inside the same production-like environment that engineers use, with enough guardrails to make the result usable.
This is where governance becomes unavoidable. Once product managers, designers, operations staff, and analysts can start code-adjacent work, companies need permission models, audit trails, cost limits, and review queues that assume many more people can ask agents to change systems.
The economic bottleneck moves to tokens and review
Orosz frames spend-per-token optimization as another emerging platform concern. That is a natural consequence of cloud agents: if agents run longer, in parallel, with bigger context windows and richer tool environments, AI usage becomes a line item that engineering organizations must actively manage.
This pressure reinforces the infrastructure story. Better prompts are not enough if a company is running many agents against large repositories all day. Platform teams will need routing, caching, model selection, context trimming, budget enforcement, and workflow design that spends expensive tokens where they change outcomes rather than where they merely produce activity.
The larger lesson is that agent adoption is becoming a systems problem. Local coding assistants made individual developers faster. Cloud agents ask organizations to build a runtime for delegated work: persistent sandboxes, reliable orchestration, observability, security boundaries, review policies, and cost discipline. The companies that treat this as infrastructure are more likely to capture the benefit than teams that simply let more agents produce more diffs.