Overview

You're asking an AI to draft incident response summaries. The first one comes back verbose, with unnecessary technical detail, and missing critical context. The second one is too brief and skips important details. The AI isn't sure what you want.

This is a few-shot prompting problem. Few-shot prompting is the practice of giving an AI a few examples of what good output looks like, then asking it to produce similar output. It's more efficient than zero-shot (asking without examples) and more targeted than generic templates.

Few-shot prompting is crucial in IT because the format matters. A change request needs specific sections in a specific order. An incident summary needs critical information highlighted. An architecture decision record needs trade-offs documented. AI can learn these formats from examples faster than from written instructions.

Purpose

Few-shot prompting gives AI examples to learn from. Instead of describing what good output looks like, you show it. This is more efficient and more reliable than abstract instructions.

Few-shot prompting is useful for:

• Format standardization: You want all incident summaries in the same format with the same sections
  - Quality consistency: You want all incident summaries to include certain critical details (timeline, impact, root cause, resolution)
  - Tone consistency: You want incident summaries to be concise and professional, not verbose
  - Domain-specific patterns: You want documentation that follows IT conventions (not business English)

The reason few-shot prompting works is that AI learns patterns from examples. Seeing a good incident summary teaches the AI what sections matter, what detail is useful, what to omit.

Why This Matters

Without few-shot prompting, AI output is inconsistent and often misses the mark:

• Inconsistent format: One summary has a "Timeline" section, another has a "What Happened" section. Leadership can't scan summaries quickly because format keeps changing.
  - Wrong level of detail: One summary buries the root cause in paragraph 3. Another highlights it immediately. Users waste time searching for the critical bits.
  - Missing context: The AI omits a section you care about (impact on users, resolution time) because you never mentioned you wanted it.
  - Verbose or too terse: One summary is 3 paragraphs of detail. Another is 1 sentence. Neither is the right length.

With good examples, AI learns the pattern. Output becomes consistent, formatted correctly, and includes the right information.

Few-shot prompting is also a form of documentation. The examples become institutional memory: "Here's how we write incident summaries. Here's how we structure RFCs. Here's how we document architecture decisions."

Key Insight: Examples Are More Efficient Than Instructions

Telling an AI "write a concise incident summary with sections for Timeline, Impact, Root Cause, and Resolution" takes a paragraph. Showing it one good incident summary teaches the same thing in 30 seconds of reading.

Few-shot prompting leverages how humans and AI both learn: from examples.

Core Concepts

1. What Is Few-Shot Prompting?

Few-shot prompting is providing examples of input and desired output, then asking for similar output on new input.

Zero-shot (no examples):
"Generate an incident summary"

One-shot (one example):
"Here's an example of a good incident summary: [example]
Now generate an incident summary for [new incident]"

Few-shot (multiple examples):
"Here are three examples of good incident summaries: [example 1]
[example 2] [example 3]
Now generate an incident summary for [new incident]"

Few-shot is typically 2-5 examples. Beyond 5, you hit diminishing returns and token cost increases.

Key insight: More examples don't always mean better output. 2-3 good examples usually suffice.

2. Selecting Good Examples

The examples matter. Bad examples teach the AI bad patterns.

Good examples for IT documentation:

