DEV Community: Sanjay Mishra

Every AI Buzzword Explained With Analogy of Learning to Drive

Sanjay Mishra — Mon, 02 Mar 2026 06:33:38 +0000

You’ve seen the words everywhere.

LLM. RAG. Fine-Tuning. Agentic AI. MCP. Embeddings. Temperature.

Every article assumes you already know what they mean. Every explainer swaps one jargon word for three others.

So let’s try something different. One analogy. Stick with it all the way through. By the end, you’ll have a clean mental model for every major AI buzzword — and you’ll actually remember it.

The analogy: a person learning to drive a car.

What Is AI?

AI is like a person learning to drive.

At first, they know absolutely nothing. Put them behind the wheel and they’ll stare blankly.

But after watching and practicing — thousands of times — they start learning patterns:

🔴 Red light → Stop
🟢 Green light → Go
↩️ Turn signal on the car ahead → It may be turning

AI works the same way. Feed it enough examples, and it learns to recognise patterns. Then it uses those patterns to predict what comes next.

The critical thing to understand: AI does not think like a human. It doesn’t understand. It predicts — based on what it’s seen before. The more examples, the better the predictions.

Small Model vs LLM

Small Model = a new driver fresh out of driving school.

They can handle the basics:

They know the pedals
They can follow clear road signs
They drive slowly and carefully
Complex situations? Forget it

LLM (Large Language Model) = a driver who’s been on the road for years.

This person has driven through:

Busy cities at rush hour
Motorways at 3am
Torrential rain
Road rage incidents, construction zones, every edge case imaginable

They can handle almost anything you throw at them.

“Large” just means the model learned from a massive number of examples — billions of texts, not thousands.

The big LLMs you hear about? Each company has trained their own experienced driver:

Company	Their “Driver”
OpenAI	GPT-4, o3
Google	Gemini
Meta	Llama
Anthropic	Claude

They compete on one question: whose driver handles novel situations better?

Prompt Engineering

You get in the car and say:

“Drive.”

The driver stares at you. Drive where? How fast? Any stops?

Now you say:

“Take me to the airport. Fastest route. Avoid the motorway if there are delays.”

Now the driver knows exactly what to do.

A prompt is the instruction you give the AI. The model doesn’t change. Your instruction changes — and it changes everything.

Prompt engineering is the skill of giving great driving directions. Being specific. Giving context. Saying what you don’t want as well as what you do.

 Bad prompt:  "Write something about our product."

 Good prompt: "Write a 3-paragraph product description for a B2B SaaS tool
               targeting HR managers. Tone: professional but warm. Focus on
               time savings. End with a soft CTA."

Same model. Wildly different outputs.

Training

Before your driver became experienced, they had to practice. A lot.

City driving
Highway driving
Night driving
Parking
Roundabouts (the nemesis of every new driver)

Thousands of hours across thousands of different situations.

That practice is called training.

AI training works identically: you feed the model enormous amounts of examples, it adjusts its internal parameters after each one, and slowly — over months of compute time — it gets better.

Training a frontier model costs tens of millions of dollars. It’s done once (per model version) by the big labs. You and I don’t do training. We use the trained model.

Fine-Tuning

Your driver is already great at general driving.

But now you need something specific. You need a race car driver. Or a lorry driver who handles 40-tonne vehicles. Or an off-road specialist for rough terrain.

You send them on a specialist course. They come back permanently improved — not just in general driving, but in that specific skill.

That’s fine-tuning.

You take an existing model (the experienced driver) and train it further on your specific data — your company’s tone, your industry’s terminology, your support tickets, your legal documents.

The knowledge is baked in permanently. It’s not looking anything up. It is the specialised driver now.

Fine-tuning is more expensive than alternatives, but the specialisation is deep.

RAG — Retrieval-Augmented Generation

Your passenger asks:

“How long will it take to get to the airport?”

A bad driver guesses. Maybe confidently. Maybe wrongly.

