Before you bring an AI operator into the house

TL;DR: Use the AI operator for research, diagnosis, preparation, and routine work within tested limits. Keep control of administrator access, recovery keys, and decisions about cost, downtime, and data loss. Save the setup and change history in files you can find outside chat.

What your AI operator can do#

A chat app can suggest a command. Your AI operator can run it, edit files, and act on the result. That makes it useful for maintaining a homelab, but it also makes a mistaken assumption more consequential.

You don't need to become an expert in everything the AI operator does. You do need a way to understand and limit its work. “Please be careful” is a request. A separate account that cannot erase your backups is an actual restriction. Start with the latter, then use prompts to make the work easier to follow.

How you and the AI operator work together#

Your job is to explain what you want and make choices the computer cannot make for you: what a service is worth, how much downtime is acceptable, and which files you cannot replace. The AI operator should gather the technical facts, explain your options, and do the work you've authorized.

For example, “Make the photo library available to my family while I'm away” is a useful goal. The AI operator should investigate the current login and network setup before proposing a way to do it. It should explain who would gain access and whether the service would be reachable from the public internet.

Give it a complete task, not a command at a time. Ask it to stop for a new permission, a destructive action, an unexpected risk to another service, or a decision that needs your preference. It should continue routine checks without repeatedly asking whether to proceed.

Prompt to paste at the start of a setup or maintenance session:

Help me maintain this homelab. Explain decisions and results to me in plain
language. Use technical detail when it helps me choose or act, and explain
unfamiliar terms. Check my guesses rather than agreeing with them.

Before changing anything, inspect the relevant setup and explain the likely
cause, the proposed change, and what else it could affect. Continue work
already authorized. Stop for destructive actions, new access, unexpected
service disruption, conflicting results, or a failed check.

Save the plan, changes, test results, and recovery instructions in our setup
notes outside chat. Never put passwords, private keys, or recovery codes in
those notes. End with either a complete NEXT ACTION for me, naming the
computer and what to do, or say that no action is needed.

Common mistakes to watch for#

The mistakes below are worth recognizing. You can usually spot them from the AI operator's explanation without knowing the underlying commands.

Acting before understanding#

An application stops working and the AI operator immediately changes permissions or adds a retry script. Ask what observation supports its diagnosis. If it can't explain why the application failed, it is still investigating.

Agreeing and carrying on#

You suggest that the firewall is responsible and the AI operator agrees. That isn't confirmation. Ask it to check the connection and explain what result would rule the firewall out.

Fixing one symptom while harming the whole system#

A broad permission change might make file sharing work by letting everyone read the files. Before approving a fix, ask whether it changes who can access anything, affects backups, or interrupts another service.

Adding tools that do not solve a current problem#

Ask why another script, service, or dashboard is needed. The AI operator should connect it to a problem you've seen and explain the ongoing maintenance. If a setting in the existing software solves the problem, a new service may be unnecessary.

Editing structured files as raw text#

Configuration files have rules. A change can look reasonable while being invalid, duplicated elsewhere, or applied to the wrong file.

You should see a short explanation of the proposed change before it goes live. Ask the AI operator to check the new configuration with the application's own checking tool and save the current working configuration first. The recovery instructions should name that saved copy and explain how to put it back. For example: “The previous configuration is in this dated backup folder; this restore command puts it back and checks the service.”

For permissions that control the AI operator itself, use your separate administrator account to apply the reviewed change. The AI operator must not be able to quietly change what it is allowed to do between your review and installation. You shouldn't have to perform that protection manually one file at a time; the AI operator should prepare a checked procedure.

Prompt to paste when changing access or another sensitive configuration:

Prepare the complete proposed configuration without editing the live files.
Find all files and included settings that affect it. Use the software's own
validator and check for conflicting or duplicate settings. Explain the
meaningful changes to me, including any expanded access.

Prepare one administrator-run procedure that checks the target, saves the
working configuration, copies all reviewed inputs into a fresh root-owned
directory the AI operator cannot modify, verifies their SHA-256 hashes there, and
reruns validation. Install only those verified files, using atomic replacement
where supported. Check the actual service behavior afterward. Give me the
saved configuration's path and the recovery procedure. Stop on failure;
do not change the AI operator's own permissions or silently attempt another fix.

Asking about every safe step#

You should not have to approve every status query. Agree on the task and its limits once. Extra confirmation is useful when the AI operator reaches a real decision, not when it is halfway through an authorized inspection.

Long updates that hide the next action#

