We learned to think like machines. Now we have to unlearn it.

Cristiano Sacchi

For the last fifty years or so, we have automated everything that could be automated with an algorithm. It turned out to be a lot. Payroll, inventory, billing, shipping, bank transfers, airline bookings... most of what a business does every day runs on a process that someone once drew as a flowchart and someone else turned into code.

Something else happened along the way, less visible but just as important: we got very good at designing processes that can be automated. We learned to think in steps, conditions and loops. Give an experienced process designer a messy business problem and you get back a clean sequence of IF/THEN boxes. The two skills grew up together, and together they worked like a charm.

So... here is the thing. That second skill is now the problem.

This is not an anti-algorithm post

I love algorithms. They are predictable, repeatable and auditable. When something goes wrong, you can trace exactly why. When one is available, it's the best tool we have, and I don't see that changing.

But algorithms are bad at inference. Not a little bad... structurally bad, the way a car is bad at flying. Nobody hates cars because they can't fly. You just don't drive one across the ocean.

So my rule is simple: use an algorithm wherever one is available. Use inference only where it isn't.

The interesting part is the second half of that rule... because for fifty years it didn't exist.

The graveyard

Every process designer has killed processes in a design meeting. Everything is fine until step 4, which says "decide whether this customer is trustworthy," or "check whether this document is relevant," or just "use judgment." There's no algorithm for that. So the process gets redesigned around the judgment, or a human gets stuck in the loop forever, or (most often) the idea quietly dies.

Nobody counted those. They didn't feel like failures, just ideas that weren't practical. And over time we stopped proposing them at all: a good designer learned to see the step-4 problem coming and steer around it before the meeting.

That's the graveyard. It's big, and every business has one.

"Is this English?"

A small example of my own. Years ago I built an automation, in Make, that takes new videos from our partners' YouTube channels and publishes them on our website, to help them promote whatever they're promoting. Pure algorithmic plumbing: new video, grab the details, post it. It worked perfectly.

Except for one thing. Some partners post videos in languages other than English, and we only sell in the US and Canada. So every morning I scrolled through the day's posts and removed the ones that weren't in English. A few minutes a day, every day, forever. The one step I couldn't automate.

One of the first things I did when language models became usable was add a step: send the transcript to the model and ask "Is this English?" If the answer is no, don't publish. One sentence. Done.

Now, the engineers reading this are already typing: language detection is a solved problem, just use langdetect or fastText. Fair. Could I have done it algorithmically? Yes-ish. Find a library, figure out how to run it inside the workflow tool, pick a confidence threshold, decide what to do with a video that's half English and half Italian... it's a project. A small one, but a project. Which is exactly why I never did it: the manual check was cheaper than the project.

And that's still not the real point. The real point is the next question. Once the English filter works, the obvious next one is "is this a product video, or a recording of the partner's holiday party?" There's no library for that. There's no library for most of the questions a business actually asks. With inference, every new judgment is one more sentence. With algorithms, every new judgment is a new project... usually one nobody approves.

Digging up the graveyard

That's the near-term shift, and it's already happening: algorithmic workflows with an inference step dropped in exactly where the judgment used to be.

"If this customer's history shows responsible behavior, extend the payment terms." In the algorithmic world you could sort of do that. Build a scoring model, train it, validate it, tune the thresholds... then explain to the credit manager why the model said no to a customer she has known for fifteen years. A lot of complexity, and a result nobody quite trusted. Now it's one step in the workflow that reads the history and answers, with a reason attached that a human can check.

Algorithms still do everything they're good at: moving the data, applying the rules, keeping the records. Inference does only the part nobody could write down. The unpredictable part stays as small as possible, and deterministic machinery does everything else.

The hard part isn't the technology. It's going back to the ideas we stopped proposing, which first means noticing that we stopped.

The longer run: stop drawing the flowchart

There's a bigger shift further out. I'm less sure about this one... but I think it's the one that will make the world tangibly different.

Today, even with inference in the loop, we still design the process first. Someone draws the flowchart, decides the steps, and implements them with their favorite tools. The inference step is a new kind of box, but it's still a box in a flowchart a human drew.

What happens when we stop drawing the flowchart? When we declare the goal, the constraints and the budget, and let an inference engine work out the steps?

That sounds like science fiction until you notice we already do it every day... with people. Nobody hands a senior employee a flowchart. You tell them what you want, what they can't do and how much they can spend, and then you check the result. Armies have called this "commander's intent" for more than a century. Management theory has called it management by objectives since the 1950s. We know how to delegate a goal and verify an outcome. We've just never done it with machines, because machines could only follow procedures.

If that shift comes, the core skill changes. It stops being "design the steps" and becomes "state the goal precisely, and know how to check that it was reached." That's a different skill from the one we spent fifty years perfecting. Some people will find it natural. Many of us, especially the ones who were best at the old way, will find it very uncomfortable.

That's what I mean by unlearning. Not forgetting algorithms. Forgetting the reflex that every process has to be one.

It's also why Heurivon is built around goals rather than workflows: you tell it what you're trying to achieve, and it keeps track. We're at the very beginning of that, and I won't pretend we've solved the "verify the outcome" half. But I'm fairly sure it's the right half to be working on.

What's in your graveyard?

Think of one process you killed, or never proposed, because a single step needed judgment. Chances are it deserves a second look.

— Cris