Use AI to build the system, not necessarily to run it

How often do you hear a system described as an "AI automation" when the finished thing never actually calls a model?

Maybe Claude or Cursor helped write the code, or an AI tool helped someone map the workflow, and suddenly the whole system gets described as AI-powered.

There are really two different decisions hiding inside that label. AI in the build loop means a model helps you design, code, test, document, or debug the system. AI in the runtime means the deployed system calls a model while it is doing the client's work.

You can use AI heavily to build a system that runs on predictable rules, and you can add a model later at the one step where interpretation actually earns its place.

The build loop is not free intelligence

AI has changed what a small team can do during development, and we have seen it first-hand at Feeble. An AI IDE can help you write code, explain an unfamiliar block, add a feature, and work through a bug without making you memorize every piece of syntax. A coding agent can go further, reading a codebase, deciding what needs to change, and editing the project directly.

That makes the build loop faster to explore, but it does not make software ownership disappear. You still have to get your local environment working, deal with errors that have nothing to do with your intended logic, understand enough of the system to point the model in the right direction, and maintain what you ship. Cursor gives you an AI-assisted editor where you can describe changes and have them applied directly to the code. Claude Code works from the terminal and can read a larger project, make edits, and keep working across a project over time. Those are useful differences in the build loop, but neither one changes the runtime architecture by itself.

That distinction matters because generated code can make the first version feel deceptively complete. The code may exist, the interface may work, and the deployment may be one push away, while the builder still does not understand why one part depends on another.

So yes, use AI aggressively while you build. Just do not confuse help with understanding. The model can remove a lot of syntax and typing from the process, but you still own the system when it goes sideways.

A useful system does not need runtime AI

Let's take an example, and see why a useful system can be completely deterministic.

My first real project was a personal CRM built in Airtable and Make. It tracked people, their birthdays, and how close I was with them. Every morning, the workflow checked the list and sent me a text with different lead times depending on the relationship. Immediate family could get a reminder a month out, while a friend I had not seen in a while could get a same-day reminder.

Nothing in that behavior required a model. The system stored the data, checked the dates, applied explicit rules, and sent the appropriate reminder. Its value came from understanding the behavior that mattered and moving the right data on a schedule.

That pattern shows up in plenty of internal work. Data can move between systems. Notifications can fire when a condition is met. Documents can be generated from known information. Scheduled checks can keep records synchronized. The same logic can sit behind lead routing, recurring reports, invoice processing, or other predictable business tasks. None of those jobs become more useful merely because a model was inserted into the middle. If the trigger is consistent, the fields are known, and the next action is already defined, adding a model can simply create another dependency without changing the outcome.

And this is the distinction worth keeping in your head: AI can help you build the system without becoming a production dependency. If the path can be drawn in advance and the inputs are predictable, a deterministic workflow can be exactly what the job needs.

A hybrid system decides separately at every step

But what if one part of the job is predictable and another part is not?

Let's take an intake workflow. Your fixed path might be simple: a form submission creates a CRM record, then sends an internal alert. Those steps have known inputs, known actions, and a known order.

Now suppose the form includes a free-form response and you want a personalized follow-up based on what the person wrote. That is a different problem. A model can interpret the response and prepare the follow-up, while the rest of the workflow remains fixed.

The path can therefore look like this:

n8n makes this distinction particularly visible because you can add a model to a workflow without turning the whole workflow into an agent. A Basic LLM Chain can take instructions and return text. An Information Extractor can turn unstructured text into structured data. A Question and Answer Chain can retrieve source material and generate an answer from it. It is a pattern we use constantly in n8n development.

That means the architecture does not have to make one grand decision called "AI or no AI." You can make a smaller decision at each boundary: where do rules work well, and where does interpretation create enough value to justify itself?

Runtime AI earns its place when the work needs interpretation

There are cases where a fixed path stops being practical. The input may arrive in many shapes. The relevant information may need to be retrieved before an answer can be produced. Or the next action may depend on what the system discovers along the way.

