Working with AI: Ein konkretes Beispiel aus der Praxis

Markus Seyfferth

Autor Dr. Web

1. Juli 2026

4 Min. Lesezeit

KI im Coding-Alltag ist kein Hype-Thema mehr, sondern eine Werkzeugfrage. Carson Gross, der Entwickler hinter dem Open-Source-Projekt htmx, hat jetzt einen nüchternen Erfahrungsbericht veröffentlicht, der zeigt: Der Nutzen von KI-Assistenten hängt radikal davon ab, welche Aufgabe man ihnen gibt.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Hand aufs Herz: Die meisten Produktivitätsversprechen rund um KI-Coding-Tools klingen verlockend, passen aber selten zum Projektalltag. Das Beispiel von Gross liefert endlich eine ehrliche Gegenprobe.

Das Wichtigste in Kürze

KI findet Ursachen von Bugs schnell – schlägt aber oft zu schmale oder systemfremde Fixes vor.
GitClear-Daten (211 Mio. Codezeilen) belegen: KI-generierter Code erhöht Copy-Paste-Anteile und drückt die Refactoring-Aktivität auf unter 10 %.
EU AI Act Art. 4 verpflichtet seit Februar 2025 zur nachweisbaren KI-Kompetenz – auch für Entwicklerteams.
Drei konkrete To-dos für DACH-Teams am Ende des Artikels.

Was kann KI, was nicht?

Roboterarm bearbeitet Holz mit Stemmeisen — Gross behebt mit Claude’s Hilfe einen Parsing-Bug in hyperscript, verursacht durch zu aggressive Refaktorierung eines Schlüsselworts in zwei Kontexten

Gross hat an einem Parsing-Bug in hyperscript gearbeitet, einer ungewöhnlichen Skriptsprache, die bewusst viele Parser-Konventionen bricht. Claude hat ihm geholfen, die Ursache des Regressionsfehlers in Minuten zu lokalisieren: Eine zu aggressive Refaktorierung hatte ein Schlüsselwort unbeabsichtigt in zwei grammatikalischen Kontexten gleichzeitig bindend gemacht. Genau darin liegt die Stärke von LLMs: Ursachenanalyse in gut dokumentiertem, generisch strukturiertem Code läuft schnell.

Beim Lösen des Problems hat sich das Bild gedreht. Claude hat zunächst einen Hack vorgeschlagen, der nur den gemeldeten Einzelfall abgedeckt hat, nicht aber den allgemeinen Fall. Der zweite Vorschlag war architektonisch interessanter, aber unnötig komplex. Keiner der Fixes hat die eigenwilligen Designentscheidungen berücksichtigt, die das hyperscript-Projekt absichtlich trägt. Gross hat beide abgelehnt und die eigentliche Lösung selbst entwickelt.

Kein Einzelfall ist das. LLMs sind statistische Mustererkennungsmaschinen, trainiert auf Milliarden generischer Codezeilen. Für Boilerplate, Regex, Dokumentation und Unit-Tests liefern die Modelle verlässliche Ergebnisse. Sobald ein System eigene Invarianten, eine bewusste Designgeschichte oder unkonventionelle Architektur trägt, fehlt dem Modell der Kontext. Das Ergebnis: Fixes, die das Symptom lösen, das System aber langfristig schwächen. Wer KI-generierten Code kritiklos übernimmt, trägt das volle Architekturrisiko allein. Ähnliche Muster zeigt auch der Vergleich von agentic Coding-Tools wie in der Antigravity-2.0-Analyse auf DrWeb.

Sorcerer’s Apprentice: Der blinde Fleck der KI

Ein Roboterarm malt mit einem Pinsel auf eine Staffelei — LLM-Assistenten verschärfen Code-Qualitätsprobleme: Geklonte Codezeilen stiegen von 8,3 auf 12,3 %, Refactoring sank von 25 auf unter 10 %

Gross nennt das Sorcerer’s Apprentice-Problem: Der LLM-Assistent löst, was sichtbar ist, kennt aber nicht, was außerhalb des Kontextfensters liegt. GitClear-Forschungsdaten aus 211 Millionen Codezeilen (2020 bis 2024) machen das messbar: Der Anteil geklonter und kopierter Zeilen ist von 8,3 auf 12,3 % gestiegen, gleichzeitig ist die Refactoring-Aktivität von 25 % auf unter 10 % gesunken. Dahinter steckt ein strukturelles Wartbarkeitsproblem, das sich nicht im Sprint zeigt, sondern nach zwei Jahren als Technische Schuld.

Die Forschungslage bestätigt das Muster. Eine Anthropic-Studie mit 52 Entwicklern hat gezeigt, dass die KI-Gruppe beim Debugging-Test 17 Prozentpunkte schlechter abgeschnitten hat als die Gruppe ohne KI-Assistenz. Laut Stack Overflow Developer Survey 2025 (49.000 Befragte) berichten 45 % der Befragten, dass das Debuggen von KI-generiertem Code mehr Zeit kostet als das Schreiben von Hand. Das Gross’sche Review-First-Modell, bei dem die KI generiert und der Mensch entscheidet, deckt sich dabei exakt mit dem Mehrheitsbefund der Forschung zu KI-augmentierter Entwicklung.

KI ist ein mächtiges Werkzeug, aber kein Architekt. Wer die Kontrolle über die Designgeschichte seines Systems abgibt, zahlt den Preis beim nächsten Refactoring.

— Michael Dobler, Herausgeber Dr. Web

Was bedeutet das für DACH-Entwicklerteams?

Geöffnete Matrjoschka mit Bauarbeiter-Minifigur und — Seit 2. Februar 2025 müssen Unternehmen KI-Kompetenzen für Mitarbeitende nachweisen und KI-Systeme datenschutzkonform dokumentieren

Seit dem 2. Februar 2025 sind Unternehmen nach EU AI Act Art. 4 verpflichtet, nachweisbar KI-Kompetenz für alle Mitarbeitenden sicherzustellen, die mit KI-Systemen arbeiten. Fehlende Dokumentation gilt bereits als Pflichtverletzung. Zusätzlich greift DSGVO Art. 25 (Privacy by Design) und Art. 32 (technische Sicherheitsmaßnahmen) auch für KI-generierten Code: Die Haftung bleibt beim Betreiber, unabhängig davon, ob ein LLM den Code geschrieben hat.

Drei konkrete To-dos für DACH-Entscheider:

Aufgabentyp differenzieren: Boilerplate, Tests und Dokumentation für KI freigeben. Architekturentscheidungen und sicherheitsrelevanter Code bleiben menschlich geführt.
Review-Prozesse formalisieren: KI-generierter Code braucht eine dokumentierte Prüfinstanz, damit DSGVO-Pflichten erfüllt und Haftungsrisiken begrenzt bleiben.
Erwartungsmanagement betreiben: Die von Vendoren versprochenen Produktivitätsgewinne treffen nur für generische Tasks zu. Für domänenspezifische Codepflege sind sie nicht übertragbar.

Wer mehr über den Einsatz von LLMs in Unternehmen erfahren möchte, findet im LLMs-Ratgeber auf DrWeb eine strukturierte Übersicht. Für den Einstieg in konkrete Tools lohnt sich auch ein Blick auf Claude Cowork im Funktionsvergleich sowie auf die Erklärung zu MCP-Servern, die zunehmend als Brücke zwischen KI-Agenten und Entwicklungsumgebungen dienen. Das Gross-Beispiel zeigt: Das Werkzeug ist stark, aber nur in den Händen, die das System kennen.