Saved. But which part of the website?

01

I started with a blunt request.

I did not begin with a perfect specification. I said the builder was not a great experience and asked the assistant to refine it. The first response turned that into concrete work: autosave after two seconds of inactivity, a manual Save button, inline failures, and a warning before leaving with unsaved changes. Publish became an action distinct from the Published status.

That was a useful first pass. Someone changing their website needs to know whether an edit is still in progress, has been stored, or failed. Otherwise they end up doing the application’s bookkeeping themselves: save again, open another tab, check the page, wonder whether it worked.

The assistant then offered three extensions. I wanted all three because they belonged to the same editing experience: change the content where I can see the page, recover an earlier layout, and find the missing information before it becomes an empty section.

02

One editing session. Two saving loops.

The content dialog brought Story, Events, and Blog into the builder, with uploads, save and delete actions, and local feedback. That reduced the need to leave the page composition to work on the information inside it. But placing two editors together did not make their persistence rules identical.

The later audit called this out. Puck, the visual page editor, autosaved its layout. The content forms saved separately. Take the example from the opening: rearrange a section, then rewrite a story headline. A successful layout save tells me nothing about whether that headline reached its own content record.

This is where I want the interface to be precise. “Layout saved” and “Story saved” describe different completed actions. The audit suggested distinguishing those scopes; that wording was a proposed refinement in that pass. My lesson is to follow the thing being saved, rather than assume nearby controls share one saving system.

03

I wanted the change to reach the database.

The first version history response included the interface and a new database table, then handed the migration back to me. I pushed back. The database connection was available, and I wanted the assistant to complete that part of the change as well. The next response reported the migration applied.

That exchange is a specific part of how I work with AI tools. An interface can be written while the storage it relies on is still missing. If I stop at the feature list, I inherit the unfinished connection between them. My follow up kept the task moving across that boundary.

The conversation also continued into database types. That supports the implementation record, but it is not the same as a tested editing flow. The later recap explicitly said tests had not been run. I keep those facts separate: the migration was reported applied; the whole experience still needed verification.

04

What comes back when I restore a version?

Version history offers reassurance: try something, and go back if it does not work. The harder question is what “go back” includes. In the retained implementation, snapshots contain the layout data. Story, Events, and Blog live in separate records.

An earlier arrangement can therefore come back with the latest saved story inside it. For a designer, that is a boundary between composition and content. For a restaurant owner, it could look like a partial undo unless the interface explains the scope first. I would call the action Restore layout and show what it will replace.

There is another detail in the code reviewed for this retrospective. Restore attempts a backup before replacing the current layout, but the backup helper catches and logs its own failures. The restore path does not check a success result from that helper before continuing. This is a code level finding, not a reproduced report of someone losing work.

It changes what I would verify next. If the recovery copy cannot be created, I want that to be a visible decision point before overwriting anything. The intended sequence, back up, then restore, only becomes a dependable experience when the failure between those steps is handled too.

05

The Publish button did not tell the whole story.

The first response made publishing easier to distinguish from saving. Reviewing the retained code now, I can be more precise about that distinction. It stores the layout in the same record that the public page reads when the builder is marked published.

On an already published site, a successful layout save can affect what a guest sees on a later page load. There is no separate draft copy and released copy established by these controls. Keeping edits private until a deliberate release would require a different storage boundary.

That is why I would trace an AI generated change through both sides of the product. The editor tells the owner a story about their action. The public page delivers the result to the guest. Those two need to agree. A calm interface cannot compensate for an unclear answer to “will this change the live page?”

06

An empty state is a decision, too.

The work added a content health checklist based on the sections actually used in the layout, followed by sample content and a Quick Start panel. I like the practical connection: if the page includes an Events section, the editor can help someone discover that there are no events ready to show.

But the route out of that empty state matters. Fill with sample puts example material into the editor. Save sample writes it to storage. Those are different commitments. The recorded location fallback could insert a generic address when the real one was missing; it still needs replacing before it can represent a restaurant.

Reservations exposed a subtler distinction. The seed logic only created settings when no settings record existed. It did not override reservations that had intentionally been disabled. A missing setup and a deliberate choice to accept no reservations should not be treated as the same problem just to clear a warning.

07

The next check is an ordinary editing session.

If I were taking this pass into verification now, I would start with the original simple task: move a section and edit a headline. Save only the layout, reload, and inspect which change survived. Then save the story separately and repeat. That checks whether the saving labels describe the real behaviour.

Next, I would restore an earlier layout after changing the story. I would inspect both the arrangement and the current content, then repeat with backup creation made to fail in a controlled test. The question is whether recovery remains understandable when the reassuring path cannot complete.

I would also load the public page after saving in both published and unpublished states. Finally, I would check a save failure with keyboard and screen reader use: can the person discover what happened and continue without losing their place? These are review steps derived from the code, not results I am assigning to the January session.

08

The smaller promise is the one I can make useful.

That day moved through saving feedback, content editing, layout recovery, missing content checks, and guided setup. AI helped me work across those parts in one conversation. My contribution included saying the first pass was not the end, approving the connected work, and asking the assistant to finish the migration it had left behind.

Revisiting the implementation adds a more demanding lesson: every success message has to earn its wording. What was saved? What can be recovered? What will someone else see? Answer those clearly and a restaurant owner has less to keep in their head. They can finish the edit and get back to the restaurant. That is the experience I want to build.

Saving information only matters when the next screen can use it. I return to that question in A portfolio is part of the answer.