High-Efficiency LLM Prompting & AI Security
Large language models (LLMs) such as Claude are powerful tools for developers and business analysts alike, but the quality of what you get back depends on what you put in, and so does the risk. This guide covers how to get accurate results on the first try, how to keep token costs down, and the security rules every employee must follow.
Step 1: Understand What the Model Sees
A few facts about how LLMs work explain almost every tip in this guide:
- It only knows what's in the conversation. The model has no access to our codebase, your previous chats, or the meeting where the requirement was agreed, unless that information is in the prompt or the tool explicitly provides it. Everything the model sees is called its context.
- Text is measured in tokens. A token is roughly three-quarters of an English word; code usually uses more tokens per line than prose. Cost, speed, and the size limit of the context (the context window) are all measured in tokens, both for what you send and what comes back.
- The whole conversation is re-read every turn. In a long chat, every new message re-sends everything before it. Long, wandering conversations get slower, more expensive, and less accurate.
- It produces plausible text, not verified truth. A model can invent an API method, a library, or a business rule with complete confidence. You are responsible for everything you use from it.
Step 2: Set Context with a Prompt Framework
A zero-shot prompt is one that gets the right answer on the first try, without examples or follow-up corrections. The most common reason a prompt fails is that the model had to guess something you knew. Use the five-part framework below for any task more complex than a quick question. The parts don't need to be long; they need to be present.
| Part | Answers the question | Example |
|---|---|---|
| Role | What expertise should it apply? | "You are a senior C# developer experienced with Unity 2D." |
| Context | What's the situation, and why does this matter? | "Our inventory system stores items in a List; players report lag when sorting 500+ items." |
| Task | What exactly should it do? | "Rewrite SortInventory() to sort by rarity, then name." |
| Constraints | What must it respect or avoid? | "No LINQ (it allocates per frame); keep the public method signature." |
| Format | What should the answer look like? | "Return only the method, then one sentence on its complexity." |
Weak prompt:
Write a function to check if an invoice is overdue.Strong prompt:
<role>
You are a senior C# developer on a multi-tenant SaaS billing system.
</role>
<context>
Each tenant sets its own grace period (0-90 days) after an invoice's
due date. Dates are stored in UTC; tenants have an IANA time zone.
</context>
<task>
Write IsOverdue(Invoice invoice, Tenant tenant, DateTimeOffset now).
An invoice is overdue when it is unpaid and the grace period has fully
passed in the tenant's local time zone.
</task>
<constraints>
- .NET 8, no third-party libraries.
- Paid or voided invoices are never overdue.
- If anything about the rule is ambiguous, ask before writing code.
</constraints>
<format>
The method, then xUnit tests covering: paid invoice, last day of grace,
first day after grace, and a tenant in UTC+13.
</format>- Separate instructions from material with tags. Wrapping pasted code, logs, or documents in tags such as
<code>…</code>or<requirements>…</requirements>stops the model confusing what you want with what you pasted. - Say what to do, not only what to avoid. "Write in plain English for a non-technical client" works better than "don't be too technical".
- Invite questions. "Ask me if anything is unclear before starting" turns a confident wrong answer into a quick clarification.
- Break big jobs into steps. "Outline the approach" then "implement step 1" beats one giant request, and lets you correct course early.
- BAs: the same framework works for user stories, acceptance criteria, test cases, and summaries. Give the audience in the Role or Format part ("for a client steering committee").
Step 3: Provide Schemas and Examples for Structured Output
When the answer will be read by code, or pasted into a tool such as a spreadsheet or issue tracker, don't describe the format in words; give the exact shape. A schema removes guesswork about field names, types, and allowed values.
Extract every acceptance criterion from the user story below.
Return ONLY valid JSON matching this schema, with no other text:
<schema>
{
"storyId": "string",
"criteria": [
{
"id": "string, e.g. AC1",
"given": "string",
"when": "string",
"then": "string",
"priority": "must | should | could",
"ambiguities": ["string; empty array if none"]
}
]
}
</schema>
<story>
...paste the user story here...
</story>- Use real type definitions when you have them. Paste the C# class, TypeScript interface, or JSON Schema your code already uses; the model will match it exactly.
- One good example beats a paragraph of rules. Showing one complete input and its correct output (called few-shot prompting) is the most reliable way to get consistent style and structure.
- Constrain the values. Enumerations (
"must | should | could") stop the model inventing new categories. - Always validate. In code, parse and validate model output against the schema before using it, and handle failure. When calling the API, prefer its structured output or tool-use features, which enforce the schema for you.
Step 4: Minimize Token Usage Without Losing Quality
Fewer tokens means faster answers, lower cost, and usually better results, because the model isn't distracted by irrelevant material. The goal isn't the shortest possible prompt; a vague prompt that needs three retries costs far more than a precise one. The goal is to send only what's relevant.
| Instead of | Do this |
|---|---|
| Pasting a 2,000-line file | Paste the one function involved, plus the signatures of what it calls. |
| Pasting a 10,000-line log | Paste the error, the stack trace, and the 20 lines before it. |
| Asking for the whole file back | Ask for "only the changed method" or a unified diff. |
| Open-ended answers | Set a length: "under 150 words", "three bullet points", "code only". |
| Re-explaining the project in every chat | Keep project context in a reusable file (such as CLAUDE.md) or a saved project prompt. |
| One endless conversation | Start a fresh conversation for each new task. Summarize the useful conclusions into the new one if needed. |
| The largest model for everything | Use a smaller, faster model for simple tasks such as reformatting, summarizing, or boilerplate; save the largest model for complex reasoning. |
| Lockfiles, minified code, generated files, binary data | Leave them out. They are expensive and rarely useful. |
When building features on the API: put the stable parts of the prompt (instructions, schemas, reference material) first and the per-request parts last. That lets prompt caching reuse the stable prefix across requests at a fraction of the cost. Set a sensible maximum output length on every call.
Step 5: Follow the Data Rules: What Must Never Be Shared
Anything you type or paste into an AI tool leaves your machine. Depending on the tool and plan, it may be logged, retained, reviewed by the vendor, or used for training. The studio classifies information into three tiers. These rules are mandatory, and they apply to every AI tool: chat apps, coding assistants, browser extensions, and AI features built into other products.
| Tier | Includes | Rule |
|---|---|---|
| Never share | Credentials and secrets: passwords, API keys, tokens, private keys, certificates, connection strings, .env files.Tenant and customer data: any data from production or customer environments, personal data (names, emails, addresses, IPs, payment details), support tickets, and logs or database exports containing any of it. Security-sensitive details: vulnerability reports, penetration test results, and security controls such as anti-cheat, licensing, or fraud detection logic. |
Never, in any AI tool, including approved ones. No exceptions without written approval from leadership. |
| Approved tools only | Proprietary source code and core business logic (pricing and billing engines, game systems, tenant isolation code), internal architecture and infrastructure details, unreleased game content and roadmaps, client documents covered by an NDA. | Only in AI tools on the studio's approved list, signed in with your studio account. Never in personal accounts or free consumer tools. |
| Open | Public documentation, open-source code, general programming questions, synthetic or made-up example data. | Any reputable tool. |
If you're unsure which tier something falls into, treat it as the stricter one and ask your lead. Ask your lead for the current approved tools list; approval depends on the vendor's data-retention and training terms, which differ between consumer and business plans of the same product.
Step 6: Sanitize Before You Paste
Most debugging doesn't need real data. Before pasting code, logs, or examples, replace anything sensitive with realistic placeholders. The model can still reason about the shape of the problem.
Before (never paste this):
2026-10-21 14:02:11 ERROR Payment failed for tenant "Northwind Clinics"
user=jane.doe@northwind.example card=4111********1111
conn=Server=prod-sql-03.internal;User Id=svc_billing;Password=Hx9!q...
at BillingService.Charge(Invoice inv) line 212After (safe to paste):
2026-10-21 14:02:11 ERROR Payment failed for tenant "TENANT_A"
user=USER_1@example.com card=[REDACTED]
conn=[REDACTED CONNECTION STRING]
at BillingService.Charge(Invoice inv) line 212- Use the same placeholder for the same value throughout (
TENANT_Aeverywhere), so relationships in the data stay clear. - For reproducing a bug, generate synthetic records that have the same shape and edge cases as the real ones.
- Check screenshots too: browser tabs, sidebars, and notifications often show customer names or internal URLs.
- For AI coding agents that read files directly, block access to secret files in the tool's settings (see Claude Code & GitHub CLI Setup).
Step 7: Treat AI Output as Untrusted
AI output is a first draft from a fast, well-read, occasionally confidently wrong colleague. It goes through the same review as any human contribution, and you are accountable for anything you commit, send, or run.
- Read and understand every line before committing it. If you couldn't explain it in code review, don't submit it.
- Verify packages exist and are the real ones. Models sometimes suggest package names that don't exist, and attackers register those names with malicious code. Check the package's official page, publisher, and download history before installing.
- Never run a command you don't understand, especially anything with
sudo,rm,curl … | sh, or a force-push. - Beware of prompt injection. Text the AI reads (web pages, issues, documents, code comments) can contain hidden instructions aimed at it. Give AI agents the least access they need, and never production credentials.
- Check facts and business rules against the source of truth: the spec, the issue, or the client. Never against the model's own claims.