Do you need AI, or is a simple script enough?

Start with the task, not the tool name

First decide whether the same input should always produce the same result or whether the system must interpret language, images, or incomplete context. A rule such as “if an invoice is paid, move it to the archive” does not need a language model. Classifying ambiguous messages or extracting fields from inconsistent documents may justify AI.

The second question is the consequence of an error. A tool that prepares a proposal for approval is different from a system that automatically sends money, deletes data, or changes a customer status. The more expensive the mistake, the more important determinism, logs, and reversibility become.

This is not a rule that the simpler solution always wins. It is a practical heuristic: the more predictable the data and the easier the effect is to reverse, the less reason there is to start with a model. When input is ambiguous and the error is costly, you need not only AI but also a process for evaluating its output.

Eurostat reported that in 2025, AI was used by 19.95% of surveyed enterprises in the EU and 8.36% in Poland. These figures cover the enterprises included in the survey, not every company, and say nothing about implementation quality. They do show that AI is not yet a default part of every process; first find a concrete use case.

• Is the input structured enough for explicit rules?
• Must the result be repeatable and predictable?
• Can a human approve the result before it has an effect?
• Can a mistake be reversed, or does it change data or a customer relationship?

Cron and a simple script are still good tools

A script that runs once a day, a webhook after a record changes, or a small service synchronizing two systems may sound less impressive than an agent, but it often matches the problem exactly. Its behavior is easier to describe, test, and hand over. In this context, I treat simplicity as a security feature only when the process also has logs, protection against duplicate runs, a timeout, a retry or alert, and a way to run it manually or roll it back.

AI can help write, explain, or extend such a script. It does not need to become part of the running process. Separating “AI helped prepare the code” from “AI makes decisions in production” lets you use a new tool without adding variability where it is unnecessary.

SaaS, API, or custom integration?

SaaS usually shortens the start for a standard problem, an API gives more control at the cost of integration work, and custom code may be justified by a specific process or data. This is an architectural heuristic, not a rule established by one study. Eurostat reported that 52.7% of surveyed EU enterprises used paid cloud services in 2025; using a ready-made service is a normal technical decision, not a lack of ambition.

Compare each option over a horizon that matches the planned life of the solution; as a practical worksheet, 24–36 months can be useful, but it is not a universal threshold. Include subscription, limits, data export, provider changes, permissions, integrations, manual work, monitoring, and the person responsible for maintenance. A custom integration may be best, but not merely because it can be built from scratch.

The cost of automation includes a wrong result

Do not count only tokens, subscriptions, or the time to write the first version. Include quality testing, retries, exceptions, human review, monitoring, provider changes, and the situation where someone must explain a wrong decision to a customer. DORA’s 2025 report, based on answers from nearly 5,000 technology professionals, found that 90% reported using AI, more than 80% felt it improved their productivity, but 30% had little or no trust in AI-generated code. DORA described a positive relationship between AI adoption and delivery throughput and product performance, and a negative relationship with delivery stability; that is not proof that AI itself causes incidents.

Start with one real operation and measure the entire path: data preparation, invocation, review, storage, and correction. In METR’s early-2025 randomized experiment, 16 experienced open-source developers completed 246 tasks in large repositories; tasks with AI allowed took 19% longer on average, with an uncertainty interval from 2% to 39%. That is a narrow result for a specific kind of work, not a universal penalty or promise of savings. It is another reason to measure your own process.

Run a small test before deciding the architecture

You do not have to decide immediately whether a custom system will exist. Prepare a small sample, compare a simple rule with an API or model, and write down what matters most: accuracy, speed, cost, data control, or handover. The test also reveals whether the problem happens often enough to justify automation.

A second opinion is useful when the tool is chosen because it is fashionable or because an assistant recommended it. In the 2025 Stack Overflow Developer Survey, 46% of respondents said they did not trust AI accuracy, while 75% would ask a person if they did not trust an AI answer. This is not a model-quality audit, but it describes a practical need: someone should challenge the assumptions, ask whether a cron job solves the problem better, and establish who owns the system next year.