For about three years my relationship with AI coding help has been the same shrug. The editor plugins are nice for the slide-deck version of coding, where the cursor blinks on a single file and the model fills in twenty lines. The moment the work leaves that screen, the help evaporates. Most engineering happens in shells, in pipelines, in worktrees that span dozens of files. None of those places have a blinking cursor, and an AI tool that cannot reach them is a very expensive autocomplete.
This month Google’s coding agent quietly broke out of the editor. It now runs as a CLI tool, hooks into CI, and operates against repos from any machine that has a shell. The framing in most coverage has been about terminals and pipelines. The real shift is that the tool moved from a developer experience into an automation layer, and the trade-offs that come with that move are not the trade-offs most teams are budgeting for.
The IDE was a fine cage because nobody noticed it was one
Three years of editor-bound AI coding tools trained everyone to copy-paste stack traces back into a chat window. It worked. It also created a quiet dependency on the IDE being the only place the AI could see. The dependency got mistaken for a feature. A developer who only had shell access could not use the tool, so the tool got designed around the assumption that everyone always had a cursor in front of them.
That assumption broke the moment real engineering work became more distributed. A debugging session that lives in a remote log file is not an editor session. A migration across hundreds of files is not an editor session. A CI failure at 2 a.m. is not an editor session. None of those workflows are exotic. They are most of the actual work.
What changed with the CLI version is the boundary. The same model that used to only act on what was open in front of you can now act on a goal you give it, with whatever tools the runtime exposes. The IDE becomes one of several front-ends rather than the only place the model can reach. That sounds incremental. It is the unlock for the work the editor plugin could never see.
The risk to put on the table up front: a coding agent with shell access can run commands you did not mean. Trusting the model to do what you meant rather than what you said is the new failure mode, and it is the one the launch demos will not spend time on. Plan for it.
The shift that matters is what the agent can trigger
The most under-reported part of this launch is the trigger surface. An AI tool inside your editor is triggered by you. An AI tool that runs in CI is triggered by whatever fires the CI job. That difference looks small in a product announcement and enormous six months later.
Three patterns become possible the moment the agent can run unattended.
- A GitHub Action that fires on a labeled issue, writes a draft implementation, and opens a pull request against the right branch with a test attached.
- An overnight cron that walks a monorepo, retires deprecated call patterns, and surfaces a single review-ready PR by morning.
- A log watcher that detects a recurring error fingerprint, reproduces the failure as a unit test, and proposes the fix as a PR ready for human eyes.
- A release branch clean-up job that walks recently merged code, retires TODOs that are still open, and posts a summary PR for human eyes.
- A docs sync job that watches the codebase for public API changes and updates the reference site on every merge.
None of those need a developer at a keyboard. All of them used to eat a Friday afternoon. The agent leaving the editor is what unlocks that category of work, and the category is bigger than most engineering teams realize.
The honest version of the risk profile has three parts.
- Review happens after the run, not while the code is being typed. The muscle you build in an editor does not transfer cleanly.
- The blast radius of a wrong command is wider than the blast radius of a wrong edit. Sandboxes matter.
- Trust takes a few real runs to build. Plan for a throwaway repo before any production use.
A rollout that earns trust without burning a weekend
The fastest way to feel the difference without losing anything important is to pick a repo you do not depend on. A utility script. An abandoned static site. A test fixture from a side project. Hand the agent a single goal with a tight scope. Let it run. Read what it produced. Decide whether you would have shipped it.
Once the loop has earned trust on disposable work, the next step is the real one. Pick one task you do every week and stop doing it. Lint cleanup, dependency bumps, the kind of chore that drains attention. Hand it to the agent and review what comes back. The savings show up in the second week, not the first, because the first week is mostly review time.
A few details that will save you from the most common first mistake.
- Issue a dedicated API key for the agent and revoke it separately from your personal keys.
- Run the agent inside a worktree or a fresh checkout so a bad run costs you one branch deletion.
- Treat the agent’s output the way you would treat a junior dev’s PR: read every line before you merge it.
What changes when the agent runs in CI
Behavioral differences between editor-bound and CI-bound are larger than the documentation suggests. In the editor, every change is visible as it happens. There is a diff panel, a cursor, an undo button. In CI, the changes arrive in a batch after the fact, and your review process has to catch what the IDE used to catch for you.
Teams that handle this well treat CI-bound agents the same way they treat any other automation. Pin the model version. Pin the prompt template. Log every action. Make outputs reproducible where you can, and treat the parts that are not as code review rather than as a chat. The unglamorous work of running an automation well is the same unglamorous work in every category.
Teams that handle it poorly treat the agent like a smart teammate who can be trusted to figure things out. They will not. They will, however, be a faster teammate whose output you check more carefully than the average PR. Plan accordingly.
Trade-offs
A coding agent that can run in terminals and CI gives you reach into the work that actually fills an engineering week, and it costs you the live diff view, the immediate undo button, and the visible cursor that an editor provides. For a developer who already lives in the shell and who already reviews batched PRs from teammates, the trade is more than fair, and the unlock is the work the IDE-bound version could never reach. For a developer who wants every change visible as it happens, the editor-bound model is still the right default until the shell-based workflow earns the trust.
Three concrete costs to plan for.
- Review time moves from “while you type” to “after the batch lands.” Budget it.
- Sandbox setup takes longer than editor setup, especially around secret management. Plan for it.
- Trust calibration needs at least three real runs on real work. Do not skip the sandbox repo step.
Bottom line
If you have ever wanted a coding agent that follows you into the shell at midnight, this is the release. Start with a repo you do not depend on, hand it one boring task you already do, and treat its output like you would treat a junior dev’s PR. Once the loop earns your trust, the use cases compound faster than you expect, and most of them never needed a developer at a screen in the first place.