The Little Bit of Systems Engineering You Actually Need

You change an appointment in Visit Book. The business's page shows Friday, but Thursday's schedule still includes the old visit. You ask the AI to fix it. It adds a button to update the schedule.

Hang on. Why is that your job?

You already told the application what changed. It has the information. Requiring you to repeat yourself in another part of the same application is a design failure dressed up as a feature. You wanted less paperwork, and the engineer has given you another button to remember.

Systems engineering includes understanding how the parts of your app depend on one another. You can ask why an arrangement leaves you doing the coordination without knowing how to write the code that would fix it.

The calendar is looking at the appointment

Imagine Friday at two is now agreed with Aster Repairs. Visit Book needs to save that agreement. The business's page, the calendar, and Friday's list of visits all need to show it. These are three ways to look at the same appointment.

The application should keep a saved record of the appointment and use it wherever that appointment appears. When you change the agreement, the other screens should show the changed record. You shouldn't have to edit a second appointment just to make the calendar match.

Saved appointment feeds Business page, Calendar, Friday visit list.

Saved appointment

• Business page
• Calendar
• Friday visit list

Ask Codex, “When I change this appointment on the business page, how do the calendar and the visit list get the new information? Am I changing one saved appointment, or maintaining separate copies?” Have it explain using the actual app it built. You want to know where your change is saved and which screens use it.

Sometimes a screen needs to refresh before it shows the change. That is different from having to type the new time again. A refresh asks for the current information; a second manual edit creates another opportunity to disagree. In this app, I would ask the engineer to update the visible schedule after a successful save. There is no reason to make you wonder whether the appointment moved.

Try cancelling the invented visit. It should disappear from the agreed schedule and remain available in the business's history. If the calendar loses it but the day's total still counts it, the app is still contradicting itself. Totals deserve the same question as screens: what records are they calculated from?

A sent schedule is a copy

Now suppose you sent Thursday's schedule to the visitor as a PDF yesterday. This morning, Aster Repairs cancels.

Visit Book can correct its own records. The PDF on the visitor's phone still says Thursday at ten. Nothing about saving the cancellation on your computer reaches into that file and removes the visit. If your app tells you everything is up to date while the visitor is preparing to drive there, its definition of “everything” isn't much use.

The same issue applies to a screenshot or a message containing a list of appointments. It described the schedule when you sent it. That can be entirely adequate when plans rarely change. When they change often, someone has to communicate the updates, or the visitor needs a way to see the current schedule.

For our present local app, a sensible improvement is to remember when you last exported a schedule and tell you which appointments have changed since then. You can send a corrected copy and contact the visitor about anything urgent. Later, you might give the visitor a live view they can open on their phone. That needs a shared service the phone can reach, plus access for the right person. Codex can build it; describe how the visitor will actually use it before deciding.

Even a live view doesn't establish that somebody read the change. If a person is already on the road, a call may be the right way to tell them. Software can remove the copying without replacing every human conversation.

The calendar, the sent document, and the visitor's understanding can all disagree for different reasons. Ask the AI to follow the information as far as the person relying on it.

Changing a name must not change who you called

Suppose Aster Repairs changes its trading name. You edit the name in Visit Book. Its phone number, earlier calls, and appointments should still belong to that business.

To make this work, the application needs a way to recognise the record independently of its displayed name. Engineers call this an identifier. It can be an internal number or another unique value; Codex can choose it. You won't have to memorise it or type it yourself.

Ask Codex to show you what happens when you rename the invented business. Then create another business with the same name but a different address. The app should keep the records separate and show you enough information to tell them apart. Distinguishing them inside the database is only half the job if both appear as identical choices on the screen.

Be especially interested when you import another spreadsheet. An import adds information from a file to your app. If you import the same file twice, you probably don't want twice as many businesses. If a later file contains a corrected phone number, you don't want a second business created just because a detail changed. Explain those situations and have the engineer propose how to match records and show uncertain matches for you to settle. The answer depends on what the files contain; guessing from names alone would be a rotten start.

Saved means it will be there when you return

A working screen is not evidence that your work has been saved. The app can hold a note while it is open and lose it when it closes. In article two, you asked for local storage that survives closing and reopening Visit Book. Now have Codex show you where those records live on your computer, in ordinary terms.

The project folder holds what the AI uses to build the app. The installed app is what you launch. Your business records are a third thing, and an update to the app must preserve them. Ask where a backup comes from and where it would go if you needed to restore it. Putting source code on GitHub does not answer those questions about the calls you've recorded since.

For a single-person Windows app, saving locally lets you work without an internet connection. Installing the app on another computer won't give that computer the same records. Sending over the source won't either. Shared work needs a deliberate arrangement for shared information; we will build that into the example later.

Saving can fail on a local computer too. Ask Codex to keep what you typed visible and tell you if a note cannot be saved. The app mustn't clear the form or display “Saved” because the button was pressed. When you retry, you want one recorded call, not two. Codex should handle the implementation and check it.

Have the engineer explain your app

Return to the project in Codex and ask it to follow one invented appointment from the moment you agree it, through a change, into the day's schedule and an exported copy. Ask where the information is saved, which screens read it, and what remains to be done after the copy has been sent. Have it inspect the implementation rather than describe an arrangement it would like to have built.

You can ask for a diagram like the one above and an explanation in PROJECT-BRIEF.md. You should be able to point to a box and ask what happens if the person using it hasn't received the change yet. You should also be able to tell Codex, “That still leaves me updating two places. Make a better proposal.”