Ihr KI rät nur. Geben Sie ihm Kontext.

Warum das Ergebnis so stark schwankt

Hier ist dieselbe Anfrage, an dasselbe Modell geschickt, sechzig Sekunden auseinander.

Anfrage: „Schreibe Akzeptanzkriterien für ein Ticket: Nutzer kann KI-Anbieter-Einstellungen konfigurieren."

Erster Versuch — ohne Kontext: Das Ergebnis ist eine generische Checkliste. „Nutzer kann einen KI-Anbieter aus einer Dropdown-Liste auswählen. Nutzer kann Einstellungen speichern. Nutzer sieht eine Bestätigungsmeldung." Das könnte jedes Produkt, jede Plattform, jedes Jahrzehnt sein. Formal ist nichts falsch daran. Praktisch nützt es auch nichts.

Zweiter Versuch — mit Produktkontext: Das Ergebnis verweist auf Jira-Cloud-Admin-Seiten, Forge-Resolver-Berechtigungen, API-Key-Validierung pro Anbieter (OpenAI, Anthropic, Google, Mistral, xAI), Datenbereichsverhalten auf Organisations- vs. Projektebene und lizenzgebundene Schreibaktionen. Es spezifiziert, dass Einstellungen über @forge/sql persistiert werden und die UI Atlaskit-Komponenten mit xcss-Tokens verwendet. Es klingt, als hätte jemand tatsächlich in dieser Codebase gearbeitet.

Das Modell hat sich nicht verändert. Die Temperatur hat sich nicht verändert. Die Eingabe hat sich verändert. Dieser Spalt — zwischen generisch und produktnah — ist das eigentliche Thema dieses Artikels.

Wenn KI-Ausgaben inkonsistent wirken, ist der Instinkt, das Modell zu beschuldigen: Anbieter wechseln, Tiers upgraden, Temperatur anpassen. Fast immer ist das der falsche Hebel.

Jede Anfrage startet bei null. Das Modell hat keine Erinnerung an Ihr Produkt, Ihre Nutzer, Ihre Einschränkungen oder Ihr letztes Gespräch, wenn Sie diese Informationen nicht explizit mitgeben. „Schreibe Akzeptanzkriterien" bedeutet etwas völlig anderes für eine Jira-native Forge-App für Engineering-Teams von zehn bis hundert Personen als für eine Consumer-Fitness-App fürs Smartphone.

Das Modell antwortet auf die Welt, die Sie ihm beschreiben. Wenn Sie nichts beschreiben, erfindet es eine — und die ist selten Ihre.

Das ist der Grund, warum zwei Personen im selben Team dasselbe Modell nutzen und völlig unterschiedliche Ergebnisse bekommen können. Es ist kein Talent. Es ist keine Prompt-Struktur. Es ist die Frage, ob dem Modell genug Produktrealität mitgegeben wurde.

Für den größeren Rahmen, warum das in Jira so teure Fehler verursacht, lesen Sie: KI löst keine Fehlausrichtung in Teams. Sie versteckt sie.

Die Lösung ist keine bessere Prompting-Technik. Es ist der Aufbau einer wiederverwendbaren Kontextschicht — eine kompakte, ehrliche Beschreibung der Produktwelt — die vor jeder Anfrage beigefügt wird. Einmal schreiben. Überall wiederverwenden. Das Modell hört auf zu raten und arbeitet mit denselben Einschränkungen, mit denen Ihr Team arbeitet.

Die vier Schichten

Produktkontext ist kein einziger Textblock. Er zerfällt sauber in vier Schichten, die jeweils unterschiedliche Arbeit leisten.

• Produktzusammenfassung beschreibt, was das Produkt tut, für wen und welche Ergebnisse wichtig sind — operative Wahrheit, kein Marketing-Text. Der Unterschied ist entscheidend. „Ein Projektmanagement-Tool für Teams" könnte alles beschreiben. „Just ist ein Jira-nativer KI-Copilot für Produkt- und Engineering-Teams auf Jira Cloud. Kernaufgabe: mehrdeutige Jira-Issues in strukturierte Ausführungspläne verwandeln — Rückfragen, Schritt-für-Schritt-Pläne und Zurückschreiben in Jira-Felder — ohne das Issue-Panel zu verlassen. Kein Chatbot. Kein eigenständiges Tool. Gebaut auf Atlassian Forge." beschreibt exakt ein Produkt.
• Zielgruppe beschreibt, wer die Nutzer sind, was sie brauchen, was sie erwarten und was sie nicht wissen.
• Designsprache beschreibt visuelle Muster, Komponentenbibliothek, Interaktionsgewohnheiten und die Dinge, die Sie nie tun.
• Stack und Einschränkungen beschreibt reale Frameworks, Laufzeitgrenzen, Integrationen und explizit unzulässige Entscheidungen.

Die schlechte Version jedes Feldes passt auf Tausende von Produkten. Die gute Version passt genau auf eines. Das ist der Test.

Zielgruppe — wo generischer Kontext bricht

Zielgruppe ist meist das erste Feld, das Teams zu stark vereinfachen. „Product Manager und Entwickler" klingt vernünftig. Es ist auch zu vage, um dem Modell bessere Entscheidungen zu ermöglichen.

