AWS Builder Center
I Stopped Running Claude Code on My Laptop. Here's What I Do Instead.

I Stopped Running Claude Code on My Laptop. Here's What I Do Instead.

Moving your AI coding agent off your laptop and into GitHub — planning work as a dependency graph of issues, delegating each to an agent that runs in CI, and reviewing its pull requests — beats the local interactive loop by unlocking parallelism, cutting context switching, and keeping a human on the merge button.

How I moved from babysitting an AI in my terminal to orchestrating a fleet of agents through GitHub — planning in one place, delegating the work, and staying in control of what ships.



The short version

For months I ran Claude Code the "normal" way: open a terminal, describe a task, watch it work, approve edits, repeat. It was great — until I realized I was the bottleneck. One agent, one machine, one thing at a time, and me glued to the screen the whole time.
So I flipped it. Now I plan work as a graph of GitHub issues, delegate each issue to an AI agent that runs in a GitHub Action, and review the pull requests it opens. The agent runs in the cloud, not on my laptop. I can kick off three tasks before lunch and review them after. My laptop can be closed.
This post is about why that's worth doing, how to actually do it, and why it's meaningfully better than the local, interactive loop most people start with.
New to this? My last post walks through the setup:  Claude in your PRs, on your terms — using the Claude Code Action with Amazon Bedrock . Get that wired up first, then come back here for how to actually work this way.



1. Why work this way

The interactive loop makes you the runtime

When the agent runs in your terminal, your attention is part of the execution loop. You're waiting on it. You're the thing that unblocks it. Every task is synchronous and single-threaded, and the "thread" is you. That's fine for a quick fix. It's a terrible way to run a project.
The asynchronous, issue-driven model breaks that coupling. The agent becomes what IDC calls an "autonomous, asynchronous collaborator that can take responsibility for assigned issues from start to finish without requiring constant developer oversight" ( IDC, June 2025 ). You assign, it works, you review. Your time and its time are no longer the same time.

This is where the industry is actually going

This isn't a niche preference — it's a measurable shift:
  • The share of GitHub projects with coding-agent activity has more than doubled since late 2025 ( Anthropic, 2026 ).
  • A large-scale study of 129,134 GitHub projects estimated coding-agent adoption at 15.85%–22.60% — extraordinarily high for a technology only months old ( arXiv, 2026 ).
The interesting part isn't that AI writes code. It's where it writes it and how you drive it. The winners are moving the agent off the laptop and into the pipeline.

The concrete payoffs

  • Parallelism. The agent runs in secure, ephemeral environments provisioned by GitHub Actions, which "supports parallel progress on multiple tasks — from architectural refactoring to feature development — without facing resource constraints" ( IDC ). Multiple agents, multiple issues, at once.
  • Less context switching. You stop toggling between "doing the task" and "supervising the task." You batch the supervision — reviewing PRs — into deliberate blocks instead of a constant drip.
  • Throughput without headcount. IDC's framing: agents let teams "accelerate delivery timelines and scale output without increasing headcount or disrupting existing workflows."
  • A real audit trail. Every run has session logs and a draft PR that narrates its plan and progress — transparency you never get from a terminal session that scrolls off the top of your screen.



2. How to work this way

Here's the loop I actually use.
Plain text
Plan → Milestones → Issues → Implement → Review → Merge → Unblock → repeat

Step 1 — Plan (Claude Code, locally, in plan mode)

I still start locally, but only to think, not to build. In plan mode, Claude explores the codebase and proposes milestones with phases, acceptance criteria, and dependencies. Once I approve, it creates:
  • GitHub milestones — one per major goal
  • GitHub issues — one discrete unit of work each, with acceptance criteria in the body
  • Blocked-by relationships — the dependency graph, explicit from day one
  • A GitHub Project with an  Actionable  view filtered to  no:blocked-by 
That  Actionable  view is my work queue. Everything in it can start immediately.
The single most important skill here is issue scoping. The field guidance is consistent: keep scopes tiny — "think 'add password reset email,' not 'build auth'" — and refine each issue "until a junior developer could deliver it" ( Medium: Solo-Dev Superpowers with Claude Code + GitHub Flow ). A well-scoped issue is the prompt.

Step 2 — Implement (agent, via GitHub Action)

I open an unblocked issue and comment  @claude  with what I want. A GitHub Action picks it up and the agent:
  1. Creates a branch and starts working
  1. Commits and pushes frequently
  1. Opens a PR when done
  1. Labels the issue so I know it's ready for review
