About Semantic Anchors

Two-hour live coding session with Johannes Rabauer and Ralf D. Müller (May 2026). Read Johannes' session summary on rabauer.dev.

What are Semantic Anchors?

Semantic anchors are well-defined terms, methodologies, and frameworks that serve as reference points when communicating with Large Language Models (LLMs). They act as shared vocabulary that triggers specific, contextually rich knowledge domains within an LLM’s training data.

Think of them as shortcuts to rich context - instead of explaining a complex methodology from scratch, you can invoke a semantic anchor and the LLM will activate its entire knowledge base about that concept.

Example

Instead of saying:

"Write tests before writing code, use mocks to isolate dependencies, and design from the outside in."

You can say:

"Use TDD, London School approach."

The LLM understands this activates:

  • Mock-heavy testing methodology

  • Outside-in development approach

  • Interaction-based verification

  • The teachings of Steve Freeman and Nat Pryce

  • Designing through collaboration tests first

Why Use Semantic Anchors?

🎯 Precision

Semantic anchors provide unambiguous communication. When you reference "SOLID Principles," both you and the LLM understand exactly which five principles you mean.

🧠 Depth

A single semantic anchor can activate dozens of related concepts. "Domain-Driven Design" brings in bounded contexts, ubiquitous language, aggregates, value objects, and much more.

⚡ Efficiency

Instead of writing lengthy explanations, you can reference established methodologies that the LLM already knows deeply.

🔄 Consistency

Different people using the same semantic anchor will get similar, predictable results from the LLM, because the anchor refers to well-documented concepts.

Quality Criteria

Not every term makes a good semantic anchor. We maintain high quality standards:

Precise

References a specific, established body of knowledge with clear boundaries.

✅ "Hexagonal Architecture" (specific architectural pattern)

❌ "Good architecture" (vague, subjective)

Rich

Activates multiple interconnected concepts, not just a single instruction.

✅ "Behavior-Driven Development" (scenarios, Gherkin, living documentation, outside-in)

❌ "Write tests" (single instruction, no depth)

Consistent

Different users invoking it get similar conceptual activation.

✅ "Test-Driven Development" (widely documented, consistent understanding)

❌ "Modern testing" (different interpretations)

Attributable

Can be traced to key proponents, publications, or documented standards.

✅ "arc42" (Gernot Starke, Peter Hruschka)

❌ "Best practices" (no specific source)

What is NOT a Semantic Anchor?

Not every well-known term qualifies as a semantic anchor. Understanding what doesn’t work helps clarify what does.

Common Counter-Examples

These terms are frequently used but lack the depth and definition required for semantic anchors:

❌ Not a Semantic Anchor Why Not?

"TLDR"

Underspecified instruction with no defined structure or methodology. Just means "be brief" without any framework for how.

"ELI5" (Explain Like I’m 5)

Vague target level with no pedagogical framework. What does "5-year-old level" mean technically? No consistent interpretation.

"Keep it short"

Pure directive with no conceptual depth. It’s an instruction, not a methodology.

"Best practices"

Too vague and not attributable. Whose best practices? Based on what research or authority?

"Modern approach"

Ambiguous and inconsistent. "Modern" means different things to different people and changes over time.

"Make it simple"

No reference to specific simplification frameworks (unlike KISS principle or Occam’s Razor which are semantic anchors).

Comparison: Good vs. Bad

Details

Example 1: Testing Instructions

Bad: "Write good tests"

Problem

Vague instruction, no methodology

Result

Inconsistent interpretations

Good: "Test-Driven Development, London School"

Activates

Mock-heavy testing, outside-in design, interaction-based verification

Proponents

Steve Freeman, Nat Pryce

Result

Consistent, rich implementation


Example 2: Communication Style

Bad: "Keep it short"

Problem

No structure, just a preference

Result

Arbitrary length decisions

Good: "Pyramid Principle"

Activates

Start with conclusion, group ideas, logical ordering

Proponent

Barbara Minto

Result

Structured, repeatable communication pattern


Example 3: Code Quality

Bad: "Best practices"

Problem

