Prompt Engineering

Prompt Engineering dient dazu, eine möglichst hohe Qualität des generierten Codes sicherzustellen und Multi-Agenten-Systeme in Migrations- und Modernisierungsprojekten effizient und zuverlässig einzusetzen. Im Mittelpunkt stehen praxisnahe Prinzipien, Vorlagen, Beispiele und Best Practices, die die Reproduzierbarkeit erhöhen, strukturierte Ausgabeformate erzwingen und das Fehlerrisiko in den erzeugten Artefakten reduzieren.

Begriffe

Prompt Engineering ist die systematische Gestaltung von Eingabeaufforderungen (Prompts) an ein KI-Modell (z. B. ein LLM), um Ergebnisse hinsichtlich Qualität, Korrektheit, Vollständigkeit, Konsistenz, Stil und Format gezielt zu steuern.

Prompts sind dabei als Engineering-Artefakte zu verstehen, weil sie:

Aufgabe, Rolle und erwartetes Ergebnis festlegen,
Grenzen definieren (Scope, Regeln, Qualitätskriterien),
einen Output-Vertrag (z. B. JSON, Diff, Markdown) erzwingen, damit Ergebnisse automatisiert geprüft und weiterverarbeitet werden können.

Rolle und Ziele

Prompt Engineering dient als Steuerungs- und Qualitätsmechanismus für die Arbeit der KI-Agenten und beeinflusst unmittelbar die Verwertbarkeit der erzeugten Artefakte (z. B. Migrationspläne, Codeänderungen, Tests, Dokumentation). Ziel ist es, Aufgaben, Rollen, Constraints und Ausgabeformate so zu definieren, dass das Agentensystem wiederholbar, vorhersehbar und prüfbar arbeitet.

Konkret ermöglicht es:

die Zerlegung komplexer Arbeiten in klar abgegrenzte Tasks mit definierten Inputs/Outputs,
die Durchsetzung eines Output-Vertrag (JSON/Diff/Markdown) für automatische Validierung und Integration,
die Verankerung von Qualitätskriterien (z. B. Definition of Done) direkt im Arbeitsauftrag,
die Kontrolle des Änderungsumfangs durch explizite Constraints („was darf geändert werden, was nicht“),
eine konsistente Orchestrierung (Rollen, Reihenfolge, kontextkonsistente Übergaben),
weniger Iterationsschleifen durch bessere Ersttrefferquote,
bessere Nachvollziehbarkeit und Auditierbarkeit durch standardisierte, strukturierte Outputs.

Prompt-Typen und Schichten

Bewährt hat sich eine geschichtete Struktur:

1. System- / Policy-Prompts

Definieren globale Regeln und Rahmenbedingungen:

Konventionen und Formatvorgaben
Do’s & Don’ts für die gesamte Interaktion

2. Rollen- / Agent-Prompts

Beschreiben die Rolle, die ein Agent einnimmt:

Beispiele: Requirements Analyst, Solution Architect, Migration Engineer, Test Engineer, Reviewer
Legen Verantwortlichkeiten und Perspektiven fest

3. Task-Prompts

Formulieren konkrete Aufgabenstellungen:

Beispiele: „Erstelle einen Migrationsplan“, „Generiere Tests“, „Refaktoriere Komponente X“
Steuern die operative Arbeit des Agenten

4. Kontext-Injektion

Stellt gezielte Artefakte und Hintergrundinformationen bereit:

Codeauszüge
API-Spezifikationen
Datenmodelle
Architekturentscheidungen (ADRs)
Styleguides

5. Output-Contract-Prompts

Definieren die erwartete Struktur und Validierung des Ergebnisses:

Strikte Spezifikation von Schema und Format
Validierungsregeln zur Sicherstellung der Konsistenz

Designprinzipien und Best Practices

1) Präzises Ziel

Was soll entstehen?
Für welchen Zweck?
Welche Entscheidung oder Umsetzung soll ermöglicht werden?

