Wie wahrscheinlich viele von Euch beschäftige ich mich aktuell mit KI, agentischen Systemen und Coding-Tools. Aktuell arbeite ich mit Claude Code, das mich bei der Umsetzung einiger kleiner Webseiten-Projekte mit zugehörigem Form-Handler-Service unterstützt.

Die Art, wie man damit Code erzeugt, unterscheidet sich natürlich substantiell von „klassischer“, händischer Programmierung und ich finde, es gibt hier sehr viel zu lernen, Tricks und Kniffe herauszufinden, aber auch Besonderheiten zu beachten. Von solchen Erkenntnissen will ich in diesem Artikel einige berichten. Vielleicht habt ihr ja ähnliche, die ihr teilen könnt.

Die gefühlten Effizienzgewinne sind beeindruckend

Ich bin mir sicher, dass die allermeisten Menschen, die zum ersten Mal mit einem Coding-Agenten arbeiten, beeindruckt sein werden. Wie gut und schnell das Werkzeug das Projekt analysiert, Pläne generiert und Code generiert, ist wirklich eindrucksvoll. Dass hier das Gefühl von massiven Effizienzgewinnen entsteht, ist, glaube ich, ganz natürlich.

Die Fehler auch

Allerdings muss man auch aufpassen, denn die Ergebnisse, die Claude Code generiert, sind weder fehlerfrei noch notwendigerweise strukturell sauber. Man liest häufig, man müsse solche Coding-Agenten behandeln wie einen übermotivierten Junior-Entwickler. Ich halte das für eine gute Analogie, aber um zu verstehen, was genau das bedeutet, muss man konkrete Beispiele gesehen haben.

In den folgenden Abschnitten möchte ich einige solcher Beispiele zeigen und erläutern.

Plan erstellen lassen und auch prüfen

Bevor man an die Umsetzung einer neuen Änderung geht, sollte man sich unbedingt einen Plan generieren lassen. Diesen iteriert man so lange mit dem Modell, bis er geeignet und vollständig erscheint. Erst dann startet man mit der Umsetzung. Claude Code bietet dafür den Planungsmodus an und Anthropic empfiehlt auch ganz explizit, diesen zu verwenden.

Bei der Einschätzung, ob der Plan geeignet und vollständig ist, sollte man aber kritisch sein.

Beispiel: Mein Form-Handler-Service loggt Zugriffe mit den typischen Informationen, darunter auch die IP-Adresse, die ja bekanntlich als personenbezogenes Datum gilt. Ich lasse mir also einen Plan generieren, um die Zugriffsprotokollierung DSGVO-konform umzubauen. Die Kernidee dabei ist, dass potenziell personenbezogene Daten nicht im Klartext, sondern pseudonymisiert über Hashing gespeichert werden. Claude Code schlägt dafür ein einfaches Verfahren über SHA-256, vor. Das erzeugt zwar eindeutige Hashes, die Pseudonymisierung ist aber eher schwach, weil sie natürlich von jedem in der gleichen Weise durchgeführt werden kann (anfällig für Dictionary- / Rainbow-Table-Attacken).

Ich hatte mir im Vorfeld ebenfalls einen Umsetzungsplan von ChatGPT erzeugen lassen, was ganz explizit davon abgeraten hatte, als Hashing-Verfahren nur SHA-256 zu verwenden und stattdessen zusätzlich HMAC zu verwenden, wofür eben ein Secret verwendet werden muss. Eine kleine Änderung, aber hinsichtlich einer DSGVO-Bewertung deutlich zu bevorzugen. Konkret darauf angesprochen sieht Claude Code das genauso und passt den Plan bereitwillig entsprechend an.

Ich bin mir sicher, dass ich diesen Punkt ohne ein Vergleichsergebnis nicht direkt gesehen hätte. Das heißt, ist man sich selbst nicht ganz sicher, welchen Weg man selbst wählen würde, ist es ratsam, den Plan noch mal prüfen zu lassen, in einem anderen Kontext oder von einem anderen Modell, bevor man in die Implementierung startet.

Unnötig komplexe Implementierung

Das Form-Handler-Backend besitzt eine Rate-Limiting-Funktion, um Missbrauch zu verhindern. Dazu wird die IP-Adresse des anfragenden Systems benötigt. Diese wird aus dem X-Forwarded-For-HTTP-Header ausgelesen und die darin enthaltene IP-Adresse zunächst auf Validität geprüft. Diese Validitätsprüfung wird für IPv4- und IPv6-Adressen durchgeführt. Hier die erzeugte Implementierung von Claude Code, nur für den IPv4-Teil:

