Vom Bauchgefühl zur Bauanleitung: Warum Context Engineering die Grundlage moderner KI-Entwicklung ist

Das Problem mit “perfekten Prompts”

Wir alle kennen das: Man schreibt einen sorgfältig formulierten Prompt an ChatGPT oder Claude, bekommt eine Antwort – und die KI hat den Kontext des Projekts komplett missverstanden. Falsche Architektur angenommen, veraltete Bibliotheken vorgeschlagen, Code-Style ignoriert.

Der Grund: Selbst der beste Prompt hilft nicht, wenn die KI nicht weiß, in welchem Kontext sie operiert.

Genau hier setzt Context Engineering an – die systematische Bereitstellung von strukturiertem Kontext, damit KI-Systeme konsistent und verlässlich arbeiten können.

Was ist Context Engineering?

Context Engineering ist die Praxis, Systeme zu designen, die entscheiden, welche Informationen ein KI-Modell sieht, bevor es eine Antwort generiert¹.

Oder anders formuliert: Context Engineering bedeutet, dynamische Systeme zu bauen, die die richtigen Informationen und Tools im richtigen Format bereitstellen, sodass das LLM die Aufgabe plausibel erfüllen kann².

Der Unterschied zu Prompt Engineering:

Prompt Engineering: “Wie formuliere ich meine Anfrage?”
Context Engineering: “Welche Informationen bekommt die KI automatisch, bevor ich überhaupt etwas frage?”

Warum Context Engineering jetzt relevant wird

Drei Entwicklungen machen Context Engineering zur kritischen Disziplin:

1. Agentic AI statt One-Shot-Prompts

Moderne KI-Assistenten sind nicht mehr statisch. Tools wie Cursor, Windsurf oder GitHub Copilot Workspace agieren als Agenten³ – sie führen mehrere Schritte aus, rufen Tools auf, durchsuchen Codebases.

Das Problem: Je länger eine Session läuft, desto mehr sammelt sich im Context Window an. Ohne Kontext-Management führt das zu:

Context Pollution: Irrelevante Informationen verstopfen das Context Window
Context Poisoning: Halluzinationen landen im Kontext und werden immer wieder referenziert
Tool Bloat: Zu viele Tools führen zu ambiguen Entscheidungen⁴

2. Model Context Protocol (MCP)

Im November 2024 hat Anthropic das Model Context Protocol (MCP) als offenen Standard veröffentlicht⁵. MCP standardisiert, wie KI-Systeme mit Datenquellen verbunden werden – statt fragmentierter Custom-Integrationen ein universelles Protokoll.

Die Adoption ist massiv:

März 2025: OpenAI integriert MCP in ChatGPT Desktop, Agents SDK und Responses API⁶
April 2025: Microsoft entwickelt offizielles C# SDK für MCP⁷
Tausende von MCP-Servern sind bereits verfügbar für Google Drive, Slack, GitHub, Postgres etc.

Das Resultat: Context Engineering wird vom manuellen Prozess zur systematischen Architektur-Disziplin.

3. IDE-integrierte KI mit Context-Files

Moderne Entwicklungsumgebungen haben Context Engineering eingebaut:

Cursor IDE: Nutzte lange .cursorrules als Legacy-Format, migriert jetzt zu .cursor/rules/ mit .mdc-Files (Markdown Components)⁸:

.cursor/
  rules/
    coding-style.mdc
    architecture.mdc
    testing.mdc

Jede Rule-Datei enthält Frontmatter (Metadaten) und Rule-Content – versioniert, strukturiert, teamfähig.

Windsurf IDE: Das von Codeium entwickelte “agentic IDE” kombiniert Copilot- und Agenten-Fähigkeiten in einem “Flow”⁹. Das Cascade AI Agent System hat deep codebase understanding und ist sich der Entwickler-Aktionen in Echtzeit bewusst.

Das Pattern: Context Files werden First-Class Citizens im Development Workflow.

Context Engineering in der Praxis

Schauen wir uns konkrete Techniken an, die den Unterschied machen.

