Accepting an AI edit is not the same as saving a file
Follow a suggested edit from proposal through acceptance, the working copy and a deliberate save.
Ouros editorial team
Accepting a suggested edit and saving a file are separate decisions. An editor can show the text you want while another program still reads the old file from disk. Check both the text you accepted and the copy you meant to keep.
Follow one sentence through the editor
Consider a document that says “The preview is ready.” You ask for a more precise sentence: “The preview opens locally.” A suggestion appears. At that point you have a proposal, not yet a saved change.
Read the proposed replacement in context. Does “locally” describe what you know, or did the agent add it because it sounds reassuring? If it is accurate, accept that part of the proposal. If the same suggestion also removes a warning elsewhere, reject or revise that separate change rather than accepting everything to get the one sentence you wanted.
The accepted text can now be in the editor's working copy. Saving is the action that writes that copy to its destination. A preview that reads the saved file can still show the earlier sentence until that write happens. This is a general editor model, not a promise that every suggestion control writes or restores files in the same way.
Check the destination, not just the tab
- Confirm which file the open tab represents. Similar names in different folders are easy to confuse.
- Read the accepted text and nearby paragraphs before saving.
- Use the editor's supported save action. Resolve any conflict deliberately; do not overwrite an external change without comparing it.
- Inspect the saved change from the project, or open the file through an independent reader that will not replace an unsaved buffer.
- Run a relevant check if the change affects behavior rather than wording alone.
In a Git project, start with:
git status --short
git diff --stat
git diff -- path/to/changed-file
Replace the example path. These commands inspect the working tree; they do not save an editor buffer. If nothing appears, check whether you are looking at the right repository and whether the file is new, ignored or already staged. A blank diff is a clue, not proof the editor lost your text.
Make future reviews less ambiguous
Project guidance can record a few consistent expectations:
# Project guidance
Preserve changes outside the requested task.
Read the target file before proposing an edit.
Report the exact check used to verify the result.
Treat this as text for review, not an automatic permission system. Agree on where guidance belongs before saving it in a shared project. Do not let an agent silently turn one task's preference into a rule for everyone.
If a save fails, preserve the unsaved text before closing the tab or restarting. A temporary private note can protect the wording while you investigate permissions, conflicts or the destination. Avoid pasting private code into a support form. Share a small public reproduction and the non-secret error instead.
The final check is concrete: the intended file contains the intended text, and the relevant project check was run on that saved version. A clicked acceptance button establishes neither by itself.