Part 5 of 7 · 2 min read
A checklist for building requests
Seven habits that remove the most common message-handling bugs, and how professionals test them.
- Build messages in one function that you can test, not in scattered string concatenation.
- Log the exact request (without secrets) for every call, so a bad answer can be replayed.
- Check the stop reason and handle
max_tokens. - Budget tokens before sending: system + history + expected output must fit the context window (module 6 of Level 1).
- Keep the system prompt in version control (Level 3, module 5).
- Never let two code paths each append the same reply to the history.
- Treat every user-supplied string as data, never as an instruction you act on.
What you will use daily at work
| Practice | What it looks like |
|---|---|
| A single request builder | One tested function turns your stored conversation into the provider's request shape. |
| Provider SDKs | You use the provider's official library, which handles the message format, retries and token fields. |
| Request logging | Each call logs model, prompt version, token usage and stop reason (never keys or private data). |
| History management | Old turns are summarised or moved to memory instead of growing forever. |
| Output filters | Anything leaving the system is checked in code: secrets, personal data, allowed formats. |
| System prompts in the repository | Prompts are files that are reviewed and versioned like code. |
Draft: to be checked against the current documentation of the providers the course uses (message fields, system or developer role, stop-reason names) before this page goes live.
Interview angle
Answer in your head first, then open it.
Is the chat API stateful?
No. The client stores and re-sends the conversation each call.
What are the roles?
System (developer instructions), user, assistant, and tool results where supported.
Why does a long conversation get slower and costlier?
Each call re-sends the whole history, so cost grows faster than the turn count.
Can a system prompt guarantee a rule?
No. It is guidance the model usually follows. Guarantees need enforcement in code.
How would you handle a history that exceeds the context window?
Trim old turns, summarise them, or move facts to external memory, always keeping the system prompt and the newest input.