Technik 1: Compaction (Kontext-Verdichtung)

Problem: Nach 20 Prompt-Response-Zyklen ist das Context Window voll.

Lösung: Compaction – die Konversation zusammenfassen, Context Window neu starten mit dem Summary¹⁰.

Praktisches Beispiel:

// Vor Compaction: 150.000 Tokens
const context = {
  conversation: [...20_exchanges],
  codebase: [...full_file_tree],
  tools: [...50_tool_definitions]
}

// Nach Compaction: 2.000 Tokens (98,7% Reduktion)
const compactedContext = {
  summary: "User implementiert Auth-System mit JWT",
  relevantFiles: ["auth.ts", "middleware.ts"],
  nextSteps: ["Token-Refresh implementieren"]
}

Anthropic dokumentiert einen Fall, wo ein Workflow von 150.000 auf 2.000 Tokens reduziert wurde – durch Code Execution und filesystem-basierte MCP APIs¹¹.

Technik 2: Context Files mit konkretem Schema

Statt alles in einen Mega-Prompt zu packen, strukturiert man Kontext in dedizierte Files.

Beispiel: .cursor/rules/coding-style.mdc

---
name: "TypeScript Coding Style"
priority: high
scope: ["*.ts", "*.tsx"]
---

# Code Style Rules

## Präferenzen
- Funktionale Programmierung > Klassen
- TypeScript strict mode
- Keine `any` Types
- Zod für Runtime Validation

## Testing
- Vitest für Unit Tests
- Testing Library für React
- Mindestens 80% Coverage

## Imports
```typescript
// ✅ Gut: Named Imports, gruppiert
import { useState, useEffect } from 'react'
import { z } from 'zod'
import type { User } from '@/types'

// ❌ Schlecht: Default Imports, unstrukturiert
import React from 'react'
const zod = require('zod')


**Der Vorteil**: Die KI bekommt präzise Regeln, bevor sie Code vorschlägt. Keine generischen "best practices", sondern projektspezifische Konventionen.

### Technik 3: Few-Shot Examples (kuratiert, nicht aufgebläht)

**Antipattern**: 50 Edge Cases in den Prompt stopfen.

**Better Practice**: 3-5 diverse, kanonische Beispiele, die das erwartete Verhalten zeigen[^12].

**Vorher (aufgebläht)**:

Hier sind 23 Beispiele, wie man Fehler behandelt:

try-catch mit console.log
try-catch mit Logger
try-catch mit Sentry …


**Nachher (kuratiert)**:
```markdown
# Error Handling Patterns

## Pattern: API Errors
```typescript
export async function fetchUser(id: string) {
  try {
    const response = await api.get(`/users/${id}`)
    return UserSchema.parse(response.data)
  } catch (error) {
    if (error instanceof ZodError) {
      logger.error('Invalid user data', { error, id })
      throw new ValidationError('User data invalid')
    }
    throw error
  }
}

Pattern: UI Error Boundaries

<ErrorBoundary fallback={<ErrorPage />}>
  <App />
</ErrorBoundary>


Die KI lernt aus wenigen, klaren Beispielen statt aus einem Wust von Spezialfällen.

### Technik 4: Tool Management (weniger ist mehr)

Anthropic warnt: **"One of the most common failure modes is bloated tool sets"**[^13].

Wenn ein menschlicher Engineer nicht definitiv sagen kann, welches Tool in einer Situation zu nutzen ist, kann es ein AI Agent erst recht nicht.

**Beispiel: File Operations**

```typescript
// ❌ Antipattern: 10 Tools für ähnliche Aufgaben
tools = [
  'read_file',
  'read_file_lines',
  'read_file_partial',
  'scan_file',
  'peek_file',
  'get_file_content',
  ...
]

// ✅ Better: 2 klare Tools
tools = [
  'read_file',        // Komplette Datei lesen
  'search_codebase'   // Gezielt nach Pattern suchen
]

Technik 5: Context Validation & Quarantine

Context Poisoning ist real: Eine Halluzination landet im Kontext, wird bei der nächsten Iteration referenziert, verfestigt sich.