A smart driver does this:

Opens Google Maps
Checks live traffic
Then answers

That’s RAG.

Instead of relying purely on what the AI learned during training, RAG first retrieves relevant documents — your company wiki, your database, today’s news, a knowledge base — then feeds them to the model as context before it answers.

The result: answers grounded in real, current information. Not guesses.

Fine-Tuning vs RAG — a common confusion:

	Fine-Tuning	RAG
Analogy	Permanent specialist training	Checking GPS each time
Knowledge	Baked in	Fetched live
Good for	Style, tone, domain expertise	Up-to-date facts, large document stores
Cost	Higher upfront	Per-query retrieval cost

Many production systems use both.

Embeddings & Vector Databases

An experienced driver has a mental map of the city.

They know:

The airport road connects to the motorway
The school zone is in the residential area near the park
Two roads that look different on a map actually connect the same neighbourhoods

This isn’t alphabetical knowledge (“A roads, B roads…”). It’s relational knowledge — understanding which places are semantically close to each other.

Embeddings are exactly this for AI.

Text is converted into lists of numbers (vectors) that capture meaning. “Dog” and “puppy” end up with similar numbers. “Paris” and “Eiffel Tower” are close. “Invoice” and “bill” cluster together.

A vector database stores all these number-maps so the AI can instantly find semantically similar content — not just keyword matches. This is the engine that powers RAG. When you ask a question, your question is turned into a vector, and the database finds documents with similar vectors.

Search query: "how do I cancel my subscription"
Finds docs about: "ending your plan", "account termination", "billing cancellation"
Even though none of them used the exact words "cancel my subscription"

Temperature

Same driver. Same route. Two very different personalities depending on the day.

Low temperature (0.1): Safe, predictable, follows the rules strictly. Always takes the same well-known route. Never improvises.

High temperature (1.0): Takes creative shortcuts. Tries new routes you’ve never heard of. Sometimes brilliant. Occasionally ends up in someone’s garden.

This is literally a parameter you can set when calling an AI model. It controls how random the model’s outputs are.

# Precise, factual tasks — use low temperature
response = client.messages.create(
   model="claude-opus-4-5",
   temperature=0.1,  # Predictable, consistent
   messages=[{"role": "user", "content": "What's the capital of France?"}]
)

# Creative writing — use higher temperature
response = client.messages.create(
   model="claude-opus-4-5",
   temperature=0.9,  # More varied, creative
   messages=[{"role": "user", "content": "Write me a poem about autumn."}]
)

Rule of thumb: Low temperature for facts. High temperature for creativity.

Agentic AI

Normal AI: you tell the driver “turn left,” “now right,” “stop here.” Every single step.

Agentic AI: you say “take care of my entire journey this week” and go back to reading your book.

The agent driver:

Plans the routes themselves
Checks fuel and refuels when needed
Adjusts dynamically for live traffic
Finds and pays for parking
Notifies you when each stage is done
Handles unexpected problems without calling you

You gave it a goal. Not a list of instructions.

This is the direction the whole industry is racing towards. Instead of answering a single question, agentic AI systems can:

Browse the web to research a topic
Write and execute code
Send emails and book meetings
Read and update databases
Complete multi-step workflows end-to-end

The key difference: normal AI responds. Agentic AI acts.

Tools

Even the best driver is limited without equipment.

With just their skills: good, but constrained.

With tools:

GPS — knows exactly where to go
Fuel gauge — knows when to stop
Traffic alerts — knows what to avoid
Payment app — can pay tolls and parking

Tools multiply what the driver can do.

AI tools work identically:

Web search — access real-time information
Code interpreter — write and run actual code
Database access — read and write data
APIs — interact with external services

A model with tools can do things a model without tools simply cannot. It’s not smarter — it’s better equipped.

MCP — Model Context Protocol

Your driver needs to use GPS, the fuel system, the traffic app, and the payment system.