• Representative of common scenarios (don't pick weird edge cases as your only examples)
• Properly formatted and complete (show the AI what "done" looks like)
• Varied enough to show patterns (one incident type doesn't teach the AI all incident types)
• Realistic (real incidents, real data, real summaries)

Bad example selection:

• Using the one perfect incident (the AI overfits to that specific scenario)
• Using only edge cases (the AI learns weird patterns, not the norm)
• Using badly formatted examples as negative examples (the AI might copy the bad format)
• Using unrealistic examples (the AI learns to produce unrealistic summaries)

Key insight: Three good, representative examples are better than five edge cases.

3. Structure of Few-Shot Prompts

A few-shot prompt has a clear structure:

1. Context/Goal
   "You are an incident summary generator. Generate concise summaries
   for IT incidents following this format."
2. Format description (optional)
   "Each summary should include:
   - Incident type
   - Timeline
   - Impact
   - Root cause
   - Resolution"
3. Examples (the examples themselves)
   Example 1: [input] → [output]
   Example 2: [input] → [output]
   Example 3: [input] → [output]
4. Request
   "Now, generate a summary for: [new incident]"

The structure guides the AI. Context → Format → Examples → Request.

Key insight: Structure makes few-shot prompting reliable.

4. When Few-Shot Is Better Than Zero-Shot

Few-shot prompting adds effort. When is it worth it?

Use few-shot when:

• Output format matters (specific sections, specific order)
• Tone is important (concise vs. verbose, formal vs. casual)
• Consistency is required (multiple people use the same prompt, output must match)
• The task is domain-specific (IT terminology, IT conventions)
• You'll reuse the prompt (it's worth investing time if you'll use it 10 times)

Use zero-shot when:

• Format doesn't matter (one-off request)
• Task is straightforward (basic question with a simple answer)
• You won't reuse the prompt (one-time request)

Key insight: Few-shot takes more effort to set up, but pays off for repeated use.

5. Common Failure Modes in Few-Shot Prompting

Overfitting to examples: The AI learns the examples too well and fails on variations.

Example: Your change request examples are all "deploy new feature." The AI sees a new request "rollback failed deployment" and handles it wrong because that wasn't in the examples.

Prevention: Include varied examples covering different scenarios.

Conflicting examples: Your examples show different patterns and contradict each other.

Example: Example 1 has "Timeline" section, Example 2 has "What Happened" section. The AI picks one and ignores the other, creating inconsistent output.

Prevention: All examples should follow the same format.

Too many examples: You provide 10 examples, the prompt gets huge, token cost is high, and the AI gets confused by the length.

Prevention: Use 3-5 good examples, not more.

Bad examples: You include an example you think is good, but it's actually poorly formatted or the wrong tone.

Prevention: Have someone review the examples before using them.

Practical Use Cases

Before: Incident summaries are inconsistently formatted, too long, or missing key details.

After: Incident summaries are consistent, concise, and include all critical information.

Use Case 1: Standardized Incident Summaries

Your incident response team writes incident summaries by hand. They're inconsistent: some have timelines, some don't. Some are 2 paragraphs, others are 5. Leadership can't scan them quickly.

You want to use AI to draft summaries, but need consistent format and content.

Few-shot setup:

1. Collect 3 good incident summaries from your team (real incidents, well-written)
2. Verify they follow the format you want: Incident Type, Timeline, Impact, Root Cause, Resolution, Lessons Learned
3. Extract the facts (incident details) from each summary separately
4. Create few-shot prompt: facts → summary (your good examples)
5. Use this prompt for future incidents

Few-shot prompt example:

You are an incident summary generator for [Company] IT Operations.
Generate concise, professional incident summaries.

Each summary should include:
- Incident Type (outage, performance, security, etc.)
- Timeline (key events, when detected, when resolved)
- Impact (who was affected, how long, severity)
- Root Cause (what caused this)
- Resolution (how we fixed it)
- Time to Detect and Time to Resolve

Format: Concise, 4-8 sentences max. Professional tone.

EXAMPLE 1:
Facts: Email service down for 2 hours Thursday morning. Users
couldn't send/receive. Detected 9 AM, resolved 11 AM. Cause was
database disk full. Fixed by archiving old logs.

Summary: Email Outage - 2 hours Database disk full caused email
service to reject connections Thursday 9-11 AM. All 500+ users
affected. Root cause: application logs consumed disk space; fix was
archiving old logs. TTD: 15 min, TTR: 120 min. Follow-up:
implementing automatic log rotation.

EXAMPLE 2:
Facts: VPN performance degradation Friday afternoon. Login taking
60+ seconds. Users couldn't authenticate quickly. Started 2 PM,
resolved 4 PM. Load spiked on auth server due to backup process
running simultaneously. Fixed by rescheduling backup.

Summary: VPN Performance - 2 hours VPN login performance
degraded Friday 2-4 PM with auth taking 60+ seconds. 30% of remote
workers affected. Root cause: scheduled backup process and VPN
authentication server competing for resources. Fixed by
rescheduling backup. TTD: 20 min, TTR: 120 min.

EXAMPLE 3:
Facts: Application hung Monday evening. Service CPU spiked to 100%.
Detected 6 PM, resolved 8:30 PM. Application memory leak under
high load. Fixed by restarting service, then released patched version.

Summary: Application Service - 2.5 hours Application service
hung Monday 6-8:30 PM due to memory leak under high load. 100
external customers affected. Root cause: memory leak in version
3.2.1. Immediate fix: restart service. Permanent fix: patch released
Tuesday. TTD: 10 min, TTR: 150 min.

Now, generate a summary for:
[Incident facts]

This prompt teaches the AI the format through examples. Each incident has consistent structure, reasonable length, and includes the right information.

Use Case 2: Change Request Templates with Examples

Your CAB process requires standardized change requests. Some teams write great RFCs, others are sloppy. You want to use AI to improve quality.

Few-shot setup:

1. Find 3 excellent change requests from your change history
2. Extract: change description → RFC format
3. Create few-shot prompt: description → detailed RFC
4. Teams use this for drafting RFCs before submission

Few-shot prompt example:

You are a Change Management Documentation Assistant. Generate
detailed Change Requests (RFCs) for IT infrastructure changes.

Each RFC should include:
- Change Title and ID (e.g., "Upgrade Windows Server to 2022")
- Change Type (Standard, Normal, Emergency)
- Description (what is changing)
- Business Justification (why)
- Scope (what systems, how many, blast radius)
- Implementation Plan (steps, timeline, success criteria)
- Risk Assessment (likelihood, impact, mitigation)
- Rollback Plan (how to undo if needed)
- Timeline (proposed date, duration, window)
- Approvals (who needs to approve, dependencies)

EXAMPLE 1:
Change: Patch Windows Server with March security updates

GENERATED RFC:
TITLE: March 2026 Windows Security Patches (RFC-2026-03-001)
TYPE: Standard Change
DESCRIPTION: Deploy Microsoft March 2026 security updates (KB5044312,
KB5044313) to all Windows Server 2019+ systems. Patches address 5
CVEs with network-facing exposure (CVSS 7-9).
BUSINESS JUSTIFICATION: Security. March patches address critical RCE
vulnerabilities in Windows SMB service. Unpatched systems risk breach.
SCOPE: 28 Win2019, 12 Win2022 systems. All environments (prod, staging,
dev). Estimated 4 hours per system (includes testing, validation).
Blast radius: Medium (if patch fails, system may need restart).
IMPLEMENTATION:
1. Deploy to test systems (2 hours)
2. Verify boot, connectivity, no errors (1 hour)
3. Deploy to 50% of production systems during maintenance window
(8 PM-midnight Friday)
4. Validate, monitor error rates (1 hour)
5. Deploy remaining 50% same window (or next Friday if issues found)
RISK ASSESSMENT:
Risk: Incompatibility with custom apps. Likelihood: Low (tested in
staging). Impact: High (system restart required). Mitigation: staging
test, staged rollout, 24-hour monitoring post-deploy.
ROLLBACK: If system doesn't boot: automated rollback to previous patch.
If network issues: rollback via command line (5-min per system).
TIMELINE: Proposed Friday, March 15, 8 PM-midnight PT. Expect completion
by 1 AM Saturday.
APPROVALS: Infrastructure lead (approval needed). Security lead
(notified).

EXAMPLE 2:
[Additional example with different change type, e.g., system upgrade]

EXAMPLE 3:
[Additional example with different change type, e.g., configuration change]

Now, generate an RFC for: [Change description]

This teaches teams how to write detailed, useful RFCs. The prompt guides them through all necessary sections.

Use Case 3: Standardized Documentation

You want to ensure all runbooks follow the same format and include critical information. Some runbooks skip important details. AI can help standardize.

Few-shot setup:

1. Collect 3 good runbooks (clear, complete, tested)
2. Extract: system description → structured runbook
3. Create few-shot prompt: system → runbook

Few-shot prompt example:

Generate runbooks for IT operations procedures.

Each runbook should include:
- Title and Purpose
- Prerequisites (what must be true before starting)
- Step-by-step procedure (numbered, clear, actionable)
- Success criteria (how do we know it worked)
- Troubleshooting (what could go wrong, how to fix)
- Rollback procedure (how to undo if needed)
- Contacts and escalation (who to contact for issues)

EXAMPLE 1:
System: Mail server failover

GENERATED RUNBOOK:
TITLE: Mail Server Failover Procedure
PURPOSE: If primary mail server is down, activate secondary to
maintain email service.

PREREQUISITES:
- Secondary mail server is operational and synced
- DNS A record for mail.company.com is ready to update (keep
current TTL short, 300 seconds)
- Service team is on-call (have contact info)

PROCEDURE:
1. Verify primary is down (ping mail-primary.internal, check
mail service status)
2. Check secondary sync status (SSH mail-secondary, check replication
lag < 1 minute)
3. Update DNS A record (mail.company.com → secondary IP address)
a. Use portal: [link]
b. Update A record to [secondary IP]
c. TTL should be 300 (already set)
4. Verify resolution: nslookup mail.company.com (should return secondary IP)
5. Test mail: send test email from external account, verify delivery
6. Notify users: post status update to [slack channel] with timeline

SUCCESS CRITERIA:
✓ mail.company.com resolves to secondary server
✓ Mail flows through secondary (test email received)
✓ All users can send/receive within 5 minutes
✓ No replication lag (all messages delivered)

TROUBLESHOOTING:
If secondary is not synced (replication lag > 5 min):
- Check network connectivity between primary and secondary
- Check database replication status on secondary
- If primary is unreachable and secondary is behind,
contact [DBA on-call] before proceeding

If DNS doesn't update (mail still goes to primary):
- Check DNS TTL (should be 300, update may need up to 5 min)
- Flush DNS cache on affected clients: ipconfig /flushdns (Windows)
or sudo dscacheutil -flushcache (Mac)

ROLLBACK:
If secondary is experiencing issues:
1. Revert DNS A record back to primary IP
2. Resolve secondary issues before next failover attempt
3. Rebuild secondary if necessary

CONTACTS:
- Mail service owner: [name, contact]
- On-call engineer: [process, contact]
- If mail stays down 30+ min: escalate to VP Engineering

This runbook format is clear, testable, and includes everything operators need.

Examples

Example 1: Few-Shot for Incident Classification

You want AI to classify incidents by severity and type, but it needs to understand your organizational definitions.

Classify incidents by SEVERITY (1=critical, 2=high, 3=medium, 4=low)
and TYPE (outage, performance, security, data, other).

EXAMPLE 1:
Incident: Email service down for all users, started 8 AM, detected 8:15 AM.
Classification: SEVERITY=1 (outage affecting all users), TYPE=outage

EXAMPLE 2:
Incident: Database query performance degraded 20%. Some reports slow
but functional. Started 2 PM, detected 3 PM.
Classification: SEVERITY=2 (impacts business function but not down),
TYPE=performance

EXAMPLE 3:
Incident: Unauthorized access attempt detected in logs. 10 failed
attempts from external IP. No access gained. Detected by SIEM.
Classification: SEVERITY=2 (attempt blocked, but security threat),
TYPE=security

EXAMPLE 4:
Incident: Backup file not created due to disk quota. Detected in
daily check. Previous backup still valid. No data lost.
Classification: SEVERITY=3 (operational issue, no immediate impact),
TYPE=other

Now classify: [incident description]

This teaches the AI your severity and type definitions through examples.

Example 2: Few-Shot for Architecture Decision Records (ADRs)

You want architecture decisions documented consistently.

Generate Architecture Decision Records (ADRs) for technical decisions.

Format:
- Title
- Status (Proposed, Accepted, Superseded)
- Context (why are we making this decision?)
- Decision (what are we deciding?)
- Consequences (what changes because of this?)
- Alternatives (what else did we consider?)

EXAMPLE 1:
Decision: Migrate from on-premise database to managed cloud database

GENERATED ADR:
TITLE: Migrate to Managed Cloud Database
STATUS: Accepted
CONTEXT: Current on-premise Oracle requires 2 DBAs to maintain,
license costs $200K/year, and performance limitations for data scale.
Cloud-native application design suggests managed database.
DECISION: Migrate from on-premise Oracle to AWS RDS PostgreSQL. Use
managed backups, automated patching, read replicas for performance.
CONSEQUENCES:
+ Reduced operational overhead (1 DBA instead of 2)
+ Lower licensing costs ($50K/year managed service)
+ Better performance for large datasets
+ Automatic backups and disaster recovery
- Less customization (some Oracle-specific features unavailable)
- Network latency between on-prem apps and cloud (expect <10ms)
ALTERNATIVES CONSIDERED:
- Stay with on-premise Oracle (high cost, operational burden)
- Migrate to different database (PostgreSQL chosen for cost +
performance, considered MySQL but PostgreSQL better for analytics)
- Hybrid (on-prem + cloud, complexity too high)

[Additional examples...]

Now, generate an ADR for: [decision description]

This ensures decisions are documented consistently and thoroughly.

Anti-Patterns

Anti-Pattern 1: Using Bad Examples

Your "good example" is actually poorly formatted or wrong.

Problem: The AI learns the bad pattern and replicates it.

Prevention: Have someone review your examples before using them. The examples should be genuinely good.

Anti-Pattern 2: Inconsistent Examples

Example 1 uses "Root Cause" section, Example 2 uses "Cause." Example 3 uses "Why it happened."

Problem: The AI sees conflicting patterns and generates inconsistent output.

Prevention: All examples should follow identical format and structure.

Anti-Pattern 3: Too Few or Too Many Examples

One example: AI overfits to that specific scenario.

Ten examples: AI gets confused, token cost is high, and it might forget which pattern applies.

Prevention: Use 3-5 good, varied examples.

Anti-Pattern 4: Edge Case Examples

Your example is an unusual incident that almost never happens.

Problem: The AI learns to handle the edge case, but fails on common scenarios.

Prevention: Use representative, typical examples. If you want to include an edge case, add it as a 4th or 5th example after the common ones.

Anti-Pattern 5: Examples That Are Too Detailed or Too Vague

Over-detailed: 10 pages of incident narrative before the summary (AI learns to produce verbose output).

Over-vague: "Stuff happened" (AI doesn't understand what information matters).

Prevention: Examples should be realistic in detail level. Show the facts before the formatted output.

Human Judgment Checkpoints

• 
  Example quality: "Are these examples actually good?" Review them before use. The examples are teaching moments, teach the right thing.
• 
  Format consistency: "Do all examples follow the same format?" If not, standardize before using them.
• 
  Coverage: "Do these examples cover the common scenarios the AI will encounter?" Make sure you're not teaching it to handle only rare cases.
• 
  Reusability: "Will I use this prompt multiple times?" Few-shot takes effort to set up. If it's a one-off, zero-shot might be better.

Key Takeaways

Few-shot prompting teaches AI through examples, not instructions. Show the AI what good looks like, then ask for similar output.

Use 3-5 good, representative examples. More doesn't mean better. Focus on quality and variety.

Examples must be consistent in format and tone. If examples contradict each other, output will be inconsistent.

Few-shot is worth the effort if the prompt will be reused. Set it up right the first time, then reuse repeatedly.

Structure the few-shot prompt clearly: Context → Format description → Examples → Request.

Avoid overfitting to examples. Include enough variety that AI generalizes to new scenarios, not just replicates your examples.

Document your few-shot prompts as institutional knowledge. These prompts become templates for how your team works. Share them.

Validate AI output against your examples. If output deviates from the example format, the prompt might need adjustment.

Few-shot prompting is a form of process documentation. The examples show how you want work done. Use them for training too.