You'll understand exactly where LLMs shine and where they fail — and how EngineerPrep's Java stack is designed around those boundaries so the AI tutor stays helpful and honest.
Picture your first week on the EngineerPrep backend team. You're given one task: hook up the AI tutor so students can ask coding questions and get answers. You call Amazon Bedrock, get Claude's response, stream it back. It works beautifully. The tutor explains recursion, explains Big-O, explains why a HashSet beats a List for lookups. You're feeling great. Then a student types: 'Based on my last three sessions, what topic should I study next?' The tutor confidently recommends dynamic programming — even though this student has never opened a DP problem. The session data lives in PostgreSQL. The LLM never saw it. It just made something up. You file your first bug. The title: 'AI tutor inventing study history.' Here's what that bug is really telling you: an LLM is not a database, not a calculator, and not an oracle. It's a very specific kind of tool…
Think of an LLM — a Large Language Model, which is the AI engine behind Claude or GPT — like an incredibly well-read intern. This intern has read millions of books, articles, Stack Overflow threads, and textbooks. Ask them to explain any concept, and they'll give you a thoughtful, well-structured answer drawn from everything they've read. But here's the catch: they finished reading on a specific date (called the training cutoff ) and they have no memory of your conversations yesterday. Every time you talk to them, they walk in fresh — no notes, no history, no access to your database. That analogy captures the two sides of an LLM perfectly. What LLMs are good at: - Explaining concepts (their training data was vast) - Generating text, code, and summaries - Recognizing patterns in language - Reasoning through a problem step by step…
Imagine a simple diagram with two lanes side by side. The left lane is labeled 'LLM Territory' and the right lane is labeled 'Database Territory' . A student question enters at the top. Step 1 — The question arrives. A student types: 'I keep failing binary search questions. Can you explain the pattern?' The question lands in a Spring @RestController . So far, nothing has touched the LLM yet. Step 2 — Retrieve context from the database. The controller calls a @Service that queries PostgreSQL via a JPA repository. It fetches this student's last five wrong answers — all binary search problems. This is pure database work. The LLM is still idle. Watch the right lane light up: student history rows flow out of PostgreSQL. Step 3 — Build a prompt with the retrieved facts. The service assembles a prompt. It looks roughly like: 'The student got these five binary search questions wrong: list .…