Old approach: custom wiring for every combination. GPS talks to the car one way. Traffic app talks a different way. Payment system yet another way. A mess of proprietary connections.

New approach: one standard connection port. Every system plugs in the same way. Add a new tool? Plug it in. Works instantly.

That’s MCP (Model Context Protocol) — an open standard developed by Anthropic for how AI models connect to external tools and data sources.

Before MCP: every developer built custom integrations between their AI and their tools. Hundreds of different “wiring” approaches, incompatible with each other.

After MCP: build one MCP server, and any compatible AI can use it. Standardised. Composable. Interoperable.

It’s the USB-C of AI integrations.

Hallucination

The driver confidently tells you:

“Oh yes, I know this road well. My grandfather drove this route for 40 years. There’s a great shortcut just ahead.”

There is no grandfather. There is no shortcut. The driver made it up — with complete confidence.

Hallucination is when AI generates false information that sounds completely plausible.

It’s not lying. It has no concept of lying. It’s generating the most statistically likely continuation of the conversation — and sometimes that means inventing facts that sound right but aren’t.

RAG and grounding techniques reduce hallucinations by anchoring the model to real documents. But they don’t eliminate the problem entirely.

The rule: always verify important AI outputs. Especially dates, statistics, citations, and anything that would be embarrassing if wrong.

Tokens

The taxi meter doesn’t charge by journey. It charges by distance — every fraction of a mile.

AI doesn’t process words. It processes tokens — chunks of characters, roughly ¾ of a word each.

"Hello, world!"   → ~4 tokens
"The quick brown fox" → ~5 tokens
"Retrieval-Augmented Generation" → ~5 tokens

Why does it matter?

Pricing is per token (both input and output)
Context limits are measured in tokens
Speed depends on token count

Every API call to an AI model is metered. The more you send, and the more the model generates back, the more tokens you consume — and the more you pay.

Context Window

The driver can only hold so many things in their working memory at once.

If you brief them on 10 things before the journey, they’ll probably remember all 10. Brief them on 200 things and they’ll start forgetting the early ones by the time you hit the road.

The context window is how much the AI can “see” and “remember” at once — the conversation history, any documents you’ve provided, the system prompt, your new message. All of it has to fit.

Modern models have huge context windows:

GPT-4o: ~128K tokens (~96,000 words)
Claude: up to 200K tokens (~150,000 words)
Gemini 1.5 Pro: up to 1M tokens

Beyond the window? The model simply doesn’t know it. Old messages fall off the edge.

The Complete Cheat Sheet

Term	The Driving Analogy	Plain English
AI	The whole concept of a driver learning	Machines doing smart things
Small Model	New learner driver	Basic skills, limited ability
LLM	Experienced driver who’s seen everything	Trained on billions of examples
Prompt	Your driving directions	Instruction you give the AI
Prompt Engineering	Learning to give great directions	Crafting inputs for better outputs
Training	Driving school + years of practice	Teaching the model from examples
Fine-Tuning	Specialist driving course	Adapting a model to a specific domain
RAG	Driver checks GPS before answering	Retrieves real docs before responding
Embeddings	Road map in the driver’s head	Text stored by semantic similarity
Vector DB	The map library	Database searchable by meaning
Temperature	Cautious vs. creative driving style	Controls randomness in outputs
Agentic AI	Driver who runs the whole trip solo	AI that plans and acts autonomously
Tools	GPS, fuel gauge, payment app	Web search, APIs, code execution
MCP	Universal car connection port	Standard protocol for AI ↔ tools
Hallucination	Driver invents a non-existent shortcut	AI confidently states false things
Token	Individual meter ticks	Unit of text AI processes
Context Window	Driver’s working memory	How much AI can see at once

The Bigger Picture

These aren’t separate things. They stack.

A production AI system in 2025 typically looks like this:

You write a prompt (clear directions)
RAG retrieves relevant documents (driver checks GPS)
A fine-tuned LLM reads everything (specialist driver applies training)
Embeddings powered the retrieval (mental map found related content)
Agentic behavior kicks in if action is needed (driver handles the trip)
Tools via MCP connect it to the real world (GPS + payment + everything else)