RAG is a clear example. A general-purpose chatbot does not automatically know a client's private documentation or internal process. A RAG agent can search a controlled knowledge base, retrieve relevant chunks, and use those chunks as the basis for its answer. The model is doing something the deterministic part of the system cannot do economically by itself: interpreting a question and connecting it to the right private information.

An agent can be justified for a different reason. If a person types a request such as rescheduling a meeting and notifying the attendees, the system cannot know the exact path until it understands the request, checks the relevant information, and chooses the allowed actions. The model is making decisions inside a bounded set of tools rather than following one completely predetermined route.

That is a serious positive case for runtime AI. The model is not there because "AI" sounds more sophisticated. It is there because the work contains interpretation or variable paths that are difficult to pre-wire economically. The same distinction applies inside n8n. A bounded model call can sit inside an otherwise fixed workflow, while an agent can control which allowed tool or action comes next. Those are different levels of runtime discretion, and treating them as the same thing makes architecture harder to reason about. We break that line down in the difference between an AI agent and an automation.

Runtime AI pays rent in more than API dollars

Once you put a model into production, its cost is not limited to the price of an API call.

There is variable token usage, which means the amount of work and therefore the cost can change from one run to another. There is latency. There are additional failure points and less predictable outputs. If a task takes several steps, retries and longer context can add more usage. You may also need extra testing, human review, and a fallback for cases the model cannot complete.

Context itself becomes an architectural concern. Every API call starts fresh, so anything the model needs to know has to be supplied in its context. That can include the system prompt, conversation history, documents, retrieved information, and previous workflow results. Longer contexts cost more, and very long contexts can make important information harder for a model to attend to.

So when you estimate runtime AI, the useful question is not simply "what does the model cost?" You need to consider the input, output, volume, context, retries, and the rest of the platform around it. A model call might be inexpensive in isolation and still introduce meaningful operating complexity when it sits inside a high-volume workflow. Even a simple estimate has to account for how many times the workflow runs and how much text it sends and receives. A longer prompt, a larger document, a higher volume, or a more expensive model can move the number. If the system needs several model calls in one task, those costs and failure points can compound. We walk through the arithmetic in how much it costs to run an AI automation.

That does not mean runtime AI is too expensive. It just means the model should actually earn its place by doing work that justifies those extra variables.

But Claire, AI is always advancing

There are two fair objections that one might raise to my entire argument.

First, it could sound like a software shop protecting itself from work it does not know how to build. If you can put a model into a workflow, why not let it handle more of the system?

Second, model capability keeps changing. A task that requires a carefully fixed workflow today may become much easier to delegate tomorrow. If the boundary moves every few months, why bother drawing one at all?

In my opinion, the boundary is supposed to move. We teach both workflows and agents because both are legitimate ways to build useful systems. The default is not permanent. You are just supposed to revisit it when model quality, latency, cost, or evaluation changes.

What should remain stable is the interface around the model. If one part of your system needs interpretation, isolate that part so you can change the model, the prompt, or the architecture without turning the whole system into an experiment. Keep approval, fallback, and measurement around the step where discretion lives. That way, if a cheaper model becomes good enough, a prompt needs to change, or the model stops being worth the cost, you have a defined component to revisit instead of a system whose behavior is distributed everywhere.

That also answers the first objection. A predictable workflow is not an excuse to avoid AI. It is a way of being precise about where AI is actually needed.

Start predictable, then add discretion deliberately

So, if you are deciding how to build a client system, I'd recommend starting with the process rather than the model.

1. Draw the process without naming tools.
2. Build the predictable path.
3. Identify the step where fixed rules become economically impractical.
4. Add the smallest model-controlled component that handles that step.
5. Preserve approval, fallback, and measurement around it.

That approach leaves room for AI without making AI the architecture.

And it gives you a better question than "Where can we put AI?" You will now find yourself asking where the system genuinely needs interpretation, variable routing, retrieval, or another capability that deterministic rules cannot handle economically.

AI can write the code, explain the code, test the code, and help you debug the code. The finished system may still be better off running on explicit rules for most of its work.

The authority you need to hold comes from knowing both sides of that decision: where AI belongs, and where it does not.