Claude Code is not just a terminal tool
When people think about Claude Code, the first image that comes to mind is a terminal: a black window, commands, code scrolling by. That is where I started using it too.
But things have changed. Claude Code is now available as a web app at claude.ai/code and as a desktop app, in addition to editor extensions like VS Code. This is not a small detail: it genuinely changes how you can use it.
In this article I explain what I have learned using the cloud version, with a concrete example that involves this very blog.
What changes with the cloud
The main difference is one thing, but it matters: when you start an agent from the cloud, it keeps working even if you close the browser or put your laptop away.
In a local terminal, stopping the session stops the agent. From the cloud, the work continues on the server in the background. You can come back and check the result whenever you want.
This opens up interesting scenarios. You can schedule agents to start on a precise schedule, similar to a cron job (an automatic timer, like "every Monday morning at 8am"). This is useful for recurring tasks: generating reports, checking data, updating content.
Another thing I appreciate: skills (the folders containing reusable instructions for agents) are available from the cloud too, as long as they live in the project repository. You do not need to reconfigure anything. The cloud agent reads the same instructions you use locally. This makes your setup portable: build the behavior once, it works everywhere.
The underlying models are Claude's own, with Opus 4.8 as the default. Fable 5 is also available for certain use cases. I have no reason to stop using the terminal for daily work, but having the cloud as an additional option is genuinely convenient.
A concrete example: how this blog post was created
Let's get practical, because this is where things get interesting.
This article you are reading was written with the help of a dedicated skill. I have a folder in the site repository containing precise instructions on how to structure blog posts: frontmatter, tone, length, style rules (no long dashes, short sentences, no unnecessary jargon).
When I want a new post, I can write a brief and launch the agent. It reads the instructions from the skill, follows the structure, writes a draft in Italian and English, respects the format, and creates the files in the repository. The draft then comes to me for review. I read it, correct it if needed, and only then approve it for publishing.
The key word is "draft." I have not removed the human review step. I have removed the time it used to take to start from a blank page.
This setup has a hidden advantage: it can be connected to any external event. An automation flow (I have written about n8n in other posts) could listen for a message on Telegram, extract the title and brief, and start the agent automatically. The article would appear as a draft in the repository without me having opened a terminal or a browser. You come back, find the draft, review it, and publish.
I am not doing this in a fully automatic way yet, but the mechanism is already in place. The only missing piece is the connection between an incoming external message and the agent being triggered.
Running work from wherever you are
This is the biggest mindset shift I have had working with cloud agents.
Before, making the computer do something required me to be in front of the computer. Obvious, right? But with the cloud this is no longer always true.
You can start an agent from the web version while on a train. You can schedule one to run overnight, so you wake up to the results. You can, in the future, trigger work from a message in another app entirely.
I am not describing science fiction. I am describing tools that exist today, that I am using, and that are concretely changing how I organize my working days.
In this profession, location freedom is often tied to having your laptop with you. With cloud agents, you can decouple at least part of the work from that too.
What to watch out for
It would be dishonest not to say it: there are real risks, and they are worth naming.
The first is the permissions problem. Agents need permissions to act: reading files, writing to the repository, calling external services. Giving overly broad permissions "for convenience" is a mistake you will pay for. Think about what each agent actually needs, case by case.
The second is irreversible actions. If an agent deletes files, sends emails, or touches real data in a database, there is no undo. Before automating anything like that, build in a confirmation step. The agent proposes, you approve, then it executes.
The third, and I repeat this often, is credentials. API keys, passwords, access tokens: these must never go in text files in the repository, not even in agent instruction files. They belong in the environment variables of your cloud service, and nowhere else. A secret in plain text in your code is a risk that no convenience is worth.
The last point is reviewing the output. An agent working on its own produces a draft, not a finished product. I always treat it like a collaborator who has done a first pass, not one who has delivered the final result. That mindset has saved me from unpleasant surprises so far.
That said: the gain in time and focus is real. I have not stopped checking the work. I have stopped doing the most mechanical parts. And that is a difference you feel every single day.
