Dieses Kapitel zeigt, warum alte Prompting-Rituale nicht mehr mit Reasoning-Modellen funktionieren und welches „neue Kommunikationsprotokoll” wirklich Ergebnisse liefert, die sich sofort kompilieren, testen und implementieren lassen. Hier werden Sie entdecken, wie man „Rollentheater” durch präzise Spezifikationen ersetzt – und die Anzahl der Iterationen um ein Vielfaches reduziert.
4 Säulen des modernen Prompts (Kontext, Ziel, Anforderungen, Einschränkungen), 3 Anfragetypen (A/B/C) und Profi-Level-Techniken: Dekompositon 1 Prompt = 50–200 Zeilen, „Zeige–Wiederhole–Erweitere”, explizites Verbot deprecated APIs.
Nicht verpassen: Nach diesem Kapitel wird offensichtlich, warum „einfach Code anfordern” ein Weg zu Technical Debt ist.
Das Kapitel enthält Prompt-Beispiele, die sofort einsatzbereit sind.
Selbsttest zum Kapitel
Warum benötigen Reasoning-Modelle keine Hinweise mehr wie „denke Schritt für Schritt” oder Rollen-Prompting?Antwort
Richtige Antwort: Reasoning-Modelle bauen automatisch interne Überlegungen auf und besitzen eingebaute Expertise, daher fügen solche Hinweise kein Wissen hinzu, sondern verschwenden nur Token und können sogar die Modellarbeit behindern.
Welche vier Säulen bilden die Anatomie eines modernen Prompts für Reasoning-Modelle?Antwort
Richtige Antwort: Technologischer Kontext (Tech-Stack), klares und eindeutiges Ziel, technische Anforderungen (Thread-Sicherheit, Performance) und Einschränkungen (Qualitätsrahmen für das Ergebnis).
Warum erfordert ein Spezifikations-Prompt vom Typ A mehr Zeit bei der Formulierung, gilt aber als effektiver?Antwort
Richtige Antwort: Eine detaillierte Spezifikation mit Kontext, Ziel, Anforderungen und API-Beispielen liefert vorhersehbare Ergebnisse, die sich beim ersten Versuch fast ohne Nachbesserungen ins Projekt integrieren lassen.
In welchen Situationen sollte ein Prompt vom Typ B (kontextual-dialogorientiert) statt Typ A verwendet werden?Antwort
Richtige Antwort: Wenn ein bestehendes Projekt weiterentwickelt werden muss: Refactoring, Verbesserung der Architektur gewachsener Klassen, punktuelle Erweiterungen und iterative Entwicklung.
Was passiert, wenn beim Debugging von Multithread-Code dem Modell nicht der vollständige Fehlerkontext bereitgestellt wird (Valgrind-Ausgabe, Call-Stacks, Qt-Logs)?Antwort
Richtige Antwort: Die Analyse wird weniger präzise, das Modell kann spezifische Ursachen von Memory-Leaks oder Race-Conditions nicht identifizieren, und die Problemlösung wird mehr Zeit in Anspruch nehmen.
Warum sieht die Dekompositions-Technik die Aufteilung der Aufgabe in Prompts von je 50-200 Code-Zeilen vor?Antwort
Richtige Antwort: Ein Prompt = ein klares Ziel gewährleistet hohe Qualität jeder Komponente, bewahrt die Kontrolle über die Architektur und vereinfacht das Testen, wobei Fokusverlust bei zu umfangreichen Aufgaben vermieden wird.
Wie hilft die Technik „Zeige – Wiederhole – Erweitere”, das Wiederholen von Anweisungen beim Erstellen einer Serie ähnlicher Komponenten zu vermeiden?Antwort
Richtige Antwort: Zuerst zeigen Sie eine Referenz-Komponente, dann definieren Sie gemeinsame Regeln, wonach das Modell eine Serie von Komponenten nach diesem Template generiert, ohne dass detaillierte Anweisungen für jede wiederholt werden müssen.
Warum sollte im Prompt explizit die Verwendung veralteter APIs wie QDesktopWidget oder QApplication::desktop() verboten werden?Antwort
Richtige Antwort: KI kann veraltete oder entfernte APIs aus älteren Qt-Versionen verwenden, die in Trainingsdaten gefunden wurden; explizites Verbot lenkt das Modell zur Verwendung moderner Äquivalente wie QGuiApplication::screens().
Warum behindert die Einschränkungs-Technik (Limits für Dateigröße, Komplexität, Pointer-Verwendung) die KI nicht, sondern verbessert die Code-Qualität?Antwort
Richtige Antwort: Einschränkungen lenken das Modell zur Erstellung sauberen, effizienten und qualitativen Codes, indem sie klare Rahmen setzen und das Erscheinen aufgeblähter, unsicherer oder suboptimaler Lösungen verhindern.
Was passiert, wenn Aufgaben systematisch an KI delegiert werden ohne Analyse des generierten Codes?Antwort
Richtige Antwort: Es kommt zur Degradierung des Engineering-Denkens: Der Entwickler verliert die Fähigkeit, Architektur zu entwerfen, komplexe Probleme zu debuggen und technische Kompromisse abzuwägen.
Welche rechtlichen Risiken entstehen bei der Verwendung von KI-generiertem Code in kommerziellen Projekten?Antwort
Richtige Antwort: Code kann proprietären Lösungen mit inkompatiblen Lizenzen (z.B. GPL) ähneln, was zu Klagen, Forderungen zur Quellcode-Offenlegung oder Produkt-Blockierung führen kann.
Warum schafft die Nutzung von Cloud-KI-Diensten Risiken für IP-Leaks selbst bei Zusicherungen, dass Daten nicht für Training verwendet werden?Antwort
Richtige Antwort: Die technische Möglichkeit eines Leaks bleibt durch Logs, Caches und temporäre Speicher bestehen; Unternehmensgeheimnisse, Kundeninformationen und einzigartige Lösungen befinden sich außerhalb Ihrer Kontrolle.
Für welche Refactoring-Aufgaben erfordern lokale Modelle (LM Studio, Ollama) zwingend die Verwendung von Reasoning-Modellen statt normalen?Antwort
Richtige Antwort: Für alle Code-Refactoring-Aufgaben, da normale Modelle nicht angemessen damit umgehen können – sie können keine tiefe Analyse des Codes und seiner Struktur durchführen, im Gegensatz zu Reasoning-Modellen wie GPT-OSS, DeepSeek-R1 oder QwQ.
Was bedeutet das Prinzip „KI-Assistenten sind Verstärker der Entwickler-Fähigkeiten, kein Ersatz”?Antwort
Richtige Antwort: KI übernimmt Routine und generiert Templates, aber Architektur-Entscheidungen, kritische Analyse, Verständnis der Konsequenzen und Verantwortung für das Ergebnis bleiben beim menschlichen Ingenieur.
Praktische Aufgaben
Einfaches Level
Prompt-Bibliothek für Refactoring
Erstellen Sie eine persönliche Bibliothek aus 5 Prompts für typische Refactoring-Aufgaben Ihres Qt-Projekts. Wählen Sie reale Problemstellen im Code (gewachsene Klassen, komplexe verschachtelte Logik, veraltete APIs) und adaptieren Sie die Templates aus dem Kapitel für Ihren spezifischen Tech-Stack. Testen Sie jeden Prompt mit einem Reasoning-Modell und dokumentieren Sie die Ergebnisse.
Hinweise: Beginnen Sie mit Typ-B-Prompts aus dem Abschnitt „Prompts für Refactoring”. Geben Sie unbedingt den genauen Stack an (Qt-Versionen, C++, Compiler). Speichern Sie erfolgreiche Prompts in einer separaten Datei mit Notizen zum Nutzungskontext. Zum Testen verwenden Sie Claude Sonnet 4.5 oder ChatGPT (GPT-4). Vergleichen Sie Ergebnisse vor und nach Refactoring: Zeilenzahl, zyklomatische Komplexität, Lesbarkeit.
Mittleres Level
Automatisiertes Review mit Problemerkennung
Entwickeln Sie ein KI-basiertes automatisiertes Code-Review-System für Ihr Qt-Projekt. Erstellen Sie ein Set von 3-4 spezialisierten Typ-C-Prompts (analytisch): einen für Thread-Sicherheitsprüfung, einen zweiten für Memory-Leak-Suche, einen dritten für Edge-Cases und einen vierten für Qt-Best-Practices-Konformität. Integrieren Sie diese Prompts in den Review-Prozess über ein Skript oder CI/CD-Pipeline, das kritische Code-Abschnitte vor dem Commit automatisch prüft.
Hinweise: Verwenden Sie Prompts aus dem Abschnitt „Prompts für Code-Review”. Zur Automatisierung erstellen Sie ein bash/Python-Skript, das Code an Claude- oder ChatGPT-API sendet. Stellen Sie unbedingt den vollständigen Kontext bereit: Valgrind-Ausgabe, Sanitizer, Qt-Logs. Konfigurieren Sie QT_LOGGING_RULES und QT_DEBUG_PLUGINS für detaillierte Diagnostik. Speichern Sie Review-Ergebnisse in strukturiertem Format (JSON/Markdown) zur Fehlerpattern-Analyse.
Komplexes Level
Qt5→Qt6 Migrations-Framework mit KI
Erstellen Sie ein vollwertiges Framework zur automatisierten Migration eines Qt5-Projekts auf Qt6 unter Verwendung von Reasoning-Modellen. Das Framework sollte: (1) die Codebasis analysieren und alle Inkompatibilitäten identifizieren; (2) Typ-A-Prompts zur Modul-Portierung generieren; (3) Änderungen automatisch mit Backup-Speicherung anwenden; (4) .pro in CMakeLists.txt konvertieren; (5) Unit-Tests zur Verhaltensäquivalenz-Prüfung vor und nach Migration generieren; (6) einen Migrationsbericht mit Detaillierung aller Änderungen erstellen. Testen Sie es an einem echten Qt5-Projekt mittlerer Komplexität (5000+ Zeilen).
Hinweise: Beginnen Sie mit Prompts aus dem Abschnitt „Prompts für Portierung”. Verwenden Sie Dekompositions- und „Zeige-Wiederhole-Erweitere”-Techniken für große Projekte. Zur Automatisierung erstellen Sie ein Python-Tool mit Claude/ChatGPT-API. Kritisch wichtig: Erstellen Sie vor Änderungsanwendung einen Git-Branch für Rollback. Generieren Sie Tests mit Typ-A-Prompts aus dem Testing-Abschnitt. Verwenden Sie QTest::qCompare zur Äquivalenzprüfung. Dokumentieren Sie alle Architektur-Entscheidungen und bekannte Einschränkungen. Denken Sie an rechtliche Risiken – prüfen Sie Lizenz-Kompatibilität des generierten Codes.
💬 Nehmen Sie an der Diskussion teil!
Haben Sie bereits Reasoning-Modelle für Refactoring getestet? Sind Ihnen unerwartete Ergebnisse beim Qt5-auf-Qt6-Porting begegnet?
Teilen Sie Ihre Prompts, die herausragende Ergebnisse geliefert haben, berichten Sie über Fallstricke bei der Arbeit mit KI-Assistenten in der Produktion oder stellen Sie Fragen zu Techniken der effektiven Interaktion mit Claude und ChatGPT!
🎯 Lassen Sie uns gemeinsam diskutieren: Wie balancieren Sie zwischen Entwicklungsgeschwindigkeit mit KI und Erhaltung des Engineering-Denkens? Welche Sicherheitsmaßnahmen wenden Sie bei der Arbeit mit Cloud-Modellen an?