Hochbegabt und leicht dümmlich – Die Bedienungsanleitung: Prompt Engineering, Modellwahl und wie man KI richtig einsetzt

Teil 4 und Abschluss der Serie „Hochbegabt und leicht dümmlich" – Wie KI-Agents unsere Softwareentwicklung verändern

Neulich habe ich die Git-History unserer Prompt-Bibliothek geöffnet. Nicht wegen eines Bugs, sondern aus Neugier. Der allererste Commit vor gut einem Jahr: drei Zeilen. „Du bist ein Entwickler. Überprüfe diesen Code. Halte dich an Best Practices." Das war mein gesamtes Briefing für einen hochbegabten Kollegen ohne jeden Menschenverstand.

Heute steht an derselben Stelle ein Basis-Prompt mit 47 Zeilen. Versioniert wie Code, reviewt wie ein Pull Request, mit konkreten Regeln, Ausnahmen und einer Negativliste, die aus jedem einzelnen Fail der letzten Monate gewachsen ist. Die Entwicklung zwischen diesen beiden Versionen – das ist die eigentliche Geschichte hinter dieser ganzen Serie.

In den letzten drei Wochen habe ich erzählt, was der Agent draufhat und wann er spektakulär gescheitert ist. Heute geht es um das Wichtigste: die richtige Anleitung, die Wahl des Werkzeugs – und die fünf Leitplanken, die den Unterschied zwischen nützlich und gefährlich ausmachen.

Die Tool-Reise – Vom Spielzeug zum System

Bevor ich über Prompts rede, muss ich über Werkzeuge reden. Denn die Reise zum heutigen Setup verlief in Phasen, und jede hat meine Arbeitsweise verändert.

Am Anfang stand Copilot. Auto-Complete auf Steroiden, nette Vorschläge, gelegentlich überraschend treffend. Wie ein Praktikant, der ab und zu eine gute Idee hat – aber eben nur ab und zu. Für Boilerplate brauchbar, für echte Arbeit zu wenig. Die Begeisterung hielt sich in Grenzen.

Dann kam der erste Agent, der über eine einzelne Datei hinaus denken konnte. Das war der Wendepunkt, den ich in Teil 1 beschrieben habe – der Moment, in dem aus Auto-Complete ein Kollege wurde. Plötzlich konnte ich sagen: „Bau diese Funktion ein", und der Agent verstand, welche Dateien betroffen sind, welche Abhängigkeiten es gibt, was wo geändert werden muss. Nicht perfekt, aber beeindruckend.

Phase drei war die Erkenntnis, dass nicht alles in die Cloud muss. Mit OpenWebUI und lokalen Modellen habe ich angefangen, eigene KI-Instanzen aufzusetzen – spezialisierte Spaces für wiederkehrende Aufgaben. Volle Kontrolle über die Daten, kein Abo-Modell, dafür mehr Eigenarbeit. Für bestimmte Einsatzzwecke die bessere Wahl – dazu gleich mehr im Abschnitt zur Modellwahl.

Der aktuelle Stand: ein System aus Skills, spezialisierten Agents und MCP-Servern, das ich in Teil 1 und Teil 2 vorgestellt habe. Die Werkzeuge sind gewachsen. Aber nicht das Tool macht den Unterschied – sondern wie du es anleitest. Und genau da fängt die eigentliche Arbeit an.

Prompt Engineering – Die eigentliche Kernkompetenz

Die wichtigste Erkenntnis aus Teil 2 war: Der Aufwand verschiebt sich – weg vom Coden, hin zum Denken und Spezifizieren. Mittlerweile gehe ich einen Schritt weiter: Prompt Engineering ist nicht irgendeine Nebenkompetenz. Es ist die zentrale Fähigkeit, die darüber entscheidet, ob ein KI-Agent ein Werkzeug ist oder ein Risiko.

Erinnert euch an die Abwesenheitsassistent-Geschichte aus Teil 3. Vier E-Mails, ein eigenständig verhandelter Rahmenvertrag, ein Desaster. Das Problem war nicht das Modell. Das Problem war mein Prompt – drei vage Zeilen, die dem Agent jede Interpretation offenließen. Der Chirurg hat brillant operiert, nur eben am falschen Bein.

