Viele Entwicklerinnen und Entwickler kennen dieses Muster: Man öffnet Claude Code, Cursor oder ein anderes KI-Coding-Tool, schreibt einen halbwegs guten Prompt, bekommt eine Antwort, die fast funktioniert, verbessert den Prompt, bekommt eine leicht andere Lösung, die wieder nicht ganz passt – und kommt irgendwann zu dem Schluss: „KI-Tools fürs Programmieren sind überbewertet.“
Doch das eigentliche Problem liegt oft nicht beim Modell. Es liegt am Kontext.
Der Moment, in dem alles klar wurde
Bei einem größeren Backend-Refactoring zeigte sich genau das: Die KI lieferte technisch korrekte Vorschläge, verfehlte aber wichtige Details des bestehenden Systems. Es ging um Transaktions-Rollbacks, spezielle Retry-Logik und historische Entscheidungen, die nach einem Produktionsvorfall getroffen worden waren.
Erst als die relevanten Architekturentscheidungen, interne Dokumentation und der Grund für diese Retry-Logik in den Kontext gegeben wurden, änderte sich die Qualität der Antwort drastisch. Plötzlich war die Lösung fast produktionsreif.
Das Modell war nicht plötzlich intelligenter geworden. Es hatte nur endlich die richtige Umgebung bekommen, um sinnvoll zu arbeiten.
Warum Prompt Engineering nicht mehr reicht
Prompt Engineering konzentriert sich darauf, wie man eine Anfrage stellt: Formulierungen, Struktur, Anweisungen, Stil. Das ist nicht unwichtig, bleibt aber oberflächlich.
Context Engineering geht tiefer. Es fragt: Welche Informationen braucht die KI, um die richtige Entscheidung zu treffen?
Dazu gehören unter anderem:
- relevante Codeausschnitte
- Datenbankschemas und Typdefinitionen
- Architekturentscheidungen
- historische Gründe für bestimmte Lösungen
- Geschäftsregeln und technische Einschränkungen
- frühere Fehler, Bugs oder gescheiterte Ansätze
Gute KI-Ergebnisse entstehen nicht nur durch bessere Prompts, sondern durch bessere Vorbereitung.
Warum Senior Engineers im Vorteil sind
Genau hier haben erfahrene Entwicklerinnen und Entwickler einen unfairen Vorteil. Sie wissen nicht nur, wie Code geschrieben wird. Sie wissen, warum ein System so aussieht, wie es aussieht.
Junior Developers kennen oft Syntax, Frameworks und Tools. Was ihnen häufig fehlt, ist das Systemverständnis: Welche Entscheidung wurde früher getroffen? Welche Lösung wurde schon einmal ausprobiert? Welche Einschränkung steht nirgends sauber dokumentiert, ist aber entscheidend?
Diese Erfahrung ist der Treibstoff für Context Engineering.
Ein Senior Engineer gibt der KI nicht einfach die Aufgabe: „Schreib diese Funktion.“ Er liefert zusätzlich die relevanten Dateien, erklärt Randbedingungen, verweist auf Architekturentscheidungen und beschreibt, warum die offensichtliche Lösung im konkreten System falsch wäre.
Context Engineering in der Praxis
Ein nützlicher Ansatz ist ein kleines „Kontextdokument“, bevor man überhaupt mit der KI arbeitet. Dieses Dokument muss nicht perfekt sein. Oft reichen zehn Minuten Vorbereitung.
Es sollte beantworten:
Was soll gebaut werden?
Welche Systeme sind betroffen?
Welche Einschränkungen gibt es?
Welche Entscheidungen wurden bereits getroffen?
Welche Altlasten oder historischen Besonderheiten sind wichtig?
Besonders wichtig sind Datenstrukturen. Wenn eine KI keine Schemas, Typdefinitionen oder API-Verträge kennt, erfindet sie plausible Strukturen. Das führt zu besonders tückischen Fehlern: Der Code sieht logisch aus, ist aber fachlich falsch.
Auch bei Infrastrukturthemen kann Kontext entscheidend sein. Wer etwa mit AWS, IAM-Policies, Lambda-Funktionen oder S3-Events arbeitet, sollte der KI konkrete Policy-Snippets, Architekturhinweise und Kommunikationswege zwischen Services mitgeben. Sonst trifft das Modell Annahmen, die allgemein sinnvoll wirken, aber im eigenen Setup falsch sind.
Der Einfluss auf Code Reviews
Interessant ist auch, wie Context Engineering Code Reviews verändert. Bei KI-unterstützten Pull Requests reicht es nicht mehr, nur den Code zu prüfen.
Die bessere Frage lautet: Welchen Kontext hat die Entwicklerin oder der Entwickler der KI gegeben?
Viele Fehler entstehen nicht, weil die KI „dumm“ war. Sie entstehen, weil sie zu wenig über das Gesamtsystem wusste. Dadurch wird Code Review stärker zu einer Lehrsituation: Es geht nicht nur darum, falschen Code zu korrigieren, sondern darum, Systemverständnis aufzubauen.
Die wichtigste Erkenntnis
Viele Entwickler verbringen zu viel Zeit damit, Prompts zu optimieren. Andere Formulierungen, neue Rollenbeschreibungen, bessere Anweisungen. Das kann helfen, ist aber selten der größte Hebel.
Der bessere mentale Vergleich lautet: Eine KI ist wie ein sehr fähiger externer Contractor, der gerade neu ins Unternehmen kommt. Sie kann viel. Vielleicht sogar sehr viel. Aber sie kennt das System nicht. Sie kennt die Historie nicht. Sie kennt nicht die Entscheidungen, die vor Jahren getroffen wurden.
Ohne gutes Onboarding liefert selbst ein brillanter Contractor Arbeit, die nicht richtig passt.
Context Engineering ist genau dieses Onboarding.
Was Teams jetzt tun sollten
Die Teams, die in Zukunft besonders stark von KI profitieren werden, investieren nicht nur in bessere Tools. Sie investieren in Wissensinfrastruktur.
Das bedeutet:
Aktuelle Dokumentation.
Gepflegte Architecture Decision Records.
Klare Runbooks.
Dokumentierte Constraints.
Nachvollziehbare Systementscheidungen.
Das klingt weniger aufregend als ein neues KI-Modell. Aber genau diese Grundlagen entscheiden darüber, ob KI im Entwicklungsalltag wirklich produktiv macht.
Fazit: Das neue Spiel heißt Kontext
Die Frage ist nicht mehr nur: „Welchen Prompt schreibe ich?“
Die wichtigere Frage lautet: „Welche Informationen stelle ich bereit, damit die KI die Aufgabe im richtigen Zusammenhang versteht?“
Wer mit KI-Coding-Tools frustriert ist, sollte den Fokus verschieben: weg von der perfekten Formulierung, hin zum richtigen Kontext.
Denn guter Code entsteht nicht durch magische Prompts. Er entsteht, wenn die KI versteht, in welchem System sie arbeitet.