u/InfamousInvestigator

You don't need to write backend code. But if you understand how backend systems behave, your prompts get dramatically better because you're speaking the same language as the system.

• Async vs Sync: user clicks "generate," you call OpenAI, it takes 3-5 seconds. If that's synchronous, the entire UI freezes, Nothing responds. The fix is to make the call async. Show a loading state immediately, let the user keep interacting, update the screen when the response arrives. Tell Claude Code "handle this asynchronously" and watch the output quality jump.
• Race conditions: two users click "claim this spot" on the last available slot at the same second. Backend reads the database, sees one spot, confirms both. Now you have a double booking. You don't need to write the fix, but you need to spot this pattern in your specs. Anytime a user action reads a value then updates it, ask one question: what happens if two users do this at the same time? The fix is an atomic transaction read and write happen as one indivisible operation.
• Idempotency user submits a form, internet cuts out for half a second. Did it go through? They don't know, so they click again. Without idempotency, you now have two records. With it, the second request returns the same result without creating a duplicate. The fix is an idempotency key is unique ID generated on the frontend, sent with every request. Backend checks if it already processed that key. Stripe uses this for every payment call.
• Graceful degradation: your app calls OpenAI and the API is down. If you haven't planned for this, users see a blank screen or a raw error code. Every feature needs three states: happy path (everything works), loading state (we're waiting), error state (something failed). Retry up to three times. If it still fails, show a friendly message and keep the rest of the page working. Never let one dependency take down the whole experience.

TLDR: Next time you're in Claude Code, try using these terms in your prompt — "handle this asynchronously," "make this endpoint idempotent," "add graceful degradation." The output gets significantly better when you speak the system's language.

Post inspired from this video, from SkillAgents AI Youtube.

Suppose User asks "what's the refund policy for annual plans?" Vector search returns five results with Pricing page is #1 but Actual refund policy is buried at #4. The answer is present but not on top.

The problem is how bi encoders work. They encode the query and each document separately, then compare vectors with cosine similarity. They are fast but the encoder never sees the query and document together. It can't reason about how they relate. "Refund policy for annual plans" and "pricing for annual plans" have massive word overlap. Similar vectors, completely different intent.

Cross-encoders fix this but break everything else. Instead of encoding separately, a cross-encoder reads the query and document together as one input. It sees every word in the query next to every word in the document. Output is a direct relevance prediction, not a vector distance. Much more accurate but much slower, every query-document pair needs a full forward pass. 100K documents × 50ms each = 83 minutes per search.

The actual solution: retrieve broadly, then rerank precisely.

Step 1:bi-encoder retrieves top 20 candidates. Milliseconds. Rough but fast.

Step 2: cross-encoder reranks those 20. Reads each one paired with the query. ~1 second for all 20.

Options if you want to add this: Cohere Rerank (hosted, three lines of code), Jina Reranker (open-source friendly), Voyage AI (domain-specific), or self-host MS MARCO cross-encoder models.

If your RAG returns technically correct but "not quite right" answers, reranking is probably the fix.

You can checkout this video for details and SkillAgents AI has other RAG related videos too.

The fix is query translation to transform the vague question before searching.

Multi-query (start from here): You question "how do I set up auth" The LLM rewrites it into three specific versions "what authentication protocols does the API support," "how do users log in and receive session tokens," "what's the step-by-step process for configuring SSO." Each one retrieves different documents. Merge the results, deduplicate. You get comprehensive coverage no single query could achieve.

Real numbers: without multi-query, the top results are billing FAQ (0.72), pricing page (0.68), general overview (0.65) zero relevant docs. With multi-query: OAuth setup guide (0.94), session management docs (0.91), SSO walkthrough (0.89). Retrieval goes from useless to production-ready.

3 more techniques for when multi-query isn't enough:

HyDE: instead of rewriting the question, generate a fake answer. "To configure authentication, first register your app in the OAuth dashboard, then generate client credentials..." Embed that hypothetical answer and search for real docs similar to it. A fake answer is closer in embedding space to the real answer than the original vague question. Works best when your docs have consistent formatting.

Decomposition: for complex questions, not vague ones. "Compare auth options and recommend the best for multi-tenant SaaS" is actually three questions. Break it into sub-questions, answer each independently, combine.

Step-back: zooms out instead of breaking down. "How do I set up auth" becomes "what are the general principles of web application authentication." Retrieves foundational context that helps the LLM reason about the specific question.

Decision tree: start with multi-query as your default it handles the most common case and is simplest to implement. Add the others only when you see specific failure patterns. Most production systems never need more than multi-query.

Post inspired from this video from SkillAgentsAI

