02 Vom Copy-Paste zum durchdachten Prompt: Strukturierte KI-gestützte Entwicklung

March 2026 (9619 Words, 54 Minutes)

1. Einführung

Willkommen zu Woche 2. Sie befinden sich in Akt I — Erfahrung, der Phase des Kurses, in der Sie KI-Werkzeuge einsetzen, bevor Sie verstehen, wie diese unter der Haube funktionieren. Letzte Woche haben Sie Ihre Entwicklungsumgebung eingerichtet, einen ersten Überblick über die KI-Landschaft erhalten und die Stack Overflow Challenge erhalten: Erstellen Sie mit Python und einem KI-Coding-Assistenten ein Diagramm der monatlichen Stack-Overflow-Fragenzahlen mit Markierungen für KI-Meilensteine.

Inzwischen haben Sie diese Challenge bearbeitet. Einige von Ihnen haben schnell einen funktionierenden Plot erstellt. Andere haben Stunden damit verbracht, halluzinierte API-Endpunkte zu debuggen. Die meisten von Ihnen lagen irgendwo dazwischen — ein Skript, das fast funktioniert, mit ein paar hartnäckigen Problemen.

All das ist zu erwarten. In dieser Vorlesung geht es darum, diese Erfahrung aufzuarbeiten und Lehren daraus zu ziehen.

Folgendes werden wir heute behandeln:

• Eine Feedback-Runde zu Ihrer Stack Overflow Challenge-Erfahrung
• Drei grundlegend verschiedene Ansätze für dieselbe Challenge — vom gedankenlosen Copy-Paste bis zur professionellen, ingenieurmäßigen Entwicklung
• Ein formalisiertes KI-Tagebuch-System zur Dokumentation Ihrer Prompts und Ihres Lernprozesses
• Claude Code als zweites KI-Werkzeug in Ihrem Toolkit
• Die Stack Overflow Challenge, Runde 2 — dieselbe Aufgabe, neues Bewusstsein

Wir vermitteln heute keine Theorie. Keine Transformer, keine Tokenisierung, keine Attention-Mechanismen. Das kommt in Akt II. Heute geht es um eine zentrale Erkenntnis: Die Art und Weise, wie Sie mit einem KI-Werkzeug interagieren, ist wichtiger als die Wahl des Werkzeugs.

2. Feedback: Ihre Stack Overflow Challenge-Erfahrung

Bevor wir in neue Inhalte eintauchen, starten wir mit einer strukturierten Feedback-Runde. Bitte füllen Sie dieses kurze Quiz zu Ihrer Erfahrung mit der Stack Overflow Challenge aus:

Stack Overflow Challenge — Feedback zum ersten Versuch

Wonach wir suchen:

• Was war das Schwierigste am Einstieg?
• Wie haben Sie die Aufgabe an die KI übergeben? (Copy-Paste? Umformuliert? In Teilaufgaben zerlegt?)
• Haben Sie Halluzinationen beobachtet — Code, der korrekt aussah, aber tatsächlich falsch war?
• Wie viele Prompt-Iterationen hat es gebraucht?
• Wie zuversichtlich sind Sie bezüglich Ihres Endergebnisses?
• Wie haben Sie Ihre Prompts und Ihren Prozess dokumentiert? (Oder haben Sie das gar nicht?)

Wir werden die aggregierten Ergebnisse kurz im Kurs besprechen. Achten Sie auf die Muster: Sie werden wahrscheinlich feststellen, dass viele Ihrer Kommiliton:innen mit denselben Schwierigkeiten zu kämpfen hatten.

3. Drei Ansätze für die Stack Overflow Challenge

Lassen Sie uns die Challenge noch einmal betrachten — nicht um sie erneut zu lösen (noch nicht), sondern um zu untersuchen, wie man sie angehen könnte. Wir werden drei grundlegend verschiedene Strategien durchgehen. Jede produziert funktionierenden Code. Der Unterschied liegt darin, wie sie dorthin gelangen, was dabei schiefgeht und wie einfach das Ergebnis zu warten und zu debuggen ist.

3.1 Die Challenge im Überblick

Hier ist die ursprüngliche Aufgabenstellung, wie sie auf der Vorlesungsfolie erschien:

Ihre Mission: Erstellen Sie den Stack Overflow-Plot mit Python und KI-Werkzeugen nach.

• Finden Sie die Daten programmatisch (Stack Overflow Data Explorer, Stack Exchange API, …)
• Reproduzieren Sie das Diagramm: monatliche Fragenzahlen + gleitender Durchschnitt
• Erweitern Sie es: Überlagern Sie Markierungen für wichtige KI-Durchbrüche aus der Zeitleiste

Diese Aufgabe hat mehrere Teilprobleme, die leicht unterschätzt werden:

1. Datenbeschaffung — Woher bekommen Sie monatliche Stack Overflow-Fragenzahlen? Die Stack Exchange API? Ein Data Dump? Web Scraping?
2. Datenverarbeitung — Monatliche Aggregation, Datumshandling, fehlende Zeiträume
3. Visualisierung — Ein Zeitreihen-Liniendiagramm mit ordentlicher Formatierung und einem gleitenden Durchschnitt
4. Meilenstein-Overlay — Hinzufügen beschrifteter Markierungen an bestimmten Daten für die KI-Durchbrüche aus der Kurs-Zeitleiste (Transformer 2017, ChatGPT 2022, GPT-4 2023 usw.)
5. Integration — Alle Teile in einem einzigen ausführbaren Skript zusammenführen

Sehen wir uns nun drei sehr unterschiedliche Herangehensweisen an.

3.2 Ansatz 1: Das Copy-Paste

3.2.1 Was Sie tun

Eigentlich nichts. Sie nehmen die Aufgabenbeschreibung — oder sogar einen Screenshot der Vorlesungsfolie — und fügen sie direkt in GitHub Copilot Chat ein.

3.2.2 Der Prompt

Sie öffnen Copilot Chat und tippen etwas wie:

Your mission: Recreate the Stack Overflow plot using Python + AI tools.

- Find the data programmatically (Stack Overflow Data Explorer, Stack Exchange API, ...)
- Reproduce the chart: monthly question counts + rolling average
- Extend it: Overlay markers for key AI breakthroughs from the timeline

Create a Python script that does all of this.

Ein Hinweis zur Prompt-Sprache. Ihnen wird auffallen, dass alle Prompts in dieser Vorlesung — und im gesamten Kurs — auf Englisch geschrieben sind, obwohl der Kurs auf Deutsch unterrichtet wird. Das ist eine bewusste Entscheidung, und sie ist durch Forschung belegt.

Aktuelle große Sprachmodelle werden überwiegend mit englischsprachigem Text trainiert. Die Trainingsdaten von GPT-3 bestanden zu etwa 93 % aus Englisch; bei LLaMA waren es ungefähr 90 % (Brown et al., 2020; Touvron et al., 2023). Diese Ungleichgewichtung hat eine direkte Konsequenz: Modelle schlussfolgern präziser, wenn sie auf Englisch angesprochen werden. Shi et al. (2022) zeigten, dass englischsprachige Chain-of-Thought-Beispiele — selbst wenn die Frage in einer anderen Sprache gestellt wird — durchgängig besser abschneiden als Prompts in der jeweiligen Landessprache, und das über 10 Sprachen hinweg. Etxaniz et al. (2023) bestätigten dies allgemeiner: Das Übersetzen von Prompts ins Englische vor der Inferenz verbessert die Ergebnisse bei Reasoning-Aufgaben, selbst wenn die endgültige Ausgabe in einer anderen Sprache erfolgen soll. Huang et al. (2023) formalisierten dies als „Cross-Lingual-Thought Prompting” (XLT) und wiesen signifikante Verbesserungen durch das Routing des Reasoning über Englisch nach.

Übersetzt das Modell intern? Nicht wörtlich. Es gibt kein verstecktes Übersetzungsmodul. Aber die Forschung zu den internen Repräsentationen multilingualer Modelle zeigt etwas Interessantes: Die mittleren Schichten des Netzwerks — in denen der Großteil des Reasoning stattfindet — arbeiten in einem Repräsentationsraum, der stark auf Englisch ausgerichtet ist (Wendler et al., 2024). Nicht-englische Eingaben werden effektiv in diesen englischzentrierten Raum abgebildet, verarbeitet und dann in den letzten Schichten zurück in die Zielsprache überführt. Das Modell übersetzt Ihren deutschen Prompt nicht ins Englische — aber seine stärksten Reasoning-Pfade wurden durch englische Daten geformt, und englische Prompts passen am direktesten zu diesen Pfaden.

Die praktische Empfehlung ist einfach: Prompten Sie auf Englisch, fordern Sie die Ausgabe in der Sprache an, die Sie benötigen. Das Modell antwortet auf Deutsch, wenn Sie es darum bitten — und es tut dies, indem es deutsche Tokens direkt in der Ausgabeschicht generiert, nicht indem es einen englischen Entwurf produziert und diesen übersetzt. Sie verlieren nichts bei der Ausgabesprache. Sie gewinnen messbare Qualität beim Reasoning und bei der Code-Generierung.

Wir werden dieses Thema ausführlicher behandeln, wenn wir die Funktionsweise von Tokenisierung und Attention-Mechanismen in Akt II besprechen. Nehmen Sie es vorerst als empirisch belegte Best Practice: Schreiben Sie Ihre Prompts auf Englisch.

