Summary
You shipped two use cases: a host-scoped Liveboard and a conversational Spotter panel, both locked down and wired to real data. The pattern underneath did not change between them. It also does not change for whatever you build next, whether that is a Liveboard for property hosts, a Spotter embed in a mobile app, or a REST job that syncs booking data on a schedule.
Every task follows the same loop:
-
Write one specific, terminology-precise prompt that names the exact ThoughtSpot object and the SDK you’re using.
-
Let SpotterCode pull the real, current documentation reference and generate code shaped to your project.
-
Review it. You are checking the code, not accepting it as-is.
-
If something is off, narrow the prompt before assuming the tool cannot do it.