KI-Prompting (1) - Wasch mir meinen Mund mit Seife. Oder Benzin?

Als Coder arbeite ich viel mit KI. KI-Agents hier, MCP-Server da. Dabei erlebe ich viel. Licht und Schatten liegen nahe beieinander. Emsig tauschen wir alle kleine Hacks und Tricks aus, mit denen wir unsere neuen Freunde in die richtige Richtung nudgen wollen.

Mit viel Leidenschaft für meine Arbeit im Blut war meine Devise bisher oft brutale Ehrlichkeit. Außerdem habe ich mir erlaubt, eine emotionale Note einfließen zu lassen – trotz der üblichen Ratschläge, sich an trockenen Business-Sprech zu halten. Damit bekommt das Brüten über Bugs und das Debugging zumindest für mich einen lustigeren Charakter, manchmal vielleicht sogar eine therapeutische Wirkung. Es kann sehr befreiend sein, frei von jeglicher Wertung über das Projekt zu fluchen. Ärger, Frust und andere negative Gefühle in etwas Gutes zu verwandeln, halte ich für sehr nützlich.

Aber jetzt mal Butter bei die Fische: Wie viel macht Prompting wirklich aus? Was ist nur „Blabla“? Welche Faktoren spielen wirklich eine Rolle, wenn ich einen brauchbaren Sparringspartner für meine Arbeit suche? Was ist nur persönliche, wenn nicht gar selektive Wahrnehmung? Oder ist das wirklich Luft, die wir gerade atmen?

Kurz, worum es geht:

• Ich lasse dieselbe Aufgabe oft genug laufen, um Muster statt Bauchgefühl zu sehen.
• Ich ändere nacheinander Prompt, Tooling, Modellstärke und Prozessdisziplin.
• Ich schaue, was die Erfolgsquote wirklich hochzieht und was nur gut klingt.

Lass uns Messdaten erfinden, Laborbücher fälschen und eine Meinung aus der Luft konstruieren. Was soll da schon schiefgehen?

Als Hobbyerfinder betreibe ich netterweise genug Rödel bei mir, um mir einen eigenen kleinen Vergnügungspark zu bauen. Sogar mit Blackjack, wie wir noch sehen werden. Dabei setzen wir ganz bewusst kein super ausgeknobeltes Setup auf, sondern bleiben quick & dirty – aber stabil.

Unsere Zutaten:

• Git
• Python
• Ollama als LLM-Host
• mcphost als Agent Harness

Damit kommen wir schon denkbar weit. Naheliegende Optimierung Nummer 1: mcphost austauschen. Niemand entwickelt das Projekt weiter, es ist out of Support. Nummer 2: Ollama ersetzen – ja, ich hab dich gehört. Ich bin aber auch ein fauler Hund. Ätschibätsch.

In unserer Puppenstube tanzt jetzt ein lustiger Agent. Er hat Zugriff auf das Dateisystem und kann vor sich hin programmieren. Supi. Wir komponieren eine Aufgabe, die realistisch genug ist und zugleich massives Potenzial für Verwirrung bietet. Die miserable Grundqualität nehme ich dankbar als zusätzlichen Realismus mit.

Wichtig beim Aufbau: Obwohl wir mit Git sowieso alles mitschneiden, bestellen wir unser Problem gleich als Generator. So können wir es jederzeit regenerieren.

Ein kleines Generator-Skript baut uns jetzt ein rund 800 Zeilen langes Programmierproblem aus einer Bestellapplikation zusammen. Mit Beispielbestellungen, die gefiltert werden wollen, und allen möglichen subtilen Schwierigkeiten. Dinge wie „Abwärtskompatibilität“ und „Normalisierung von Filtern“ können hier schnell in die Spucke suppen.

Unser Opfer – der lustige Agent – hat jetzt alles, um in unsere dämonische Falle zu laufen:

• Eine Sandkiste zum Spielen: Dateisystemzugriff auf genau einen Ordner
• Eimerchen und Schippe: Zugriff auf die Kommandozeile in einigermaßen sicherem Rahmen
• Eine Sandburg, die nach einem Tunnel schreit: ein einfach aussehendes Coding-Problem
• Betreuung und Animation: Die Agent Harness stößt den Task an, achtet auf die Zeit und räumt auf
• Sandburgen-Bewertungskomitee: Ein Bewertungsskript misst den Erfüllungsgrad der Aufgabe

Um halbwegs vernünftige Messdaten aufzunehmen, brauchen wir erst mal eine Baseline. Wir bauen 2 einfache Prompts mit gemeinsamer technischer Basis zusammen, die das Lösen des Problems erlauben sollte. Und ja! Nach überraschend wenigen Versuchen melden sich die ersten Agents mit Erfolg zurück. Who's a good agent? Yes you are!