// IsValidIPv4 checks if an IPv4 address is valid
func IsValidIPv4(ip string) bool {
	parts := strings.Split(ip, ".")
	
	// IPv4 must have exactly 4 parts
	if len(parts) != 4 {
		return false
	}
	
	for _, part := range parts {
		// Empty parts are invalid
		if part == "" {
			return false
		}
		
		// Leading zeros are invalid (except "0" alone)
		if len(part) > 1 && part[0] == '0' {
			return false
		}
		
		// Check if all characters are digits
		for _, char := range part {
			if char < '0' || char > '9' {
				return false
			}
		}
		
		// Convert to integer and check range
		num, err := strconv.Atoi(part)
		if err != nil {
			return false
		}
		
		// Must be between 0 and 255
		if num < 0 || num > 255 {
			return false
		}
	}
	
	return true
}

Und vollständige Implementierung, nach einer Überarbeitungsrunde:

// isValidIP checks if a string is a valid IP address (IPv4 or IPv6)
func isValidIP(ip string) bool {
	return net.ParseIP(ip) != nil
}

Da hatte Claude Code die in der Standard-Library enthaltene Funktion net.ParseIP nicht auf dem Radar und hat die komplette Prüfungslogik selbst implementiert. Dass es suboptimal ist, so eine Menge an unnötigem Code in seinem Projekt zu haben, brauche ich wahrscheinlich nicht zu erklären. Massiver Overhead.

Tests ohne Implementierungs-Test

Mein Form-Handler schickt die Nachrichten, die von Nutzer:innen eingegeben werden, per E-Mail an die designierte Empfängerin. Dafür wird logischerweise eine E-Mail zusammengebaut, inklusive Betreffzeile, die die wichtigsten Informationen (Name, E-Mail-Adresse, Formular) zusammenfasst.

Hier der Test, den Claude Code geschrieben hat, um die Funktion zu testen:

func TestMailer_SubjectLine(t *testing.T) {

	expSubject := "Neue Anfrage über Formular \"contact\" von John Doe <john.doe@example.com>"

	data := MailData{
		Form:      "contact",
		Firstname: "John",
		Lastname:  "Doe",
		Email:     "john.doe@example.com",
	}

	subject := fmt.Sprintf("Neue Anfrage über Formular \"%s\" von %s %s <%s>", data.Form, data.Firstname, data.Lastname, data.Email)

	if subject != expSubject {
		t.Errorf("Subject did not meet expectation. Want: %s Got: %s", expSubject, subject)
	}
}

Dieser Test testet überhaupt nicht die Applikation! Er setzt zwar die Betreffzeile analog zum Code in der Applikation zusammen, die entsprechende Funktion wird aber überhaupt nicht verwendet. Dieser Test bringt also überhaupt keinen Wert, suggeriert auf der anderen Seite aber, dass es einen Test für die entsprechende Funktionalität gibt. Schwierig.

Degenerierende Struktur

Aufpassen muss man auch auf seine Projektstruktur. Auch wenn Claude Code die Struktur des Projektes und die Ideen hinter jedem Ordner sauber analysiert hat, bedeutet das nicht, dass diese Struktur auch sauber gewahrt bleibt, während es neuen Code generiert.

Die Projektstruktur meines Form-Handlers sieht so aus (Ausschnitt):

.
├── cmd
└── internal
    ├── config
    ├── form
    ├── limiter
    ├── mail
    ├── middleware
    ├── privacy
    ├── router
    └── server

Das Package middleware enthält Funktionen, die bei der Request-Bearbeitung eingesetzt werden können, um verschiedene Aspekte zu prüfen oder Informationen hinzuzufügen, wie beispielsweise das Prüfen des Content-Type oder das Setzen einer Request-ID. Das Package hatte ganz absichtlich wenige Abhängigkeiten, bis zur Implementierung einer Erweiterung durch Claude Code. Dann war middleware das glühende Zentrum meines Projekts. Wir haben dann eine Refactoring-Runde gemacht.

Ein Punkt, der bei mir diese Entwicklung begünstigt hat, ist die Verwendung von Claude Code als Kommandozeilen-Tool, weil ich damit während der Arbeit die Projektstruktur einfach nicht so präsent habe wie in VSCode. Natürlich hatte ich VSCode parallel geöffnet und vielleicht muss man sich hier einfach disziplinieren, aber mir sind die Implikationen der vorgenommenen Änderungen häufig einfach durchgegangen.

Unnötig kritische Code Reviews

