Vibe coding
Keep a decision log that prevents an AI app from drifting
Record the business decisions behind a feature, their reasons and the examples that make them testable.
Zocri · 2 min read · Sources checked
Capture the choice, not the conversation
Lovable describes project knowledge as persistent context for a single app, including its purpose and architectural decisions. Use a decision log alongside whatever persistent context your builder supports. A useful entry says that customers may cancel a pending request themselves, while approved requests require owner review. It does not need the twenty messages that led to that decision.
Add a reason in ordinary language. Perhaps an approved request already reserves a scarce staff slot, so the owner must decide how to release it. A future editor can then judge whether a proposed change preserves the reason or requires the business to make a new choice.
Make the entry testable
For each decision, include an example of allowed behavior and one boundary. A pending request shows a cancel action; an approved request shows a request-cancellation action. Specify what state follows each action and who can see it. Avoid recording only a broad aspiration such as simple cancellations.
Include the date, the person responsible and the surfaces affected. A cancellation rule may appear in the customer account, owner queue and confirmation message. Naming those surfaces helps someone find the consequences when a later change is proposed, without turning the log into an implementation manual.
Resolve contradictions openly
When a new request conflicts with an earlier rule, mark the old decision as replaced and state the new one. Do not leave both active. Explain whether existing records follow the old policy or change with the new one, because historical treatment is often where ambiguity remains.
Keep temporary experiments separate from accepted decisions. A trial layout or draft automation should not silently become a permanent requirement. Give experiments an outcome and a review date, then either adopt the learning or remove it from the active context the builder is expected to follow.
Use the log during review
Before approving a feature, compare it against the relevant decisions and run their examples. If the app behaves differently, determine whether the implementation is wrong or the business has changed its mind. That distinction keeps a repair conversation from becoming an unrecorded policy discussion.
Periodically prune the active view to the decisions a maintainer needs now, while retaining history where useful. Hand the log to a colleague and ask them to explain one workflow. If they cannot identify who decides and what happens next, the entry needs clearer language or a better example.