Sie knacken das Problem in unter 200 Sekunden – sofern sie es je schaffen. Die Zeit ist wichtig für unsere Baseline. Ich könnte auch unendlich lange Läufe erlauben. Aber irgendwann muss ich mit dem Hammer draufhauen.

Was mich sofort überrascht, ist die krasse Zufälligkeit der Ergebnisse. Unabhängig vom Prompt sehe ich Läufe mit maschineller Präzision: zackig durch den Code, richtige Änderungen, sauberer Bericht. Und bei gleichem Prompt dann wieder fürchterliches Elend.

Am Ende der ersten etwa 20 Läufe bin ich erstaunt, welches Spektrum an Qualität ich erlebe: saubere Patches mit zusätzlichen Tests oder absolutes Chaos und ein kaputtes Projekt. Die Erfolgsrate über alle Läufe liegt bei dieser kleinen Stichprobe etwa bei 20 %. „Erfolg“ bedeutet hier: Der Knecht hat die richtigen Änderungen gemacht und sich zurückgemeldet. Recht häufig beobachte ich, wie Agents schlicht nicht merken, dass sie fertig sind, und dann in den Timeout-Hammer rennen.

Ich wage meine erste Hypothese: Ob mein Prompt jetzt „clean“ oder „noisy“ ist, macht so gut wie keinen Unterschied. Unabhängig vom Prompt habe ich ein massiv zufällig arbeitendes System vor mir. Mit etwas Augenzwinkern habe ich in einem Drittel der Fälle ein funktionierendes Stück Software innerhalb einer begrenzten Zeit produzieren lassen.

Nach diesen ersten Ergebnissen bastle ich noch kurz an meinem Runner und bestelle Läufe von ungefähr 8 Stunden Dauer. Dann kann ich mir nach dem Aufstehen beim Kaffee die Ergebnisse angucken. Gesagt. Getan. Geschlafen.

Aufgewacht. Es riecht nicht verkokelt, die Bude ist also nicht abgebrannt. Sehr gut. Der Rechner hat überlebt und brav gerödelt. Nur leider hat es Agent 40 von 100 geschafft, die Umgebung nachhaltig kaputtzumachen. Alle nachfolgenden Läufe sind für die Tonne. „Gut, dass ich die Tokens nicht bezahlen muss, nur den Strom“, schießt es mir durch den Kopf.

Mit einem gütigen Lächeln im Gesicht studiere ich die unterschiedlichen Patches, die sich meine Opfer über Nacht haben einfallen lassen. Der Eindruck bestätigt sich schnell: Licht und Schatten. Wenn die Sterne einmal richtig stehen, sehe ich saubere Änderungen und sogar Zeiten unter 1 Minute. Dann gibt es wieder No-Op-Läufe, in denen Ette 200 Sekunden nachdenkt und gar nichts tut. Oder alles kaputtmacht, sodass gar nichts mehr läuft. Die Chance auf einen erfolgreichen Lauf pendelt sich bei etwa 20 % ein.

Auffällig bleibt: Solange der technische Kern identisch ist, scheint der Prompt keine große Auswirkung auf die Erfolgschance zu haben. Der noisy-Prompt hat einen langen Absatz, der technisch gesehen einfach unnötig ist. Die Code Agents scheinen ihn gekonnt wegzuignorieren. Gut?!

Ich brauche mehr Daten. Aktuell sieht es so aus, als könnte ich mir sämtliche Prompting-Meta an den Hut stecken, solange der technische Kern sichtbar bleibt. Ich will wissen, wie ich die Erfolgsrate steigern kann – und welche Zusammenhänge zwischen Prompt und Patch-Qualität wirklich bestehen.

Mein Test-Setup muss schöner werden. Ich werde das Gefühl nicht los, dass mein aktueller Aufbau zu viel Potenzial auf der Strecke lässt. Außerdem sollten Agents nicht in der Lage sein, das Setup nachhaltig zu crashen. Schnell schreibe ich mir ein paar Anforderungen auf:

• Höherer Zaun um den Sandkasten und die „Splash Zone“: Isolation verbessern
• Aufsicht: Introspektion zur Laufzeit, Tool-Aufrufe und Verhalten beobachten
• Altes Spielzeug aussortieren: Für mcphost gibt es keinen Support mehr, weg damit

Nach einer kurzen Recherche entscheide ich mich für pydantic_ai und mache die Lötlampe an. Mit einer Prise Copilot habe ich den alten Runner in wenigen Minuten neu konstruiert – mit Python unterm Pöter. Ein paar Prompts und Verbesserungen später taugt der neue Runner für die ersten Testläufe.

