Vibe coding
Ask an AI builder for a change without turning it into a rebuild
Bound a feature request by its purpose, affected journey and the behavior that must still work afterward.
Zocri · 2 min read · Sources checked
Give the change one business purpose
Lovable's Plan mode documentation allows a proposed change to be reviewed before implementation begins. Apply the same review habit in any builder that supports it. Suppose the owner of a repair shop needs to find overdue jobs. The purpose is to find those jobs quickly, not to redesign the entire operations dashboard.
Describe the exact journey: the owner opens the jobs list, selects overdue and sees jobs past the agreed due date that are not completed or cancelled. State whether jobs without a due date should appear. A precise inclusion rule prevents the builder from inventing the business meaning.
Draw a boundary around the request
List the affected surfaces: a filter on the jobs list, its selected state and an explanation when no jobs match. Name any existing behavior that is especially important to recheck, such as sorting, search and opening a job. Keep this boundary focused rather than prohibiting every conceivable change.
Put attractive extras in a separate backlog. Reminder emails, staff rankings and automatic rescheduling may become useful later, but each changes the scope and the verification required. Decide whether the overdue filter solves the immediate problem before attaching those additional workflows.
Ask for a reviewable explanation
Before implementation, ask how the proposed change interprets overdue and what existing behavior it affects. If the builder proposes replacing the entire data structure, ask why that is necessary. Evaluate the reason against the requested outcome rather than accepting a large change because it sounds technically sophisticated.
Provide examples at the boundaries: a job due yesterday, one due today, one completed yesterday and one with no date. Decide how the current business day is determined. These examples give you a concrete way to review the proposal and the finished filter.
Accept the result through use
After the change, compare the list against the example records. Try search and sorting while the filter is active, then remove it and confirm the full list returns. Refresh the page and check that the chosen behavior for preserving or resetting filters matches your decision.
Record the accepted rule and any deliberately deferred work. If the result is wrong, request a correction against one failed example rather than reopening the entire design. Small changes remain manageable when their purpose, interpretation and evidence stay visible throughout the conversation.