When It Breaks, You Still Own It

The AI announces that it has found the problem, corrected the cause, and checked the result. You open Visit Book. The cancelled appointment is still on Friday's schedule.

Tell it.

You do not owe the machine a more agreeable reality. Its explanation can be excellent English and a bad account of what happened.

Give it something it can investigate

Suppose you cancelled the invented Friday visit to Aster Repairs. The business page says cancelled; the Friday list still includes the visit. That disagreement is useful evidence. Describe it in the Codex conversation for this project:

I opened Visit Book from the Windows Start menu. I cancelled Aster Repairs' Friday appointment on the business page. That page now says cancelled, but Friday's visit list still shows the appointment. I expected it to leave the list of agreed visits. I closed and reopened the app, and it is still there. Investigate this discrepancy and fix it without losing the appointment history.

Say what you actually tried. If you didn't close and reopen the app, leave that sentence out.

A screenshot is useful when you need to show which screen or control you mean. If an error message appears, copy its exact wording. You don't need to understand it first. Keep passwords and service credentials out of anything you share. Use your invented records when reproducing an issue that doesn't require private data.

You can offer a theory too. Perhaps the calendar hasn't refreshed. Just keep that distinct from the observation. “The list still includes a cancelled visit” gives the engineer room to discover whether the list is old, the cancellation wasn't saved, or the wrong rule selects the appointments. Asking it to “fix the refresh” can send it off to improve a mechanism that isn't causing your problem.

Have it explain what it found in terms of your work: what was saved, what the list read, and why they disagreed. Then ask it to complete the repair and install the corrected version. You shouldn't have to translate your own bug report into a file name before it starts investigating.

Check which app you are opening

Codex can change the project and run a new version from the development tools while the Start menu still opens the old installed version. If the AI sees the correction and you don't, establish whether you are looking at the same build before anybody rewrites the fix.

Tell it how you opened Visit Book. Ask which installed version contains the repair and how to recognise it. Have it remove the ambiguity with a visible version number in the app and a clear account of which installer it produced. The number lets you say, “This is the one I'm using.”

For the shared version, also tell it whether your colleague sees the problem and whether the app reports a connection. A problem on one computer and a problem on both are different clues. Ask your colleague what they actually see rather than inferring it from your screen.

Before closing an app with an unsaved note, preserve what you typed. A restart is a reasonable recovery tool, but losing the conversation you were recording is a lousy price for trying it.

Stop a run of guessed repairs

If the same fault survives several confident fixes, ask the AI to reconsider the explanation before changing more code:

The last repairs didn't change what happens in the installed app. Pause the repairs and investigate the cause. Reproduce the disagreement I described, check which version is running, and use the records and logs to distinguish the explanations. Tell me what you find before making another change.

Logs are the application's recorded messages about its own activity. They can tell the engineer whether an operation ran or failed. Ask Codex to find the relevant ones. You are not obliged to spend your afternoon hunting through folders for a file whose name you have never heard.

A small bug, the wrong installer, and a misunderstanding of which appointments belong on the list call for different repairs. More code is not an improvement when it extends the wrong explanation.

Once the cause is clear, let the engineer fix it and check the result. If you need to keep working while it investigates, ask for a practical recovery option. It may be possible to use the last working version, refresh a view, or avoid one broken action temporarily. Have it explain what the option preserves and what it prevents you from doing. You need enough information to choose, not a promise that nothing could possibly go wrong.

Practise getting a change back

Do this once with something harmless, such as the app's title. Start from a working Visit Book and ask Codex to save that source version with Git. Then ask it to change the visible title to Visit Book — recovery practice, build it, and install the update. Open it normally and find the changed title.

Now ask Codex to undo that specific title change using the saved source history, while preserving any other work. Have it build and install the result. When you open the app, the original title should be back and your records should still be there.

Don't use “reset everything” as a casual substitute. Tell the engineer what you want restored and what must remain. “Undo the title change and keep the call history” describes the job much better.

Recovering records is a different operation

If a note appears to be missing, first have the engineer find out whether it is missing from storage or merely absent from the screen you opened. Restoring yesterday's backup because a filter hid today's note could turn a display problem into actual lost work.

Ask Codex to preserve the records that exist now before attempting data recovery. A backup made yesterday won't contain this morning's calls. Restoring it over the current records can replace newer information. You may need to recover a particular missing record instead, or combine recovered information with work done since the backup. Have the engineer explain what will happen before it does that.

An older version of the app can also expect a different arrangement of stored information. That is why returning to old code and restoring old data are separate decisions. Codex should check whether they are compatible, rather than assume that a previous installer will understand every change made since it was built.

While everything is working, ask the engineer to establish a backup routine appropriate to your app and show a restoration using invented records in a separate practice copy. Find out what the backup contains, where it is kept, and how you would retrieve it if this computer stopped working. A schedule exported as a PDF is useful to read; it cannot reconstruct all the calls and changes that produced it.

Have the recovery instructions saved with the project. If you adopted the shared service from the previous article, include how to recover those shared records. A backup of the old local app is not a backup of calls made through the new service.

Come back after a break

Your project should remain understandable when you haven't thought about it for a month. Before finishing a substantial change, ask Codex to update START-HERE.md with how to open and build the current app, and PROJECT-BRIEF.md with any decisions that changed. Ask it to add a short CURRENT-STATE.md describing the installed version, where records and backups live, and the next unfinished work. Credentials belong in the appropriate account or credential storage, not in this note.

Read the note in VS Code. Correct “finished” if the AI has only proposed something. Correct a description of the work if it has tidied away an inconvenient rule. Those corrections save the next session from enthusiastically rebuilding the misunderstanding.

When you return, open the same project folder. You can resume the earlier Codex conversation as described in article two, or start a new one and say:

Read START-HERE.md, PROJECT-BRIEF.md, and CURRENT-STATE.md. Inspect the project before making changes. Tell me what is working, what remains unfinished, and whether the files agree with the note. Then continue the unfinished work. Ask me about choices that affect how I want to use the app; handle the engineering yourself.

Another capable coding agent can also take up the project. It will need access to the files and whatever services the app uses. The GitHub address and the notes help it establish that environment; they don't automatically supply your service accounts or business records. Have the new engineer read what exists instead of asking it to reconstruct the project from your recollection.

You should be able to keep software that fits you when a conversation ends, an AI disappoints you, or you decide another builder does better work. The saved project, recoverable records, and plain account of the decisions let you continue without moving all your work into another app.