ComputeSphereLearn
Console
Learning paths / Vibe coding to production / Operate, cost and when to stop

Operate with an agent, safely

Reading · 6 min · Module 9, lesson 1 of 446 min left in this module

Module 9 · Operate, cost and when to stopLesson 1 of 4

Goal: Use an agent to read logs and status on a live service, approve its changes, and keep the actions it must never take alone out of its reach.

3:55 · captions and chapters · narrated with an AI-generated voice
Transcript

Narration uses an AI-generated voice.

[00:00] Where we're going

By the end of this video, you'll know how to put an agent to work on a live app, safely. It reads freely. It changes things only with your yes. And a few things, it never does alone.

[00:14] Reading: let it loose

Logs are where an agent saves you the most time. It reads hundreds of lines in seconds, and groups what matters. Here's a service on a demo account that won't start. So give the agent a reading job, and say it's read-only. Group the errors. Name the likely cause. Quote the lines. And don't change anything.

It starts with the help, then reaches for the same commands you would. The runtime logs. The deploy log. And the deployment's status.

[00:46] Quote the lines

Here's its report. One error, every time the app starts, and the lines quoted. The app needs a secret called nonce secret, at least thirty-two characters long, and it isn't set. It also says what it didn't do. Every command it ran only read.

Ask for the quote every time. A summary can drop the one line that matters. So open the log yourself, before you act on it.

[01:15] Changing: approve each one

Now ask for the fix. It brings the exact commands, and runs none of them. Changes like these are everyday operations. Each one still gets your yes. Before you give it, check the command. The ID. And the environment. Then ask one more question. What does this do to users' data?

Take the starter from this path. It keeps its tasks in memory. So a restart that clears an error also deletes every task your users added. A redeploy does too.

This demo service keeps no data, so the answer is yes. You run it yourself. The secret comes from a variable, so its value never shows. Then the redeploy. And it's Running.

[02:06] Never alone

Some actions can't be undone, or hurt people who aren't in the conversation. The agent proposes them. A human does them. Deleting a service, environment, project or volume. Deleted data doesn't come back. Rotating or replacing production secrets. A new key locks out everything still using the old one. Changing domains or DNS. A mistake takes the site offline. And creating or revoking tokens, or changing plans and billing. Put this list in your instruction file, and keep approval on for commands.

[02:45] A project token

And the agent never had your sign-in. It used a token for this one project, expiring in a week. So a mistake stops at this project. Revoke it when the work is done.

[02:57] When it's on fire

And when it's on fire, undo first, diagnose second. If a new version broke things, roll back to the last good one. Then investigate while users are served. Fixing forward feels fast with an agent. Under pressure, one bad release becomes three.

[03:16] Recap

To recap. Let it read freely, and make it quote the lines. Approve every change, and ask what it does to data. Keep what can't be undone out of its hands.

Here's a question to check yourself. Your agent suggests restarting the starter to clear a stuck error. What should you weigh first? That a restart wipes the tasks, because they live in memory. Next, see what running an agent costs, and when to stop. I'll see you there.

Key idea

On a live app, an agent is a fast pair of eyes. Let it read freely: logs, status, history. Let it change things only after you approve each one. And keep a short list of actions it never takes alone, because they can't be undone.

Reading: let it loose

Logs are where an agent saves you the most time. It reads hundreds of lines in seconds and groups what matters. Ask for a reading job, and say it's read-only:

Read the last hour of vibe-starter's runtime logs and its deploy log.
Group the errors, tell me the most likely cause, and quote the lines.
Don't change anything.

The commands it will reach for:

csph logs vibe-starter --since 1h
csph logs vibe-starter --kind deploy
csph logs vibe-starter -q error
csph deployments get <deployment-id>

Ask it to quote the lines behind its conclusion. A summary can drop the one line that matters, so open the log yourself before you act on it.

Changing: approve each one

Redeploy, restart, scale and variables are everyday operations, and each still gets your yes. They're less harmless than they look. The starter keeps its tasks in memory, so a restart that "clears the error", or a redeploy that applies a change, also deletes every task your users added. An agent that doesn't know that will suggest it cheerfully.

When you approve, you're checking the command, the ID and the environment, as in lesson 4.8.2, plus one more question: what does this do to users' data?

Never alone

Some actions can't be undone, or hurt people who aren't in the conversation. Your agent proposes them, explains why, and a human does them, or at least reads the exact action first:

  • Deleting a service, environment, project or volume. Deleted data doesn't come back.
  • Rotating or replacing production secrets. A new key locks out everything still using the old one, and secrets set --replace removes every secret you didn't list.
  • Changing domains or DNS. A mistake takes the whole site offline for everyone.
  • Creating or revoking tokens, and changing plans or billing.

Put this list in your instruction file's "never without asking" section (lesson 4.7.1), and keep your agent's approval setting on for commands. A project token already keeps all of this away from your other projects.

When it's on fire

Undo first, diagnose second. If a new version broke things, roll back to the last good one (lab 4.9.3), then investigate with the agent while users are served. Agents make fixing forward feel fast: another quick change, another deploy. Under pressure that's how one bad release becomes three. A rollback is one known step back to a version that worked.

Check yourself

Your agent suggests restarting vibe-starter to clear a stuck error. What should you weigh first?
Which of these should the agent never do alone?

In the docs