{"slug": "the-first-cloud-agent-felt-less-like-pair-programming-and-more-like-hiring-an", "title": "The first cloud agent felt less like pair programming and more like hiring an engineer", "summary": "A developer testing Cursor's Cloud Agent on a real monorepo found that it behaves less like pair programming and more like hiring an autonomous engineer. The agent completed environment setup, ran tests, and opened a pull request without continuous supervision, but lacked continuity with local reasoning and tool authentication. The experience highlights the need for clear briefs and documentation like AGENTS.md for effective cloud agent use.", "body_md": "I thought a cloud coding agent was still pair programming: the same local conversation, just running somewhere else.\n\nThe first thing that surprised me was not the code. It was how little the run needed me.\n\nMy evidence is a first Cursor Cloud Agent run against a real monorepo. What initially looked like a Cursor feature turned out to be a different execution model. The run started over in a fresh environment, did the onboarding work, and left proof. Useful. Autonomous. And missing almost everything I already knew in the local session.\n\nIn local Cursor I already had a planning thread: investigation, tradeoffs, and tools I had already authenticated in that session (including Notion MCP). When I pointed a Cloud Agent at [Codenames AI](https://codenames-ai.com/?utm_source=devto&utm_medium=article&utm_campaign=the-first-cloud-agent-felt-less-like-pair-programming-and-more-like-hiring-an-engineer&utm_content=intro), an npm-workspaces monorepo with an Express API, a Vite frontend, Playwright E2E, and CI, I expected continuity. Same decisions. Same auth. Same half-finished reasoning, just remote.\n\nThat assumption failed in the first hour.\n\nThe task itself was small: make the repository ready for future Cloud Agent runs and document the non-obvious setup in `AGENTS.md`\n\n. Completing it required establishing and proving the whole execution environment.\n\nAfter that prompt, the agent worked without me sitting in the loop. It cloned the repo, installed dependencies, ran lint, typecheck, build, and tests, installed Playwright browsers, ran the E2E suite, played a Solo turn in the UI (a single-player practice game), captured screenshots and a walkthrough video, and opened a pull request.\n\nThat pull request added the `AGENTS.md`\n\nnotes and recorded the verification trail from the clean VM, including a hello-world Solo turn in the UI. The change set was small. The *behavior* was large: autonomous environment setup plus artifacts local agent workflows rarely leave behind.\n\n**Local reasoning stayed on the laptop.** Choices I had already made in Cursor (what mattered, what to skip, how I was framing the job) were not present in that new cloud task. Anything that depended on that judgment had to be re-established. The agent could reach the repo and CI. It could not inherit the argument I had already had with myself. Other Cursor flows can move a conversation into the cloud. This fresh task did not arrive with the local framing behind it.\n\n**Tool auth did not ride along.** Notion MCP worked only after separate authentication for the cloud run. Local Cursor access was not session continuity. \"The cloud can use MCP\" and \"the cloud already has my MCP sessions\" turned out to be different claims.\n\nAsync handoff fit. Open-ended design debate in the cloud did not. The run wanted a bounded job and a definition of done, not a remote pair for figuring out the product.\n\nYou do not onboard someone by forwarding a half-finished Slack thread. You give them a machine, a checklist, and a brief. Missing context hurts more as autonomy increases, because a new clean-environment job starts without your local reasoning.\n\n`AGENTS.md`\n\nmattered once the agent was in an unfamiliar checkout: non-obvious Node version floors, optional `.env`\n\nfor local runs, E2E setup, font-sensitive visual snapshots. You do not need the file itself. The point is that this is briefing material for an execution worker, not a substitute for the planning conversation that happened on my laptop.\n\nA second local git worktree can also provide parallel execution, and it has one obvious advantage: it can reuse the tools, credentials, caches, and machine state I already have. For a single developer, that can make the handoff cheaper.\n\nBut it leaves me managing another local workspace, and it keeps the result coupled to my machine: extra checkouts, local processes, port conflicts, and the risk that the result only works in my environment. A teammate cannot reproduce that run exactly without inheriting my laptop state.\n\nA cloud agent starts with less inheritance, so the handoff matters more. In return, I get an isolated task that is easy to parallelize, with less \"works on my machine\" risk, and I can start or monitor work remotely without babysitting another local workspace.\n\nCursor was where I encountered the boundary clearly. Clean environments, onboarding, and missing laptop state are not new lessons if you have been shipping to remote servers for years. What was new was seeing that old systems idea reappear inside an AI coding workflow. The useful response is an explicit handoff, not a remote continuation of your session. Wherever coding agents become independently executable, I expect the same trade-off to appear. The boundary is architectural.\n\n```\nLocal workspace\n(planning, judgment, brief)\n        ↓\nCloud agent\n(bounded execution in a clean environment)\n```\n\nThat first run left open questions: whether later runs would reuse the onboarding work, and how the pattern would hold beyond one carefully bounded task.\n\nLooking back, I kept choosing Cloud Agents for bounded execution: maintenance loops (including [dependency upgrades](https://dev.to/michaeltruong/upgrades-dont-have-to-be-a-blind-trust-exercise-13mj)), targeted bug fixes, and focused investigations such as tracing a review finding or validating a specific question. Not because the first-run costs disappeared, but because isolation and the shared task model reduced coordination overhead. The run still leaves a reviewable trail (screenshots, video, a PR), the same kind of demo evidence you would expect from another engineer handing work back.\n\nThe lasting surprise was that the clean boundary is not only a limitation. It is also the feature that makes the model scale.\n\n**Takeaway:** A cloud agent gives up some inherited local context in exchange for isolation and scalable delegation. Brief it like a new hire, not like a remote continuation of your existing session. The context it needs must cross that boundary deliberately.\n\nIf you'd like to see the project behind these workflow experiments, try [Codenames AI](https://codenames-ai.com/?utm_source=devto&utm_medium=article&utm_campaign=the-first-cloud-agent-felt-less-like-pair-programming-and-more-like-hiring-an-engineer&utm_content=footer).", "url": "https://wpnews.pro/news/the-first-cloud-agent-felt-less-like-pair-programming-and-more-like-hiring-an", "canonical_source": "https://dev.to/michaeltruong/the-first-cloud-agent-felt-less-like-pair-programming-and-more-like-hiring-an-engineer-18j4", "published_at": "2026-07-31 05:53:25+00:00", "updated_at": "2026-07-31 06:00:10.407813+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "artificial-intelligence"], "entities": ["Cursor", "Cloud Agent", "Notion MCP", "Codenames AI", "Playwright", "Express", "Vite"], "alternates": {"html": "https://wpnews.pro/news/the-first-cloud-agent-felt-less-like-pair-programming-and-more-like-hiring-an", "markdown": "https://wpnews.pro/news/the-first-cloud-agent-felt-less-like-pair-programming-and-more-like-hiring-an.md", "text": "https://wpnews.pro/news/the-first-cloud-agent-felt-less-like-pair-programming-and-more-like-hiring-an.txt", "jsonld": "https://wpnews.pro/news/the-first-cloud-agent-felt-less-like-pair-programming-and-more-like-hiring-an.jsonld"}}