Oder vielleicht machen Sie einen Screenshot der Folie und fügen das Bild direkt in den Chat ein — ohne zusätzlichen Text. Die Bildverarbeitungsfähigkeiten der KI können die Aufgabe aus dem Bild interpretieren. Das ist bereits eine interessante Beobachtung: Sie nutzen multimodale Eingabe (Bild-zu-Text), ohne sich dessen notwendigerweise bewusst zu sein. Wir werden darauf zurückkommen, wie das funktioniert, wenn wir die Tokenisierung in Akt II behandeln.

3.2.3 Was passiert

Die KI wird wahrscheinlich ein vollständiges Python-Skript in einem Zug generieren — vielleicht 50 bis 100 Zeilen. Sie wird eine Datenquelle wählen (oft die Stack Exchange API), eine Plotting-Bibliothek auswählen (matplotlib oder plotly) und die Meilensteinmarkierungen einbauen. Es wird beeindruckend vollständig aussehen.

Aber hier ist, was häufig schiefgeht:

Halluzinierte API-Endpunkte. Die KI erfindet möglicherweise einen Stack Exchange API-Endpunkt oder ein Antwortformat, das nicht existiert. Die URL sieht plausibel aus, die Parameternamen wirken vernünftig, aber wenn Sie das Skript ausführen, erhalten Sie einen 404-Fehler oder eine unerwartete JSON-Struktur.

Hartcodierte Fake-Daten. Manche Modelle generieren, anstatt Code zum Abrufen realer Daten zu schreiben, plausibel aussehende, aber erfundene Zahlen. Das Diagramm sieht großartig aus — die Daten sind nur frei erfunden.

Monolithische Struktur. Alles befindet sich in einer Datei, oft in einer einzigen Funktion oder ganz ohne Funktionen. Wenn etwas nicht funktioniert, können Sie nicht erkennen, ob das Problem beim Datenabruf, beim Parsing oder beim Plotten liegt.

Fehlende Abhängigkeiten. Kein requirements.txt, keine Setup-Anweisungen. Beim ersten Ausführen erhalten Sie einen ModuleNotFoundError.

Unvollständige Fehlerbehandlung. Das Skript stürzt beim ersten Netzwerkfehler mit einem wenig hilfreichen Traceback ab.

Was folgt, ist eine Hin-und-her-Schleife: „Das funktioniert nicht, weil…“, „Jetzt bekomme ich diesen Fehler…“, „Die Daten sehen falsch aus…“. Jede Korrektur führt neue Probleme ein. Nach 10–15 Iterationen haben Sie ein Skript, das funktioniert — aber Sie sind sich nicht ganz sicher, warum es funktioniert, und Sie haben den Überblick darüber verloren, was sich geändert hat.

3.2.4 Warum das wichtig ist

Dieser Ansatz veranschaulicht mehrere wichtige Muster:

Das 80-20-Problem. Die KI bringt Sie innerhalb von Minuten zu „sieht aus, als würde es funktionieren”. Die verbleibenden 20 % — das Debugging, die Datenzugriffsprobleme, die subtilen Bugs — dauern Stunden. Die anfängliche Geschwindigkeit ist verführerisch, aber irreführend.

Halluzinations-Angriffsfläche. Ein einzelner, breiter Prompt gibt der KI maximale Freiheit. Ohne Einschränkungen oder Struktur füllt das Modell Lücken, indem es plausibel klingende Inhalte generiert. Je breiter der Prompt, desto mehr Raum für Halluzinationen.

Keine Fehlerisolierung. Wenn das monolithische Skript fehlschlägt, können Sie nicht erkennen, welcher Teil versagt hat. Liegt es am API-Aufruf? Am Datums-Parsing? An der Plot-Formatierung? Alles ist miteinander verflochten, und jeder Debugging-Prompt birgt das Risiko, neue Probleme in anderen Teilen einzuführen.

Haben Sie den Code tatsächlich verstanden? Das ist eine Frage, die es sich lohnt, ehrlich zu stellen. Wenn die KI 80 Zeilen Code in Sekunden generiert, ist es verlockend zu prüfen, ob er läuft, zu sehen, dass ein Plot entsteht, und weiterzumachen. Aber verstehen Sie, was er tut? Könnten Sie erklären, warum er requests.get mit genau diesen Parametern verwendet? Könnten Sie das Datums-Parsing reparieren, wenn es auf eine Weise bricht, bei der die KI nicht helfen kann?

Das ist weit über diese Übung hinaus relevant. Code — oder ganze Software-Artefakte wie Projektstrukturen, Anforderungsdokumente, Commit-Historien — zu verwenden, den Sie nicht vollständig verstehen, macht diese Software deutlich schwieriger zu warten. Das gilt selbst dann, wenn Sie agentische KI-Werkzeuge haben, die bei zukünftigen Änderungen helfen können: Der Agent arbeitet besser, wenn Sie ihn mit einem Verständnis des bestehenden Designs anleiten können. Es geht hier nicht darum, dass Sie jede Zeile lesen müssen — sondern darum, dass Sie sich bewusst sein sollten, dass dies der entscheidende Aspekt der KI-gestützten Softwareentwicklung ist. Der Fortschritt von Ansatz 1 zu Ansatz 3 ist auch ein Fortschritt im Verständnis: Je mehr Sie die Prompts strukturieren, desto mehr setzen Sie sich mit dem Design auseinander, und desto mehr begreifen Sie, was die KI produziert.

Wir werden auf dieses Thema ausführlich zurückkommen, wenn wir Kontextfenster und die Verarbeitung von Informationen durch LLMs behandeln (Akt II), und erneut, wenn wir die umfassendere Herausforderung von KI-Systemen und Gedächtnis diskutieren (Akt III). Machen Sie es sich vorerst zur Gewohnheit: Lesen Sie den Code, den die KI Ihnen gibt.

Eine Vorschau auf spätere Theorie. In Akt II werden Sie erfahren, warum das passiert: wie Kontextfenster funktionieren, warum große, ungerichtete Prompts den Fokus verlieren und welche statistischen Mechanismen hinter Halluzinationen stecken. Beobachten Sie vorerst einfach das Muster.

3.3 Ansatz 2: Die strukturierte Zerlegung

3.3.1 Was Sie tun

Bevor Sie das KI-Werkzeug anfassen, verbringen Sie 5 bis 10 Minuten damit, über das Problem nachzudenken. Sie identifizieren verschiedene Anliegen:

1. Datenrecherche — Woher kommen die Daten? Was sind die Optionen?
2. Datenzugriff — Ein separates Modul zum Abrufen und Cachen der Daten
3. Visualisierung — Ein separates Modul für das Plotten
4. Meilenstein-Daten — Woher stammen die Daten der KI-Meilensteine?
5. Integration — Ein Hauptskript, das alles zusammenführt

Dann schreiben Sie mehrere, fokussierte Prompts anstelle eines einzigen großen.

Ein wichtiger Hinweis, bevor wir uns die Prompts ansehen. Die folgenden Beispiele spiegeln das Denken einer Person wider, die bereits Erfahrung mit APIs, Datenformaten und Python-Bibliotheken hat. Ihre Prompts werden je nach Hintergrund anders aussehen — und das ist völlig in Ordnung. Wenn Sie noch nie vom Stack Exchange Data Explorer gehört haben, würden Sie ihn nicht als Datenquellenoption aufführen. Wenn Sie neu in Python sind, würden Sie keine pandas-DataFrame-Spaltennamen spezifizieren.

Es geht nicht darum, diese Prompts zu kopieren. Es geht um die Strategie: das Problem in Teile zerlegen, erst recherchieren, dann implementieren. Eine weniger erfahrene Entwicklerin könnte Prompt 1 einfach so formulieren: „Ich brauche monatliche Stack Overflow-Fragenzahlen von 2008 bis 2024. Wie kann ich diese Daten bekommen?” — ohne spezifische Quellen aufzulisten. Die KI wird Optionen vorschlagen, und Sie lernen über SEDE, die API und Data Dumps durch die Antwort der KI statt durch Vorwissen. Das ist genauso valide. Der Recherche-Prompt funktioniert, weil er die KI bittet, Optionen zu erkunden, nicht wegen der spezifischen Optionen, die Sie auflisten.

3.3.2 Prompt 1 — Recherche

I need to get the monthly count of questions posted on Stack Overflow
from 2008 to 2024. What are my options for data sources?

Consider:
- Stack Exchange API
- Stack Exchange Data Explorer (SEDE)
- Data dumps
- Web scraping
- Pre-existing datasets

For each option, list pros, cons, and any rate limits or access
requirements.

Dieser Prompt fragt nicht nach Code. Er fragt nach Recherche. Sie nutzen die KI als Analystin, bevor Sie sie als Programmiererin einsetzen. Das ist an sich bereits eine wirkungsvolle Prompting-Strategie.

Die KI wird typischerweise einen soliden Vergleich liefern. Sie können dann eine informierte Entscheidung über die zu verwendende Datenquelle treffen. Vielleicht bietet der Stack Exchange Data Explorer (SEDE) eine direkte SQL-Schnittstelle, die Ihnen genau das liefert, was Sie brauchen, ohne Paginierungs-Probleme.

3.3.3 Prompt 2 — Datenzugriffsmodul

Nachdem Sie sich für eine Datenquelle entschieden haben (sagen wir SEDE), schreiben Sie einen fokussierten Implementierungs-Prompt:

Write a Python module `data_fetcher.py` that fetches monthly Stack
Overflow question counts using the Stack Exchange Data Explorer.

