Embeddings — a Tool, Not a Cancer

# "Embeddings Are a Cancer on the System": Harmful Dogmatic Advice That Robs You of a Useful Tool

## Dogmatic Advice from a Lecture

https://youtu.be/Nm3MsnngCJg?si=4QWKn2MKNIyEsEGg

Sheiko in Q&A says:

> "This is an old meme. Today you might have heard about cancer on top of embeddings, semantic search. Basically, it doesn't work. As someone who does AI engineering for companies, I'm telling you — don't use it unless you understand very, very well why you need it. If you're indexing code with embeddings, you should probably stop doing that too."

It sounds dogmatic. It sounds like expert opinion. The audience nods. Everyone thinks: "Okay, embeddings are evil, let's not use them."

This is **harmful advice**. Because it substitutes "embeddings aren't a panacea and aren't a replacement for grep/AST" with "embeddings are cancer and never use them." These are different statements. And the second one is false.

---

## Why Embeddings Aren't "Cancer"

Embeddings are a **tool**. Like grep. Like AST Search. Like any other search tool. It has strengths and weaknesses. Calling it "cancer" is like calling a hammer "cancer" because someone tried to use it on screws.

**Strengths of embeddings:**

- Semantic search: find by meaning, not exact match

- Search across unstructured data: comments, documentation, logs

- Search when you don't know exact terms or names

- Connecting scattered information from different sources

**Weaknesses of embeddings:**

- Don't work well for exact code search (grep is better here)

- Require infrastructure: vector database, indexing, updates

- Can produce false positives (semantic similarity ≠ relevance)

- Don't replace structural search (AST is better for that)

Embeddings are an **additional tool in the arsenal**, not a replacement for grep/AST. And there are specific cases where they're **irreplaceable**.

---

## Case 1: Search Across Static Information (Archives, Logs, Features, Bugs)

Imagine: you have a 5-year-old project. Over that time, you've accumulated:

- Thousands of Jira tickets (features, bugs, improvements)

- Incident logs with root cause analyses

- Architectural decisions (ADRs)

- Integration documentation with external systems

- Slack/Teams conversations on critical issues

When an agent needs to solve a task, it often needs **historical information**:

- "Why did we build this integration this way?"

- "Was there a bug like this before and how was it fixed?"

- "What were the client's constraints on this feature?"

grep is **useless** here. Because:

- You don't know the exact terms used 3 years ago

- Information is scattered across different systems (Jira, Confluence, Slack)

- Context might be in another language or with typos

**Embeddings solve this:**

1. Index all tickets, logs, ADRs, documentation into a vector database

2. Agent makes a semantic query: "Find all decisions about integration with system X and related bugs"

3. Vector database returns **semantically relevant** documents, even if they don't mention the exact name of system X

4. Agent gets context and makes decisions accounting for history

This isn't "cancer." This is a **powerful tool for working with unstructured historical information** that grep won't find.

---

## Case 2: Search Through Code Comments

Code comments are a **goldmine of tacit knowledge**. But grep across comments works poorly:

- Comments are often written in conversational, not technical language

- The same concept is described with different words

- A comment's context might be related to the task you're looking for, but not explicitly mentioned

**Example:**

You're looking for why module X uses a specific algorithm. grep for `algorithm` gives nothing. But a comment from 3 years ago says:

```python

# Using bubble sort instead of quicksort because

# the client required stable sorting for reports,

# and quicksort isn't stable. See ticket PROJ-1234

```

If you search for "why bubble sort" or "stable sorting" — grep might not find it if you don't know the exact phrasing. But embeddings find it by **semantic proximity**: the query "reason for choosing sorting algorithm" will return this comment.

**Embeddings for comments:**

1. Index all comments from the codebase

2. Agent makes a semantic query: "Why does module X use this approach?"

3. Vector database returns relevant comments

4. Agent gets context and understands the reasons behind decisions

This isn't "cancer." This is a **tool for extracting tacit knowledge** hidden in comments and inaccessible to grep.

---

## Case 3: Semantic Search on Complex Projects When You Don't Know Where to Look

On complex projects it often happens: **you know the information exists somewhere, but you don't know where**.

Examples:

- "There was a spec for this feature somewhere, but I don't remember the document name"

- "Someone wrote about this integration, but I don't remember where"

- "There was an architectural document, but I don't remember the exact title"

grep requires **exact terms**. If you don't remember the document name or exact phrasing — grep is useless.

**Embeddings solve this:**

1. Index all project documentation

2. Agent makes a semantic query: "Find the document about payment system integration"

3. Vector database returns relevant documents, even if they don't use the exact words "payment system" (might say "billing," "payments," "transactions")

4. Agent finds the needed document

This isn't "cancer." This is a **tool for navigating large volumes of documentation** when you don't know exact terms.

---

## Case 4: When a Spec Doesn't Link to Code

