Before building what ai suggests, ask what the project needs.

While working on a proof of concept for managing store data through typed instructions, Claude proposed a way to track database changes: save the affected records for every query so those changes could later be undone.

The explanation was clear, detailed, and confident. For a moment, I was inclined to accept it.

Then I stepped back. Which rows would we need to capture for each SQL operation? How would we reliably reverse those changes? What happens when an operation changes the database structure, or an edge case breaks the undo logic?

A reliable change history can become a substantial engineering project of its own, with storage costs, performance tradeoffs, and maintenance responsibilities. Before taking that on, I needed to ask whether the product required it.

This was my response to Claude:

How would I reliably identify which rows changed? That requires logic for different SQL operations, and undoing those changes adds another layer of complexity.

More fundamentally, I can’t promise users a reliable history of their data while building my own backup system. That isn’t the focus of this project.

What I may need is much simpler: the initial database and its latest saved state when the user closes their session. I don’t need a complete history of every previous change.

If I can’t reliably preserve the latest session, I shouldn’t promise that either. Users would still need to keep their own backups.

That changed the discussion from how to implement versioning to what the application actually needed to guarantee.

Accepting the original proposal would have added a maintenance burden without a clear benefit for this proof of concept. A few decisions like that can make a small project much harder to finish and support.

This is where I still see architecture as a human responsibility, even when AI writes the entire implementation. A convincing technical argument is only part of the decision. Someone still has to connect it to the product’s purpose, the available resources, and the promises the team can realistically keep.