Seit der Veröffentlichung von Claude Sonnet 4.5 hat sich die Arbeit mit KI-gestützten Programmiertools noch einmal deutlich verbessert. Als Softwareentwickler bei 42ways setze ich Claude seit etwas über einem Monat regelmäßig für verschiedenste Programmieraufgaben ein – von kleinen Skripten bis hin zu komplexeren Komponenten. In diesem Artikel möchte ich meine Erfahrungen teilen: Was funktioniert hervorragend, wo sind die Grenzen, und welche Best Practices haben sich in der Praxis bewährt?

Die Stärken: Wo Claude wirklich überzeugt

Überraschend sauberer Code

Eines vorweg: Claude Sonnet 4.5 produziert größtenteils lauffähigen und gut strukturierten Code. Das klingt selbstverständlich, ist es aber nicht. Viele frühere KI-Modelle neigten zu unstrukturiertem Code mit langen Funktionen, kryptischen Variablennamen und inkonsistentem Stil.

Claude hingegen zeigt in dieser Hinsicht bemerkenswerte Qualität:

  • Objektorientierung: Sinnvoller Einsatz von Klassen, wo es angebracht ist
  • Methodenlänge: Funktionen bleiben überschaubar und fokussiert
  • Naming: Variablen und Funktionen erhalten aussagekräftige Namen
  • Best Practices: Das Modell hält sich an Konventionen der jeweiligen Programmiersprache

Fallbeispiel: Custom Chunking für RAG-Pipeline

Ein konkretes Beispiel aus unserer Arbeit: Wir entwickelten eine Custom-Chunking-Strategie für die Inhalte unserer E-Learning-Plattform LernCULtur, um diese für eine RAG-Pipeline (Resource Augmented Generation) aufzubereiten.

Die Anforderungen waren:

  1. Semantische Chunks erstellen: Inhalte sollen nach „Kapiteln” aufgeteilt werden
  2. HTML bereinigen: Konvertierung zu Markdown, Entfernung überflüssiger Links und Bilder (Token-Optimierung)
  3. Metadaten anreichern: Chunks sollten mit Informationen aus unserer RDF-Struktur versehen werden (Content-ID, Links, Backlinks, Content-Area)
  4. JSON-Export: Strukturierte Darstellung für die Weiterverarbeitung

Claude entwickelte hier eine Lösung, die funktional und gut wartbar war. Die Verwendung geeigneter Libraries (BeautifulSoup, markdownify, rdflib) erfolgte ohne explizite Vorgabe, und die Code-Struktur war nachvollziehbar.

Der Vorteil für uns: Die Chunks sind nun deutlich besser durchsuchbar (auch für Vektorsuche), und die Metadaten ermöglichen es, dem LLM erweiterten Kontext bereitzustellen.

Kluge Library-Auswahl

Claude trifft häufig sinnvolle Entscheidungen bei der Auswahl von Bibliotheken. Für das oben genannte Beispiel wählte das Modell ohne explizite Anweisung passende Python-Packages aus.

Best Practice: Trotz der meist guten Auswahl empfehle ich, sich mehrere Optionen vorschlagen zu lassen, diese selbst zu verifizieren und dann eine fundierte Entscheidung zu treffen. Besonders bei weniger bekannten Libraries oder speziellen Anforderungen (z. B. Lizenzmodelle, Performance-Charakteristika) sollte man nicht blind vertrauen.

Die Schwächen: Wo menschliche Steuerung unverzichtbar ist

So beeindruckend die Stärken sind – ohne aktive Steuerung durch einen erfahrenen Entwickler entstehen schnell Probleme.

Problem 1: Alles-in-einem-File-Mentalität

Claude neigt dazu, möglichst viel Code in einem einzigen File unterzubringen. Das mag für Prototypen oder kleine Skripte sinnvoll sein, führt aber bei größeren Projekten zu unübersichtlichem Code.

Problem 2: File-Versioning statt Refactoring

Ein besonders interessantes Verhalten: Beim Hinzufügen neuer Features erstellt Claude oft neue Versionen von Files, anstatt bestehende zu erweitern. Das Resultat:

  • Redundante Dateien wie poc_chunk_builder.py, chunk_builder_v2.py, advanced_chunk_builder.py
  • Der Code bleibt zwar meist DRY (Don’t Repeat Yourself), Importe werden oft aus Vorgängerversionen übernommen
  • Für menschliche Entwickler entsteht Verwirrung, da alte Files noch vorhanden sind und unklar ist, welche Version aktuell ist