So people build using Claude Code but hit the same wall, you build a frontend that looks great, but it's running on hardcoded data. No database, no auth, no real API calls. You can use one of these to connect to other systems:

API are raw HTTP calls the most granular option. Think of it like buying individual pages from a bookstore. You make one specific request, you get one specific response. Maximum control, maximum setup work. Every integration starts here under the hood.

SDK (Software Development Kit) is a pre-packaged wrapper around APIs. Instead of assembling raw HTTP calls yourself, someone gives you a library with clean functions like supabase.auth.signUp(). Way less boilerplate, way fewer mistakes. Supabase, Stripe, Firebase all ship SDKs that Claude Code can use directly.

CLI: for deployment and infrastructure tasks. You're not calling these from your app at runtime you use them to push code live, create database tables, set up environments. Claude Code runs these for you.

MCP is the newest option. Lets Claude Code connect directly to external services as tools. Instead of writing integration code, Claude just calls the service natively.

You can checkout this video for tutorial.

Three metrics are

1. Faithfulness: did the answer come from the retrieved context, or did the LLM hallucinate? User asks about refund policy. Source says "refund minus $50 processing fee." LLM generates "full refund within 30 days, no questions asked." Faithfulness: 0.2. You measure it by breaking the answer into individual claims and checking each one against the retrieved context. Aim for 0.85+. Below 0.7 means the LLM is regularly inventing details, that's a support ticket factory.

2. Answer relevance: did the answer address what the user actually asked? User asks "how do I set up SSO?" LLM returns a paragraph explaining what SSO is. Its technically accurate, but completely useless. Relevance: 0.3. Aim for 0.8+. Below 0.6 means your users get correct but useless answers and stop trusting the system.

3. Context recall: did the retriever even pull the right documents? User asks about system requirements. Ground truth has four items. Retriever only covers two of them. Context recall: 0.5. Even a perfect LLM can't answer correctly if the right docs aren't retrieved. Aim for 0.75+. Below 0.5 means your retriever is missing half the information.

This post is inspired from this video, playlist list for learning RAG available on SkillAgents youtube.

Most things people call "agentic" are one good agent in a loop with two or three tools. Multi-agent adds real cost more latency (each handoff is a network call), more token spend (each agent rereads context), more failure modes (any worker can return garbage), more debugging surface (bad output could come from any of five places).

Three patterns that actually exist:

Orchestrator worker: one agent plans and delegates, specialized workers each handle one piece. Research agent pulls competitor data, copywriter drafts copy, image agent makes the hero asset, reviewer checks tone and claims. Each worker has a narrow job and only the tools it needs. Right shape when steps are genuinely different jobs needing different specialists.

Pipeline: linear handoff. Agent A finishes, B starts on A's output, C on B's. Support ticket comes in classify intent, extract customer ID, draft reply, check tone. Simple to debug because each stage has one input and one output. Use when steps are independent and order is fixed.

Peer2peer: multiple agents argue toward consensus. Three code reviewers read the same PR one for correctness, one for security, one for readability. A judge agent reads all three and decides what blocks merge. Use when no single perspective is enough and disagreement improves the answer.

Note these points:

Are the steps genuinely parallel where running them simultaneously saves real time?

Do different stages need different tools or prompts that can't fit in one agent?

Do you need a critic separate from the actor?

Two or more yeses is multi-agent. One or zero use single agent with good tools.

Inspired from this video from SkillAgents YT.

Suppose a PM shipped a care coordination agent. Week one, patient says "I've been getting chest pain in the evenings." Agent logs the note and demo looks great. Week three, same patient comes back "should I be worried about that pain again?" Agent replies: "What pain?"

By default, agents forget everything the moment a turn ends. If you want continuity, you build it yourself:

• Context window: everything the model sees right now, fast, free to use, but has a token budget. As conversation gets longer the oldest turns fall off. When the session ends, everything disappears.
• Scratchpad: working memory that survives across loop steps within a single task. If Patient says "book my follow-up and refill my prescription." Agent writes a note, calls calendar tool, updates note as it completes it. Without this, the agent forgets what it already did and repeats what its supposed to do once. Simplest implementation is a JSON object the agent reads and writes every turn.
• Vector store: At the end of each conversation, the agent summarizes the important parts. In our example things like diagnosis, medications, follow-up dates, embeds it and stores it with a patient/user ID. Next session, before replying, it searches the archive. So when needed that note flows back into the context window. Now the agent has continuity across sessions.

Thus Memory is a product decision, not a model feature. Your job is designing what gets summarized, what gets stored, what gets retrieved.

You can checkout this video from SkillAgents YT for more details. Subscribe for similar content.