Every buzzword is one piece of the same vehicle.

If this helped, share it with whoever is still nodding along blankly when their CTO says “we’re building a RAG pipeline with an agentic layer.” They’ll thank you.

Unbounded Data Fetching: A Silent Performance Anti-Pattern in API and Database Layers

Sanjay Mishra — Sun, 22 Feb 2026 20:50:40 +0000

Overview

One of the most pervasive and costly performance anti-patterns in backend development is unbounded data fetching — querying the database for an entire result set when only a fraction of that data is needed by the caller. This pattern is deceptively simple to introduce, difficult to detect in development environments with limited data, and expensive in production systems operating at scale.

This article examines where unbounded fetching occurs, why it degrades performance across the full request lifecycle, and how to eliminate it at each layer of the stack — from SQL queries to ORM abstractions to API contract design.

What Is Unbounded Fetching?

Unbounded fetching occurs when an application retrieves more data from a data source than it intends to use or return. The most common manifestation is a query with no LIMIT, TOP, ROWNUM, or equivalent constraint — combined with application-side filtering or slicing after the result set has already been transferred.

Consider the following example:

# Python + cx_Oracle
cursor.execute("SELECT * FROM orders")
rows = cursor.fetchall()
return rows[:10]

The output of this code — 10 rows — is identical to a query that fetches only 10 rows. The cost is not. The database must evaluate and serialize the full result set, the network must carry it, the driver must deserialize it, and the application server must allocate memory to hold it. Every step in this pipeline scales with the number of rows returned by the query, not the number of rows ultimately used.

The same pattern appears in other forms:

# Application-side filtering after full fetch
users = db.query("SELECT * FROM users WHERE active = true")
admins = [u for u in users if u['role'] == 'admin']

# ORM equivalent
orders = Order.objects.all()
recent = [o for o in orders if o.created_at > threshold]

# Node.js / Sequelize
const records = await Model.findAll();
return records.slice(0, 10);

In each case, the constraint is applied in application code rather than being pushed down to the database where it belongs.

The Performance Cost Across Layers

Understanding why unbounded fetching is expensive requires examining what happens at each layer of the data path.

Database Layer

Without a row-limiting clause, the database query optimizer cannot use early-exit optimizations. A full table scan or index scan is executed to completion. For a table with 700,000 rows and 9 columns, this means evaluating and preparing all 700,000 rows for transfer regardless of how many the application will use.

Oracle's ROWNUM pseudo-column, for example, causes the execution plan to terminate row evaluation as soon as the limit is reached. Without it, the plan has no such signal.

Network Layer

Serialized row data must travel from the database server to the application server. On a local network, this is fast but not free. In a cloud architecture where the database and application tier are separated — even within the same region — data transfer incurs latency proportional to payload size, and in some configurations, measurable egress costs.

A table with 700,000 rows of average row size 200 bytes represents approximately 140 MB of raw data per unbounded query. Under moderate concurrency, this becomes a significant bandwidth consumer.

Application Layer

The database driver deserializes the wire-format response into language-level objects — Python tuples, Java POJOs, JavaScript objects. Memory is allocated for the full result set before any application logic executes. For Python's cx_Oracle or psycopg2, a 700,000-row result set can consume several hundred megabytes of heap memory per request. Under concurrent load, this accelerates memory pressure and can trigger garbage collection cycles that further degrade throughput.

The combined effect across layers produces response times that are orders of magnitude slower than equivalent bounded queries — not because the application logic is slow, but because the data pipeline is doing unnecessary work at every stage.

Correcting the Pattern at the SQL Layer

The fix must be applied at the source — in the SQL query itself. Each major database platform provides a mechanism for row limiting:

-- Oracle (legacy)
SELECT * FROM orders WHERE ROWNUM <= 10;