Lösung: Context Validation¹²

function validateContext(context: Context): ValidatedContext {
  // 1. Prüfe auf widersprüchliche Informationen
  if (context.framework === 'React' && context.imports.includes('vue')) {
    throw new ContextPoisoningError('Framework mismatch')
  }

  // 2. Quarantäne für unsichere Informationen
  const quarantined = context.facts.filter(fact =>
    fact.confidence < 0.7
  )

  return {
    validated: context.facts.filter(f => f.confidence >= 0.7),
    quarantined
  }
}

MCP in Aktion: Ein konkretes Beispiel

Statt abstraktem Gerede schauen wir uns an, wie MCP konkret funktioniert.

Szenario: Eine KI soll Issues aus GitHub lesen, um Code-Kontext zu bekommen.

Ohne MCP (Custom Integration):

// Jede App braucht eigene GitHub-Integration
const octokit = new Octokit({ auth: process.env.GITHUB_TOKEN })
const issues = await octokit.rest.issues.listForRepo({
  owner: 'myorg',
  repo: 'myrepo'
})
// Dann manuell formatieren, cachen, error handling...

Mit MCP (Standardisiert):

MCP Server für GitHub (bereits verfügbar):

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

MCP Client (in deiner App):

import { MCPClient } from '@modelcontextprotocol/client'

const client = new MCPClient()
await client.connect('github')

// Standardisiertes Protocol – funktioniert mit jedem MCP-kompatiblen Tool
const issues = await client.callTool('github_list_issues', {
  owner: 'myorg',
  repo: 'myrepo'
})

Der Vorteil: Einmal MCP-Server aufsetzen, von allen MCP-Clients nutzen (Claude Desktop, Cursor, Windsurf, eigene Apps).

Das ist Context Engineering auf Infrastruktur-Ebene.

Workflow: Context Engineering für ein neues Feature

Konkret: Wie nutzt man Context Engineering beim Entwickeln?

Schritt 1: Session Splitting

Nutze dedizierte Sessions für verschiedene Phasen¹³:

Session A: Recherche & Design (lese Docs, analysiere Codebase)
Session B: Implementation (nutze Design-Summary aus Session A)
Session C: Testing & Bugfixes (nutze Implementation-Summary)

Warum? Jede Session bekommt optimierten Kontext statt einem aufgeblähten Misch-Kontext.

Schritt 2: Project Context File

Erstelle .cursor/rules/project-context.mdc:

---
name: "Project Context"
priority: highest
scope: ["*"]
---

# Project: E-Commerce Platform

## Stack
- Frontend: Next.js 14 (App Router), React 18, TypeScript
- Backend: tRPC, Prisma, PostgreSQL
- Auth: NextAuth.js mit JWT
- Payments: Stripe

## Architektur-Entscheidungen
- Server Actions statt API Routes
- Optimistic Updates für bessere UX
- Zod Schemas sind Single Source of Truth (shared zwischen Client/Server)

## Aktueller Stand
- Phase 1 (Auth, Products) ✅
- Phase 2 (Cart, Checkout) 🚧 in progress
- Phase 3 (Admin Dashboard) ⏳ pending

Schritt 3: Feature-spezifischer Kontext

Beim Implementieren von Checkout:

# Feature: Checkout Flow

## Kontext
- User hat bereits Cart (Cart-Context vorhanden)
- Stripe Integration steht, aber noch nicht verwendet
- Wir nutzen Server Actions für Payment-Flow (kein API Route)

## Ziel
- Multi-Step Checkout (Shipping, Payment, Confirmation)
- Optimistic UI für bessere UX
- Error Handling mit Toast Notifications

## Relevante Files
- app/checkout/page.tsx (neu erstellen)
- lib/actions/checkout.ts (Server Actions)
- lib/stripe.ts (existing)

Jetzt kann die KI fokussiert arbeiten – sie kennt Stack, Architektur-Entscheidungen, aktuellen Stand und Feature-Kontext.

Schritt 4: Validation Loop

Nach jedem größeren Schritt:

