A vague prompt hands the model the retention decision on a payments table

A vague request leaves the model room to pick a familiar shape, and the post names the shapes it picks: route handler, controller, model, query, response ^[6]. It calls that pull regression to the architectural mean, where a model without constraints reaches for the common answer instead of the answer that fits this system ^[7]. The miss is quiet, because the endpoint returns the field and the test passes ^[8]. A model cannot know about an unreliable provider, a rule shared across the app, or a need for history unless the request or the codebase shows it ^[9].

Asking it to behave like a senior architect does not supply any of that. "That gives it a title; it does not tell it how this system works," the post says ^[10].

The concrete damage in the payments example is one controller holding three jobs: it verifies the provider's signature, writes the row, and decides whether the customer may be charged again ^[11]. That arrangement is convenient until one of the three has to change on its own, at which point it drags the other two along ^[12]. "The code made that choice quietly. The product was never asked," according to the post ^[13].

The fix offered is a prompt that carries the constraints. As the post writes it, the model is told to verify the signature and translate the payload, to call the existing recordPayment function, to leave payment records alone rather than updating them directly, to follow the duplicate handling in recordRefund, and to test a valid event and a repeated event ^[14]. The rule now has a name. The model has an example, and the tests have a job ^[15]. Output may still need editing, and it has less room to build a second architecture beside the first ^[15].

A prompt lasts for one request and then it is gone. The next agent, or the next Friday patch, has to be able to find the decision, so it lives in module boundaries, in examples in the repository, and in tests; a dependency check can make a broken boundary plain ^[16][17].

Retention has a running cost, and the post puts it on the read side: "The cost is not in the writing but in the reading" ^[19]. Every payment event kept is a shape somebody must still be able to interpret in five years, including events written by a version of the charge code that no longer exists ^[20]. Against that sits the alternative already described: "The March repair job is what the other choice costs." ^[21]

The post limits the scope. The profile photo still needs updating, and several layers would add little to it ^[22]. A boundary belongs where a shared rule or an external dependency has needs of its own ^[23]. Where history matters, an append-only log of decisions may be enough, and event sourcing takes the same idea further by building current views from the saved facts ^[24].

The argument rests on a single worked payments example, with no measured comparison between vague and constraint-carrying prompts ^[29]. The retention part transfers on its own logic, because the three remedies in the story are three attempts to read back rows that were already gone, and the last one depends on the provider's statements ^[28][18].