I Asked My AI to Teach Me Algorithms. We Ended Up Shipping a Factory.

It started as a lesson. A few hours later we had two tools in the team's hands and a machine that builds more of them.

I went into this wanting one small thing. I know the word "algorithm." I use software built out of them all day. But I could not have told you what one actually is without waving my hands. So I sat down with Claude and asked it to teach me, plainly, no math, like I was a smart adult and not a computer science sophomore.

The rest of it, I did not see coming. By the end of the afternoon we had shipped two real tools to the team and built a little factory that stamps out more of them. I want to walk you through how a lesson turned into that, because the way it happened is the actual point, and it says something about how working with AI is starting to feel.

First, the thing that finally clicked

An algorithm is a recipe. That is the whole word. A list of clear steps a very fast, very literal helper can follow. A cake recipe is one. The route your GPS picks is one. Boring so far.

The part that lit me up was this: for any job, there is usually a dumb recipe and a clever recipe, and they can differ by a factor of a thousand. Finding a name in a phone book by reading every page versus flipping to the middle and throwing away half the book each time. Same answer. Wildly different effort. And the single most useful instinct in the whole field is just learning to ask: "when this pile gets ten times bigger, does the work get ten times harder, or barely harder?"

That is not a programming question. That is a business question wearing a lab coat. It is why your app feels instant on a hundred records and falls over on a hundred thousand.

The insight that turned a lesson into a tool

A few lessons in, something landed that I could not unsee.

Picture two workers. An AI model is a brilliant, expensive intern. Stunning range, reads messy human language, reasons, writes. Also slow, costs money every time you ask it anything, and once in a while makes something up with total confidence. An algorithm is a clerk. Narrow, but free, instant, and never wrong about its one job.

Most "AI automation" being built right now is quietly paying the intern to do the clerk's filing. Asking a language model to sort a list, or remove duplicates, or score a lead by a rule you could write on a napkin. It works in the demo, everybody claps, and meanwhile you are renting a genius to alphabetize a spreadsheet.

The fix is a single question, asked of every step in a system: does this need judgment, or is it clerical? If you can write the rule down in a sentence, it is clerical, and a free algorithm should do it. Keep the expensive intern for what it is actually worth paying for. Meaning. Taste. Ambiguity. Language.

What got me is that this is a rare three-way win. Move the clerk work off the model and it gets cheaper, faster, and more reliable, all at once. You almost never get all three from one decision.

So we built the tool, then a factory to build more

Once you see a useful pattern, the move is to make it repeatable. So we turned that question into a small tool that reads a workflow and flags every place a model is doing clerk work it should hand off. Then we built a second one for a related question, "where is this AI just plain overspending."

Then the obvious thought. These two tools have the same shape. A single, sharp question. A read-only report. And here is the bit I am proud of: each one carries a built-in guard against its own favorite way of being wrong. So instead of building tools one at a time, we built a little factory that stamps out new ones with that shape baked in, plus a test bench that grades each one against an answer key written by a different AI, so it cannot quietly grade its own homework.

We ran the factory on its first real tool. The test bench immediately caught that the tool was too timid and missed the biggest savings. Which sounds like a failure and was actually the best moment of the day. We fixed the flaw once, in the shared blueprint, so every future tool inherits the fix before it is even built. The bench did exactly the job we built it for: it stopped a plausible, confident, wrong tool from shipping.

What this actually says about working with AI

Three things I am taking with me.

One. The fastest way to understand something is to build with it while you learn it. I was not trying to make tools. I was trying to understand a word. The tools fell out of genuinely getting the idea, because once an idea is real in your head you start seeing where it applies.

Two. The good stuff is not the AI doing magic. It is the boring discipline around it. The guard against being wrong. The independent grader. The honest benchmark that tells you your shiny new thing is not good enough yet. Anybody can generate a tool. The value is in proving it works before you trust it.

Three, and this is the one I will be repeating to clients. Using AI well is mostly knowing when not to. The intern is brilliant and should manage the work. But a manager who insists on doing all the filing personally is not impressive, just expensive. The craft is handing the clerical jobs to the clerks and saving the genius for the genius work.

We do this for a living, so naturally I will mention that if your AI setup feels like it is doing a lot of expensive filing, that is exactly the kind of thing we untangle. But honestly, even if you never call us, go ask your own system the question. For every step it takes, judgment or clerical? You will be surprised how much of it is filing.

I came for a definition. I left with two tools, a factory, and a much better question. Not a bad trade for an afternoon.

Robot Friends builds and untangles AI systems for teams who would rather their genius interns stopped doing filing.