2) Explizite Constraints

Scope und Grenzen festlegen: Annahmen, Nicht-Ziele, erlaubte Module/Dateien.
Beispiel: „Keine neuen Dependencies ohne Begründung“, „Änderungen nur in Modul X“.

3) Output-Format als Vertrag

Ausgabe strikt definieren (z. B. JSON Schema, Markdown-Template, Unified Diff).
Keine Freitexte, wenn maschinelle Weiterverarbeitung vorgesehen ist.

4) Qualitätskriterien integrieren

Definition of Done, Checks, Edge-Cases.
Beispiel: „Füge eine kurze Liste möglicher Regressionen hinzu“.

5) Kontext sparsam und zielgerichtet

Nur relevanten Kontext bereitstellen; Überladung verschlechtert oft die Ergebnisse.

6) Few-Shot-Beispiele bewusst einsetzen

Wenige, repräsentative Beispiele erhöhen Konsistenz; zu viele fördern Overfitting auf Stil.

7) Iterationsfähigkeit einplanen

Entweder: „Wenn unklar, stelle Rückfragen“ oder: „Liste Annahmen und markiere Unsicherheiten“.

Standard-Template für Task-Prompts

Ein pragmatisches Template:

Rolle: Wer bist du?
Ziel: Was soll erreicht werden?
Input: Welche Artefakte liegen vor?
Kontext: Relevante Auszüge (Code/Specs/ADRs).
Constraints: Was ist erlaubt/verboten?
Output-Vertrag: Exaktes Format (Schema/Markdown/Diff).
Qualitätskriterien: Prüfpunkte, Risiken, Edge-Cases.
Beispiele: (optional) 1–2 Minimalbeispiele.

Beispiele

Beispiel A: Migrationsplan als strukturiertes JSON

Zweck: Automatisierbare Planungsschritte.

Rolle: Du bist Solution Architect für Software-Migrationen.
Ziel: Erstelle einen Migrationsplan vom Ist-System zur Zielarchitektur.
Input: Beschreibung des Ist-Systems, Ziel-Constraints, Abhängigkeiten.
Constraints:
- Keine Änderungen an externen Schnittstellen ohne explizite Kennzeichnung.
- Plane in Inkrementen mit Rollback-Strategie.
Output-Vertrag: Gib ausschließlich valides JSON mit folgendem Schema aus:
{
  "assumptions": [string],
  "risks": [{"id": string, "description": string, "mitigation": string}],
  "increments": [
    {
      "id": string,
      "goal": string,
      "changes": [string],
      "verification": [string],
      "rollback": string
    }
  ]
}
Qualitätskriterien:
- Jeder Inkrement-Schritt enthält mindestens 2 Verifikationspunkte.
- Risiken sind konkret und testbar.

Beispiel B: Code-Änderungen als Unified Diff

Zweck: Direkte Übernahme in Repository-Workflows.

Rolle: Du bist Migration Engineer.
Ziel: Refaktoriere die angegebene Komponente, um eine Legacy-API zu kapseln.
Constraints:
- Keine Verhaltensänderung nach außen.
- Halte Naming- und Formatting-Styleguide ein.
Output-Vertrag:
- Gib ausschließlich einen Unified Diff (git patch) aus.
- Wenn du Dateien anlegst: include vollständige Datei im Patch.
Qualitätskriterien:
- Ergänze am Ende (als Kommentarblock im Patch) eine Liste: "Mögliche Regressionen" (max. 5 Bulletpoints).

Orchestrierung: Prompt-Pipelines für Agentensysteme

Für komplexe Vorhaben ist eine Pipeline typischer als ein Einzelprompt:

Analyse (Ist-Zustand, Abhängigkeiten, Risiken)
Planung (Inkremente, Prioritäten, Strategie)
Umsetzung (Code-Transformation, Adapter, Datenmigration)
Verifikation (Testgenerierung, statische Analyse, Review)
Dokumentation (ADR, Migrationsnotizen, Betriebsdoku)