Requirements:
- Return data as a pandas DataFrame with columns:
  year_month (datetime), question_count (int)
- Cache results locally to a CSV file to avoid repeated queries
- Handle network errors gracefully with retry logic
- Include a main block that demonstrates usage

Beachten Sie die Spezifität: exakte Spaltennamen, exaktes Verhalten für Caching und Fehlerbehandlung, exaktes Ausgabeformat. Die KI hat viel weniger Spielraum für Halluzinationen, wenn die Anforderungen präzise sind.

Auch dieser Prompt spiegelt Erfahrung wider. Einen pandas DataFrame mit exakten Spaltennamen und -typen zu spezifizieren, ist etwas, das eine mit dem Python-Datenökosystem vertraute Entwicklerin tun würde. Wenn Sie neuer in Python sind, könnte Ihr Prompt lauten: „Schreibe ein Python-Skript, das monatliche Stack Overflow-Fragenzahlen herunterlädt und in einer CSV-Datei speichert.” Das ist ein vollkommen vernünftiger Prompt — und die KI wird wahrscheinlich ohnehin pandas wählen. Das Kernprinzip ist nicht, welche Bibliotheken Sie spezifizieren, sondern dass Sie dem Prompt eine fokussierte Aufgabe mit einer einzigen Verantwortlichkeit geben, anstatt ihn zu bitten, alles auf einmal zu erledigen. Tatsächlich kann übermäßige Vorgabe manchmal schaden: Wenn Sie auf pandas bestehen, die Aufgabe aber mit einfachem CSV-Lesen simpler wäre, haben Sie die KI von einer potenziell besseren Lösung abgehalten.

3.3.4 Prompt 3 — Visualisierungsmodul

Write a Python module `plotter.py` with a function
`plot_so_trends(df, milestones)` that:

- Takes a pandas DataFrame (year_month, question_count) and a list
  of milestones as (date, label) tuples