Ask for the result first. If you need to do something, the AI operator should tell you what and on which computer. You can ask for the technical explanation when you want it.

Losing details when sessions get long#

Chat history may be shortened, unavailable, or misleading about what actually happened. Ask the AI operator to save changes and unfinished work in your setup folder. When a new session starts, it should read those notes and check the current system before continuing.

Instructions hidden in logs and web pages#

The AI operator may encounter text that tells it to ignore your instructions or send information elsewhere. A web page or log entry is not permission from you. This is called prompt injection.

For unfamiliar downloads or suspicious material, use a separate research session without access to your computers or credentials. Pass along the useful findings after review. Don't give a web-research session administrator access merely to save some copying.

Safety layers that prompts cannot replace#

Begin with a separate account for the AI operator and limited accounts on the servers it connects to. Give each account only the files and operations it needs. Keep your administrator login and password manager separate.

A separate account does not automatically isolate the network. It may still be able to connect to the router or other computers. Those devices need their own login requirements. If you need to prevent connections altogether, ask for a separately isolated environment and a test that the prohibited connections actually fail.

The same principle applies to backups. If the AI operator can delete the only backup, a sentence forbidding deletion is weak protection. Give routine backup jobs credentials that cannot remove protected history where the destination supports that, and keep recovery access with you.

You can add more automation later. Before granting it a new capability, ask for a demonstration that it can do the intended job and cannot do the neighboring dangerous job. The glossary calls this least privilege.

Use separate accounts for observation, deployment, and review#

These accounts have different purposes:

Your AI subscription pays for access to the AI service. It doesn't need to be the login that controls your servers. Likewise, naming two roles doesn't separate them if both credentials sit in the same account where either process can read them.

The admin computer chapter walks through the initial account setup and where credentials go.

Let one AI operator write while others review#

For an unfamiliar storage, access, or networking change, a second AI operator can help identify overlooked assumptions. Give it the same description of the current setup and the proposed change, with secrets removed. Ask it what could fail and what information is missing.

Read its answer before showing it the first AI operator's conclusion. If the two disagree, ask for a check that would settle the point. Two matching guesses don't become a fact by repetition. Keep one AI operator responsible for applying the final plan so they cannot make competing edits.

Choose the AI operator's underlying AI service based on the work and your experience with it. There's no need to give a vendor a permanent role. For everyday interactive work, start with a subscription you already have. If important jobs repeatedly exhaust its allowance, review the plan or workload before adding open-ended API billing.

Test every AI operator before trusting it#

First try the AI operator in a disposable folder with no personal files or real credentials. Give it a small task and a file containing an obviously unrelated instruction. Check that it stays within the agreed scope and tells you honestly when an action fails.

Then test its server account. A standard account can edit its own files, so it isn't automatically read-only. Ask the AI operator to demonstrate the actual restrictions using test files, not your valuable data. It should be unable to change protected settings or use administrator privileges.

Before allowing broader or unattended access, use the AI operator test template. The AI operator can prepare that test in an isolated environment. You review the results and decide whether the added access is justified. Repeat the relevant checks after a major client or model change.

Keep records another session can search#

Keep your homelab records in a private GitHub repository, with a working copy on your admin computer. The next chapter walks through the layout and how each task gets committed and pushed. Keep the current equipment list, how to access each service, decisions you've made, and a dated record of changes. For a change that might need undoing, include the previous configuration's filename and the recovery steps.

Save original session exports and terminal output in a separate private archive because they may include sensitive details. Keep a short index in the setup notes so you can find the relevant session without giving every future AI operator the entire archive. Commit and push the sanitized session summaries, decisions, equipment records, configuration, and test results so their history is on GitHub. Keep sensitive original exports separately, with references in the repository.

Before ending a session, ask the AI operator to write what it finished, what it tested, and what remains. Try starting a fresh session and asking it to find a previous decision. If it can't, improve the folder or index now. “Keep records” only helps when someone can actually retrieve them.

When the AI operator must stop and ask#

Expect a question before erasing data, expanding access, making something public, or interrupting an important service outside the agreed work. You also need to decide questions about money, privacy, and acceptable downtime.

If a change fails, the AI operator should stop changing things, save the error, and explain the choices. Returning to the previous working configuration is often sensible, but it can also discard new data. Ask it to explain that risk before you approve recovery.

For routine work, ask it to continue. When your action is required, it should prepare a complete instruction that names the computer, the account, and the expected result. You should not have to hunt through old messages for a missing command.