Locate the source that controls the result
A low-code project may contain editable templates, configuration files, shared styles, content records, and generated output. Before requesting an edit, identify which files the build process treats as authoritative. A change to an exported page may disappear the next time the source is rebuilt.
Map one representative feature from its source to its published result. For a shared article card, find the template, the content fields, the styling, and the page that uses it. This small map gives both the developer and the assistant a concrete starting point for understanding a requested change.
Describe a bounded improvement
Suppose article cards truncate long titles on mobile. The task should specify that the full title must remain readable, the card link must stay usable, and the surrounding grid must accommodate the additional height. Name the component and provide an example that reproduces the problem.
Ask for the smallest coherent change that addresses that behavior. Keep unrelated typography changes and file reorganization out of the same task unless they are necessary to solve it. A focused patch is easier to review and helps reveal whether the assistant understood the actual cause.
Review the work at three levels
- Source review: inspect the changed files and confirm that the edit reached the maintained component.
- Behavior review: reproduce the original issue and check the expected interaction.
- Page review: inspect the component inside representative layouts at narrow and wide widths.
For the article-card example, try a short title, a long title, and a title containing an unusually long word. Follow the card link with the keyboard and check its focus appearance. Look for nearby content that moves or overlaps when the title grows.
Use automated checks where they resolve a concrete risk, such as a failed build or missing asset reference. Use visual and interaction review for the presentation and behavior that the change affects. The appropriate evidence depends on the task; adding more checks is useful only when they answer a remaining question.
Keep the next session reproducible
Record the relevant source location, the build command, the output directory, and the page used for verification. Save a concise explanation of the change and any unresolved limitation. A collaborator should be able to produce the same result from the maintained files without reconstructing the entire conversation.
If work moves between tools, pass the current brief and artifact through the project's normal mechanism. Confirm what the new environment can access. Do not assume that a different assistant has the same files, conversation history, or permissions.
Common mistake: repairing a generated copy
A correct-looking exported page can hide an unfixed source component. Run the normal build after a repair and inspect the resulting page again. If the fix disappears, trace the generation path and update the maintained source instead of adding a second manual exception.
Continue with the practical AI IDE workflow article for a complete approach to briefs, context, small edits, review evidence, and handoffs.