Bewährte Muster:

Plan-then-Execute: erst Plan, dann Implementierung.
Constrained Output: jede Stufe liefert maschinenlesbare Artefakte.
Reviewer/Verifier Stage: separater Prüfschritt zur kritischen Validierung.

Qualitätssicherung für Prompts (PromptOps)

Damit Prompt Engineering skalierbar bleibt, sollten Prompts wie Code behandelt werden:

Versionierung (Repository, Tags, Changelog)
Prompt-Tests
„Golden Inputs/Outputs“ (Snapshot-Tests)
Schema-Validierung (z. B. JSON Schema)
Regressionstests (Output-Stabilität)
Messgrößen (KPIs)
Anteil valider Outputs (Schema-Passrate)
Anzahl Nachbesserungsschleifen
Test-Passrate nach generierten Änderungen
Zeit bis zum verwertbaren Artefakt

Robustheit: Haluzinationen (falsche Annahmen)

Ein zentrales Risiko ist die Tendenz von Modellen/Agenten, nicht belegte Aussagen über Code, Schnittstellen, Abhängigkeiten oder Laufzeitverhalten zu erzeugen (z. B. „diese Methode existiert“, „dieses Feld hat Typ X“), obwohl dies nicht aus dem bereitgestellten Kontext ableitbar ist.

Warum das relevant ist

Haluzinationen können dazu führen, dass:

Refactorings auf falschen Prämissen beruhen,
Code nicht kompiliert oder Contracts verletzt,
versteckte Regressionen erst spät sichtbar werden.

Mitigation (praxisorientiert)

Explizite Annahmen erzwingen: Output enthält eine Sektion „Annahmen“, jede Annahme muss verifizierbar sein (z. B. Datei/Klasse/Methode).
Kein Raten: fehlt Kontext, wird eine Liste fehlender Informationen oder alternative Varianten mit Konsequenzen geliefert.
Grounding in Artefakten: Aussagen müssen auf konkrete Repo-Elemente referenzieren (Pfade, Typen, Codefragmente), nicht auf Vermutungen.
Output-Vertrag + Validierung: Schema, erlaubte Felder und Konsistenzregeln begrenzen den Spielraum für unprüfbare Behauptungen.
Tool-basierte Verifikation: Ergebnisse werden durch Repo-Suche, Build, Tests oder Linter bestätigt – nicht durch Selbstaussagen des Modells.
Verifier-Stage: separater Prompt prüft Änderungen gezielt auf unbelegte Aussagen, Inkonsistenzen und Kontextlücken.
Fail-closed: bei Inkonsistenzen stoppt die Pipeline (z. B. Schema-Verletzung, Build-/Testfehler) statt „trotzdem“ zu integrieren.

Praktische Leitlinien für die Weiterentwicklung

Prompt-Katalog aufbauen (Rollen, Tasks, Output-Verträge).
Templates standardisieren (einheitliche Struktur, Wiederverwendbarkeit).
Kontextstrategie definieren (welche Artefakte wann, in welcher Kürzung).
Prompt-Tests etablieren (Schema + Golden Sets).
Telemetry einführen (wo scheitern Prompts, welche Varianten funktionieren).
Governance festlegen (Review-Prozess, Freigaben, Dokumentation).

Zusammenfassung

Prompt Engineering ist ein zentraler Hebel, um Qualität, Reproduzierbarkeit und Prüfbarkeit der Agentenergebnisse zu erhöhen. Klare Ziele, explizite Constraints, strikte Output-Verträge, zielgerichteter Kontext sowie standardisierte Prompt-Pipelines verbessern die Ersttrefferquote und reduzieren Iterationen. Für nachhaltige Skalierung sind Versionierung, Tests, KPIs und ein Review-/Governance-Prozess erforderlich; Haluzinationen werden durch Grounding, Verifikation und fail-closed Mechanismen wirksam begrenzt.