How to use Bezi
Bezi looks very simple because the power lies in how you prompt it. This feels intuitive but, just like any other tool, time gets wasted if you don’t learn the fundamentals before diving in.
Prompting
- Best prompt structure: Current state, Expected/Ideal state, Response format you want
- Prototype example: “I have a system for X. I want to adjust it to add Y. Prototype that and describe any necessary setup steps.”
- Prompt quality = response quality. No vague asks, statements without clear asks, or overcomplicated prompts
- Good standard: if you asked a colleague the same thing, is there enough detail that they’d know how to answer it?
- Anti-example: “Fix errors”
- This will get a bad response, as Bezi doesn’t know which errors you want fixed!
- Bezi can’t read minds; give all relevant info! These tools help give it specifics:
- Always pin relevant project assets, scripts, etc. in-line: type “@” to search or select an asset/gameObject in Unity
- Use image attachments (screenshots, figma layouts, etc.)
- If Bezi gives a response you don’t like, DO NOT PROMPT TO FIX IT. This causes rabbit-holes. Instead, do either:
- Edit the original prompt to add extra, missing info. This regenerates the response (and wipes any changes that followed the OG)
- Start a new thread, summarize what you you liked from the previous, and re-ask the questions
Using Threads
- Threads are a series of prompts/responses
- Keep threads short: aim for <10 prompts per thread
- Only 1 topic/task per thread: start a new thread when the topic or task changes
- Bezi uses an active thread’s history as context for prompt responses in the thread. Threads that are long or cover multiple tasks/topics create noise and will lead to a worse response