-- Oracle 12c+ / ANSI SQL standard
SELECT * FROM orders FETCH FIRST 10 ROWS ONLY;

-- PostgreSQL / MySQL / SQLite
SELECT * FROM orders LIMIT 10;

-- SQL Server
SELECT TOP 10 * FROM orders;

For filtered queries, the constraint should be combined with appropriate indexing:

-- With filtering and ordering
SELECT * FROM orders
WHERE status = 'PENDING'
ORDER BY created_at DESC
FETCH FIRST 25 ROWS ONLY;

This approach allows the database query optimizer to select an execution plan that respects the row limit. In many cases, this enables index-based access paths that avoid full table scans entirely.

Correcting the Pattern at the ORM Layer

ORMs introduce an additional risk: their abstractions can obscure the SQL being generated, making it easy to write code that looks harmless but produces expensive unbounded queries.

SQLAlchemy (Python):

# Unbounded — generates SELECT * FROM orders with no LIMIT
session.query(Order).all()[:10]

# Bounded — generates SELECT * FROM orders LIMIT 10
session.query(Order).limit(10).all()

# With filtering
session.query(Order).filter(Order.status == 'PENDING').order_by(
    Order.created_at.desc()
).limit(25).all()

Django ORM (Python):

# Unbounded — fetches all records into memory before slicing
orders = list(Order.objects.all())[:10]  # list() forces evaluation

# Bounded — Django QuerySet slicing translates to LIMIT in SQL
orders = Order.objects.all()[:10]

# Correct pattern with ordering
orders = Order.objects.filter(status='PENDING').order_by('-created_at')[:25]

Note: Django QuerySet slicing generates a LIMIT clause only when the QuerySet has not been previously evaluated. Calling list(), len(), or iterating the QuerySet before slicing evaluates it fully.

Sequelize (Node.js):

// Unbounded
const orders = await Order.findAll();
return orders.slice(0, 10);

// Bounded
const orders = await Order.findAll({
  limit: 10,
  order: [['createdAt', 'DESC']]
});
return orders;

Spring Data JPA (Java):

// Unbounded — loads entire collection
List<Order> orders = orderRepository.findAll();
return orders.subList(0, 10);

// Bounded — uses Pageable to generate LIMIT/OFFSET
Pageable pageable = PageRequest.of(0, 10, Sort.by("createdAt").descending());
Page<Order> orders = orderRepository.findAll(pageable);
return orders.getContent();

A practical measure during code review is to flag any application-side slicing operation ([:10], .subList(), .slice(), .take()) that follows a database query call. These are strong indicators that limiting is happening in the wrong layer.

Correcting the Pattern at the API Layer

Unbounded fetching is not only a database concern. An API endpoint that returns an unbounded collection by default has the same problem at a higher level of abstraction — it transfers more data than the client needs and places no constraint on the downstream database query.

Well-designed APIs enforce explicit, bounded result sets through pagination:

GET /api/orders?page=1&limit=25
GET /api/orders?cursor=eyJpZCI6MTAwfQ==&limit=25

Two pagination strategies are in common use:

Offset-based pagination is straightforward to implement and supports random page access, but degrades in performance at high offsets as the database must skip rows:

SELECT * FROM orders ORDER BY created_at DESC LIMIT 25 OFFSET 500;

Cursor-based pagination uses a stable reference point (typically a primary key or timestamp) to avoid the offset penalty. It is the preferred approach for large datasets and real-time data:

SELECT * FROM orders
WHERE id < :cursor_id
ORDER BY id DESC
LIMIT 25;

Regardless of strategy, two enforcement rules should apply at the API layer:

Default to a safe page size. A request that does not specify a limit should receive a bounded default (e.g., 20 or 25 records), not the full table.
Enforce a server-side maximum. Client-supplied limits should be capped:

DEFAULT_PAGE_SIZE = 25
MAX_PAGE_SIZE = 100

