Who decides the business rules when AI writes the code?

The address-change feature is ready and its tests pass. But an operations manager points to an order that still allows address changes: “The warehouse has already started picking that one.”

In this hypothetical system, the application marks an order as “being prepared” when a notification arrives from the warehouse. The developer has used that status to decide when address changes stop. The operations manager means the moment warehouse staff actually start picking. If the notification arrives late, the customer can still enter a new address after work has begun.

The AI-generated code follows its instructions. The developer and operations have used “preparation has started” to mean different things. A feature the team thought was ready now needs another decision about how it should work.

Generating more code with AI does not, by itself, mean delivering more software. A team needs a shared understanding of the intended business outcome, acceptance criteria that express it, and code that reflects the current decision. Someone must also have the authority to resolve the choices left open.

An earlier cutoff leaves customers less time to change an address

Operations has a reasonable concern: once the warehouse is working with the old address, a change may create extra work to correct the shipment. The product team wants customers to retain the option until preparation begins.

A developer might propose disabling address changes as soon as the order is sent to the warehouse, rather than waiting for the delayed notification. In this system, though, orders wait in a picking queue after that handoff. The proposed fix would stop customers changing their address before anyone had touched the goods.

Changing a status check may be straightforward. Shortening the customer's opportunity to make a change is a business choice, with consequences for the customer and complaints for product and operations to handle. A code reviewer cannot close the finding with “fix the check.” The people responsible need to see which customer-facing behavior would change.

The team could change how the warehouse and application work together to preserve the customer's existing window. Or it could accept the earlier cutoff. Engineering explains what each option would involve; the person authorized to settle the tradeoff between product and operations decides which outcome is acceptable.

Suppose the team chooses the earlier cutoff for the first release. The acceptance criteria can now replace the ambiguous “until preparation starts” with a specific rule: reject address changes after the order has been sent to the warehouse, and tell the customer that changes are no longer available. Tests check that behavior. The team also assigns responsibility for investigating any mismatch between the customer screen and warehouse activity in production.

Keep the reason where the next developer can find it

A developer looking only at the code might see no reason to block changes while the order is still waiting to be picked. Without knowing about the delayed notification, they could bring back the original problem while trying to improve the feature. A new AI prompt that omits the rationale carries the same risk.

The team needs to record why it made the decision, which order flow it applies to, and who to consult about changing it. If that information already lives in the work item, there is no need to copy it into another document. Code and tests can link to the existing record. If warehouse processes change and make the early cutoff unnecessary, the team revisits the decision.

Wei Zhang and Jessie Jie Xia's Structured-Prompt-Driven Development treats prompts as development inputs to be versioned and reviewed alongside code. It is a practitioner proposal from Thoughtworks' internal IT teams, illustrated with a small billing system. The article offers no independent comparative evidence of effects on speed, quality, reliability, cost, or ROI.

For the address-change example, the useful idea is to keep the agreed business intent available for subsequent code generation. That requires a current record. When the business chooses different behavior, the instructions, acceptance criteria, tests, and code must follow. Keeping an old decision in Git does not automatically tell the next developer which decision still applies.

Does the record prevent the same argument next time?

Extra documentation and approvals need to justify the work they create. On the next change, is it easier to find out why the old rule exists? Is there less rework caused by misunderstanding? Does review time go into examining code, or waiting for someone to make a decision?

These are questions for assessing the approach, not claims of improvement. Count the effort of writing and maintaining the records too. Production defects and rollbacks on comparable work are other useful measures. If the team or the type of work has changed, attributing any difference solely to the new documentation practice becomes harder.

For the order at the start, the team can now explain why address changes stop, why the customer has less time, and when that choice should be reconsidered. The person taking over the feature knows which behavior to preserve. Alongside working code, the team has something it can hand over: an understanding of what the feature is meant to do and why.