Context Engineering – KI-Assistenten optimal briefen

Context Engineering bezeichnet den systematischen Aufbau, die Strukturierung und das Management von Kontextinformationen für KI-Assistenten wie Claude, GPT-4 oder andere Large Language Models. Es ist die nächste Evolution von Prompt Engineering – während Prompt Engineering sich auf einzelne Eingaben fokussiert, geht es bei Context Engineering um das große Ganze: Wie vermittle ich der KI langfristig, wie sie in meinem Projekt arbeiten soll?

Context Engineering ist zentral für professionelles Agentic Coding geworden. Ohne strukturierten Kontext verhält sich die KI bei jedem Prompt anders. Mit gutem Context Engineering arbeitet sie konsistent nach den Regeln, die für Ihr Projekt gelten.

Warum Context Engineering wichtiger ist als Prompt Engineering

Das Problem mit reinem Prompt Engineering

Traditionelles Prompt Engineering fokussiert sich auf die einzelne Eingabe:

• Jeder Prompt muss alle relevanten Informationen enthalten
• Regeln müssen immer wieder wiederholt werden
• Keine Konsistenz über Sessions hinweg
• Kontext geht verloren wenn Token-Limit erreicht ist

Die Lösung: Context Engineering

Context Engineering etabliert einen persistenten, strukturierten Kontext:

• Regeln werden einmal definiert und automatisch berücksichtigt
• Projektspezifisches Wissen ist immer verfügbar
• Konsistentes Verhalten über alle Prompts hinweg
• Effiziente Nutzung des Context-Budgets

Die drei Ebenen des Context Engineering

1. Globale Ebene: Persönliche Präferenzen

Regeln, die für alle Ihre Projekte gelten:

• Datei: ~/.claude/CLAUDE.md (bei Claude) oder globale .cursorrules (bei Cursor)
• Inhalt: Generelle Entwicklungsprinzipien, bevorzugte Tools, Code-Style
• Beispiel: "Ich bevorzuge TypeScript über JavaScript. Niemals Credentials hardcoden. Immer deutsche Texte mit Umlauten (ä, ö, ü)."

2. Projekt-Ebene: CLAUDE.md / .cursorrules

Spezifische Regeln für das aktuelle Projekt:

• Datei: PROJECT_ROOT/CLAUDE.md oder .cursorrules
• Inhalt: Architektur, Tech-Stack, Coding-Konventionen, Deployment-Workflows, Testing-Anforderungen
• Beispiel: "Vue 3 mit Composition API. Logger statt console.log. Backend-Pfad ist /api/*. Build-Check vor jedem Commit."
• Best Practice: Konkrete Regeln ("NIEMALS X") statt vage Empfehlungen ("X sollte bevorzugt werden")

3. Memory-Ebene: Lessons Learned & Decisions

Dokumentation von Entscheidungen und gelernten Lektionen:

• Datei: MEMORY.md oder dokumentation/DECISIONS.md
• Inhalt: Warum wurde Technologie X gewählt? Welche Known Issues gibt es? Was hat in der Vergangenheit gut/schlecht funktioniert?
• Beispiel: "2026-02-10: Filter-Persistenz in Admin-Views ist PFLICHT. Immer localStorage nutzen. Pattern siehe LeadsDashboard.vue"

Context Budget Management

Jeder KI-Assistent hat ein Token-Limit für den Kontext. Effizientes Context Engineering nutzt dieses Budget optimal:

Context-Hierarchie

1. Immer im Kontext: CLAUDE.md, kritische Regeln (durch Tool automatisch eingebunden)
2. Bei Bedarf: Relevante Dateien für die aktuelle Aufgabe
3. Referenz: Memory Files, Dokumentation (KI kann bei Bedarf nachlesen)

Selective Reading

• Nur relevante Dateien für die Aufgabe in den Kontext laden
• Bei großen Projekten: Nicht das gesamte Repository auf einmal
• Beispiel: Frontend-Task → nur Frontend-Dateien laden

Session Handover

Wenn der Kontext zu voll wird:

1. Erstelle eine Session-Handover-Datei mit:
   • Abgeschlossene Aufgaben
   • Offene TODOs
   • Wichtige Entscheidungen dieser Session
   • Links zu geänderten Dateien
2. Speichere die Datei im Projekt (z.B. dokumentation/TODO-fuer-CLEAR/)
3. Neue Session kann diese Datei einlesen und nahtlos weitermachen

Auto-Compact (Claude Code)

Claude Code nutzt automatische Kontext-Komprimierung:

• Ältere Teile der Konversation werden komprimiert
• Wichtige Informationen bleiben erhalten
• Kein manuelles Context-Management nötig
• Session kann sehr lange laufen ohne /clear

