Cheap Codification

Today, I wanted to share an observation I’m seeing increasingly as organizations are building more with AI:

In a lot of cases, AI creates the most value by letting you build a solution that ultimately doesn’t need AI at all.

Let me explain.

The thing I’ve realized is that once people discover the power of AI, they often use this “magic” for something that is actually quite straightforward.

Usually, the prompt looks like this:

If this looks like a decision tree to you, it’s because it is.

Most of these rules actually aren’t ambiguous and don’t require much interpretation

It’s simply that nobody wanted to spend the time (or had the necessary tool or skill) to translate those rules into a proper automation based on explicit logic.

The thing is…

The LLM prompt really shouldn’t be the solution.

It should be the instruction for building the solution.

One of the most powerful things AI can do today is to write code.

Most people have experienced this through something like “vibe coding” (or at least seen it on social media). “Describe what you want and let AI build it for you.”

Sometimes it works.

But most people will also hit a wall quickly because building an app that works “kind of” and building an app that works reliably in production are two very different beasts.

And that’s not a rabbit hole worth going into for most business users anyway.

I think the more interesting implication is broader than building apps.

Because code is really just one way of codifying rules.

And businesses are full of rules:

For a long time, many of these processes stayed manual not because the rules were impossible to define, but it was just too much effort to turn “here’s how this should be done” into “here is the exact logic a system can do every single time.”

Traditionally, this was a classic consultant job and it would cost a company 4 figures and a purchase order just to get started. For many smaller automations, that made the economics unattractive.

But with AI, the economics of that translation have changed dramatically.

You can literally describe how a process should work in plain language, and any modern AI model can help turn that into whatever deterministic system makes sense – like code, workflow logic, formulas, or decision tables.

All of these are just different forms of codification.

Turning something that’s done by you today into something that runs without you – and can be tried and tested.

And once it works, you may not need AI anywhere in the actual execution.

That’s what I mean by cheap codification.

AI can write the system without having to be the system.

This leaves us with a fairly simple question:

Where should AI actually sit in the system?

I usually see 3 cases:

If the process can be easily described upfront in a handful of steps without many branches or exceptions, just build a normal workflow.

Drag and drop a few nodes together in n8n, Zapier, Power Automate, or whatever workflow automation tool you’re using and call it a day.

You might still use AI for individual steps like extracting information from a document, classifying text, or summarizing something.

I call these AI Workflows.

The process itself remains largely deterministic. The workflow decides what happens next, while individual AI steps introduce some uncertainty where it’s actually useful.

For example, you might use AI to classify an incoming email and then use deterministic rules to route it based on that classification.

Run the same email through the classifier a thousand times and you might get a few different classifications.

But the routing logic itself doesn’t change.

Sometimes it’s simply impossible to reasonably define every possible path in advance.

The system genuinely needs to interpret context, decide what to do next, use tools, or react to situations you didn’t explicitly anticipate.

For example, you want to automatically draft a reply to an incoming email.

Depending on what comes in, the system might need to open (or unzip) an attachment, look up internal information, review a style guide, or check whether it needs input from someone else.

Even if you had all the time and money in the world, you couldn’t really map all of those paths upfront.

Here, the ambiguity is part of the problem you’re trying to solve.

That’s typical AI Agent territory.

This is the case I think we’ll see much more often.

The process itself doesn’t really require an agent. Sometimes it doesn’t even require AI at all at runtime!

It’s just painful to translate all the rules into something a computer can reliably process.

Let’s stick to the email example.

Some companies have tried solving this with Rules in Microsoft Outlook on a shared inbox:

The problem is that these rules often start simple but grow more complex before you can say “email automation.”

At some point, the person who set this up just leaves, and nobody understands the logic anymore. The whole thing gets abandoned over time.

This is where you can use AI to do the tedious part for you.

Describe how the process should work and let AI help you build the underlying logic. When something changes, use AI to update it. Then test the result and deploy it.

The system itself can still be 100% deterministic – no AI involved at runtime. Run the same input through it a thousand times and get the same output every time.

The distinction matters because these are very different architectures.

Just because AI is the easiest way to build the system doesn’t mean AI should be the thing running it.

At first, the three cases might sound like a nerdy discussion for AI architects. You just pick whichever architecture you prefer, right?

But that’s not the case.

There’s an economic reason I care about this.

Every time you put an LLM into the execution path, you introduce another variable that adds:

Sometimes that trade-off is absolutely worth it – for example, when the task genuinely benefits from AI interpretation or judgment.

But if the underlying logic can be codified, then paying a model to reinterpret the same rules every single time is simply unnecessary and creates more problems to solve.

This is where cheap codification becomes interesting.

AI can help you build the boring, reliable automation that should have existed all along. It dramatically lowers the cost of building the deterministic system.

You still get the speed advantage of AI.

But you don’t necessarily inherit all of its uncertainty at runtime.

This is why I think “vibe coding” is only the most visible part of what’s happening.

The bigger opportunity is that AI is lowering the cost of turning business knowledge into something explicit and executable.

Not every automation needs AI at runtime.

Sometimes the best use of AI is simply to help you codify what you already know – faster, cheaper, and with less effort than ever before.

That opens up a whole category of automations that previously weren’t worth building.

Which is why, when you look at a process, I’d like you to ask:

Does this really need AI to run – or do I just need AI to help me build it?

See you next Saturday,
Tobias