Beispiel aus unserem Projekt: Die ursprüngliche poc_chunk_builder.py stellte Importe für spätere, erweiterte ChunkBuilder bereit – eine Struktur, die für das Modell logisch war, für uns aber schwer nachvollziehbar.

Lösung: Projektstruktur früh vorgeben! Definieren Sie klare src-Verzeichnisse, Package-Strukturen und Modul-Aufteilungen. Lassen Sie Claude dann Refactorings durchführen oder prüfen – anschließend hält sich das Modell meist daran.

Problem 3: Naive Algorithmen

Bei komplexeren Datenstrukturen oder Algorithmen wählt Claude manchmal naive Implementierungen.

Konkretes Beispiel: Beim Parsen von RDF-Reifications und dem Finden von Backlinks entstand eine O(n²)-Implementierung – bei größeren Datenmengen ein Performance-Killer.

Die gute Nachricht: Ein einfacher Hinweis auf das Problem genügte, und Claude lieferte eine performante Lösung mit geeigneten Datenstrukturen.

Fazit: Code-Review durch den menschlichen Entwickler bleibt essentiell, besonders bei Performance-kritischen Komponenten!

Problem 4: Tests die durchlaufen, aber nichts testen

Ein besonders tückisches Problem zeigt sich beim automatischen Generieren von Tests. Claude ist durchaus in der Lage, Test-Code zu schreiben – das Resultat läuft auch meistens fehlerfrei durch. Aber: Die entscheidende Frage ist, was diese Tests eigentlich prüfen.

Das Problem in der Praxis:

Claude neigt dazu, Tests zu erstellen, die primär darauf ausgelegt sind, erfolgreich durchzulaufen, anstatt die eigentliche Funktionalität kritisch zu hinterfragen. Das Resultat sind Tests, die:

  • Happy-Path-Szenarien abdecken, aber Edge Cases ignorieren
  • Oberflächliche Assertions verwenden (assert result is not None statt konkreter Wertprüfungen)
  • Mocks und Stubs so konfigurieren, dass sie immer zum gewünschten Ergebnis führen
  • Fehlerhafte Logik nicht aufdecken, weil die Tests die gleichen Annahmen wie der Code treffen

Konkretes Beispiel aus unserem Chunking-Projekt:

Claude generierte Tests für die Markdown-Konvertierung, die prüften, ob die Funktion eine Ausgabe erzeugt – aber nicht, ob diese Ausgabe korrekt ist. Ein Test wie dieser:

def test_html_to_markdown():
    html = "<p>Test</p>"
    result = convert_to_markdown(html)
    assert len(result) > 0  # Test läuft durch, prüft aber nichts Sinnvolles!

Das Problem: Der Test schlägt nur fehl, wenn die Funktion gar keine Ausgabe liefert. Ob die Konvertierung korrekt ist, wird nicht geprüft.

Besser wäre:

def test_html_to_markdown():
    html = "<p>Test</p>"
    result = convert_to_markdown(html)
    assert result == "Test\n"  # Prüft konkret das erwartete Ergebnis

Weitere typische Probleme:

  1. Fehlende Negative Tests: Claude generiert selten Tests, die prüfen, ob falsche Eingaben korrekt abgelehnt werden
  2. Unzureichende Edge-Case-Abdeckung: Grenzwerte, leere Eingaben, Null-Pointer – oft nicht getestet
  3. Zu breite Exception-Catches: except Exception: statt spezifischer Exceptions
  4. Fehlende Integration-Tests: Der Fokus liegt oft auf Unit-Tests, Zusammenspiel von Komponenten wird vernachlässigt

Best Practice für Tests mit Claude:

  1. Explizit nach Test-Szenarien fragen: “Erstelle Tests für Happy Path, Edge Cases und Fehlerbehandlung”
  2. Test-Reviews durchführen: Prüfen Sie jeden generierten Test kritisch – testet er wirklich das Richtige?
  3. Konkrete Erwartungswerte vorgeben: Beschreiben Sie genau, was ein Test prüfen soll
  4. Code Coverage als Indikator nutzen: Aber nicht als alleiniges Qualitätskriterium
  5. TDD-Ansatz umkehren: Lassen Sie Claude die Tests vor dem Code schreiben – das führt oft zu durchdachteren Tests