def get_orders(limit: int = DEFAULT_PAGE_SIZE) -> list:
    limit = min(limit, MAX_PAGE_SIZE)
    return db.query(
        "SELECT * FROM orders ORDER BY created_at DESC FETCH FIRST :n ROWS ONLY",
        n=limit
    )

This prevents a single API call from triggering an unbounded database query regardless of what the client requests.

Beyond Pagination: Other Manifestations of the Pattern

Unbounded fetching appears in contexts beyond basic list endpoints.

Existence checks:

# Unbounded — fetches all matching rows to check if any exist
rows = db.query("SELECT * FROM users WHERE email = ?", email)
if len(rows) > 0: ...

# Bounded — stops at the first match
row = db.query(
    "SELECT 1 FROM users WHERE email = ? FETCH FIRST 1 ROW ONLY", email
)
if row: ...

In-application aggregations:

# Unbounded — transfers all rows to compute a sum in Python
rows = db.query("SELECT amount FROM orders WHERE customer_id = ?", cid)
total = sum(row['amount'] for row in rows)

# Correct — delegates aggregation to the database
result = db.query(
    "SELECT SUM(amount) AS total FROM orders WHERE customer_id = ?", cid
)
total = result[0]['total']

Duplicate detection:

# Unbounded
all_records = db.query("SELECT * FROM events")
seen = set()
duplicates = [r for r in all_records if r['id'] in seen or seen.add(r['id'])]

# Correct — delegate to SQL
duplicates = db.query("""
    SELECT id, COUNT(*) as cnt FROM events
    GROUP BY id HAVING COUNT(*) > 1
""")

In each case, the database is better equipped to perform the operation than the application layer. Delegating work to the database reduces data transfer, leverages indexes, and reduces memory consumption in the application tier.

Quantifying the Impact

To illustrate the scale of the problem, consider a table of 700,000 rows with 9 columns and an average row size of 200 bytes:

Metric	Unbounded Fetch	Bounded Fetch (10 rows)
Rows transferred	700,000	10
Approximate data volume	~140 MB	~2 KB
Driver deserialization cost	High	Negligible
Memory allocated (API server)	~200–400 MB	< 1 MB
Response time (single request)	8–15 seconds	< 50ms
Data reduction	—	99.999%

These figures represent a single request. Under concurrent load — 50, 100, or 500 simultaneous users hitting the same endpoint — the impact compounds multiplicatively across CPU, memory, and network resources.

Code Review Checklist

The following signals in code review indicate potential unbounded fetch issues:

fetchall(), .all(), or findAll() without an accompanying .limit() or SQL LIMIT/FETCH FIRST clause
Application-side slicing on query results: rows[:n], .subList(0, n), .slice(0, n), .take(n)
Aggregation, sorting, or filtering logic applied to a variable that holds a full query result
API endpoints that accept a limit parameter but do not enforce a server-side maximum
ORM calls where the QuerySet or criteria object is evaluated (via list(), len(), or iteration) before pagination is applied
Integration tests using a dataset of fewer than 1,000 rows that have not been load-tested against production-scale data volumes

Summary

Unbounded data fetching is a structural inefficiency that operates silently across the database, network, and application layers. It produces correct output in low-data environments, making it resistant to detection through standard testing. At production scale, it degrades response times, increases memory consumption, saturates network bandwidth, and under concurrent load, can destabilize the entire service.

The remediation is consistent across all layers: push data constraints as close to the source as possible. Apply LIMIT, FETCH FIRST, or TOP in SQL queries. Use .limit() at the ORM layer rather than slicing collections in application code. Design API contracts that enforce bounded defaults and server-side maximums. Delegate aggregations, filters, and existence checks to the database rather than performing them on transferred data.

The database exists to evaluate, filter, and limit data efficiently. Every row transferred beyond what the application needs is a cost that scales with your data volume and your user concurrency — and pays nothing in return.

Refer the details of Orcale Performance tuning in my book https://a.co/d/0dqlb969