Working with an AI assistant without outsourcing your brain

Every section of this book has a prompt you can copy. This page is about using them well, because the difference between learning from this and ending up with a server you do not understand is mostly habit.

It is about the conversation, not about access. Giving an assistant a login on your server, or letting it run commands there unattended, is a different decision with a much larger blast radius, and this page does not cover it.

What the prompts contain #

When you copy one, you get a block of text with several parts already filled in:

A set of instructions about how to help you. One diagnostic command at a time, the reason before the fix, you doing the typing, and no wandering off to reorganise the rest of your server.
Where you are. The book, the chapter, the section heading.
What you have already built, accumulated from every chapter before this one. This is why you do not have to explain your setup.
What the current chapter is for, and what state your machine should be in.
A slot for your error, at the bottom, where you paste what you actually ran and what it printed.

That last part is the only bit you have to write, and it is the part that decides how useful the answer is.

The habit that makes this work #

Read the error first. Then form a guess. Then ask.

It slows you down by about ninety seconds. What it buys you is the ability to tell a good answer from a plausible one. If you have no opinion about what is wrong, then any confident explanation will do, and you will accept the first one you are given. If you arrived with a hypothesis, you are having a conversation instead, and you will notice when the reply does not fit.

A useful test: before you paste, try to finish this sentence out loud. "I think the problem is X, because Y." If you cannot, spend two more minutes reading the output. Linux error messages are far more informative than their reputation suggests. They are just written by people who assumed you already knew the vocabulary, which after a few chapters of this you will.

Paste the whole thing #

The most common way to get a bad answer is to summarise the error yourself.

"It says permission denied" throws away the part that mattered. Which file, which user, which operation, and what came in the four lines before it. Paste the command you ran and everything it printed, including the parts that look irrelevant, because you are not yet in a position to know what is irrelevant. That is the whole point of asking.

Same for configuration. If the question is about a file, paste the file. If it is about a service, paste systemctl status and the last twenty lines of its log.

When it is wrong #

It will be, sometimes, and it will be wrong in a particular way: fluent, specific, plausible, and about a machine other than yours. This happens because it cannot see your machine and because sounding certain is easier than being certain.

Some ways this shows up on a home server, all of which I have seen:

A flag that does not exist in your version of the tool. Versions matter enormously here, and the internet is full of instructions for the release before yours.
A path that is nearly right. /etc/ssh/ssh_config instead of /etc/ssh/sshd_config will waste a genuinely annoying amount of your time.
A confident diagnosis that fits the symptom but contradicts something you can see. Firewall blamed for something that never reached the network.
Advice to disable a security control to make an error go away. Sometimes correct as a diagnostic step, almost never correct as a fix, and it should always come with a plan to put it back.

What to do about it is short:

Trust what you can see over what you were told. Your terminal is the authority. The assistant is a colleague who is not in the room.
Say so plainly. "That flag does not exist in my version, here is --help." A good response to that is a correction, not a defence.
Ask what would settle it. "Which single command would distinguish between your explanation and mine?"
Refuse the vandalism. If you are told to turn off a protection, ask what specifically it is blocking and how you would confirm that. Often the real answer is a narrower rule.

Two things worth never doing on a suggestion alone

Anything that writes to a raw disk device, and anything that reinstalls or wipes to "start clean". Both are occasionally the right answer and neither should be reached for before you understand the problem. If you are told to do either, that is the moment to stop and ask what evidence points there.

The commands you should not need to be given #

There is a small set worth knowing by hand, because reaching for a prompt to remember them is where the learning quietly stops:

$ systemctl status <unit>
$ journalctl -u <unit> -b --no-pager | tail -40
$ ss -tlnp
$ ip -brief addr
$ df -h
$ ls -la <the directory in the error message>

Nearly every problem in the first half of this book is diagnosed by two or three of those. If you can run them and describe what you see, you are already doing the part that matters, and the assistant is just filling in the vocabulary.

Using it to go deeper, not just to unstick #

The prompts are framed around being stuck, but the more valuable use is the other one. When a chapter tells you that something is true and you want to know why, ask. When a chapter makes a trade-off and you suspect it is the wrong one for you, argue about it. When you have finished a chapter, ask it to quiz you on what you just did and see whether your explanations hold up.

Following instructions and explaining them are different skills, and the second is the one that helps at 11pm.