- Creates a time series line plot of monthly question counts
- Adds a 12-month rolling average line
- Overlays vertical markers with labels for each milestone
- Uses matplotlib with a clean, professional style
- Returns the figure object (don't call plt.show())

Derselbe Vorbehalt gilt hier: matplotlib, Funktionssignaturen und Rückgabeverhalten zu spezifizieren, setzt Vertrautheit mit Python-Plotting-Konventionen voraus. Ein weniger spezifischer Prompt — „Schreibe ein Python-Skript, das ein Liniendiagramm der monatlichen Fragenzahlen mit Markierungen für KI-Meilensteine erstellt” — würde ebenfalls funktionieren. Die KI wird Bibliotheks- und Designentscheidungen für Sie treffen. Ob das gut ist, hängt davon ab, ob Sie eine Meinung zu diesen Entscheidungen haben. Mit zunehmender Erfahrung werden Sie natürlich spezifischer — nicht weil Sie müssen, sondern weil Sie es können.

3.3.5 Prompt 4 — Meilenstein-Daten

Die Aufgabenbeschreibung sagte: „Überlagern Sie Markierungen für wichtige KI-Durchbrüche aus der Zeitleiste.” Die auf der Kurs-Zeitleiste dargestellten Durchbrüche sind:

• Transformer (2017)
• ChatGPT (2022)
• GPT-4 (2023)
• Cursor und KI-IDEs (2023)
• Claude Code (2025)
• GitHub Copilot Agent Mode (2025)

Das sind die Ereignisse, die Sie im Plot markieren sollten — keine Liste, die Sie sich ausdenken oder die KI raten lassen. Dies ist ein Fall, in dem Sie die Daten bereits haben. Der Prompt könnte lauten:

I need a Python list of AI breakthrough milestones for my plot.
Here are the events with their dates:

- Transformer: June 2017
- ChatGPT: November 2022
- GPT-4: March 2023
- Cursor & AI IDEs: August 2023
- Claude Code: February 2025
- GitHub Copilot Agent Mode: February 2025

Format this as a list of tuples: (date_string, label), suitable
for passing to a plotting function that draws vertical markers.

Hinweis: Bei nur 6 Meilensteinen, die Sie bereits kennen, könnten Sie diese auch einfach direkt in eine Python-Datei tippen — kein Prompt nötig. Das ist eine vollkommen valide Engineering-Entscheidung und eine wichtige dazu. Nicht alles muss KI-generiert werden. Zu wissen, wann man die KI nicht einsetzt, ist Teil der Kompetenz.

3.3.6 Prompt 5 — Integration

Write a `main.py` that imports `data_fetcher` and `plotter`, fetches
the data, loads the milestones, and creates the visualization.

Include an `if __name__ == '__main__'` block that:
1. Fetches or loads cached data
2. Creates the plot
3. Saves it as 'so_trends.png'
4. Shows it in a window

3.3.7 Was anders ist

Jedes Modul ist eigenständig und kann unabhängig getestet werden. Wenn der Datenabruf fehlschlägt, wissen Sie genau, wo Sie suchen müssen — und die Behebung riskiert nicht, den Plotter zu beschädigen. Die KI liefert bessere Ergebnisse pro Prompt, weil jeder Prompt einen klaren, fokussierten Umfang hat.

Sie werden wahrscheinlich weiterhin einige Halluzinationen erleben, insbesondere in der Datenzugriffsschicht. Aber jetzt sind sie isoliert. Ein halluzinierter API-Endpunkt ist ein Problem in data_fetcher.py, nicht in Ihrem gesamten Projekt.

3.3.8 Zentrale Erkenntnisse

Separation of Concerns zahlt sich sofort aus. Auch ohne den formalen Begriff aus der Softwarearchitektur zu kennen, können Sie sehen, dass isolierte Module einfacher zu debuggen und zu verbessern sind.

Recherche vor Implementierung. Die KI zu nutzen, um Optionen zu erkunden (Prompt 1), bevor man sie bittet, Code zu schreiben, ist eine Strategie, die konsistent bessere Ergebnisse liefert.

Prompting ist Design. Die Art, wie Sie Ihre Prompts zerlegen, spiegelt wider, wie Sie Software zerlegen würden. Das ist kein Zufall — gutes Prompting ist eine Design-Aktivität.

Manuelle Arbeit ist manchmal die richtige Wahl. 6 Meilensteine manuell einzutippen dauert 2 Minuten. Einen Scraper zu bauen, der sie automatisch findet, dauert 20 Minuten und halluziniert möglicherweise Daten. Ingenieurmäßiges Urteilsvermögen bedeutet, das richtige Werkzeug zu wählen — einschließlich keines Werkzeugs.

Die KI als Kollaborateur, nicht als Wunderbox. Sie leiten die Arbeit. Sie entscheiden über die Architektur, die Modulgrenzen, den Datenfluss. Die KI führt die Teile aus, die Sie ihr zuweisen.

3.3.9 Aber Moment — Könnte das ein einziger Prompt sein?

Wenn Zerlegung die zentrale Erkenntnis ist, drängt sich eine offensichtliche Frage auf: Kann ich die KI bitten, das Problem selbst zu zerlegen, innerhalb eines einzigen Prompts?

Ja. Betrachten Sie etwas wie:

I need a Python project that visualizes monthly Stack Overflow
question counts (2008-2024) with AI milestone markers.

Before writing any code, first:
1. Research available data sources and recommend the best option
2. Design a modular architecture with separate concerns for data
   fetching, visualization, and milestone management
3. For each module, define the interface (inputs, outputs, behavior)

Then implement each module one at a time.

Das ist ein einzelner Prompt, aber er codiert den Denkprozess von Ansatz 2 als Anweisungen. Sie bitten die KI, die Recherche durchzuführen, die Designentscheidungen zu treffen und dann zu implementieren — alles sequenziell, in einem einzigen Gesprächsdurchgang.

Moderne KI-Modelle können dies ziemlich gut bewältigen. Das Ergebnis wird oft besser sein als bei Ansatz 1, weil Sie der KI einen Prozess vorgegeben haben, dem sie folgen soll, statt einer leeren Leinwand. Aber es gibt Kompromisse, die es sich zu verstehen lohnt:

Was Sie gewinnen: Bequemlichkeit. Ein Prompt statt fünf. Die KI übernimmt die Zerlegung für Sie.

Was Sie verlieren: Kontrolle. Die KI entscheidet über die Modulgrenzen, die Datenquelle, die Bibliothekswahl. Wenn diese Entscheidungen falsch sind, bemerken Sie es möglicherweise erst viel später — weil Sie sie nicht bewusst getroffen haben.

Das tieferliegende Problem: Wenn Sie das Problem in Ansatz 2 zerlegen, bauen Sie das mentale Modell der Lösung auf. Sie verstehen, warum es separate Module gibt, was jedes tut und wie sie zusammenhängen. Wenn die KI für Sie zerlegt, hat sie das mentale Modell — Sie nicht. Das ist wichtig, wenn etwas schiefgeht und Sie debuggen müssen.

Dieses Muster — einen mehrstufigen Prozess in einen einzelnen Prompt zu codieren — ist eine Vorschau auf etwas, das wir in Akt III ausführlich erkunden werden: agentische Workflows. Werkzeuge wie Claude Code gehen noch weiter: Sie geben eine übergeordnete Anweisung, und der Agent plant, implementiert, testet und iteriert autonom. Der Agent ist Ansatz 2 (oder sogar Ansatz 3), automatisiert.

Aber hier ist der entscheidende Punkt: Sie können keinen guten Meta-Prompt schreiben — oder einen KI-Agenten effektiv beaufsichtigen — ohne vorher zu verstehen, wie man Probleme selbst zerlegt. Die manuelle Zerlegung in Ansatz 2 ist nicht nur eine Technik. Sie ist eine Denkfähigkeit, die Sie unabhängig davon brauchen, wie viel die Werkzeuge automatisieren. Lernen Sie zuerst zu gehen, bevor Sie rennen.

3.4 Bevor wir fortfahren: Das Problem mit der Chat-Historie

Bevor wir uns Ansatz 3 ansehen, lassen Sie uns etwas ansprechen, das Sie wahrscheinlich bereits erlebt haben. In Vorlesung 1 haben wir das Konzept eines KI-Tagebuchs eingeführt — die Aufzeichnung Ihrer Prompts, der KI-Antworten und dessen, was Sie gelernt haben. Seien wir ehrlich darüber, was wahrscheinlich passiert ist:

• Einige von Ihnen haben nichts aufgezeichnet
• Einige von Ihnen haben sich auf die eingebaute Chat-Historie in Copilot oder ChatGPT verlassen
• Einige von Ihnen haben unstrukturierte Notizen gemacht

Die eingebaute Chat-Historie ist besser als nichts, aber sie hat erhebliche Lücken:

• Keine Artefakt-Zuordnung: Welcher Prompt führte zu welcher Code-Änderung? Der Chat zeigt die Konversation, aber nicht, welchen generierten Code Sie tatsächlich verwendet haben und welchen Sie verworfen haben.
• Kein Iterations-Tracking: Wie viele Hin-und-her-Zyklen hat eine Aufgabe wirklich gebraucht? Der Chat macht es schwer, das zu zählen.
• Kein Intent-Tracking: Was wollten Sie tun, im Vergleich zu dem, was Sie gefragt haben? Das sind oft unterschiedliche Dinge.
• Kein werkzeugübergreifender Vergleich: Wenn Sie sowohl Copilot als auch ChatGPT verwendet haben, befinden sich die Historien an verschiedenen Orten mit unterschiedlichen Formaten.
• Fragile Speicherung: Copilot-Chat-Sitzungen können verloren gehen, wenn VS Code neu startet oder aktualisiert wird.

3.5 Warum Tracking wichtig ist

Das KI-Tagebuch ist keine Beschäftigungstherapie. Es dient drei konkreten Zwecken:

Selbstreflexion. Sie erlernen eine neue Fähigkeit — KI-gestützte Entwicklung. Wie bei jeder Fähigkeit erfordert Verbesserung bewusste Reflexion. Was hat funktioniert? Was nicht? Was würden Sie anders machen? Ohne Aufzeichnungen basiert diese Reflexion auf vager Erinnerung.

Zukünftige Kursarbeit. In Akt III werden Sie Ihre eigenen Prompting-Strategien analysieren. Dafür benötigen Sie Daten — Prompt-Anzahlen, Halluzinationsmuster, Iterationstrends über Wochen. Das Tagebuch ist Ihr Datensatz.

Professionelle Evidenz. Am Ende dieses Kurses ist Ihr Tagebuch ein Portfolio darüber, wie Sie mit KI-Werkzeugen arbeiten. Es zeigt einem Arbeitgeber nicht nur, was Sie gebaut haben, sondern wie Sie es gebaut haben — ein wesentlich wertvolleres Signal als Code allein.

Mit dieser Motivation im Hinterkopf wird Ansatz 3 eine Lösung direkt in seinen Workflow integrieren — Prompts als Dateien im Projekt speichern, zusammen mit dem Code committet, den sie hervorbringen. Die vollständigen Details zu Format und Struktur folgen nach dem Vergleich der drei Ansätze.

3.6 Ansatz 3: Der Professionelle

3.6.1 Was Sie tun

Bevor Sie überhaupt prompten, entscheiden Sie sich für einen professionellen Entwicklungsprozess:

1. Ein Projekt mit ordentlicher Paketierung aufsetzen — und es von Anfang an als Git-Repository anlegen
2. Jeden bedeutsamen Meilenstein separat committen
3. Anforderungen als Dokument definieren, bevor Sie Code schreiben
4. Tests vor der Implementierung schreiben
5. Infrastruktur-Tooling wählen (uv für Abhängigkeitsverwaltung, gh für Repository-Erstellung)
6. Jede KI-Interaktion in einem diary/-Ordner dokumentieren — die KI speichert eine kompakte Aufzeichnung jedes Prompt-Zyklus neben dem Code, den sie produziert

Dieser Ansatz bettet den Software Development Lifecycle (SDLC) direkt in Ihre Prompting-Strategie ein. Entscheidend ist, dass sowohl der Git-Workflow als auch das Tagebuch keine Nachgedanken sind — sie beginnen mit dem allerersten Prompt.

3.6.2 Prompt 0 — Projektaufbau und Repository

Create a Python project called so-challenge using uv (from Astral)
for dependency management. The project should separate data
collection (data_fetcher.py) from visualization (plotter.py), with
a separate module for milestone definitions (milestones.py).

Set up pytest for testing with corresponding test files for each
module. Manage all dependencies through pyproject.toml — I'll need
pandas, matplotlib, requests, and pytest.

Include a README.md with a brief project description.

Create a diary/ folder for tracking AI interactions. For every
prompt cycle in this project, save the interaction record to this
folder as a numbered markdown file. Use this format:

# NNN — Short Title

**Date**: YYYY-MM-DD
**Tool**: [tool name]
**Model**: [model name]
**Iterations**: [number]

## Prompt

**YYYY-MM-DD HH:MM**

[The full prompt text as given by the user.]

If there were follow-up prompts (corrections, clarifications),
add each as a separate entry with its own timestamp under the
same Prompt section.

Save this initial setup prompt as diary/001-project-setup.md.

Do NOT implement any logic yet — just create the project structure,
configuration, and empty module files with docstrings describing
their purpose.

Initialize a git repository and create an initial commit with this
scaffolding. Then create a GitHub repository using the gh CLI and
push the initial commit.

Beachten Sie mehrere Dinge an diesem Prompt.

Erstens wird das Tagebuchformat explizit spezifiziert — einschließlich der Markdown-Struktur, des Zeitstempelformats und des Umgangs mit mehreren Iterationen. Wenn Sie das weglassen, wird die KI ein Format erfinden, und es wird wahrscheinlich jedes Mal anders sein. Sie müssen das gewünschte Format definieren, sonst erhalten Sie es nicht konsistent. Innerhalb einer einzelnen Chat-Sitzung wird die KI dieses Format für nachfolgende Prompts beibehalten. Aber wenn Sie morgen eine neue Sitzung starten, wird sie es vergessen haben.

Genau hier werden Projektanweisungsdateien wertvoll. Wir werden dies weiter unten im Detail besprechen, aber die Kernidee ist einfach: Anstatt das Tagebuchformat in jedem Prompt 0 zu spezifizieren, schreiben Sie es einmal in eine Datei, die das KI-Werkzeug automatisch zu Beginn jeder Sitzung liest.

Zweitens ist die Einschränkung „Do NOT implement any logic yet” entscheidend. Ohne sie wird die KI eifrig jedes Modul mit Implementierungscode füllen, was den Zweck der mehrstufigen Strategie zunichtemacht. Zu kontrollieren, was die KI NICHT tut, ist genauso wichtig wie ihr zu sagen, was sie tun soll.

Drittens ist Git Teil von Prompt 0 — kein separater Schritt am Ende. Das Scaffolding bekommt seinen eigenen Commit, bevor überhaupt Code existiert. Dies setzt das Muster für den gesamten Workflow: Jede bedeutsame Änderung wird sofort committet, und jeder Commit enthält seinen zugehörigen Tagebucheintrag.

Viertens beschreiben Sie, anstatt einen ASCII-Verzeichnisbaum einzufügen, was Sie wollen und warum (Separation of Concerns, Testing, Abhängigkeitsverwaltung) und lassen die KI das konventionelle Layout herausfinden. Das ist näher an der Art, wie Sie eine Kollegin briefen würden. Es lässt auch Raum für die KI, ein Layout vorzuschlagen, an das Sie vielleicht nicht gedacht haben — vielleicht erstellt sie ein src/-Layout, vielleicht ein flaches. Beides ist valide, und Sie können anpassen.

Wie zuvor spiegelt der Detailgrad Ihre Erfahrung wider. Eine erfahrene Entwicklerin könnte einen viel knapperen Prompt schreiben. Eine Studierende, die uv zum ersten Mal begegnet, muss möglicherweise expliziter sein — oder könnte die KI bitten, die getroffenen Entscheidungen zu erklären.

Prompt 1 — Anforderungsdokument

Write a brief requirements specification for this project and save
it to docs/requirements.md.

Include:
- Functional requirements (data source, date range 2008-2024, plot
  type, milestone overlay)
- Non-functional requirements (performance: cache data locally,
  reliability: handle API errors with retries, usability: clear axis
  labels and legend)
- Acceptance criteria for each requirement

Save the diary entry for this interaction and commit everything
together with a meaningful commit message.

Dieser Prompt produziert ein Dokument, keinen Code — und committet es sofort zusammen mit seinem Tagebucheintrag. Beachten Sie, dass wir hier nicht das vollständige Tagebuchformat wiederholen. Prompt 0 hat bereits festgelegt, wie ein Tagebucheintrag aussehen soll. Die KI trägt diesen Kontext innerhalb der Sitzung weiter. Sie haben jetzt eine schriftliche Spezifikation, auf die Sie (und die KI) während der gesamten Entwicklung verweisen können. Der docs/-Ordner ist ein konventioneller Ort für Projektdokumentation, und die Anforderungen in der Versionskontrolle zu haben bedeutet, dass sie sich gemeinsam mit dem Code weiterentwickeln.

Prompt 2 — Tests zuerst (TDD-Stil)

Write pytest tests for `data_fetcher.py`. The module should:
- Fetch monthly SO question counts (2008-2024)
- Return a pandas DataFrame with columns: year_month, question_count
- Cache results locally as CSV
- Handle network errors gracefully

Write the tests BEFORE the implementation. Use unittest.mock to
mock API/network calls in tests. Include tests for:
- Successful data fetch returns correct DataFrame shape
- Cached data is returned without network call
- Network error triggers retry logic

Save the diary entry and commit everything with a proper commit
message describing what was added.

Sie haben jetzt Tests, die das erwartete Verhalten definieren, ins Repository committet zusammen mit ihrem Tagebucheintrag. Die Implementierung wurde noch nicht geschrieben — diese Tests werden fehlschlagen. Das ist der Sinn.

Prompt 3 — Implementierung gegen Tests

Now implement `data_fetcher.py` to pass the tests in
test_data_fetcher.py. The implementation should pass all tests.
Do not modify the tests.

Run the tests to confirm they pass. If they do, save the diary
entry and commit everything with a proper commit message that
describes what was implemented and why.

Da Sie sich in derselben Chat-Sitzung befinden, hat die KI den Testcode bereits in ihrem Kontextfenster — es ist nicht nötig, ihn erneut einzufügen. Der Dateipfad reicht aus, damit sie weiß, wogegen sie implementieren soll. Das ist ein praktischer Vorteil des Multi-Prompt-Ansatzes innerhalb einer einzelnen Sitzung: Jeder Prompt baut auf dem gemeinsamen Kontext all dessen auf, was zuvor kam. Dasselbe gilt für die Tagebuchkonvention — einmal in Prompt 0 festgelegt, implizit weitergetragen.

Wenn Sie tatsächlich eine neue Sitzung starten würden (vielleicht am nächsten Tag), müssten Sie die Testdatei explizit referenzieren und die KI an die Tagebuchkonvention erinnern. Werkzeuge wie GitHub Copilot können geöffnete Dateien in Ihrem Editor lesen, und Claude Code kann direkt auf jede Datei in Ihrem Projekt zugreifen. In jedem Fall dienen die Tests als präzise Spezifikation: Die KI kann keinen API-Endpunkt erfinden, wenn die Tests einen bestimmten mocken.

Beachten Sie, dass der Prompt „a proper commit message” sagt, anstatt eine bestimmte Nachricht vorzugeben. Die KI sollte die Nachricht aus den tatsächlichen Änderungen ableiten — genau wie eine Entwicklerin es tun würde. In einem realen Projekt könnten Sie sogar eine Commit-Message-Vorlage oder Konvention haben (z. B. Conventional Commits, ein projektspezifisches Format). In späteren Wochen, wenn wir Projektanweisungsdateien wie CLAUDE.md besprechen, werden wir sehen, wie solche Konventionen — und die Tagebuchkonvention — einmal definiert und automatisch angewendet werden können. Ohne sie in irgendeinem Prompt erwähnen zu müssen.

Sie wiederholen das Muster Prompt 2 → Prompt 3 für plotter.py und milestones.py. Jeder Zyklus produziert zwei Commits: erst Tests, dann Implementierung. Ihr Git-Log wächst zu einer klaren Aufzeichnung des gesamten Entwicklungsprozesses.

Oder, wenn Sie ein agentisches Werkzeug wie Claude Code verwenden, können Sie den Zyklus komprimieren:

Implement the data_fetcher module with tests. Run the tests. If they
pass, save the diary entry and commit everything with a meaningful
message. Then move on to the plotter module. Follow the same pattern
for each module.

Ein Referenz-Repository, das diesen vollständigen Ansatz demonstriert, wird separat bereitgestellt.

Die resultierende Git-Historie

Wenn Sie fertig sind, könnte Ihr Git-Log so aussehen:

* f4e2a1b Integrate main.py and update README
* c8d3b7e Implement milestones module
* 91a0f5c Add tests for milestones module
* 7b2e4d9 Implement plotter module
* 3f8c1a6 Add tests for plotter module
* a5d9e2f Implement data_fetcher module
* e1c7b3d Add tests for data_fetcher module
* 6d4f8a1 Add requirements specification
* 9c3e8f1 Initial project scaffolding

Jeder Commit erzählt eine Geschichte. Jeder Commit entspricht einem Prompt. Und jeder Commit enthält einen Tagebucheintrag im diary/-Ordner, der die vollständige Interaktion dokumentiert. Führen Sie git show auf einem beliebigen Commit aus und Sie sehen sowohl die Code-Änderungen als auch den Prompt, der sie hervorgebracht hat. Die Git-Historie in Kombination mit den Tagebuchdateien gibt Ihnen eine vollständige, durchsuchbare, diff-bare Aufzeichnung Ihres gesamten Entwicklungsprozesses.

Was anders ist

Git und Tagebuch von Anfang an. Das Repository und der diary/-Ordner existieren vor der ersten Zeile Code. Jeder Commit enthält sowohl die Code-Änderungen als auch den Tagebucheintrag, der die Interaktion dokumentiert. Das schafft eine automatische, exakte Zuordnung zwischen Prompts und Artefakten — die Grundlage des KI-Tagebuch-Systems, das wir im nächsten Abschnitt formalisieren werden.

Tests als Halluzinations-Detektoren. Wenn Sie zuerst Tests schreiben, schlägt halluzinierter Code sofort fehl. Es gibt keine stillen Bugs — die Tests fangen sie ab, bevor Sie überhaupt den Output ansehen.

Infrastruktur zählt. Ein uv-Projektaufbau mit ordentlicher Paketierung bedeutet, dass jeder Ihre Umgebung reproduzieren kann. uv sync und alles funktioniert. Keine „bei mir läuft’s”-Probleme.

SDLC eingebettet ins Prompting. Anforderungen, dann Tests, dann Implementierung, dann Commit. Das ist ein Entwicklungslebenszyklus, den Sie in Ihre Prompt-Sequenz codieren. Die KI schreibt nicht nur Code — sie nimmt an einem strukturierten Prozess teil.

Die KI kann Prozesse managen, nicht nur Code. Sie können Anforderungsdokumente, Commit-Messages, Projektstrukturen, README-Dateien prompten. Die KI unterstützt den gesamten Workflow, nicht nur die Implementierung.

Wie bei Ansatz 2 gilt derselbe Erfahrungsvorbehalt. uv, pytest, TDD und Feature-Branches zu kennen, spiegelt eine Entwicklerin wider, die professionelle Workflows bereits verinnerlicht hat. Wenn diese Konzepte neu für Sie sind, könnte Ihre Version von Ansatz 3 einfacher beginnen — vielleicht nur „richte einen Projektordner mit separaten Dateien ein, erstelle ein Git-Repo und schreibe einen Test vor der Implementierung.” Das Kernprinzip bleibt dasselbe: Lassen Sie den Engineering-Prozess Ihr Prompting leiten.

Und genau wie in Ansatz 2 besprochen — ja, dieser gesamte Workflow kann in einen einzelnen Prompt komprimiert oder an einen KI-Agenten delegiert werden. Das Claude Code-Beispiel oben macht genau das bereits. Wir werden dies ausführlich in Akt III erkunden. Aber die Erkenntnis bleibt: Sie können nur dann effektive Agentenanweisungen schreiben, wenn Sie den zugrundeliegenden Prozess selbst verstehen.

Das Problem der Wiederholung — und Projektanweisungsdateien

Sie haben vielleicht zwei Ärgernisse in diesem Workflow bemerkt. Erstens enthält Prompt 0 eine lange Tagebuchformat-Spezifikation. Zweitens enthält jeder folgende Prompt „save the diary entry and commit.” Sie müssen das wiederholen, weil die KI sich Projektkonventionen nicht über Sitzungen hinweg merkt. Innerhalb einer einzelnen Chat-Sitzung bleibt der Kontext erhalten. Aber beim nächsten Öffnen des Editors, einer neuen Sitzung oder einem Werkzeugwechsel — ist der gesamte Kontext weg.

Das ist nicht nur ein Tagebuchproblem. Denken Sie an alle Konventionen, die Sie codieren möchten: Commit-Message-Format, Testing-Anforderungen, Coding-Standards, welche Bibliotheken bevorzugt werden, wie Fehler behandelt werden sollen. All das in jedem ersten Prompt jeder Sitzung zu spezifizieren, ist mühsam und fehleranfällig.

Projektanweisungsdateien lösen dieses Problem. Es sind einfache Textdateien, die das KI-Werkzeug automatisch zu Beginn jeder Sitzung liest, bevor Sie Ihren ersten Prompt eingeben. Das Werkzeug behandelt sie als persistenten Kontext — als hätten Sie diese Anweisungen selbst eingetippt.

Claude Code verwendet eine Datei namens CLAUDE.md im Projektstammverzeichnis. Wenn Sie eine Claude Code-Sitzung in einem Verzeichnis starten, das eine CLAUDE.md enthält, liest das Werkzeug sie und folgt den Anweisungen. Für unsere SO-Challenge könnte eine CLAUDE.md so aussehen:

# Project Instructions

## AI Diary
For every prompt cycle, save a diary entry to diary/ as a numbered
markdown file. Use this format:

# NNN — Short Title

**Date**: YYYY-MM-DD
**Tool**: [tool name]
**Model**: [model name]
**Iterations**: [number]

## Prompt

**YYYY-MM-DD HH:MM**

[Full prompt text with timestamp for each iteration.]

Always commit the diary entry together with the code changes.

## Conventions
- Run tests before committing implementation code
- Use meaningful commit messages derived from the changes
- Do not modify existing tests when implementing against them

Mit dieser Datei bräuchten Sie das Tagebuchformat in Prompt 0 überhaupt nicht. Jede Sitzung, jeder Prompt, jeder Werkzeugaufruf würde automatisch diesen Konventionen folgen.

GitHub Copilot hat ein Äquivalent: .github/copilot-instructions.md. Dasselbe Konzept — eine Markdown-Datei im Repository, die Copilot liest, um projektspezifische Konventionen zu verstehen. Cursor verwendet .cursorrules. Die Dateinamen unterscheiden sich, aber die Idee ist bei allen großen KI-Coding-Werkzeugen identisch: Codieren Sie Ihre Projektkonventionen einmal, in einer Datei, die im Repository lebt, und das Werkzeug wendet sie automatisch an.

Wir werden diese Dateien noch nicht einrichten — das kommt in Akt III, wenn wir mit agentischen Workflows im Detail arbeiten. Aber jetzt verstehen Sie, warum sie existieren: Sie lösen genau das Wiederholungsproblem, das Sie gerade erlebt haben. Das strukturierte Denken, das Sie in Ansatz 3 geübt haben — Konventionen definieren, Formate spezifizieren, Prozesse codieren — ist genau das, was in diese Anweisungsdateien einfließt. Sie erlernen bereits die Fähigkeit; das Tooling automatisiert nur die Bereitstellung.

Verbindung zu späteren Inhalten

Dieser Ansatz führt natürlich zu Themen, die wir in späteren Wochen behandeln werden:

• Akt III: Professionelle KI-gestützte Workflows — Ansatz 3 ist die Grundlage
• Akt III: Evaluationsmetriken — Tests liefern harte, messbare Metriken für Codequalität
• Akt III: Agentische Workflows mit Claude Code — Ein Agent, der Tests ausführt und selbstständig committet, ist Ansatz 3, zu Ende gedacht
• Akt III: Projektanweisungsdateien — CLAUDE.md, .github/copilot-instructions.md und .cursorrules codieren Ihre Standards, damit die KI sie automatisch befolgt
• Akt IV: Organisatorische Adoption — So integrieren professionelle Teams tatsächlich KI-Werkzeuge

7.1 Vergleich der drei Ansätze

Die folgende Tabelle fasst die wesentlichen Unterschiede zusammen. Ein Wort zu den Zeitschätzungen: Diese sind grobe Richtwerte und hängen stark von Ihrer Erfahrung ab. Eine Entwicklerin, die uv, pytest und Git-Branching bereits kennt, richtet Ansatz 3 in 15 Minuten ein. Eine Studierende, die diese Werkzeuge zum ersten Mal kennenlernt, braucht vielleicht eine Stunde — und das ist in Ordnung, weil die Einrichtungszeit Lernen beinhaltet, das sich bei jeder zukünftigen Aufgabe auszahlt. Ebenso könnte die „Zeit bis es tatsächlich funktioniert” bei Ansatz 1 für eine starke Debuggerin 30 Minuten betragen oder einen ganzen Nachmittag für jemanden, der weniger vertraut mit Python ist. Das relative Muster (mehr Vorabinvestition führt zu weniger Gesamtdebugging) gilt über alle Erfahrungsstufen hinweg, aber die absoluten Zahlen variieren.

7.2 Kernaussagen

Keiner dieser Ansätze ist „falsch”. Sie stellen eine Progression dar. Ansatz 1 ist in Ordnung für ein schnelles Experiment oder ein Wegwerf-Skript. Ansatz 2 ist für die meisten Aufgaben angemessen. Ansatz 3 wählen Sie, wenn Qualität, Wartbarkeit und Reproduzierbarkeit wichtig sind. Dieser Kurs wird Ihnen helfen, sich natürlich entlang dieses Spektrums zu bewegen.

Es geht nicht um Prompting-Tricks. Es geht darum, Software-Engineering-Denken auf KI-gestützte Entwicklung anzuwenden. Die Prompting-Strategie folgt aus dem Engineering-Denken — nicht umgekehrt.

Die KI weiß nicht, was „gut” für Ihr Projekt bedeutet. Sie müssen Ihre Qualitätsstandards in den Prompt codieren. Struktur, Anforderungen, Tests — das sind die Mechanismen, über die Sie Ihre Erwartungen kommunizieren.

Eine Vorschau auf das, was kommt. In einigen Wochen werden Sie verstehen, warum diese Ansätze so unterschiedliche Ergebnisse liefern. Es hängt damit zusammen, wie Attention-Mechanismen funktionieren, wie Kontextfenster Informationen verarbeiten und mit der statistischen Natur der Token-Generierung. Beobachten Sie vorerst das Muster: Mehr Struktur im Prompt führt zu besserer Ausgabe.

8. Das KI-Tagebuch: Format und erste Schritte

Wir haben weiter oben besprochen, warum die Chat-Historie unzureichend ist und warum das Tracking Ihrer KI-Interaktionen wichtig ist. Ansatz 3 hat die Lösung bereits in Aktion gezeigt: einen diary/-Ordner, der in Prompt 0 angelegt wird, wobei jeder Prompt-Zyklus einen Tagebucheintrag neben den produzierten Code-Änderungen speichert.

Lassen Sie uns nun die Details formalisieren: wie ein Tagebucheintrag aussieht, wie Ihr Projekt strukturiert ist und wie Sie loslegen.

8.1 Wie ein Tagebucheintrag aussieht

# 004 — Data Fetcher Implementation

**Date**: 2026-03-23
**Tool**: Claude Code
**Model**: Claude Opus 4.6
**Iterations**: 2

## Prompt

**2026-03-23 10:25**

Now implement `data_fetcher.py` to pass the tests in
test_data_fetcher.py. The implementation should pass all tests.
Do not modify the tests.

Run the tests to confirm they pass. If they do, save the diary
entry and commit everything with a proper commit message that
describes what was implemented and why.

**2026-03-23 10:32**

The test `test_retries_on_network_error` is failing —
mock_get.call_count is 1 instead of 3. The retry logic calls a
helper function internally so the mock only sees the outer call.
Move the retry loop to call requests.get directly in each attempt
so the mock captures all 3 tries.

Dieses Beispiel zeigt einen Eintrag mit 2 Iterationen. Der erste Prompt bat um die Implementierung. Er produzierte Code, aber ein Test schlug fehl. Der Follow-up-Prompt — mit Zeitstempel 7 Minuten später — beschreibt das Problem und bittet um eine Korrektur. Beide Prompts werden so dokumentiert, wie sie stattfanden. Keine Zusammenfassungen, keine nachträglichen Anmerkungen. Das Tagebuch ist eine Rohaufzeichnung der Konversation.

Für Einträge mit einer einzigen Iteration (bei denen die KI es beim ersten Versuch richtig macht) gibt es einfach einen Prompt mit Zeitstempel. Das Format bleibt gleich — nur kürzer.

9.1 Die resultierende Projektstruktur

so-challenge/
├── src/
│   └── so_challenge/
│       ├── data_fetcher.py
│       ├── plotter.py
│       └── milestones.py
├── tests/
│   └── ...
├── docs/
│   └── requirements.md
├── diary/
│   ├── 001-project-setup.md
│   ├── 002-data-fetcher-tests.md
│   ├── 003-data-fetcher-impl.md
│   ├── 004-plotter-tests.md
│   ├── 005-plotter-impl.md
│   ├── week-02-reflection.md
│   └── ...
└── pyproject.toml

Jeder nummerierte Tagebucheintrag entspricht einem Prompt-Zyklus. Da jeder Tagebucheintrag zusammen mit dem Code committet wurde, den er produzierte, zeigt git show auf einem beliebigen Commit sowohl die Änderungen als auch die Interaktion, die sie verursacht hat. Das ist die exakte Zuordnung zwischen Prompts und Artefakten, die die Chat-Historie grundsätzlich nicht bieten kann.

Beachten Sie, dass der Großteil der Buchführung automatisch stattfand. Die KI weiß, welches Modell sie ist, welchen Prompt sie erhalten hat, wie viele Iterationen Sie durchlaufen haben. Sie schreibt den Tagebucheintrag als Teil ihrer Aufgabe. Das Einzige, was Sie manuell hinzufügen — wenn Sie möchten — ist eine kurze Beobachtung im Abschnitt „What I Used” oder „Observations”. Der Aufwand ist minimal, weil die KI die Arbeit erledigt.

Ein ehrliches Wort zur Commit-Granularität. Die Ein-Commit-pro-Prompt-Strategie, die wir hier verwenden, ist ein Lernwerkzeug, keine universelle Best Practice. Indem Sie nach jeder KI-Interaktion committen, erstellen Sie eine feingranulare Aufzeichnung, mit der Sie Ihr eigenes Prompting-Verhalten studieren können — welche Prompts funktioniert haben, welche in Sackgassen führten, wie viele Iterationen eine Aufgabe erforderte. Diese Nachverfolgbarkeit ist der gesamte Sinn für diesen Kurs.

Aber erkennen Sie, was das impliziert: Sie legen eine Commit-Strategie auf Ihr Projekt, die von Ihren Lernzielen bestimmt wird, nicht von den Konventionen des Projekts. In einem echten Team arbeiten Sie möglicherweise auf einem Feature-Branch, bei dem die Konvention ist, alle Commits vor dem Merge zu einem einzigen Squash-Commit zusammenzufassen. Oder das Team erzwingt konventionelle Commit-Nachrichten (feat:, fix:, refactor:), in denen „Tagebucheintrag für Prompt 3” kein gültiges Präfix ist. Ihre Tagebuch-Commits und der Git-Workflow des Projekts können in Konflikt geraten.

Für diesen Kurs hat der Lernwert vorerst Priorität — committen Sie nach jeder bedeutsamen KI-Interaktion. Aber mit wachsender Erfahrung werden Sie Ihre eigene Position auf einem Spektrum finden: von strikt (nach jedem einzelnen Prompt committen, einschließlich trivialer) bis entspannt (über viele Prompts hinweg arbeiten, bei bedeutsamen Meilensteinen committen, Interaktionen in einer separaten Tagebuchdatei festhalten). In Vorlesung 3 werden wir diese Spannung erneut aufgreifen, wenn wir auf echte Projektkonventionen treffen, mit denen unsere Tagebuch-Strategie koexistieren muss. Das wichtige Prinzip ist nicht die exakte Commit-Frequenz — sondern dass die Zuordnung zwischen Ihren Prompts und deren Artefakten in irgendeiner überprüfbaren Form existiert.

9.2 Warum sollten Sie Ihre Prompts versionieren?

Sie finden es vielleicht seltsam, Prompt-Dateien in ein Repository zu committen. In einem Produktionsprojekt in einem Unternehmen würden Sie das wahrscheinlich nicht tun. Aber dies ist kein Produktionsprojekt — dies ist ein Kurs über den Aufbau von KI-Kompetenz.

Prompts sind Engineering-Artefakte. Sie sind die Anweisungen, die Ihren Code hervorgebracht haben. In diesem Kurs ist es genauso wichtig, gute Prompts zu schreiben, wie guten Code zu schreiben. Wenn Sie Ihren Quellcode nicht wegwerfen würden, warum dann die Anweisungen, die ihn erzeugt haben?

Die Versionierung Ihrer Prompts ermöglicht es Ihnen:

• Genau zu sehen, welcher Prompt welchen Code erzeugt hat — ein git diff erzählt die ganze Geschichte
• Prompts über die Zeit zu vergleichen — hat sich Ihr Prompting zwischen Woche 2 und Woche 10 verbessert?
• Modelle zu vergleichen — derselbe Prompt an Copilot vs. Claude Code, verschiedene Tagebucheinträge, leicht zu diffen
• Zu teilen und zu diskutieren — in Code-Reviews und Kursdiskussionen liefert der Prompt Kontext, den Code allein nicht bieten kann

9.3 Ein Hinweis zu einfacheren Ansätzen

Nicht alle werden Ansatz 3 vom ersten Tag an verwenden. Wenn Sie noch in einem einfacheren Stil arbeiten (näher an Ansatz 1 oder 2), können Sie trotzdem ein Tagebuch führen — speichern Sie Ihre Prompts einfach manuell in den diary/-Ordner nach jeder Sitzung. Das Minimum: Dokumentieren Sie für jede KI-Interaktion den Prompt, das Werkzeug/Modell und eine Beobachtung. Das Format ist weniger wichtig als die Gewohnheit.

9.4 Jetzt gleich loslegen

Wenn Sie im Vorlesungsraum sitzen, nehmen Sie sich jetzt 5 Minuten:

1. Erstellen Sie einen diary/-Ordner in Ihrem Challenge-Repository
2. Schreiben Sie Ihren ersten Tagebucheintrag — einen kurzen Rückblick auf Ihren ersten Stack Overflow Challenge-Versuch. Welche Prompts haben Sie verwendet? Was hat funktioniert, was nicht?
3. Wenn Sie sich an Halluzinationen oder „Aha-Momente” erinnern — schreiben Sie sie jetzt auf, bevor sie verblassen

Dieser erste Eintrag muss nicht perfekt sein. Er muss nur existieren.

10. Ihre Toolbox erweitern: GitHub Copilot und Claude Code in VS Code

In diesem Kurs verwenden wir zwei KI-Coding-Assistenten, beide über ihre VS Code-Erweiterungen:

• GitHub Copilot — der KI-Assistent, den Sie bereits in Vorlesung 1 eingerichtet haben
• Claude Code — Anthropics KI-Coding-Agent, den wir jetzt einführen

Beide leben in VS Code. Beide akzeptieren natürlichsprachliche Prompts. In ihren jeweiligen Agent-Modi können beide Dateien in Ihrem Projekt lesen und schreiben, Terminal-Befehle ausführen, Tests starten, Git-Commits erstellen und sogar GitHub-Repositories über die gh-CLI anlegen. Die Fähigkeiten haben sich erheblich angenähert — beide Werkzeuge sind vollständige agentische Coding-Assistenten, wenn sie im Agent-Modus verwendet werden. Die Unterschiede liegen in ihren zugrundeliegenden Modellen, der Ökosystem-Integration und dem Umgang mit dem Kontext.

10.1 Wie sie sich vergleichen

Wie Sie sehen, sind die Kernfähigkeiten nahezu identisch. Beide Werkzeuge können alles, was Ansatz 3 erfordert: Projektscaffolding erstellen, Dateien schreiben, Tests ausführen, Commits erstellen, zu GitHub pushen. Die echten Unterschiede liegen in den Modellen (Copilot bietet Multi-Anbieter-Auswahl, Claude Code hat Zugang zu Opus mit seinem größeren Kontextfenster) und der Ökosystem-Integration (Copilot ist enger mit GitHubs Issue- und PR-Workflows integriert).

In der Praxis werden Sie ein Gespür dafür entwickeln, welches Werkzeug Sie für welche Aufgaben bevorzugen. Manche bevorzugen Copilots Inline-Vervollständigungen für kleine Bearbeitungen und Claude Code für größere Multi-Datei-Aufgaben. Andere verwenden ein Werkzeug für alles. Beides ist valide — und Ihre Werkzeugpräferenzen im KI-Tagebuch zu dokumentieren, ist selbst eine wertvolle Lernübung.

10.2 Interaktionsmodi: Ask, Agent/Edit und Plan

Wenn Sie eines der beiden Werkzeuge in VS Code öffnen, werden Sie einen Modus-Selektor oben im Chat bemerken. Beide Werkzeuge bieten drei Modi mit ähnlichen Namen, aber leicht unterschiedlichem Verhalten:

Die Terminologie unterscheidet sich leicht — Copilot nennt seinen aktiven Modus „Agent”, während Claude Code ihn „Edit automatically” nennt — aber die zugrundeliegende Idee ist dieselbe: Wie viel Autonomie geben Sie der KI?

• Ask: Die KI ist eine Beraterin. Sie berät, Sie führen aus.
• Agent / Edit: Die KI ist eine Kollaborateurin. Sie nimmt Änderungen vor, Sie prüfen.
• Plan: Die KI ist eine Architektin. Sie entwirft, Sie genehmigen, dann baut sie.

Wir werden erkunden, was diese Unterschiede antreibt — Kontextfenster, Tool-Nutzung und agentische Architekturen — in Akt II und Akt III. Experimentieren Sie vorerst mit allen drei Modi und beobachten Sie, wie sie sich unterschiedlich anfühlen.

10.3 Berechtigungen konfigurieren: Der KI beibringen, was sie darf

Wenn Sie Claude Code zum ersten Mal im Modus „Edit automatically” verwenden, werden Sie bemerken, dass es trotzdem vor bestimmten Befehlen um Erlaubnis fragt — Git-Operationen, Paketinstallationen, Test-Runner. Das ist eine Sicherheitsfunktion: Die KI möchte eine Bestätigung, bevor sie Aktionen durchführt, die Ihr System betreffen.

Für wiederholte Workflows (wie unser Ansatz-3-Muster von Test → Implementierung → Commit → Push) werden diese Abfragen lästig. Beide Werkzeuge ermöglichen es, Berechtigungsregeln zu konfigurieren, damit vertrauenswürdige Operationen ohne Nachfrage ausgeführt werden.

Claude Code verwendet eine JSON-Einstellungsdatei. Sie haben zwei Ebenen:

Benutzerebene (~/.claude/settings.json) — gilt für alle Ihre Projekte:

{
  "permissions": {
    "allow": [
      "Edit",
      "Write",
      "Bash(git:*)",
      "Bash(gh:*)",
      "Bash(uv:*)",
      "Bash(npm:*)"
    ]
  }
}

Das bedeutet: Dateibearbeitungen, Dateischreibvorgänge und jeden Befehl, der mit git, gh, uv oder npm beginnt, erlauben — ohne Nachfrage. Das * ist ein Platzhalter, sodass Bash(git:*) auf git add, git commit, git push und so weiter passt.

Projektebene (.claude/settings.json in Ihrem Repo) — gilt für alle, die an diesem Projekt arbeiten. Hier werden teamweite Konventionen hinterlegt. Sie kann auch verwendet werden, um gefährliche Operationen zu verbieten:

{
  "permissions": {
    "deny": ["Bash(rm -rf:*)"]
  }
}

Es gibt auch .claude/settings.local.json (gitignored) für persönliche Überschreibungen innerhalb eines Projekts.

GitHub Copilot handhabt das anders. In VS Code nutzt Copilots Agent-Modus das VS Code Trust-Modell — wenn Sie einen Workspace öffnen, fragt VS Code, ob Sie dem Ordner vertrauen. Innerhalb eines vertrauenswürdigen Workspaces kann Copilot Agent Terminal-Befehle ausführen. Es gibt kein Äquivalent zu Claude Codes granularer Pro-Befehl-Erlaubnisliste. Stattdessen zeigt Copilot einen Bestätigungsdialog für jeden Terminal-Befehl, und Sie klicken auf „Allow” oder „Always Allow” für dieses spezifische Befehlsmuster.

Für beide Werkzeuge: Beginnen Sie mit der Standardeinstellung (für alles nachfragen) und fügen Sie Berechtigungen hinzu, wenn Sie entdecken, welche Befehle Sie häufig ausführen. Das ist eine gute Praxis — Sie lernen, was das Werkzeug tut, bevor Sie ihm mehr Freiraum geben.

10.4 Projektanweisungsdateien nochmals betrachtet

Wir haben CLAUDE.md und .github/copilot-instructions.md bereits im Kontext des KI-Tagebuchs besprochen. Diese Dateien dienen einem breiteren Zweck: Jede Konvention, der die KI automatisch folgen soll, kommt hierhin.

Für Claude Code wird CLAUDE.md zu Beginn jeder Sitzung gelesen. Für Copilot erfüllt .github/copilot-instructions.md dieselbe Rolle. Die oben genannten Einstellungsdateien steuern Berechtigungen (was das Werkzeug tun darf). Die Anweisungsdateien steuern Verhalten (wie das Werkzeug es tun soll).

Wir werden diese in Akt III ordentlich einrichten. Wissen Sie vorerst einfach, dass sie existieren — und dass die Wiederholung, die Sie in Ansatz 3 erlebt haben („save the diary entry and commit”), genau das ist, was sie eliminieren.

10.5 Claude Code in VS Code einrichten

1. Erweiterung installieren: Öffnen Sie VS Code, gehen Sie zum Erweiterungen-Panel, suchen Sie nach „Claude Code” und installieren Sie sie.

2. Konto erstellen: Wenn Sie kein Anthropic-Konto haben, erstellen Sie eines. Die kostenlose Stufe bietet eine begrenzte Anzahl von Nachrichten pro Tag — ausreichend für Experimente und Kursarbeiten.

3. Eine einfache Aufgabe ausprobieren: Öffnen Sie das Claude Code-Panel und geben Sie eine kleine, klar definierte Aufgabe. Zum Beispiel:

Create a Python script that prints "Hello from Claude Code" and
saves the current date and time to a file called 'timestamp.txt'.

Beobachten Sie, wie es arbeitet: Es wird Ihr Projekt lesen, die Datei erstellen und sie möglicherweise ausführen, um sie zu verifizieren — alles autonom.

1. Die Erfahrung vergleichen: Probieren Sie dieselbe Aufgabe in Copilot Agent-Modus aus. Beide Werkzeuge können die Datei erstellen und ausführen — beachten Sie die Unterschiede in der Oberfläche (Chat-Panel vs. Terminal-Panel), wie sie vorgeschlagene Änderungen anzeigen und wie sie den Ausführungsschritt handhaben.

Es gibt keinen Studierendenrabatt für Claude Code, aber die kostenlose Stufe bietet brauchbaren Wert für die Aufgaben in diesem Kurs. Wenn Sie das Tageslimit erreichen, wechseln Sie für den Rest des Tages zu Copilot — und notieren Sie den Wechsel in Ihrem Tagebuch.

10.6 Wann welches Werkzeug verwenden

Beide Werkzeuge können fast jede Aufgabe bewältigen. Mit der Zeit werden Sie Ihre eigenen Präferenzen entwickeln. Hier sind einige Anfangsbeobachtungen — keine Regeln:

• Copilots Inline-Vervollständigungen (außerhalb des Agent-Modus) sind ausgezeichnet für kleine, fließende Bearbeitungen — eine Zeile vervollständigen, einen Funktionskörper vorschlagen, schnelle Syntax-Hilfe. Claude Code hat kein Inline-Vervollständigungs-Äquivalent.
• Copilots Modellflexibilität ermöglicht den Wechsel zwischen GPT-4o, Claude Sonnet und Gemini innerhalb derselben Sitzung. Nützlich zum Vergleichen von Outputs oder wenn ein Modell bei einer Aufgabe Schwierigkeiten hat.
• Claude Codes größeres Kontextfenster (bis zu 1M Tokens mit Opus) kann ein Vorteil sein bei Aufgaben, die das Verständnis einer großen Codebasis oder langer Gesprächsverläufe erfordern.
• Claude Codes eigenständige CLI funktioniert außerhalb von VS Code — nützlich für Skripting, CI/CD-Integration oder wenn Sie einen Terminal-Workflow bevorzugen.

Der beste Weg zu lernen, welches Werkzeug zu welcher Aufgabe passt, ist beide auszuprobieren und zu vergleichen. Dokumentieren Sie Ihre Erkenntnisse in Ihrem KI-Tagebuch — diese Beobachtungen sind genau die Art von Lernen, für die das Tagebuch gedacht ist.

11. Die Stack Overflow Challenge — Runde 2

Sie haben nun drei grundlegend verschiedene Ansätze für dieselbe Challenge gesehen. Sie haben ein strukturiertes KI-Tagebuch-Format. Sie haben ein zweites KI-Werkzeug zur Verfügung. Es ist Zeit für einen neuen Versuch.

11.1 Ihre Aufgabe

Die Challenge ist dieselbe wie in Vorlesung 1:

Ihre Mission: Erstellen Sie den Stack Overflow-Plot mit Python und KI-Werkzeugen nach.

• Finden Sie die Daten programmatisch (Stack Overflow Data Explorer, Stack Exchange API, …)
• Reproduzieren Sie das Diagramm: monatliche Fragenzahlen + gleitender Durchschnitt
• Erweitern Sie es: Überlagern Sie Markierungen für wichtige KI-Durchbrüche aus der Zeitleiste

11.2 Was diesmal anders ist

Die Aufgabe ist identisch. Ihr Ansatz sollte es nicht sein.

Verwenden Sie diesmal Ansatz 3 — den professionellen SDLC-Workflow mit integriertem Tagebuch. Konkret:

1. Richten Sie ein ordentliches Projekt ein mit uv, separaten Modulen und einem diary/-Ordner — genau wie in Prompt 0 von Ansatz 3 gezeigt.

2. Folgen Sie der Prompt-Sequenz: erst Anforderungen, dann Tests, dann Implementierung, dann Integration. Committen Sie nach jedem Schritt, mit einem Tagebucheintrag neben jedem Commit.

3. Sie dürfen GitHub Copilot, Claude Code oder beide verwenden. Wenn Sie beide verwenden, notieren Sie in Ihren Tagebucheinträgen, welches Werkzeug Sie für welchen Prompt-Zyklus verwendet haben.

4. Konzentrieren Sie sich auf den Prozess, nicht nur auf das Ergebnis. Ein funktionierender Plot ohne Commit-Historie und ohne Tagebuch ist weniger wert als ein teilweise funktionierender Plot mit einem sauberen Git-Log und vollständigen Tagebucheinträgen. Wir bewerten, wie Sie arbeiten, nicht nur was Sie produzieren.

11.3 Referenz-Repository

Ein vollständiges Beispiel dieses Workflows ist verfügbar unter: github.com/l3gj0n/so-challenge

Durchsuchen Sie sein Git-Log, um die erwartete Commit-Struktur zu sehen. Schauen Sie sich den diary/-Ordner an, um zu sehen, wie Tagebucheinträge aussehen — einschließlich eines mit einer mehrstufigen Korrektur (004-data-fetcher-impl.md). Ihr Repository sollte demselben Muster folgen, obwohl Ihr Code, Ihre Prompts und Ihre Tagebucheinträge natürlich anders sein werden.

11.4 Abzugebende Leistungen

• Ein Git-Repository (GitHub) mit einer sauberen Commit-Historie, in der jeder Commit Code-Änderungen mit einem Tagebucheintrag verbindet
• Ein diary/-Ordner mit nummerierten Tagebucheinträgen (einer pro Prompt-Zyklus) im Format von Ansatz 3
• Der generierte Stack Overflow-Trend-Plot

11.5 Zeitplan

Beginnen Sie während der Vorlesung, wenn die Zeit es erlaubt. Vervollständigen Sie die Arbeit als Hausaufgabe bis zum Beginn von Vorlesung 3.

12. Feedback nach der Challenge

Nach Abschluss des zweiten Versuchs der Stack Overflow Challenge füllen Sie ein zweites Feedback-Quiz aus. Dieses ist kürzer und konzentriert sich auf den Vergleich Ihrer beiden Versuche.

Wir werden die aggregierten Ergebnisse beider Feedback-Runden vergleichen, um zu sehen, wie sich der Kurs zwischen Versuch 1 und Versuch 2 entwickelt hat. Zentrale Fragen sind: Hat sich Ihr Ansatz geändert? Ist Ihre Iterationszahl gesunken? Was war das Wichtigste, das Sie gelernt haben?

Die Ergebnisse werden zu Beginn von Vorlesung 3 besprochen.