Everything happens in a sandboxed, ephemeral environment — repository cloned, tests run, credentials protected, branch protections enforced by default so the agent can only push to its own branches ( IDC ). Nothing touches  main  without me.
The quality of the output tracks the quality of the context. As one field guide puts it, "an AI coding agent is a workflow amplifier — it becomes useful when you give it context, constraints, tools, tests, review loops, and a narrow definition of done" ( Medium: Stop Treating Claude Like a Chatbot ). In practice that means an  AGENTS.md , clear acceptance criteria, and tests the agent can run to check itself ( Agentic Coding Context Best Practices ).

Step 3 — Review (the human-in-the-loop step)

The PR is now the active work item — I review the diff, not the issue. Test the preview if branch CI/CD is wired up. Then either merge, or comment  @claude  to request changes and the agent pushes a new commit.
This is the checkpoint that makes the whole thing safe. Developers "retain control through the ability to review and approve pull requests before any changes are merged" ( IDC ). The agent proposes; I dispose.

Step 4 — Merge and unblock

Merging a PR closes its issue (via  Closes #N ), and any issues that were blocked by it now surface in the  no:blocked-by  view. That's my next queue. Pick the next issue, repeat from Step 2.

Running several at once

Because each task is a self-contained issue → branch → PR, you can have multiple agents in flight on different issues simultaneously. GitHub is leaning into exactly this — you can now "assign issues asynchronously to Claude Code, Jules, xAI, or the agent of your choice within the GitHub platform" while your source stays in one place ( AWS re:Invent 2025, AIM294 ). For heavier work, orchestrate sub-agents with explicit human checkpoints ( The 12-Step Agentic Professional Developer Workflow ).



3. Why this is different — and better — than Claude Code on your laptop

To be clear: local, interactive Claude Code is excellent, and I still use it — for planning, for exploration, for rapid prototyping where I want to watch every step. GitHub itself draws this line: agent mode in the IDE is "optimized for synchronous workflows, rapid prototyping, and immediate feedback," while the coding agent is "a cloud-based, asynchronous collaborator assigned tasks through GitHub issues" ( IDC ). Different tools for different jobs.
Here's where the asynchronous, issue-driven model wins:

Local / interactive Claude Code
Async / issue-driven agents
Concurrency
One task, one machine
Many issues, many agents, in parallel
Your attention
In the loop — you're the runtime
Batched into review windows
Where it runs
Your laptop (must stay open)
Ephemeral cloud env via GitHub Actions
Record of work
Terminal scrollback
Draft PR + session logs + audit trail + AWS CloudWatch Logs
Safety model
You eyeball each edit live
Branch protections + PR review gate
Planning artifact
Ad-hoc / in your head
Issues, milestones, dependency graph
Handoff / collaboration
Hard — it's on your machine
Native — it's all in GitHub
The deeper difference is philosophical. Local interactive work optimizes for the task in front of you. The issue-driven model optimizes for the project as a whole — it forces you to externalize the plan into a dependency graph, which means the work survives you closing your laptop, is legible to teammates, and can be picked up by any agent. You stop being a code author and start being an orchestrator.

The honest caveats

This isn't magic, and the research is refreshingly candid about it:
  • A landmark 2025 METR randomized controlled trial found that for experienced developers on complex "brownfield" codebases, AI tools produced a 19% slowdown in task completion ( Haithem Builds, 2026 analysis ). Speed is not guaranteed; scoping and context are everything.
  • Velocity gains are front-loaded — one arXiv study found large throughput jumps "only when agents are the first observable AI tool in a project"; repos with prior AI-IDE usage saw minimal or short-lived gains ( arXiv 2601.13597 ).
Which is exactly why the human-in-the-loop review gate isn't optional — it's the whole point. The consensus across every source: this is not about replacing developers but "augmenting our capabilities to focus on what matters most — solving problems and creating value" ( GitHub Community Discussion #163572 ).



Try it

If you already use Claude Code locally, the on-ramp is small:
  1. Next time you have a multi-step feature, open Claude Code in plan mode and ask it to create milestones and issues with blocked-by relationships instead of just building.
  1. Wire up the  @claude  GitHub Action so issue comments trigger a run — my previous post covers this end-to-end:  Claude in your PRs, on your terms — using the Claude Code Action with Amazon Bedrock .
  1. Delegate one issue. Review the PR. Notice that you did something else while it worked.
That last part — you did something else while it worked — is the whole pitch. Move the agent off your laptop and into your pipeline, keep your hand on the merge button, and let the plan, not your attention span, be the thing that drives the project forward.


Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article