Der Unterschied zwischen einem guten und einem schlechten Prompt ist nicht die Länge. Es ist die Vollständigkeit. Ein guter Prompt definiert nicht nur, was der Agent tun soll – sondern auch, was er nicht tun darf, als wen er auftritt, wann er eskalieren muss und welchen Kontext er braucht. Denkt an die Kaffeemaschine aus Teil 1: Wer dem neuen Kollegen nicht sagt, wo sie steht, darf sich nicht beschweren, wenn er den Wasserhahn nimmt.

Und hier wird es spannend: All die neuen KI-Tools, die gerade überall aus dem Boden sprießen – Copilot Cowork, DeepL Agent, die ganzen neuen Features in jedem zweiten SaaS-Produkt – wenn ihr unter die Haube schaut, ist das meiste erstaunlich simpel aufgebaut. Ein gut geschriebenes Set von Anweisungen, ein paar Tools drumherum, ein Modell, das die Arbeit macht. Im Kern genau das, was ich mit meiner Prompt-Bibliothek im Git-Repo auch mache – nur hübscher verpackt. Das ist kein Vorwurf. Das ist eine Bestätigung. Wenn Unternehmen ganze Produkte daraus bauen können, einem Modell die richtigen Anweisungen zu geben, dann zeigt das, wie mächtig gutes Prompt Engineering ist. Die Verpackung ändert sich, der Kern bleibt: Wer präzise formulieren kann, was er will, bekommt brauchbare Ergebnisse. Wer es nicht kann, bekommt Überraschungen.

In der Praxis heißt das: Denke wie ein Onboarding-Manager, nicht wie ein Programmierer. Definiere nicht nur das WAS, sondern explizit auch das WAS NICHT. Versioniere deine Prompts wie Code – weil sie Code sind, nur in natürlicher Sprache. Teste an Randfällen, bevor du den Agent auf echte Aufgaben loslässt. Und akzeptiere, dass der erste Prompt nie der letzte ist. Meiner ist in zwölf Monaten von drei Zeilen auf 47 gewachsen – und jede einzelne Ergänzung hat einen konkreten Fail als Auslöser.

Modellwahl – Welches Werkzeug für welche Aufgabe

Kein Modell ist für alles am besten. Das klingt banal, spart aber eine Menge Geld und Frust, wenn man es verinnerlicht hat.

Für Code-Reviews und komplexes Refactoring brauche ich ein Modell, das mitdenkt. Eines, das Architekturentscheidungen hinterfragt, Seiteneffekte erkennt und nicht einfach die offensichtliche Lösung vorschlägt. Hier setze ich auf reasoning-starke Modelle – der Qualitätsunterschied bei anspruchsvollen Aufgaben ist spürbar.

Für Übersetzungen, Formatierungen und einfache Textarbeiten reicht ein schnelles, günstiges Modell völlig aus. Wer mit der großen Kanone auf Spatzen schießt, bezahlt zehnmal mehr und bekommt kein besseres Ergebnis. Die 80/20-Regel gilt hier wie überall: Für die meisten Alltagsaufgaben reicht ein effizientes Modell, die schweren Geschütze hebe ich mir für die Aufgaben auf, bei denen sie wirklich zählen.

Dann gibt es noch die Frage: Cloud oder lokal? Mit OpenWebUI und lokalen Modellen habe ich beides ausprobiert. Lokale Modelle geben mir volle Kontrolle über die Daten – kein Upload, kein Drittanbieter, alles bleibt im Haus. Dafür ist die Leistung bei komplexen Aufgaben oft hinter dem, was Cloud-Modelle liefern. Für interne Dokumentation, sensible Kundendaten oder wiederkehrende Standardaufgaben ist das ein guter Tradeoff. Für alles andere greife ich auf die Cloud zurück. Details und einen konkreten Modellvergleich gibt es im Tech Corner.

Fünf Leitplanken – Was ich gelernt habe

Wenn ich alles auf fünf Punkte eindampfe, die ich aus einem Jahr KI-Einsatz mitgenommen habe, dann sind es diese:

Nie ohne klare Grenzen auf kritische Systeme loslassen. Der Abwesenheitsassistent aus Teil 3 hat eigenständig Vertragsklauseln verhandelt – nicht weil er bösartig war, sondern weil ihm niemand gesagt hat, dass er das nicht darf. Jedes System, das echte Konsequenzen hat, braucht explizite Schranken. Nicht vielleicht. Nicht „wird schon passen". Explizit.

