Terminal first · Worktree workstations · Supervised loops · agents.md + MCP · Remote Mac
Open your laptop in 2026. The first window that lights up is not your IDE. It is three terminals: Claude Code, Codex CLI, and Antigravity CLI, each running its own session. This piece skips the news cycle and the timeline. It answers one question: what does a developer’s day actually look like now? And once parallel worktrees, /goal long-running loops, and MCP + agents.md push a laptop past its limits, why does a remote high-performance Mac become the new primary workstation? Read alongside Mac Mesh × AI Agent collaboration and Git Worktree parallel branches.
A 2026 developer’s morning has quietly flipped. Terminals open first; the IDE opens later. In the terminal: claude, codex, and antigravity sessions, each pinned to a repo. In the browser: a GitHub PR tab and a staging URL. The IDE sits on the second monitor as the diff and UI tuning panel.
The reason is not nostalgia for shells. The main stage moved from writing code to directing agents that write code. Agents live natively in the shell. They read the repo, run commands, edit files, and execute tests without any plugin bridge. The IDE did not die. It stepped into a supporting role for visual review.
The shape of the day shifts with it. Yesterday: 80% typing, 20% running. Today: about 30% writing intent, 30% reviewing diffs, 30% running and reading tests, 10% hand-coding the few pieces that truly need a human touch. The developer becomes a reviewer and a tech lead, while agents act like a fast junior team.
Terminal first: launch Claude Code, Codex, and Antigravity CLI; pin each session to its repo cwd. The IDE goes to the second monitor as a diff and review surface.
One session, one workstation: each agent session targets a single goal (refactor, bug fix, tests, migration). Mixing two tasks in one session pollutes the context.
Start by aligning intent: the first message of the day is often “read the README, the PR template, and the last two weeks of changes, then tell me what you think the goal is.”
Use the IDE for what eyes do best: reading long diffs, tweaking UI, stepping through a breakpoint. The primary keyboard is no longer there.
Stop stuffing the IDE with plugins: capabilities now live in agents.md and MCP servers. The IDE configuration gets thinner, not thicker.
In 2026 the developer is not writing code in the terminal. The developer is directing the people who write code.
A single session can only do one thing at a time. That bottleneck breaks first. The fix already exists in git: worktrees. One repo can check out several branches into different directories that share one .git store. Give each worktree to a different agent. Refactor, tests, migration, docs, and an experiment can all move forward at the same time. Conflicts no longer happen during editing; they wait for the merge.
| Dimension | Traditional IDE, one workstation | AI agents + worktrees, many workstations |
|---|---|---|
| Tasks in flight | 1 | 3–5 (refactor, tests, migration, docs, experiment) |
| Main action | Edit, save, run | Send intent, read diffs, approve, merge |
| When conflicts surface | Mid-edit, in the same file | At merge, surfaced by git tooling |
| Feedback loop | Human → code → tests → human | Human → agent → code → tests → agent → diff → human |
| Local resource load | Low (one process) | High (many parallel builds and tests) |
| Real bottleneck | Typing and thinking | Laptop CPU, RAM, and disk I/O |
The point is not raw speed. The point is where attention goes. Engineering attention moves from line-by-line editing to strategy and boundaries. Instead of watching a cursor, you sweep five worktrees and act like a tech lead reviewing five engineers. When an agent stalls, drifts, or over-edits, you send one message to nudge it. You almost never reach for the keyboard yourself.
Tip: worktrees are also the right way to isolate build artifacts such as iOS DerivedData or Gradle caches. Without them, parallel agents poison each other’s caches. See Git Worktree parallel branches for the field notes.
The real change to daily rhythm is not letting the agent write more. It is letting the agent know when it is done. The newer /goal command in Claude Code, and the equivalent in Codex, attaches a verifiable completion condition to a session. After each turn, a smaller evaluator model checks the condition. If unmet, the agent keeps working. If met, control returns to you.
A real example. Before lunch you type “goal: get every npm run test:e2e green, keep the PR diff under 500 lines.” You leave the desk. When you come back, the diff is PR-ready. The agent ran six turns, fixed three flaky cases, and reverted an unnecessary API change. Below is a minimal supervised loop that works with most CLI agents:
Write the completion condition in one sentence: what command to run, what output to read, what threshold to hit. Example: “pnpm test green and lint with zero warnings.”
Draw the boundary: list the directories the agent may edit and the files it must not touch, such as migrations/, .env, or production secrets.
Start the loop: issue /goal "..." or the tool’s equivalent. Let the agent read, edit, run, inspect output, and iterate.
Set a checkpoint: every N turns or every X minutes, have the agent append a short progress summary to a markdown file you can skim later.
Intervene only when needed: when the agent stalls, drifts, or pushes against the boundary. Nudge it and let the loop continue. Do not grab the keyboard.
Single review before merge: read the full PR diff once. Write review comments. Let the agent do one more pass before you merge.
git worktree add ../proj-fix-flaky fix/flaky-e2e
cd ../proj-fix-flaky
claude
> /goal "pnpm test:e2e all green; do not edit migrations/;
diff < 500 lines; append progress to PROGRESS.md every 3 turns"
# Leave the desk for lunch or a meeting.
# Come back. Read PROGRESS.md and git diff main. Approve or nudge.
The deeper shift is how a developer’s attention is scheduled. Yesterday you had to stay at the desk. Today you can park a 30 to 60 minute task with an agent and go do something with higher leverage—read a spec, sketch an architecture, sync with product. Come back at the checkpoint. Your time becomes schedulable.
The real foundation of this workflow is not an IDE plugin marketplace. It is a folder of markdown and one protocol. Files like CLAUDE.md, agents.md, and .cursorrules are project manuals written for agents—team conventions, build commands, directory boundaries, safety rails, repeat pitfalls. Write them once; every agent benefits. MCP (Model Context Protocol) does the same for tools—databases, browsers, internal APIs, issue trackers—turned into capabilities any agent can call directly, reusable across tools.
| File or protocol | Primary consumer | What goes inside |
|---|---|---|
| CLAUDE.md | Claude Code | Repo context, build commands, test entry points, do-not-touch directories |
| agents.md | Cross-tool convention used by many CLI agents | The canonical “introduce this repo to a new agent” entry point |
| .cursorrules | Cursor and Cursor cockpit | Editing style, naming, directory limits |
| skills / commands directory | Each CLI agent (custom commands) | Repeating flows packaged as /deploy, /release, and friends |
| MCP server | Any MCP-aware client | Database queries, browser automation, internal APIs, issue systems |
Build this layer well and the team gains a shared brain. A new hire’s first task is not reading the wiki; it is asking an agent to read agents.md and describe the repo back. A naming change does not need a team email; one line in .cursorrules closes the loop the next day. A new database does not need a fresh script; attach an MCP server and every agent gets it. Team rules move from human memory to machine memory.
Warning: never put secrets or production connection strings into CLAUDE.md or agents.md. Those files end up in the agent’s context window in full, which is effectively public. Inject secrets at runtime through an MCP server, or keep them in .env and explicitly tell the agent the file is off-limits.
This workflow sounds elegant. The hardware bill is not. Parallel worktrees, long /goal loops, headless browser QA, and local model inference hit CPU, GPU and ANE, RAM, and disk I/O at the same time. A normal laptop runs out of cooling and storage in a hurry. These reference numbers help you decide whether your current workstation still holds up:
node_modules, DerivedData, or Gradle caches around 10–40 GB. Add Docker images and local model weights (4–20 GB each) and 1 TB SSD is the practical floor. Anything smaller fills within a week./goal loops often run for 30 minutes to several hours. Close the lid, lose power, or trigger an OS update and the loop breaks. An always-on node makes “not getting interrupted” a soft but very large win.Lay the bill out and the conclusion is obvious. The weakest link in this workflow is not the model, and it is not the tooling. It is the machine that carries the load. A laptop still works well as the “thin client” that writes intent, reads diffs, and approves merges. The heavy parts—parallel worktrees, long loops, headless QA, caches, and builds—belong on a remote high-performance Mac that stays online with ample RAM, fast disks, and sustained cooling. Forcing a laptop to take that load means throttling, fan noise, and missed runs. For production-grade iOS CI/CD and always-on AI agents, VpsMesh’s Mac Mini cloud rental is usually the better fit—dedicated nodes, predictable resources, instant SSH or remote desktop access, and no depreciation or maintenance on your own hardware. Specs and pricing live on the pricing page; setup notes live in the help center.
No. The IDE is still the best surface for UI design, breakpoint debugging, and visual diff review. What changed is that it stepped down from the place where code is written to a secondary panel for review; the main stage moved to terminal-based AI agents. See Mac Mesh × AI Agent collaboration for the broader picture.
Parallel worktrees, long /goal loops, headless browser QA, and local model inference all hit CPU, GPU/ANE, RAM, and disk I/O at the same time. Laptops throttle and fans roar. A remote M4 Pro or Max Mac with more RAM, faster storage, and sustained cooling absorbs the heavy lifting while your laptop stays a thin client for diffs and decisions. Specs and prices on the pricing page.
They are all project manuals written for agents. CLAUDE.md targets Claude Code, .cursorrules targets Cursor, and agents.md is the cross-tool convention adopted by more CLI agents. They can coexist; each tool reads what it needs. Start with a single agents.md as the canonical entry, then add a tool-specific file if your primary agent needs more. Remote setup notes live in the help center.