Not attributable, no specific practices

Result

Everyone has different "best practices"

Good: "SOLID Principles"

Activates

Five specific design principles (SRP, OCP, LSP, ISP, DIP)

Proponents

Robert C. Martin

Result

Concrete, testable guidelines

The Key Difference

Semantic Anchors activate rich, interconnected knowledge domains from the LLM’s training data.

Simple Instructions just tell the LLM what to do, without providing conceptual framework or methodology.

Think of semantic anchors as nouns (methodologies, frameworks, principles) rather than verbs (instructions, directives).

Testing a Potential Anchor

Before proposing a new semantic anchor, ask an LLM:

What concepts do you associate with '<your term>'?

If the response includes:

  • ✅ Multiple interconnected concepts

  • ✅ Key proponents or publications

  • ✅ Specific techniques or practices

  • ✅ Clear scope and boundaries

→ It’s likely a good semantic anchor!

If the response is:

  • ❌ Just a simple definition

  • ❌ No attributed source

  • ❌ Vague or inconsistent interpretations

  • ❌ Just instructions without depth

→ It’s probably not a semantic anchor.

How to Use This Catalog

Browse by Category

The catalog is organized into 12 categories:

  • Communication & Presentation

  • Design Principles & Patterns

  • Development Workflow

  • Dialogue & Interaction Patterns

  • Documentation Practices

  • Meta (about this catalog itself)

  • Problem-Solving Methodologies

  • Requirements Engineering

  • Software Architecture

  • Statistical Methods & Process Monitoring

  • Strategic Planning & Decision Making

  • Testing & Quality Practices

Filter by Role

Select your professional role to see anchors most relevant to you:

  • Software Developer / Engineer

  • Software Architect

  • QA Engineer / Tester

  • DevOps Engineer

  • Product Owner / Product Manager

  • Business Analyst / Requirements Engineer

  • Technical Writer / Documentation Specialist

  • UX Designer / Researcher

  • Data Scientist / Statistician

  • Consultant / Coach

  • Team Lead / Engineering Manager

  • Educator / Trainer

Use the full-text search to find anchors by:

  • Title (highest priority)

  • Proponents and key people

  • Tags and keywords

  • Content and descriptions

Using Semantic Anchors with LLMs

In Prompts

Reference semantic anchors directly in your prompts:

"Refactor this code following SOLID Principles."

"Design this API using RESTful constraints as defined by Roy Fielding."

"Write these scenarios in Gherkin format per Behavior-Driven Development."

In Context Setup

Set up your LLM conversation with semantic anchors:

I'm working on a project where we follow:
- Test-Driven Development (TDD, Chicago School)
- Hexagonal Architecture
- Domain-Driven Design
- SOLID Principles

Please keep these in mind when suggesting code changes.

In Code Reviews

Ask the LLM to review code against specific methodologies:

Review this code for violations of:
- Single Responsibility Principle
- Dependency Inversion Principle
- Law of Demeter

Testing Recognition

Before relying on a semantic anchor, test if the LLM recognizes it:

What concepts do you associate with 'MECE'?

If the LLM provides accurate, detailed information, it’s safe to use that anchor.

Contributing

We welcome proposals for new semantic anchors! See our Contributing Guide for details on:

  • How to propose a new anchor

  • Quality criteria and testing methodology

  • Automated validation with GitHub Copilot

  • The review and publication process

Click Propose New Anchor to get started!

About This Project

Semantic Anchors is an open-source catalog maintained by the LLM Coding community. The project aims to:

  • Document effective communication patterns with LLMs

  • Establish shared vocabulary for AI-assisted development

  • Provide a curated, quality-controlled reference

  • Enable more precise and efficient human-AI collaboration

Technology

  • Website: Vite + Vanilla JavaScript

  • Styling: Tailwind CSS

  • Content: AsciiDoc

  • Visualization: Card Grid with category organization

  • Hosting: GitHub Pages

  • Automation: GitHub Actions + Copilot

License

This project is open source. See the LICENSE file for details.

Source Code

View the source, report issues, or contribute:


Ready to explore? Browse the catalog →