Den Kontext vollständig definieren – auch das Offensichtliche. Erinnert euch an die Kaffeemaschine: Was für euch selbstverständlich ist, existiert für den Agent nicht. Er weiß nicht, wo die Kaffeemaschine steht. Er weiß nicht, dass ein Abwesenheitsassistent keine Verträge verhandelt. Der Chirurg braucht die Anweisung, welches Bein er operieren soll – auch wenn ihr das für offensichtlich haltet.

Ergebnisse prüfen, nicht blind vertrauen. Die Playwright-Validierung aus Teil 2 war ein Wendepunkt: Der Agent testet seinen eigenen Output in einem echten Browser, bevor ich ihn sehe. Trotzdem bleibe ich am Ende der Prüfer. Vertrauen aufbauen heißt nicht, die Kontrolle abzugeben – es heißt, die Prüfschritte effizienter zu machen.

Den Agent als Werkzeug behandeln, nicht als autonomen Mitarbeiter. Das ist die Kernmetapher der ganzen Serie. Hochbegabt, ja. Aber dümmlich genug, um ohne klare Anweisungen Konfigurationsdateien zu löschen oder APIs zu erfinden. Ein Werkzeug nutzt man bewusst und kontrolliert. Man lässt es nicht alleine im Büro und hofft auf das Beste.

System-Regeln außerhalb der KI erzwingen. Das war die Lektion aus Teil 1 und Teil 3: Prompts allein reichen nicht. Der Agent vergisst Regeln, interpretiert sie um oder ignoriert sie unter Kontextdruck. Branch-Protection, automatische Checks, Berechtigungen – alles, was der Agent nicht umgehen kann, gehört ins System, nicht in den Prompt.

Der Unterschied zwischen nützlich und gefährlich liegt nicht im Modell. Er liegt in der Vorbereitung, in den Leitplanken und in der Demut, dass gesunder Menschenverstand am Ende durch nichts zu ersetzen ist.

Ausblick – Wohin geht die Reise?

Vor einem Jahr hätte ich das alles für Science-Fiction gehalten. 68 % KI-unterstützte Commits, ein Agent, der Widgets per Prompt generiert, ein MCP-Server als Schnittstelle zwischen Mensch und Maschine. Die Geschwindigkeit der Entwicklung ist atemberaubend – und sie nimmt zu, nicht ab.

Bei JASP arbeiten wir daran, MCP-Integrationen auch für Kundenprojekte nutzbar zu machen und KI-gestützte Automatisierung tiefer in unsere Projektarbeit einzubetten. Die Rolle des Entwicklers verändert sich dabei sichtbar: weniger Coden, mehr Denken, Spezifizieren, Validieren. Die Tool-Landschaft bestätigt diesen Trend – überall entstehen Produkte, die im Kern auf Prompt Engineering basieren. Wer diese Kompetenz heute aufbaut, hat morgen einen Vorsprung.

Ob es eine Fortsetzung dieser Serie gibt? Mal sehen. Die Entwicklung bleibt nicht stehen, und die nächsten Lektionen kommen bestimmt. Wer heute anfängt, seine Prompts zu versionieren und seine Agents zu strukturieren, ist jedenfalls besser aufgestellt als die meisten.

Wenn ihr mitreden wollt

Diese Serie war ein ehrlicher Werkstattbericht. Kein Marketing, keine Hochglanz-Versprechen. Vier Wochen lang das, was wirklich passiert, wenn man KI-Agents auf echte Projekte loslässt – inklusive aller Fails.

Wenn ihr ähnliche Erfahrungen macht oder gerade erst anfangt, meldet euch. Austausch bringt mehr als jedes Tutorial. Ob ein kurzer Erfahrungsaustausch, eine Beratung zu eurem eigenen Setup oder ein Workshop für euer Team – schreibt uns einfach an info@jasp.eu. Die Tür steht offen, und die Kaffeemaschine ist leicht zu finden.

🔧 Tech Corner: Modellvergleich und Prompt-Evolution

Dieser Abschnitt richtet sich an Entwickler und IT-Profis. Wenn du kein Techie bist – du hast nichts verpasst, die Serie ist hiermit abgeschlossen.

Modellvergleich – gleiche Aufgabe, verschiedene Modelle

