System prompts set the AI's permanent rules and persona while user prompts carry the human's actual request — understanding the difference lets you build AI features that stay on-task, consistent, and safe.
Picture this: you're building the EngineerPrep AI tutor. Your goal is a focused mentor that only answers software interview questions, speaks in an encouraging tone, and never wanders off into unrelated topics. You write the code, test it yourself, and it works beautifully. Then you share it. The first tester asks it to write a poem. It writes a poem. The second asks it to be mean. It gets mean. The third just asks a normal question but gets back a completely different tone than you designed. Your natural first instinct is: I'll just add instructions to every message. Put a reminder at the top of whatever the user sends — "remember, you are a helpful tutor" — and call it a day. That works for five minutes.…
An LLM (a large language model — the AI brain behind features like the EngineerPrep tutor) doesn't receive one big blob of text. It receives a conversation , and every message in that conversation has a role . Think of it like a job briefing before a customer call. Before the call starts, your manager pulls you aside and says: "You are a technical support agent. Only answer questions about our product. Stay professional. Never discuss competitors." That's your briefing — it shapes everything you do, and the customer never hears it. Then the customer calls and says: "Hi, my login isn't working." That's the actual request. In LLM terms: - The system prompt is the manager's briefing. It sets the rules, the persona, and the boundaries. The AI reads it first, and it colors every response. - The user prompt is the customer's message. It's the live input — what the person actually typed.…
Step 1 — You write the system prompt (once) Imagine a notecard sitting on the developer's desk. It reads: "You are an encouraging software interview coach. Only answer questions about coding interviews, data structures, and system design. Keep answers concise and friendly." This notecard is baked into your Spring service. It never changes while the app is running. --- Step 2 — A user sends a message A learner on EngineerPrep types into the chat box: "Can you explain what a binary search tree is?" That text becomes the user prompt. It arrives at your REST endpoint, gets picked up by your service layer, and is about to be packaged up. --- Step 3 — Your service assembles the conversation Think of a small envelope. Inside, two index cards are stacked in order: 1. SYSTEM — the notecard from Step 1 2. USER — the learner's message from Step 2 The cards are labeled with their roles.…
We'll build a minimal TutorService that sends a system prompt and a user prompt to Claude via Amazon Bedrock using Spring AI's ChatClient . The system prompt is a constant — it never changes at runtime. java private static final String SYSTEM PROMPT = """ You are an encouraging software interview coach for EngineerPrep. Only answer questions about coding interviews, data structures, and system design. Keep answers concise and friendly. """; This is just a plain Java string. It lives in the class, not in a database or a request object. It is your text, written by the developer. --- The service receives the user's question as a method parameter. java public String answer(String userQuestion) { userQuestion is whatever the learner typed. It changes every call. --- Spring AI's ChatClient has a fluent builder that keeps the two roles separate.…