Describe the Life You Want the Software to Fit

A person is talking to you on the phone. You need yesterday's note, but opening it closes the form where you were writing today's note. You can either remember what they're saying while you go looking, or interrupt them and ask them to repeat it. The app has a notes feature. The feature works. The person using it would like to throw the laptop out of a window.

Losing your place during a call is a software problem, just as a broken calculation is. The application was supposed to help you do the job.

By now you may have a first version of Visit Book. It records calls and appointments. You have tried a change and put the source on GitHub. Now try using it for an afternoon's work. If you are still discussing the design, the same questions will help you shape it before the first build.

The quickest way to get a generic app is to ask for a generic app. “Make a dashboard for managing appointments” names a familiar category. The AI can supply something that resembles other dashboards without finding out much about you. It will have cards. God, will it have cards. Somewhere among them may be the thing you need while somebody is waiting on the phone.

Tell it about one call

Return to Codex and describe a particular bit of work. If you are following our invented example, try this:

I'm calling Aster Repairs to arrange a visit. Before I dial, I need the phone number and the last conversation in front of me. While somebody is speaking, I want to type a new note without losing the old one. They say the person who agrees appointments isn't available until tomorrow afternoon. I need to record what happened and remind myself to call then. There isn't a visit booked yet. When I finish, I want to move to the next business without leaving this one half-saved.

Ask Codex to walk through that call using the current app. Have it tell you what you would click, what you would see, and what would be saved. Then try the sequence yourself with the invented business. You may discover that the app technically supports everything, but requires opening four different panels to do it. Passing a feature checklist won't make that less irritating.

You can say, “I need these things visible together while I'm on the phone. What arrangement would let me do that comfortably?” Let the AI propose the layout. You supply the situation and judge the result. You aren't obliged to design every button just because the first design was bad.

Explain what a change means

Now take a less tidy call. Aster Repairs was booked for Thursday at ten. They call to say Thursday is impossible and ask whether Friday at two would work. You have to check with the person making the visit. For this example, the Thursday appointment is no longer happening, and Friday is a request awaiting agreement.

If the app simply moves the appointment to Friday and calls it confirmed, it has made an agreement on your behalf. If it leaves Thursday on the confirmed schedule, it is showing a visit that won't happen. Both errors follow from treating “reschedule” as a date-editing task without understanding the conversation.

Tell Codex what is true while you are sorting it out: keep the earlier arrangement in the history, remove Thursday from the agreed visits, record Friday as requested, and show that you need to settle a new time. Once both sides agree, Friday belongs on the confirmed schedule. You don't have to know how many tables this requires in a database. You know which appointment you would be willing to send someone out to.

The details may be different in your work. Some people keep the original booking until the replacement is confirmed. Some visit arrangements don't require a precise time. The AI should ask which arrangement applies instead of choosing whichever is easiest to represent on a calendar. Giving it a concrete case makes that question difficult to miss.

Keep the cases somewhere you and the builder can refer to:

Use the situations that actually happen to you. A few honest cases are more useful than a long list of features copied from a software company's homepage.

Let the AI do some of the thinking

You shouldn't need to arrive with an exhaustive account of your work. Much of what you know is so familiar that you won't think to mention it. Of course you need yesterday's note while writing today's. Of course a person asking you to call on Friday hasn't invited you to visit on Friday. These things become visible when you imagine doing the work and discover that the software expects something else.

Ask the AI to interview you about the job, one situation at a time. It can suggest possibilities you hadn't considered, such as preparing the next day's schedule without copying appointments into another document. Have it explain what its proposals would change for you.

If it responds with twenty questions about technical preferences, redirect it. “Ask about how I work. Recommend the technical arrangement yourself.” If it asks you to choose a colour scheme before it understands how an appointment is agreed, tell it to come back to the appointment. Neither a questionnaire nor an attractive first screen is evidence that the engineer has understood the job.

You can also keep parts of the work because you want to do them. For Visit Book, you make the calls and agree the appointments. The software handles the record-keeping around those decisions. If your pleasure is making glitch art, you probably want controls to experiment with, not a service that produces an approved artistic result and tells you you're done. If you like designing lessons but hate assembling the materials, explain that difference. “Automate my work” is a poor instruction when some of the work is the reason you enjoy it.

Save the understanding, including what changed

Once you and Codex agree on how Visit Book should behave, ask it to write that account in the project folder as PROJECT-BRIEF.md. A brief is a description of what you're making and why. Have it include the call examples and the decisions you've settled, then open the file in VS Code and read it. Correct anything that makes your job sound tidier than it is.

The brief can say who uses the app, what happens during a call, what counts as an agreed visit, and what a changed appointment should do. It should also name the thing you want improved: for example, avoiding repeated copying, or keeping the previous note visible while writing the new one. Those reasons help a later AI understand why the design is the way it is.

When experience changes your mind, change the brief. You might try a compact call screen and find it too cramped, or discover that a requested Friday slot needs its own visible list. Preserve what you learned and ask Codex to revise the app accordingly, keeping your existing records.

Try the next version while pretending to make that Aster Repairs call. Read the old note, start the new one, and change your mind halfway through. See whether you can finish the conversation without losing your place. No explanation of how sophisticated the implementation is should talk you out of wanting that.