Agentic Coding

Agentic Coding Guide

Dieser Leitfaden beschreibt, wie wir in dieser Lehrveranstaltung mit Large Language Models arbeiten: nicht als Blackbox, sondern als intelligenten Assistenten, den wir kritisch und kompetent einsetzen.

Was ist Agentic Coding?

Agentic Coding beschreibt einen Ansatz der Softwareentwicklung, bei dem KI-Agenten (insbesondere Large Language Models) als aktive Partner im Entwicklungsprozess eingesetzt werden. Im Gegensatz zum reinen "Copy-Paste aus ChatGPT" bedeutet Agentic Coding:

  • Du formulierst klare Anforderungen, bevor du Code generieren lässt.
  • Du stellst dem LLM relevanten Kontext bereit (Daten, Struktur, Constraints).
  • Du verstehst den generierten Code und kannst ihn erklären.
  • Du prüfst das Ergebnis systematisch und iterierst bei Bedarf.
  • Du dokumentierst deinen Prozess und reflektierst darüber.
Kernidee

Agentic Coding bedeutet nicht, dass das LLM für dich programmiert. Es bedeutet, dass du lernst, eine neue Art von Werkzeug kompetent einzusetzen — so wie Geisteswissenschaftler:innen gelernt haben, Datenbanken, Bibliothekskataloge oder digitale Editionen als Werkzeuge zu nutzen.

Informed Vibe Coding

"Vibe Coding" ist ein populärer Begriff für das explorative Programmieren mit LLM-Unterstützung — man beschreibt, was man will, und schaut, was herauskommt. Das kann funktionieren, führt aber oft zu Code, den man nicht versteht und der bei Problemen schwer zu debuggen ist.

Unser Ansatz ist Informed Vibe Coding: Wir nutzen die explorative Kraft des Vibe Codings, aber mit wachsendem Verständnis. Je mehr du über HTML, CSS und JavaScript lernst, desto:

  • bessere Prompts kannst du formulieren,
  • besser kannst du generierten Code einschätzen,
  • schneller erkennst du Fehler,
  • gezielter kannst du iterieren.
Informed Vibe Coding in der Praxis

Woche 1: "Erstelle mir eine HTML-Seite" → Du schaust, was rauskommt, lernst die Struktur kennen.
Woche 5: "Erstelle eine Funktion, die ein Array von Briefobjekten nach Datum filtert. Verwende Array.filter() und vergleiche die Date-Objekte." → Du weißt, was du willst und wie es ungefähr aussehen sollte.

Der 8-Schritte-Workflow

Dieser Workflow beschreibt den empfohlenen Ablauf, wenn du ein Feature oder eine Funktion mit LLM-Unterstützung entwickelst:

Anforderung formulieren (RE)

Was genau soll die Website/Funktion können? Schreibe die Anforderung in eigenen Worten auf, bevor du das LLM öffnest. Je klarer die Anforderung, desto besser das Ergebnis.

Beispiel: "Ich brauche eine Tabelle, die 20 Briefkorrespondenzen anzeigt. Spalten: Absender, Empfänger, Datum, Ort. Die Tabelle soll nach jeder Spalte sortierbar sein."

Kontext aufbereiten (CE)

Welche Informationen braucht das LLM, um guten Code zu generieren? Sammle: Datenbeispiele, gewünschtes Design, bestehender Code, technische Constraints.

Beispiel: "Hier sind die ersten 3 Zeilen meiner CSV-Datei: [Daten]. Das Design soll zum bestehenden CSS passen, das CSS-Variablen verwendet: [CSS-Snippet]."

Prompt schreiben (PE)

Formuliere einen spezifischen, kontextreichen Prompt. Sei präzise: Welche Technologie? Welches Format? Welche Einschränkungen?

Code generieren

Sende den Prompt an das LLM und warte auf das Ergebnis.

Code lesen (CL)

Lies den generierten Code aufmerksam durch. Verstehst du, was jede Zeile tut? Markiere Stellen, die du nicht verstehst, und frage das LLM: "Erkläre mir Zeile 15-20 dieses Codes."

Testen (RV)

Kopiere den Code in dein Projekt und teste ihn im Browser. Funktioniert alles? Öffne die DevTools und prüfe auf Fehler in der Konsole.

Iterieren (PE + RV)

Falls etwas nicht funktioniert: Beschreibe das Problem präzise. Kopiere die Fehlermeldung. Erkläre, was du erwartet hast und was stattdessen passiert.

Beispiel: "Der Code zeigt einen Fehler: 'Cannot read property of undefined'. Das passiert in Zeile 12 beim Zugriff auf item.title. Ich glaube, das Array ist leer. Wie kann ich das abfangen?"

Reflektieren (EW)

Was hast du gelernt? Was hat gut funktioniert? Was würdest du beim nächsten Mal anders machen? Notiere dir diese Erkenntnisse für deine LLM-Reflexion.

Das 7-Dimensionen-Kompetenzmodell

Agentic Coding erfordert Kompetenzen in sieben Dimensionen. Im Laufe des Semesters entwickelst du alle davon — manche stärker, andere leiser im Hintergrund.

CT Computational Thinking

Probleme in bearbeitbare Schritte zerlegen und abstrahieren. Bevor du ein LLM fragst, überlegst du: Was sind die Teilprobleme? In welcher Reihenfolge müssen sie gelöst werden?

