Here's a cheap way to learn how LLMs actually work: please, I beg you, don't take another course.

Pick one repetitive thing you do every week and turn it into a system.

I'm not saying automate the thing you love doing. I'm telling you to look at all that repetitive stuff around the thing you're doing.

You make videos

You want to make the video. That's the creative part. That's the reason you started.

But one video creates a whole trail of little jobs afterwards.

One video, and the trail of little jobs it creates: video, transcript, vlog notes, description, chapters, social posts, archive and tag everything, update your content tracker

None of those tasks individually feels like a big deal. That's exactly why they're interesting. You do them again and again. They happen in roughly the same order. They take something in, do something predictable to it, and produce something else.

That's a system. You've been running it manually this whole time without calling it anything.

Where the LLM actually comes in

You don't even need to automate this yet.

Take the transcript. Give it to an LLM. Ask it to write the description according to rules you've written. Check the result. Fix your rules where the result was wrong. Then try the next step.

Once that works reliably, connect two steps.

Then three.

The point isn't to build an impressive AI system. The point is to understand your own system well enough that you can decide what should be automated. Most people skip straight to the second half of that sentence, which is why they end up with something that produces output nobody wants and nobody checks.

You're a writer

Same exercise, different shape, and this one needs a boundary drawn in permanent marker.

The system is:

YOU WRITE → manuscript → formatting → consistency check → metadata → submission and publishing checklist → archive

It is not:

IDEA → AI WRITES BOOK → AI EDITS BOOK → AI PUBLISHES BOOK

I've written about what happens when you try the second one. It cost me a novel and two months of editing that went nowhere.

But the first one is genuinely useful, and it's the version nobody talks about because it isn't exciting. Checking whether your character's eye colour changed in chapter nine is not a creative act. Neither is generating your keyword list, or working through the fourteen boxes a publishing platform wants filled in, or making sure the file you're uploading is the file you think it is.

The thing I want to do sits in the middle: write. Everything else is orbit. The system handles the orbit. You keep the centre.

You work in an office

You don't have to be a creator for this to apply. Most office work is a small amount of judgment surrounded by an enormous amount of administrative trail.

A client project starts as an inbox full of noise and ends up as: extract requirements → project brief and scope → task breakdown and timeline → updates and touchpoints → final delivery → archive and lessons.

Three worlds, three systems: the YouTube video trail, the writing workflow, and the client project from chaos to clarity

Think about how many people spend an entire career doing precisely this. A meeting happens, and then someone spends the rest of the afternoon turning it into notes, decisions, action items, owners, deadlines, and a follow-up email that mostly restates what everyone already heard.

The meeting isn't being replaced here. Neither are the decisions. The decisions are the part that requires a human who understands the client, and delegating those blindly is how you end up committing to a deadline nobody can hit. What the system handles is the trail the meeting leaves behind.

Three genuinely different worlds, same underlying shape:

  • Creator: one video creates eight little jobs.
  • Writer: protect the creative core, systematize everything around it.
  • Office worker: one meeting creates a trail of admin.

Start embarrassingly small

Forget Ubuntu. Forget Ollama. Forget agents. Forget diagrams with 47 boxes and twelve databases in them.

Open whatever LLM you already use. Write down one thing you repeatedly do. Then answer these, in order:

  • What starts the process?
  • What happens next?
  • What happens every single time?
  • What requires judgment?
  • What doesn't?
  • What should always require my approval?
  • What is the final output?

There's your first system. Written in plain language, on one page, by you.

Only once you can see it written down does automation become a sensible conversation. At that point you can start handing individual steps to a model, one at a time, checking each one until it's boring and reliable. Then you can string the boring reliable ones together and let them run without you. That's the whole arc, and it takes weeks, not an afternoon.

Most people do it backwards. They build the automation first, discover it produces something slightly wrong, and can't tell you why, because they never understood the process well enough to describe it in the first place.

The point

You don't need to automate your creativity.

You don't need to automate your hobbies.

You don't need a diagram that looks like you're operating a nuclear reactor.

Learn to see the systems around the work you love. Then let the machines help with the boring parts.

Keep the fun part for yourself.