The Business Rules AI Can't Guess

AI-generated code that passes all tests can still ship the wrong business behavior, and the cost multiplies when discovery comes during integration. Teams that treat AI as a requirements interpreter instead of an implementation tool will accumulate hidden technical debt and broken user-facing contracts.

A one-line requirement like "add an order cancellation feature" sets off a chain of unspoken business questions. AI will locate the order interface, add status checks, update the database, write notification logic, and even pass tests. Then a product manager asks when the money refunds for paid orders, and the real work begins: inventory release, coupon refundability, shipment state, and what the user sees when a refund API times out.

Those default assumptions come from prior discussions and existing system behavior, not from the requirement text. When context runs thin, AI picks a common implementation and realizes it fully, which makes the team less likely to notice the unconfirmed assumptions baked in. Compilation and green tests only prove the code satisfies language and test conditions, not that it matches business intent. Code and tests sharing the same wrong assumption cannot correct each other.

The fix is to write a task spec with five parts: goal, scope, basis (where to find code, APIs, docs), constraints (compatibilities, permissions), and acceptance criteria that cover normal, exceptional, and repeated scenarios. For order cancellation, explicit scenarios like unpaid cancellation, paid cancellation, shipped orders, duplicate requests, and downstream failures each need defined behavior. Existing systems magnify the cost: a wrong field meaning spreads into APIs, databases, pages, and tests before integration exposes it. The depth of confirmation should match the change's impact, and humans confirm business meaning while AI handles the implementation.