Practical AI for IT Admins
Faster scripts, clearer docs, and the discipline to not paste the config.
For the people who keep the systems running and are now also expected to have an opinion on AI. This course is practical in the specific sense: what to paste, what never to paste, and how to get the tool to do the boring half of the job (docs, first drafts, explaining someone else's script) while you keep the half that carries the risk.
What it is
Six short lessons, each built around a job that is already on your plate: pasting the wrong thing, reading someone else's script, writing the runbook that never gets written, telling users what is broken, and answering the policy question that keeps landing on your desk. Every lesson has real prompt text you can copy and ends with one thing to do this week, on your own systems, with your own material.
What it is not
It is not a tour of products, and it is not a recommendation to put a model between you and production. Nothing in here runs unattended; you read every line before it executes. It also assumes nothing about your stack — the habits work the same whether you run servers, endpoints, or both.
What you need
- One hosted AI assistant you can type into, on a free tier. Any of the well-known ones. Do not go shopping before lesson 1; the course is about habits that survive the tool changing.
- A terminal on a machine you control, and somewhere to put a small script on your
PATH. Nothing to install and nothing to buy. - A throwaway host, container, or VM you can break. Not production, and not "production but carefully."
- Your own material, open in another window — one real log excerpt, one config you did not write, the oldest uncommented script you own, a closed ticket that took more than an hour, and the how-to your team resends most often. Every exercise runs on these rather than on samples.
- A repository or folder your team actually uses, for the artifacts you build: a never list, a redaction script, runbooks, a notices file, a policy draft.
- About five hours, which you can spread across a fortnight. The first four lessons take half an hour or less each. The last two are longer and are where the rest of the time goes: lesson 5 asks for about ninety minutes, most of it waiting on a download, and lesson 6 for about two hours, best split into one sitting to draft and stress-test and one to run the review.
How to work through it
In order. Lesson 1 draws the boundary every later lesson stays inside, and if you skip it the rest of the course is a way to get yourself in trouble faster. After that, each lesson assumes the artifact the previous one told you to build — lesson 2 assumes your redaction script, lesson 4 assumes you have somewhere to file things, lesson 6 assumes the never list from lesson 1 is written down.
Pace it at one lesson per sitting — two for lesson 6 — with the "Do this now" exercise done before you open the next. That exercise is the lesson; reading without doing it produces a pleasant hour and nothing on disk. A fortnight at two or three lessons a week is a better shape than an afternoon, because the habits have to survive a real bad day to be worth anything.
Keep three things open while you work: the lesson, your own material, and a scratch file where every prompt you send goes. The scratch file matters more than it sounds — a prompt that worked and was not saved is a prompt you will rewrite worse next month.
The toolkit page is the other half of this course. It carries every prompt finished rather than abbreviated, the templates the lessons tell you to build, and a one-screen reference for the boundary. Read the lessons for why, then work from the toolkit forever after; that is the page you keep open at 4:40 on a Friday, not this one.
By the end you will have a redaction script, a never list, a set of message templates, a runbook or two, a measured local model or a clear reason not to run one, and a policy draft that has already been argued with.
By the end
- you can use AI to draft, explain, and review scripts and configs without handing it anything sensitive
- you can turn a messy ticket thread into documentation, a runbook, or a clear message to users
- you can set up a local or approved tool so the work stays inside your boundary
- you can write the AI acceptable-use guidance your organization keeps asking you for
Lessons
- 01The boundary first
What goes in, what never does, and how to redact a config or a log so you can still get a useful answer.
free · 35 min - 02Scripts and configs
Draft it, explain it, review it — and the reasons you still run it in a test environment first.
subscribers · 35 min - 03From ticket thread to runbook
The documentation that never gets written, written — because it now takes ten minutes instead of an afternoon.
subscribers · 30 min - 04User communication
Outage notices, change announcements, and the how-to nobody reads — made readable, in your voice, in minutes.
subscribers · 30 min - 05Running it locally
When an on-machine model is the right answer, what it costs, and how to stand one up without a project.
subscribers · 40 min - 06The acceptable-use policy you have been asked to write
A one-page policy people can actually follow, drafted, stress-tested, and defensible in the meeting where it gets questioned.
subscribers · 40 min
The toolkit
- kitThe admin's toolkit
Every prompt from the course finished rather than abbreviated, the templates it told you to build, the six exercises as a checklist, a one-screen reference, the resources worth keeping, and one admin's week start to finish.
subscribers - fileYour starter file
The one note file the course tells you to keep, already laid out: your context block, every prompt in its slot, the templates, the routine, and the six done-lines as a checklist. Markdown; opens in any notes app.
subscribers