Best Practices für CLAUDE.md / .cursorrules

1. Konkrete Regeln statt vage Empfehlungen

Schlecht: "Logger sollte bevorzugt werden"

Gut: "NIEMALS console.log/warn/error verwenden. IMMER Logger aus @/core/Logger nutzen."

2. Beispiele geben

// RICHTIG:
import { Logger } from '@/core/Logger'
Logger.debug('ADMIN', 'Loading models', { count: models.length })

// FALSCH:
console.log('Loading models')  // NIEMALS!

3. Anti-Patterns explizit verbieten

• "NIEMALS hardcodierte Credentials"
• "KEINE Mock-Daten oder Fallback-Werte"
• "NICHT window.innerWidth in onMounted (verursacht Layout Reflow)"

4. Workflows dokumentieren

## Deployment
```bash
./deploy.sh               # Interaktives Menü
./deploy.sh --dry-run     # Preview
./deploy.sh --skip-build  # Nur Deploy
```

5. Wichtiges hervorheben

Nutze visuelle Marker für kritische Regeln:

## ⚠️ KRITISCHE REGELN - ABSOLUT BINDEND

- **NIEMALS etwas hardcodieren**
- **KEINE FALLBACKS MIT DATEN**
- **IMMER echte Umlaute (ä, ö, ü, ß) verwenden**

Memory Files: Wissen bewahren

Was gehört in Memory Files?

• Architektur-Entscheidungen: Warum MongoDB statt PostgreSQL? Warum Microservices statt Monolith?
• Known Issues: "Playwright MCP muss in ~/.claude.json unter projects konfiguriert werden, nicht in settings.json"
• Patterns: "Filter-Persistenz Pattern: siehe LeadsDashboard.vue Zeile 45-67"
• Lessons Learned: "CSS background-image für Hero-Bilder verursacht schlechten LCP-Score. Immer echte <img> Tags nutzen."

Wann Memory Files aktualisieren?

• Nach jeder wichtigen Entscheidung
• Wenn ein Problem gelöst wurde (damit es nicht wieder auftritt)
• Wenn ein neues Pattern etabliert wurde
• Bei Session Handover

Context Engineering bei elasticbrains

Bei elasticbrains haben wir Context Engineering perfektioniert:

• Globale CLAUDE.md: Definiert unsere Coding-Standards über alle Projekte hinweg
• Projekt-CLAUDE.md: Jedes Projekt hat eine detaillierte CLAUDE.md mit spezifischen Regeln
• Memory-Dateien: Systematische Dokumentation in dokumentation/MEMORY/
• Session-Handover: Strukturierte Übergabe in dokumentation/TODO-fuer-CLEAR/
• Resultat: Jeder Entwickler (Mensch oder KI) kann sofort produktiv sein, Code ist konsistent

Context Engineering vs. Prompt Engineering

Aspekt	Prompt Engineering	Context Engineering
Fokus	Einzelne Eingabe	Gesamtes Projekt
Persistenz	Temporär	Dauerhaft
Wiederholung	Regeln müssen wiederholt werden	Einmal definiert, immer aktiv
Konsistenz	Variiert je nach Prompt	Einheitlich über alle Prompts
Team-Arbeit	Schwierig	Einfach (geteilter Kontext)

Tools und Techniken

Claude Code

• CLAUDE.md wird automatisch in jeden Prompt eingebunden
• Auto-Compact Management
• Memory Files können referenziert werden

Cursor

• .cursorrules Datei im Projekt-Root
• @-Mentions für Dateien und Docs
• Composer für lange Context-Sessions

GitHub Copilot

• Lernt aus geöffneten Dateien
• GitHub Copilot Chat kann Workspace durchsuchen
• Begrenzt: Kein explizites Context-File-System

Die Zukunft von Context Engineering

• Automatisches Context Management: KI lernt selbst, welcher Kontext relevant ist
• Team-Kontext: Geteilte Memory Files über mehrere Entwickler hinweg
• Versionierter Kontext: Context Rules in Git mit Branches und Merges
• Context-as-Code: Programmierbare, testbare Context-Regeln

Agentic Coding Workshop: Context Engineering meistern

In unserem Agentic Coding Workshop lernen Sie:

• Strukturierte CLAUDE.md / .cursorrules erstellen
• Effizientes Context Budget Management
• Memory Files systematisch pflegen
• Session Handover professionell durchführen
• Best Practices aus 3 Jahren Erfahrung

Weiterführende Ressourcen

• Glossar: Agentic Coding, Prompt Engineering
• Workshop: Agentic Coding Workshop
• Tools: Claude Code, Cursor, GitHub Copilot