Ein nützliches Zielgruppen-Feld ist spezifisch über Teamgröße, KI-Vertrautheit, Vertrauenserwartungen und was Nutzer nicht möchten. Für Just bedeutet das: PMs und Senior-Engineers in Jira-Cloud-Teams von 10–100 Personen, mit moderater KI-Vertrautheit, die ihre eigenen API-Keys verwalten und mehr an verlässlicher Ausgabe interessiert sind als an beeindruckender.

Die „Nicht für"-Zeile ist genauso wichtig. Zu sagen, dass das Produkt nicht für Teams außerhalb von Jira Cloud oder für Nutzer gedacht ist, die vollständig autonome Agenten wollen, beseitigt ganze Kategorien falscher Annahmen, bevor sie entstehen.

Das macht Kontext geerdet statt dekorativ. Dem Modell wird nicht nur mitgeteilt, wer der Nutzer ist. Es wird auch erklärt, in welcher Welt dieser Nutzer agiert und welche Workflows sich falsch anfühlen würden.

Extrahieren, was bereits vorhanden ist

Die meisten Teams haben alle vier Kontextschichten bereits — sie sind nur über Codebase, Designdateien, Docs und Team-Gedächtnis verteilt, anstatt in einer Form, die KI verwenden kann.

Aus Ihrem Repository: Weisen Sie einen Coding-Agenten — Claude Code, Codex oder Ähnliches — auf Ihre Codebase und bitten Sie um eine Markdown-Zusammenfassung, die Produktzweck, Stack, Implementierungsgrenzen und bekannte Einschränkungen abdeckt. Ein gut strukturiertes Repository liefert in Minuten einen brauchbaren ersten Entwurf.

Aus Ihren Designdateien: Identifizieren Sie den Namen der Komponentenbibliothek, drei bis fünf Schlüssel-Interaktionsmuster, auf die sich Ihr Produkt stützt, und drei Dinge, die die UI nie tut. Die Anti-Patterns sind genauso wichtig wie die Patterns.

Aus bestehenden Docs: Onboarding-Notizen, README-Dateien, interne Briefs oder Marketingkontext können alle Fragmente von Produktzusammenfassung und Zielgruppendefinition liefern. Sie müssen nicht perfekt sein, um nützlich zu sein.

Aus Ihrem eigenen Kopf: Wenn nichts davon noch existiert, öffnen Sie ein leeres Dokument und schreiben Sie jetzt einen Absatz pro Feld. Es wird unvollkommen sein. Unvollkommener Kontext schlägt keinen Kontext um Längen.

Sie brauchen keine perfekte Dokumentation. Sie brauchen eine kompakte, ehrliche Beschreibung der Welt, in der Ihr Produkt lebt.

Einmal speichern, überall verwenden

Kontext zahlt sich nur aus, wenn er wiederverwendbar ist. Einmal schreiben und in eine einzige Session einfügen hilft dieser Session. Es dauerhaft machen hilft jeder Session.

• In Just hat das Admin-Panel einen eigenen Bereich für jede der vier Kontextfelder — Produktzusammenfassung, Zielgruppe, Designsprache und Stack. Fügen Sie Ihren Inhalt einmal pro Projekt in jedes Feld ein. Jeder zukünftige Insight, jede Rückfrage, jeder Plan und jeder Ausführungsschritt in diesem Projekt wird automatisch durch diesen Kontext fundiert.
• Wenn Sie Just nicht verwenden, erstellen Sie eine einzelne context.md-Datei im Root Ihres Repos oder in gemeinsamen Docs. Strukturieren Sie sie mit denselben vier Abschnitten. Fügen Sie sie zu Beginn jeder KI-Session ein — Coding-Assistenten, Chat-Tools, Dokumentengeneratoren. Das Format ist weniger wichtig als die Gewohnheit: Kontext zuerst, dann die Anfrage.

Behandeln Sie Ihre Kontextschicht als lebendiges Dokument, nicht als Launch-Day-Artefakt. Überarbeiten Sie sie, wenn sich das Produkt wesentlich ändert — eine neue Integration, eine bedeutende Zielgruppenverschiebung, eine Design-System-Migration. Überarbeiten Sie sie nicht jeden Sprint. Wenn Ihre Produktzusammenfassung sich alle zwei Wochen ändert, sind es keine Produktnotizen — es sind Meeting-Protokolle.

Kontext ist kein Prompt-Engineering

Produktkontext ist kein Prompt-Engineering. Es ist kein Trick, keine Vorlage, kein cleverer Hack. Es ist dem Modell dasselbe Briefing zu geben, das Sie einem neuen Auftragnehmer am ersten Tag geben würden: Hier ist, was wir bauen, für wen, wie es aussehen soll und worauf es läuft.

Teams, die das einmal tun — und es konsequent wiederverwenden — bekommen Ausgaben, die sich anfühlen, als kämen sie von jemandem, der das Produkt wirklich versteht. Weil sie das in jedem funktionalen Sinne auch tun. Das Modell wurde nicht klüger. Sie haben einfach aufgehört, es raten zu lassen.