The UI

This is a very personal choice of mine. My mental model when building new features (not just AI features) flows from customer needs to the UI required and only then to the backend logic.

So the next logical step is to think about what UI is required to serve the use cases we defined previously.

Factors to consider:

Share UIs among multiple use cases.

We don't want to build a new UI for each use case. A handful of UIs should cover all of them. The UIs should be generic, not business-use-case specific. Examples: Search text, Generate text, generate image, generate code, etc.

This way, supporting a new use case is just a matter of adding a new backend endpoint and a new prompt. The UI is already there.

So, for a given "generic" UI, we can either hardcode the specific use case supported or let the user select it.

An example of the former is when the user needs a suggested title or description. The UI is the same. The backend, however, needs to know which use case it is serving.

An example of the latter is when the user needs to select the tone of voice of the suggested content. In this case, the user will pick from a list of tones of voice (use case 1, use case 2, etc.).

Never let the AI change data directly

This is a must for any business SaaS.

Always let the user review and approve/reject the changes suggested by the AI. Translated to the UI, this means the user needs to compare the suggested changes with the current data and decide whether to accept or reject them.