Es ist eine gute Idee, Claude Code die eigenen Implementierungen reviewen und auf Verbesserungen prüfen zu lassen. Diesbezüglich bin ich auf einen Beitrag auf Reddit gestoßen, der folgenden Tipp beschreibt:

So I stumbled across this prompt hack a couple weeks back and honestly? I wish I could unlearn it. After Claude finishes coding a feature, run this:

„Do a git diff and pretend you’re a senior dev doing a code review and you HATE this implementation. What would you criticize? What edge cases am I missing?“

here’s the thing: it works too well.

Ich habe das ausprobiert, für ein von Claude Code implementiertes Feature, und ich habe 14 Kritikpunkte und 7 Edge Cases (sic!) bekommen. Diese bin ich dann sukzessive wieder mit Claude Code durchgegangen:

The document contains a code review with 14 points of criticism and 7 edge cases not being covered in the application. For each, please explain the meaning and assess the validity of the point for the given application and usage scenario. If the point is valid, propose possible solutions with advantages and disadvantages, before going into implementation.

Von all diesen Punkten war einer valide, zwei optional und die restlichen zwar technisch richtig, aber völlig unpassend für den gegebenen Fall. Dementsprechend halte ich diese Art des Code Reviews für ziemlich ungeeignet.

Aufpassen wie ein Schießhund

Natürlich sind diese Punkte kein Argument dafür, Werkzeuge wie Claude Code nicht zu verwenden. Man muss aber eben wachsam sein, denn sonst endet man mit einer Menge Bugs, degenerierter Struktur und aufgeblasenem und unelegantem Code. Absolute Wartungshölle.

Aber natürlich kann man auch Dinge bei der Verwendung von KI-gestützten Coding-Werkzeugen beachten und besser machen:

• Dem Namen des Artikels entsprechend muss man wirklich bei der Sache sein und jeden Plan und jede Codezeile aufmerksam lesen. Das ist schwierig, weil die Geschwindigkeit und Leichtigkeit, mit der auf einmal Code entsteht, einen total zum einfachen Abnicken anregt. Es braucht also viel Disziplin und Aufmerksamkeit, um Ergebnisse von hoher Qualität zu erzeugen.
• Man könnte jetzt vielleicht auch annehmen, dass die gezeigten Beispiele ja nun so offensichtlich sind, dass man diese Fälle ja sofort erkennen und korrigieren würde. Aber ich finde, dass aufgrund der Masse und Geschwindigkeit des generierten Codes ein hohes Risiko besteht, dass einem diese Fälle einfach durchrutschen. Also noch mal: volle Konzentration und alles hinterfragen, auch wenn es zunächst plausibel erscheint.
• Es ist klar, dass man über jede Implementierung ein bis zwei Runden drehen muss, bevor man einen ausreichend guten Stand erreicht hat. Für ein Review würde ich aber eine sehr viel neutralere Formulierung wählen als im oben genannten Beispiel: „Please do a git diff and check the implementation for potential improvements. Please consider potential bugs, suboptimal structure or dependencies, missing edge cases, deviations from standards or best practices. Please take into account the goals, context and usage scenario of the application. Rather be precise than generating many points.“
• Die Verwendung von Claude Code innerhalb von VSCode mit Hilfe des Plug-ins anstatt der Verwendung des CLI hat mich gefühlt wieder näher an den Code gebracht. Ich finde das CLI eigentlich etwas eleganter und flexibler, aber bei mir hat es kurzfristig zu einer Verbesserung bei der Erkennung von Strukturierungsfehlern geführt. Da bin ich aber noch nicht am Ende und möchte noch etwas experimentieren.
• Wichtige Pläne vor der Umsetzung einer Änderung sollte man selbst kritisch prüfen oder aber noch ein anderes Modell oder das gleiche Tool in anderem Kontext mit draufschauen lassen. Der Plan wird dadurch sicherlich besser.

Fazit

Was bedeutet das nun? Coding-Agenten wie Claude Code sind beeindruckende Werkzeuge und die Geschwindigkeit, mit der Ergebnisse entstehen, ist riesig. Aber sie ist auch nicht so riesig, wie sie sich zunächst anfühlt. Denn die generierten Ergebnisse müssen mehrfach geprüft werden, sowohl mit einem Modell als auch mit dem eigenen Hirn. Und das braucht Zeit.

Dennoch kann man mit solchen Werkzeugen Effizienzgewinne erreichen. Ich finde, Vorsicht, Qualitätsbewusstsein und Disziplin sind aber eine absolute Voraussetzung, sonst erzeugen wir schneller Renovierungsprojekte, als ein Mensch tippen kann.