# Checkpoint: Checkout Step 1 (Shipping) implementiert

## Was funktioniert
- Form mit React Hook Form + Zod
- Server Action speichert Shipping-Info
- Optimistic UI zeigt Loading State

## Was noch fehlt
- Validation der PLZ gegen Versandregionen
- Error Handling bei Server-Fehler

## Nächster Schritt
- Payment Step implementieren

Diese strukturierte Dokumentation wird Teil des Kontexts für die nächste Session.

Praktischer Vergleich: Vorher/Nachher

Ohne Context Engineering

User: “Implementiere einen Login mit JWT”

KI (ohne Kontext):

// Generischer Code, passt nicht zum Projekt
import express from 'express'  // ❌ Projekt nutzt Next.js
import jwt from 'jsonwebtoken' // ❌ Projekt nutzt NextAuth

app.post('/api/login', (req, res) => {
  // Sehr basic, keine Integration mit existierendem Code
  const token = jwt.sign({ userId: req.body.id }, 'secret')
  res.json({ token })
})

Mit Context Engineering

Context Files aktiv:

.cursor/rules/project-context.mdc (Stack: Next.js, NextAuth)
.cursor/rules/coding-style.mdc (TypeScript strict, Zod validation)

User: “Implementiere einen Login mit JWT”

KI (mit Kontext):

// app/api/auth/[...nextauth]/route.ts
import NextAuth from 'next-auth'
import CredentialsProvider from 'next-auth/providers/credentials'
import { prisma } from '@/lib/prisma'
import { LoginSchema } from '@/lib/schemas' // Nutzt existierendes Schema
import bcrypt from 'bcryptjs'

export const authOptions = {
  providers: [
    CredentialsProvider({
      async authorize(credentials) {
        // Zod Validation (wie in coding-style.mdc definiert)
        const { email, password } = LoginSchema.parse(credentials)

        const user = await prisma.user.findUnique({ where: { email } })
        if (!user || !await bcrypt.compare(password, user.password)) {
          throw new Error('Invalid credentials')
        }

        return { id: user.id, email: user.email }
      }
    })
  ],
  session: { strategy: 'jwt' } // Wie im Projekt definiert
}

export const handler = NextAuth(authOptions)
export { handler as GET, handler as POST }

Der Unterschied:

Nutzt Next.js App Router (nicht Express)
Integriert mit existierender Prisma-DB
Befolgt Zod-Schema-Pattern aus coding-style
JWT-Strategy wie in project-context dokumentiert

Das ist der Wert von Context Engineering: Die KI macht nicht “irgendwas”, sondern das Richtige für dein Projekt.

Die Zukunft: Context-First Development

Context Engineering ist kein Nischen-Thema mehr. Es wird zur Kernkompetenz:

2024: “Schreibe bessere Prompts” 2025: “Baue bessere Context-Systeme” 2026: Context Engineering als Standard-Skillset für Entwickler

Die Tools entwickeln sich rasant:

MCP wird zum Standard-Protokoll (OpenAI, Microsoft, Google on board)
IDEs bauen Context-Management nativ ein (Cursor, Windsurf, VS Code)
AI Agents werden länger laufende, komplexere Aufgaben übernehmen

Wer jetzt Context Engineering lernt, ist vorbereitet.

Zusammenfassung: Die 5 wichtigsten Prinzipien

Context > Prompt: Investiere mehr Zeit in strukturierten Kontext als in perfekte Prompt-Formulierungen
Kuratiere, nicht Akkumuliere: Weniger, relevanter Kontext schlägt viel, unstrukturierten Kontext
Validiere Kontext: Implementiere Checks gegen Context Poisoning
Session Splitting: Nutze dedizierte Sessions für verschiedene Task-Phasen
MCP nutzen: Standardisierte Kontext-Integration statt Custom-Integrationen

Context Engineering ist die Grundlage, auf der moderne KI-Entwicklung steht. Je besser der Kontext, desto besser die Ergebnisse – und desto mehr Zeit bleibt für die eigentliche kreative Arbeit.