Beispiel: "Ich brauche (1) die Daten laden, (2) die Daten filtern, (3) die Ergebnisse als HTML rendern, (4) einen Event-Listener für das Suchfeld."

RE Requirement Engineering

Anforderungen präzise und vollständig formulieren. Vage Anforderungen führen zu vagem Code.

Schlecht: "Mach mir eine Tabelle."
Gut: "Erstelle eine HTML-Tabelle mit den Spalten Absender, Empfänger, Datum, Ort. Die Daten kommen aus einer CSV-Datei. Jede Zeile soll beim Hover hervorgehoben werden."

CE Context Engineering

Dem LLM den richtigen Kontext geben: relevante Dateien, Datenbeispiele, bestehenden Code, Design-Vorgaben, Constraints.

Beispiel: "Hier ist mein bestehendes HTML: [Code]. Hier sind die ersten 5 Zeilen meiner JSON-Datei: [Daten]. Füge eine Filterfunktion hinzu, die zum bestehenden Code passt."

PE Prompt Engineering

Effektive Prompts formulieren: spezifisch, kontextreich, mit Beispielen, iterativ verfeinernd.

CL Code Literacy

Generierten Code lesen und verstehen können. Nicht jede Zeile auswendig wissen, aber die Logik nachvollziehen können.

RV Review

Ergebnisse systematisch prüfen: Funktioniert es? Ist es korrekt? Ist es zugänglich? Gibt es Fehler in der Konsole?

EW Expertenwissen

Dein Domänenwissen aus den Digital Humanities einbringen: Du weißt, was TEI ist, was eine Korrespondenz-Edition braucht, wie historische Daten strukturiert sind. Dieses Wissen macht deine Prompts besser als die eines reinen Informatikers.

CLAUDE.md — Projektregeln für dein Repository

Eine CLAUDE.md-Datei im Wurzelverzeichnis deines Projekts definiert Regeln und Kontext, die ein LLM (insbesondere Claude Code) bei der Arbeit an deinem Projekt beachten soll. Ab Assignment 3 ist eine solche Datei Pflicht.

CLAUDE.md 
# Mein DH-Projekt — Projektregeln

## Beschreibung
Interaktiver Explorer für die Korrespondenz von Hugo Schuchardt.
Statische Website mit HTML, CSS und JavaScript.

## Technische Regeln
- Vanilla HTML/CSS/JS, keine Frameworks
- CSS-Variablen für alle Farben und Abstände
- Deutsche Sprache in allen Inhalten
- Leaflet.js für Kartenvisualisierung (CDN)

## Datenstruktur
- data/korrespondenzen.csv: Briefmetadaten (Spalten: id, absender, empfaenger, datum, ort)
- data/orte.geojson: GeoJSON mit Korrespondenzorten

## Konventionen
- Semantisches HTML (header, main, footer, article)
- Funktionsnamen auf Englisch, Kommentare auf Deutsch
- Alle fetch()-Aufrufe mit try/catch

Anti-Patterns — Was du vermeiden solltest

Copy-Paste ohne Verstehen

Code vom LLM kopieren, ohne ihn zu lesen. Das führt zu Problemen, die du nicht debuggen kannst, und zu einer Reflexion, die nichts Substanzielles enthält.

Zu vage Prompts

"Mach mir eine Website" ist kein guter Prompt. Je spezifischer du bist, desto besser das Ergebnis. Beschreibe Struktur, Daten, Design, Funktionalität.

Keinen Kontext geben

Das LLM kennt dein Projekt nicht. Wenn du nach einer Erweiterung fragst, zeige den bestehenden Code, die Datenstruktur und das gewünschte Ergebnis.

Nicht testen

Generierten Code immer im Browser testen. Die Konsole (F12) zeigt Fehler. Live Server zeigt die Seite. Nur weil das LLM sagt "das sollte funktionieren", heißt das nicht, dass es funktioniert.

Zu früh aufgeben oder zu spät iterieren

Wenn der erste Prompt nicht perfekt funktioniert, ist das normal. Beschreibe das Problem, kopiere die Fehlermeldung, und iteriere. Oft reichen 2-3 Runden.

Ethische Aspekte

Der Einsatz von LLMs im akademischen Kontext wirft wichtige Fragen auf:

  • Transparenz: Dokumentiere immer, welche Teile deines Codes mit LLM-Unterstützung entstanden sind. In dieser LV ist der LLM-Einsatz erwünscht und Pflicht — aber die Dokumentation ebenso.
  • Verstehen: Reiche keinen Code ein, den du nicht erklären kannst. Wenn du in der Präsentation nach einer Funktion gefragt wirst, solltest du sie beschreiben können.
  • Grenzen: LLMs können Fehler machen, veralteten Code generieren und Sicherheitslücken einbauen. Deine Aufgabe ist, das zu erkennen.
  • Datenschutz: Lade keine sensiblen oder personenbezogenen Daten in ein LLM hoch. Die Beispieldaten der LV sind unbedenklich, aber bei eigenen Forschungsdaten ist Vorsicht geboten.
  • Nachhaltigkeit: LLM-Abfragen verbrauchen Energie. Nutze sie gezielt, nicht für Dinge, die du schnell selbst nachschlagen kannst.