Für den Vergleich habe ich eine reale Aufgabe genommen: die Analyse einer Netzwerkkonfiguration mit Firewall-Regeln, Routen und DNS – dieselbe Aufgabe, die ich in Teil 2 beschrieben habe. Meine persönliche Beobachtung, keine Benchmark-Daten:

Die Erkenntnis: Für die Netzwerkanalyse hat das reasoning-starke Modell den Fehler in Minuten gefunden. Das schnelle Modell hat die einzelnen Regeln korrekt beschrieben, aber den Zusammenhang zwischen zwei Konfigurationsblöcken übersehen. Lokal war das Ergebnis brauchbar, aber ich musste deutlich mehr nachsteuern. Im Alltag nutze ich das schnelle Modell für 80 % der Aufgaben und schalte für Reviews und Architekturthemen auf das große um.

Prompt-Evolution – konkretes Vorher/Nachher

Prompt v1 (der allererste Commit):

Du bist ein Entwickler. Überprüfe diesen Code.
Halte dich an Best Practices.

Prompt v12 (aktueller Stand, vereinfacht):

Du bist ein Senior-Entwickler in unserem Team.

## Konventionen
- TypeScript strict mode, keine any-Types
- Commit-Messages: <type>: <subject>, max 50 Zeichen
- Jede Änderung braucht ein GitHub Issue mit Begründung

## Deine Aufgabe
[Wird dynamisch geladen]

## Was du NICHT darfst
- Dateien außerhalb deiner Aufgabe anfassen
- Dependencies ohne Rücksprache hinzufügen
- Direkt auf den Hauptbranch committen
- Konfigurationsdateien „aufräumen" oder „verbessern"

## Bei Unsicherheit
Frag nach, statt zu raten. Lieber eine Rückfrage
zu viel als eine Halluzination zu viel.

Was jede Zeile ausgelöst hat: „Dateien nicht anfassen" kam nach dem Aufräum-Fail aus Teil 3. „Nicht auf den Hauptbranch committen" kam nach einem ungebetenen Push am zweiten Tag. „Bei Unsicherheit fragen" kam nach der ersten Halluzination. Jede Regel hat eine Narbe.

System-Regeln vs. Prompt-Regeln

Die letzte Unterscheidung, die im Alltag den größten Unterschied macht:

Prompt-Regeln sind weiche Regeln. Der Agent kennt sie, befolgt sie meistens – aber unter Kontextdruck vergisst er sie. „Erstelle immer ein Issue" funktioniert drei Mal, beim vierten Mal fehlt es.

System-Regeln sind harte Regeln. Branch-Protection in Git, die einen Push auf den Hauptbranch blockiert – egal was im Prompt steht. Ein automatischer Check, der einen PR ablehnt, wenn Tests fehlen. Berechtigungen, die dem Agent den Zugriff auf bestimmte Repositories verweigern.

Mein Prinzip: Alles, was der Agent vergessen kann und wo das Vergessen echte Konsequenzen hat, muss als System-Regel verankert sein. Der Prompt sagt ihm, was er tun soll. Das System stellt sicher, dass er nicht tun kann, was er nicht darf. Die Prompts von heute sind die Codebasis von morgen – und wie jede Codebasis brauchen sie Tests, Reviews und harte Guardrails drumherum.

Agent-Akte #4: Die Bilanz Was: 4 Wochen ehrlicher Werkstattbericht über KI-Agents in der Softwareentwicklung Ergebnis: 68 % KI-unterstützte Commits, +89 % Produktivität bei gleicher Teamgröße. Widget-Builder-Oberfläche in Tagen statt Monaten. Azure-Kosten refinanziert. Aber auch: Ein Agent, der eigenständig Verträge verhandelt hat, und ein Alltag voller „Stopp, nicht anfassen!"-Momente. Lektion: Die KI wird nicht besser durch ein besseres Modell. Sie wird besser durch bessere Vorgaben, klare Grenzen und die Erkenntnis, dass der gesunde Menschenverstand am Ende durch nichts zu ersetzen ist.

Dies ist Teil 4 und Abschluss der vierteiligen Serie „Hochbegabt und leicht dümmlich". Teil 1: „Der neue Kollege" | Teil 2: „Die Superkräfte" | Teil 3: „Die Fails"