Fazit: Tests von Claude sind ein guter Startpunkt, ersetzen aber nicht das kritische Denken eines Entwicklers. Die wichtigste Frage bleibt: “Würde dieser Test einen Bug finden?” Wenn die Antwort unsicher ist, muss der Test überarbeitet werden.

Best Practices für die Arbeit mit Claude

Aus unserer Projekterfahrung haben sich folgende Praktiken bewährt:

1. Statusdokumentation für längere Projekte

Bei komplexeren Aufgaben, die sich über mehrere Sessions erstrecken, ist eine Statusdokumentation Gold wert (im wahrsten Sinne des Wortes, je nach Subscription kann echtes Geld gespart werden)

Warum?

  • Token-Limits können erreicht werden
  • Der Kontext muss komprimiert werden
  • Sessions werden abgebrochen (oder müssen unterbrochen werden)

Eine gut strukturierte Dokumentation ermöglicht es, Claude schnell (und token-günstig!) wieder auf den aktuellen Stand zu bringen.

Best Practice: Lassen Sie die Dokumentation in Formaten erstellen, die Claude gut verwalten kann:

  • JSON mit jq-Tool für strukturierte Daten
  • YAML für übersichtliche Konfigurationen
  • Markdown mit klaren Abschnitten für Projektübersichten

2. Regelmäßige “Frisch-Checks”

Ein ungewöhnlicher, aber hilfreicher Trick: Lassen Sie gelegentlich einen “frischen” Claude-Agent (neue Session) den Projektstatus prüfen.

Ziel: Unklar dokumentierte Stellen identifizieren, die für ein neues Modell (oder einen neuen Entwickler) schwer nachvollziehbar sind.

Anschließend können Sie zusätzliche Dokumentation erstellen lassen – z. B. in einer CLAUDE.md oder AI_CONTEXT.md.

3. Projektstruktur von Anfang an definieren

Wie bereits erwähnt: Geben Sie die Projektstruktur früh vor! Ein klares Layout verhindert das File-Versioning-Problem und sorgt für Konsistenz.

Beispiel-Struktur:

project/
├── src/
│   ├── chunking/
│   │   ├── __init__.py
│   │   ├── parser.py
│   │   └── builder.py
│   ├── metadata/
│   │   └── rdf_handler.py
│   └── utils/
│       └── markdown_converter.py
├── tests/
├── docs/
└── requirements.txt

4. Iterative Verbesserung durch Feedback

Claude reagiert sehr gut auf spezifisches Feedback:

  • “Diese Funktion ist zu lang, bitte in kleinere Funktionen aufteilen”
  • “Das ist O(n²), können wir das optimieren?”
  • “Bitte in ein separates Modul auslagern”

Präzise Anweisungen führen fast immer zu guten Ergebnissen.

Fazit

Die Arbeit mit Claude als Coding-Partner hat unsere Produktivität bei 42ways spürbar erhöht. Besonders bei klar definierten Aufgaben, Boilerplate-Code und Refactorings ist das Modell eine enorme Hilfe.

Gleichzeitig zeigt unsere Erfahrung: KI ersetzt keine erfahrenen Entwickler, sondern ergänzt sie. Architektur-Entscheidungen, Performance-Optimierungen, Code-Reviews und strategische Projektentscheidungen bleiben Aufgaben, die menschliche Expertise erfordern.

Wer Claude (oder andere LLMs) erfolgreich in der Softwareentwicklung einsetzen möchte, sollte:

  • Klare Strukturen vorgeben
  • Aktiv steuern und reviewen
  • Konkrete, iterative Anweisungen geben
  • Dokumentation pflegen
  • Kritisch hinterfragen

Mit dieser Herangehensweise wird aus einem vielversprechenden Tool ein echter Produktivitätsgewinn.

Haben Sie ähnliche Erfahrungen gemacht? Oder nutzen Sie Claude/andere LLMs auf ganz andere Weise? Kontaktieren Sie uns – wir freuen uns auf den Austausch!

You May Also Enjoy