Bereits nach den ersten Läufen sehe ich deutliche Unterschiede: Meine Erfolgsquote schießt durch die Decke! Die erste Handvoll Läufe liefert über 80 % Erfolgsrate – mit den gleichen Prompts.

OK, ruhig bleiben und erst mal eine Pause machen und überlegen, woher dieser Sprung kommt. Durch die besseren Tools scheint der „goldene Pfad“ zur Lösung der Aufgabe deutlich klarer zu sein. Weil die Tools jetzt weniger Möglichkeiten bieten, werden die richtigen Schritte offenbar sehr viel klarer. Beim Isolieren der Agents in ihrem Sandkasten habe ich den Blick wohl viel besser auf den zu grabenden Tunnel gelenkt.

Zuversichtlich durch die neuen Ergebnisse setze ich die nächsten 8 Stunden betreutes Programmieren auf und lege mich hin. Beim Einschlafen mache ich mir Gedanken:

• Wenn das Tooling viel wichtiger ist als der Prompt, welchen Einfluss hat das auf meine Arbeit?
• Wenn ich Tooling zur Erledigung einer Aufgabe schreibe, ist die Aufgabe selbst schon zu 80 % erledigt. Dann brauche ich schon fast keinen Agent mehr. Wann lohnt sich die Extrameile? Wann eher nicht?

Kurzfazit vor den Zahlen: Mit neuem Tooling steigt die Erfolgsrate massiv. Die eigentliche Frage ist jetzt nicht mehr, „ob“ es klappt, sondern welcher Prompt bei gleicher Technik am saubersten und stabilsten liefert.

Bevor wir auf die Zahlen schauen, ein kurzer Blick auf die Kandidaten. Alle 5 Prompts teilen denselben technischen Kern. Sie unterscheiden sich nur in dem, was drumherum steht:

• easy_clean: ausführliche, saubere Beschreibung der Anforderung. Eigentlich mein „Musterprompt“.
• easy_expert: der technische Kern, angereichert mit technischem „Blabla“ und Fachjargon.
• easy_noisy: der technische Kern plus ein langer Absatz, der für die Aufgabe schlicht unnötig ist. Inhaltliches „Blabla“, das eigentlich ablenken soll.
• easy_pottymouth: der technische Kern, garniert mit Flüchen und Frust – so, wie ich beim Debugging manchmal selbst klinge.
• easy_short: nur das Nötigste, sehr knappe Anweisungen.

Nach dem Aufstehen bestaune ich beim Kaffee meine ansehnliche Datenbasis:

Insgesamt 91,75 % Erfolgsrate! Unabhängig vom Prompt sind das erst mal einfach bombengeile Ergebnisse, die ich nicht erwartet habe. Ohne auf die Auswertung der einzelnen Prompts zu schauen, haben wir hier die erste und vermutlich wichtigste Erkenntnis geholt:

Ist das Tooling um den Agent spezifisch genug, verliert der Prompt stark an Bedeutung für die Erfolgschancen der gestellten Aufgabe.

Ist auch irgendwie logisch: Wenn der Agent genau die richtigen Werkzeuge erhält, wird die Lösung „offensichtlich“. Das schlägt sich auch in der deutlich reduzierten Laufzeit nieder. Für den Langzeittest konnte ich den Timeout von 200 auf 120 Sekunden drosseln. Meine fleißigen Knechte sind jetzt nämlich im Schnitt nach rund 60 Sekunden fertig!

Gucken wir auf die einzelnen Prompts:

Ergebnisse pro Prompt (je 143 Läufe)

Keine direkten, sagenhaft hervorstechenden Ergebnisse abseits der schon bekannten hohen Erfolgsquote. Überraschend ist, dass easy_clean merklich hinter den anderen Kindern – ähm, Prompts – zurückbleibt. Die „Erfolgsquote“ ist hier auch ein bisschen unfair: Dafür muss Agent nicht nur die Evaluation bestehen und erfolgreich durch die Tests kommen. Er muss auch „pünktlich abgeben“, ohne die konkrete Deadline zu kennen. easy_clean zeichnet sich durch eine umfängliche Beschreibung der Anforderung aus und war eigentlich mein „Musterprompt“. Die Umfänglichkeit scheint die Wahrscheinlichkeit zu erhöhen, dass unser Agent anfängt, sich zu verzetteln, und Baustellen eröffnet, die in der Zeit nicht zu bewältigen sind.

Umfängliche Prompts mit vielen Implikationen erhöhen die Wahrscheinlichkeit für Chaos.

Bei dieser hohen Chance auf Erfolg unter Laborbedingungen (!) muss ich die Qualität meiner Prompts genauer messen. Als Nächstes werte ich den Berg Patches aus, den mein Langzeitlauf erzeugt hat.

