An AI has built a purchase-order approval screen. The buttons work, a manager can approve an order, and the status changes from pending to approved. Before letting purchasing staff use it, I would ask a less impressive question: what happens when someone edits the amount after approval?
That question helps us see what the demo still lacks before other people use it for real work. A screen can look complete while leaving the most expensive decisions unresolved. Who may approve? Which amount determines the approval route? What happens if a request is sent twice? A demo that does not answer these questions can still help us learn, provided we keep its boundaries clear.
This series follows a hypothetical purchase-order approval project. It is an original teaching example, not a customer implementation or a system I have deployed. We will move from a prototype toward a bounded pilot, examining context, permissions, verification, delegation, operation, and cost along the way.
Give the demo a job it can actually do
Suppose the purchasing team wants to find out whether approvers understand a proposed screen. We can use invented orders, simulated users, and a button that changes only a local test record. The useful result is feedback: a missing field, a confusing status, or a step the team forgot. We do not need a live purchasing connection to learn that.
The risk changes when the same button updates a real order or sends it onward. Now an interface mistake can become a business action. Even a read-only screen may expose information to someone who should not see it. The boundary depends on what the system can affect, not whether we call it a prototype.
Concepts informed by The New SDLC With Vibe Coding, Addy Osmani, Shubham Saboo and Sokratis Kartakis (May 2026). Author’s article · Full public paper
I would write the experiment's limit in plain language: “This version uses synthetic data, records simulated approvals, and cannot send purchase orders.” That statement belongs in the test environment and the handoff notes. A label alone is insufficient; the environment should also lack the connection and credentials needed to send real orders.
Vibe coding describes an approach, not a product badge
People use vibe coding to mean several things. Here, it means exploring by describing what we want, accepting AI-generated changes quickly, and feeding errors back for another attempt, with limited inspection of the underlying work. That can be productive when the output is disposable and the consequences are contained.
The source figure compares approaches from quick experimentation to structured verification. The distinction is how outputs are checked, rather than the tool name. Verification still needs to match the consequences of the task. The structure, speed, and reliability arrow is conceptual, not measured performance or a guarantee.
Figure reproduced from The New SDLC With Vibe Coding, Addy Osmani, Shubham Saboo, and Sokratis Kartakis (May 2026). Document design: Michael Lanning. Figure reuse offered by Addy Osmani. Source and reuse permission · Full public paper
Agentic engineering adds a deliberate system around the work. A person defines the intended outcome and boundaries; an agent uses tools to make changes; evidence, checks, and review determine whether the result can proceed. The responsibilities remain even when the typing is automated.
The source paper, The New SDLC With Vibe Coding, presents these approaches as a spectrum. That is useful because the same coding tool can support a quick experiment or a carefully governed change. Even with a more capable model, we still need to decide who owns the approval rule, how permissions will be enforced, and what counts as acceptable evidence.
My preference is to choose the amount of structure from the cost of being wrong. A disposable layout experiment and an approval action deserve different controls. “More process” is not a useful objective by itself. A check earns its place when we can explain the failure it is meant to catch.
Write down the rule before asking AI to implement it
For our example, suppose an order up to 50,000 baht may be approved by a department manager, while an order above 50,000 baht requires a purchasing director. These amounts and roles are hypothetical. Before generating code, we still need to define which amount the rule uses: before or after tax, before or after discounts, and in which currency.
Let us choose the final order total in baht after discounts and tax. Under that invented rule, an order totaling exactly 50,000 baht follows the manager route; 50,000.01 baht follows the director route. If the total changes after approval, the previous approval becomes invalid and the order returns for review. Those are business decisions, not details an agent should silently guess.
At the inclusive limit
50,000 baht
Department manager approves
Above the limit
50,000.01 baht
Purchasing director approves
| Question | Evidence before a pilot |
|---|---|
| Is the approval route correct? | Reviewed rule and tests around the 50,000 baht boundary |
| Can the wrong user approve? | Server-side permission checks and rejected unauthorized requests |
| Can an order be approved twice? | A defined response to repeated requests, tested against stored state |
| What happens after an edit? | A state transition that invalidates approval when relevant fields change |
| Who responds when it fails? | A named pilot owner and a rehearsed way to stop the new workflow |
Make the handoff about evidence
An agent saying “done” is a report to investigate. Ask for the changed files, the rule it implemented, the checks it ran, the results, and the gaps it could not resolve. A person reviewing the change should be able to connect the business requirement to the implementation without reconstructing a long chat.
For this project, I would keep the first live pilot narrow: an agreed group of users and orders, a responsible reviewer, and a way to return to the previous process. The exact scope would depend on the organization. A small pilot reduces the area of uncertainty; it does not remove the need to protect data or enforce permissions.
Stopping the pilot needs its own definition. Disabling a new screen may prevent future actions, but it does not undo an order already sent. Recovery may require identifying affected records and asking the authorized business owner what to correct. That is why “we can roll back the code” is only part of the answer.
Before moving this demo forward, I would require an agreed rule, evidence for the risky cases, enforceable access limits, and an owner who can stop the pilot. Any missing item becomes an explicit open issue, rather than an assumption hidden in generated code.
Try this with one screen your team already has: name the first action that affects a real record, the person allowed to authorize it, and the evidence needed before that action is enabled. The next article takes that answer into the information we give an agent before it starts.
Reading and scope
This article develops original business examples from concepts in The New SDLC With Vibe Coding by Addy Osmani, Shubham Saboo, and Sokratis Kartakis, dated May 2026. Osmani's explanation of agentic engineering is a public companion reading on deliberate AI-assisted development. The proposed controls here are a starting point for discussion, not evidence that a particular system is secure, compliant, or ready for every deployment.
