Does AI reduce cost? Count more than the subscription

A monthly AI bill can be small while the work becomes expensive. If the team spends an afternoon clarifying an assignment, another checking the result, and a third repairing an assumption, the subscription is only one line in the decision. The useful question is whether a defined job reaches an acceptable result with a total effort the team is willing to sustain.

The hypothetical P1 policy uses the final total in Thai baht after discounts and tax: a manager approves up to and including THB 50,000; a director approves above THB 50,000. An amount edit invalidates prior approval. This is an example policy, not an Odoo default.

This final episode proposes a pilot for the hypothetical purchase-order approval system used throughout the series. It is a measurement design, not a claim of savings, or a customer result. “Upfront investment” here means preparation for operating the workflow. It does not determine whether any expenditure should be recognized as an accounting asset.

Compare a complete job with a complete job

Choose one bounded change with acceptance criteria fixed in advance. In this example, changing an approved order's amount invalidates its prior approval. Measure the work from understanding the request through integration and acceptance. Stopping the clock when AI produces its first patch would omit the work that decides whether the patch is usable.

Use a comparable task completed by the existing method as a baseline. Record important differences: familiarity with the code, size of the change, quality of the requirements, and the experience of the reviewer. A comparison of an unfamiliar legacy change with a familiar AI-assisted change would mix several causes. When comparable work is unavailable, report the pilot as a first measurement, not proof of improvement.

Before the trial, the business owner and technical owner should agree on the checks that determine acceptance. Include the amount-change rule, relevant permissions, failure behavior, and the effect of combining changes. Keep unresolved requirements visible. If the task grows halfway through, record the scope change instead of treating the added time as evidence against one method.

Keep time and cash visible separately

Record human time by activity and service spending from actual usage records. Time released by a task is not automatically cash saved. The same employees may still be paid, and any extra capacity may be used elsewhere. Applying an internal hourly rate can help compare resource use, but it is a planning convention whose basis should be disclosed.

The assumed hourly rate is THB 1,000 for both methods. The six AI-assisted hours already include assignment preparation, checking, rework, and integration; they do not mean six hours of generation. Setup is assumed to cost THB 10,000 and to be allocated across ten accepted changes, giving THB 1,000 per change. Under those assumptions, the arithmetic difference is THB 400. It is not verified savings, profit, or a forecast.

The allocation matters. If the same setup serves only two accepted changes, its allocation becomes THB 5,000 each. Holding the other assumptions constant, the illustrative AI-assisted total becomes THB 11,600. This is not a prediction that pilots will be expensive. It shows why a claimed advantage can depend on a volume assumption that has not yet been observed.

The simplified example leaves out costs shared by both methods and does not assign a monetary value to incidents or long-term maintenance. Keep those omissions explicit. For a real pilot, count a new cost caused by the trial, identify an existing cost that continues anyway, and avoid charging the same review hour twice. Do not turn an unknown incident cost into zero merely because no incident appeared in a short trial.

Measure quality before celebrating a lower total

Alongside time and spending, record whether the result met acceptance criteria, how many correction cycles were needed, and what defects were discovered later. Separate an unclear requirement from an implementation mistake and from a review miss. They require different changes to the workflow. A low service bill cannot compensate for an authorization defect that the team cannot accept.

An evaluation pass supports only the tested scope. For the documentation assistant from episode 6, record unsupported conclusions, incorrect citations, inappropriate access, and unsuccessful handoffs as well as acceptable answers. If the pilot cannot meet a critical boundary, pause expansion even when the average answer looks useful. Averages can conceal a small category of failures with a different consequence.

Choose models by demonstrated fitness for the task and its risks. A smaller, lower-cost model may handle a stable extraction or wording task adequately. A complex authorization review may need stronger reasoning and an experienced human reviewer. “Review” is not automatically an easy task. Test proposed routing on representative cases before treating a lower price as a lower total cost.

Name the owner of the recurring work

Someone must maintain the project rules, accepted examples, evaluation cases, document versions, and tool permissions. Add that work to the pilot record. Preparation can be reused, but it also becomes stale. A rule without an owner can mislead later workers more consistently than an empty folder would. Record what changes trigger a review and who can suspend the workflow.

For this proposed pilot, use a small, explicitly bounded set of synthetic-data tasks. Keep live approvals and external publication outside its authority. At each review, compare accepted results, total effort, outstanding risks, and the operating work needed to continue. The team may expand, narrow the task, improve the preparation, or stop. Those are decisions to make from the record, not promises attached to adopting AI.

Make the next decision answerable

A useful pilot report names the task, baseline limitations, acceptance evidence, human time, incremental service spending, setup assumptions, rework, and unresolved failures. It should also state what the trial did not test. A handful of changes does not establish future reliability or organization-wide return. The report can still answer a narrower question: is this particular workflow ready for another bounded trial?

Before the next purchase-order change, assign a person to collect that record and agree on the conditions for continuing. Do not ask only whether the team wants AI. Ask which accepted job it should help with next, what evidence would justify that choice, and who will own the work that remains after the first result arrives.

Conceptual reading: The New SDLC With Vibe Coding by Addy Osmani, Shubham Saboo, and Sokratis Kartakis, May 2026. The purchase-order examples, work orders, and pilot design are original proposals, not reported research results from the paper.

Further reading from the source author on planning, review, and responsibility: Addy Osmani, Agentic Engineering.