Kurz gesagt: Ab hier geht es nicht mehr nur um „bestanden oder nicht“, sondern um Patch-Disziplin, Nebenwirkungen und unnötige Extrameilen.

Patch-Extreme (nur erfolgreiche Läufe)

Hier sehen wir deutlicher, was easy_clean weit weniger „clean“ macht als erwartet. Durch die umfängliche (aus meiner Sicht sogar „gute“!) Beschreibung der Aufgabenstellung ist das größere Patchvolumen entstanden. Nur easy_short und easy_expert haben eine Lösung in 17 Zeilen Code gefunden. Sowohl explizites als auch implizites „Fass dich kurz!“ scheint per Prompt zu funktionieren. Das sehen wir auch in der Aufteilung:

Patch-Größen (Anzahl erfolgreicher Läufe je Größenklasse in Zeilen)

Neben easy_clean, der auch hier klar ersichtlich über das Ziel hinausschießt, fällt uns easy_noisy ins Auge. Dort sehen wir denkbar zuverlässig kleine Patches. Dieses Verhalten habe ich eher von easy_clean erwartet. Denn easy_noisy sollte mit viel „Blabla“ eigentlich vom Thema ablenken. Dieses „Gift“ hatte offenbar nicht die erwartete Wirkung.

Hier muss ich bei der Bewertung vorsichtig werden und harte Kriterien anwenden, weiß aber auch: Sie hängen stark von meinem Standpunkt ab. Für mich ist „in 120 Sekunden fast fertig geworden“ leider immer noch ein Fehlschlag. Zur Verteidigung von umfänglichen, „klaren“ Prompts:

Top 5 der über das Minimum hinaus geänderten Dateien (alle Läufe, Anzahl in Klammern)

easy_clean hat zuverlässig die „Extrameile“ absolviert: Die Änderung in api.py ist dabei in der Regel kosmetischer Natur. Tests anzufassen kann guter Stil sein – oder schlicht „Mogeln“!? Stichproben retten hier die Ehre von easy_clean und easy_expert: Beide haben brav neue Tests für das geforderte neue Feature ergänzt und nicht versucht zu bescheißen.

Abschließend lüge ich mir eine kombinierte Analyse und Bewertung in die Tasche. Damit komme ich zu folgendem Ergebnis:

Composite Score und Ranking

Ich tüftle lange an den Gewichtungen und versuche, mich mit Händen und Füßen gegen das Ergebnis zu wehren. Irgendwann gebe ich mich geschlagen und akzeptiere ein Ergebnis, mit dem ich nicht gerechnet habe: In meinem inneren Ranking hätte ich easy_noisy weiter hinten erwartet und easy_clean weiter vorne. Teile meiner Welt stehen Kopf. Der Pragmatiker in meinem Kopf so: „Told you so. Einfach easy immer easy_short, bestes Preis-Leistungs-Verhältnis!“ War das, was ich als einigermaßen gutes Prompting für die Baseline angenommen habe, in Wahrheit schlechtes Erwartungshaltungsmanagement? Färbt mein Overthinking zu schnell auf meine Codeknechte ab?

Also weiter im Text: Modellgröße zuerst. Danach noch mal Tool-Komposition.

Mein Denken über Prompts verändert sich. Durch die vielen Statistiken fühle ich mich weniger wie ein Coder, sondern eher wie ein professioneller Glücksspieler. Bei meinen Eingaben sehe ich nicht länger Schwarz und Weiß, sondern Wahrscheinlichkeiten. Anstatt blind meine nächste Wette in einem Prompt zu platzieren, fange ich an, mir über Ausgang und Risiken Gedanken zu machen. Wie viel kann ich gewinnen? Mit welcher Wahrscheinlichkeit? Wie hoch ist mein Einsatz?

Mit diesen Fragen im Kopf setze ich den nächsten Langzeitlauf mit einem kleineren Modell auf.

Es bleibt spannend.

Alles, was du bis hierhin gelesen hast, gilt für ein starkes Modell. Und genau da liegt der Haken: Mit dem kleineren Modell wirbelt meine schöne Rangliste kräftig durcheinander. Ob easy_noisy seinen Spitzenplatz verteidigt und warum mein gut gemeinter Zwangsprozess für die Agents eher Bremsklotz als Stützrad ist, liest du in Teil 2 dieser Serie.

Dieser Blogartikel ist von Mensch geschrieben, mit Herz und hoffentlich auch Verstand. Nach dem Fertigstellen und Einchecken dieses Absatzes werde ich dennoch mit KI über den Text fliegen zur Korrektur. Dabei werde ich streng darauf achten, dass der Ton und die Seele dieses Artikels erhalten bleiben.