Common problem: **a spec describes requirements but doesn't reference specific code files**.

Example:

- Spec: "User must be able to cancel their subscription"

- Code: 50 files implementing this feature (controllers, services, models, views, tests)

When an agent needs to modify this feature, it must find **all related files**. But the spec doesn't contain a file list. grep for `cancel subscription` finds only explicit mentions, but not related files where this phrase isn't used.

**Embeddings solve this:**

1. Index code + specs

2. Agent makes a semantic query: "Find all code related to subscription cancellation"

3. Vector database returns files that are **semantically related** to this feature, even if they don't mention "subscription cancellation"

4. Agent gets the complete list of files to modify

This isn't "cancer." This is a **tool for linking requirements and implementation** when explicit references are absent.

---

## When Embeddings Don't Work (and Sheiko Is Right About This)

Sheiko is right about one thing: **embeddings don't work as a grep replacement for exact code search**.

If you need to find:

- All calls to function `calculateTotal()`

- All imports of module `auth`

- All places where variable `user_id` is used

Then **grep or AST Search is better**. Because:

- They give precise results

- They're faster

- They don't require infrastructure

Trying to use embeddings for such tasks is **misusing the tool**. It's like trying to drive screws with a hammer.

**Embeddings shouldn't replace grep/AST. They should complement them.**

---

## The Right Place for Embeddings in the Arsenal

Here's what the **correct search tool arsenal** looks like for an agent:

**1. grep (with indexing and filtering)**

- For exact code search

- For searching function names, variables, imports

- Fast, simple, no infrastructure needed

**2. AST Search**

- For structural code search

- For pattern search ("all calls without try-catch")

- Requires parsers but gives precise structural results

**3. Embeddings (vector search)**

- For semantic search across unstructured data

- For searching documentation, comments, logs, tickets

- For linking requirements and implementation

- Requires infrastructure but gives results unavailable to grep/AST

**4. Direct file reading**

- When the agent knows exactly which file to read

- For detailed analysis of specific code

Each tool solves **its own problem**. And embeddings aren't "cancer." They're a **specialized tool for specific tasks**.

---

## Why Sheiko Gave This Dogmatic Advice

Because he encountered **misuse of embeddings**:

**Misuse:**

- Team indexes all code into a vector database

- Agent searches code through embeddings instead of grep

- Results are imprecise, slow, with false positives

- Team gets disappointed and says "embeddings don't work"

This isn't an **embeddings problem**. This is a **misuse problem**. Like someone trying to drive screws with a hammer, getting disappointed, and saying "hammers are cancer, don't use them."

**Correct use:**

- Embeddings for unstructured data (documentation, comments, logs)

- grep/AST for exact code search

- Combination of tools for different tasks

---

## What to Do Right Now

If you have use cases where embeddings are useful:

**Step 1: Define what you need embeddings for.**

Not to replace grep. But for:

- Searching documentation

- Searching comments

- Searching tickets, logs, ADRs

- Linking requirements and implementation

**Step 2: Set up infrastructure.**

- Vector database (Chroma, Pinecone, Weaviate, Qdrant)

- Data indexing

- Index updates on changes

**Step 3: Integrate into the agent environment.**

- MCP tool for semantic search

- Agent uses embeddings when semantic search is needed, grep when exact search is needed

**Step 4: Don't try to replace grep.**

Embeddings are a **complement**, not a replacement. Use each tool for its own task.

---

## Conclusion

"Embeddings are a cancer on the system" is harmful dogmatic advice. It substitutes "embeddings aren't a panacea and aren't a replacement for grep" with "embeddings are evil and never use them."

Embeddings are a **useful tool** for specific tasks:

- Search across static information (archives, logs, features, bugs)

- Search through code comments

- Semantic search on complex projects when you don't know where to look

- Linking requirements and implementation when specs don't link to code

Embeddings **should not replace grep/AST**. They should **complement** them. Each tool solves its own task.

Those who say "embeddings are cancer" simply encountered misuse and drew the wrong conclusion. But that doesn't mean the tool is useless. It means it needs to be used correctly.

In a proper arsenal, there's room for all tools: grep for exact search, AST for structural, embeddings for semantic. And the agent uses each for its own task. This isn't "cancer." This is an **engineering approach**.

---

The correct model is two-stage:

**Stage 1: Embeddings for semantic search.**

You find relevant information by meaning in unstructured data: comments, documentation, logs, tickets. This is when you don't know exact terms and grep is useless.

**Stage 2: Structuring and indexing for grep.**

The found information is structured: indexes, metadata, relationships are created. After that, search goes through grep — fast, precise, without semantic inaccuracies.

This solves both problems:

- Embeddings find what grep won't (by meaning)

- grep provides the speed and precision that embeddings don't

Embeddings are a **bridge** from unstructured to structured. Not a grep replacement. But a way to prepare data so grep works effectively.