Rechtsklick, Seitenquelltext anzeigen. Mehr braucht es nicht, um zu sehen, wie eine Website gebaut ist. Bei einer News-Seite, die wir uns neulich angesehen haben, stand dort mehr als erwartet: rund 70 Kommentare in HTML, JavaScript und CSS, ausgeliefert an jeden Besucher. Die meisten davon waren doppelt vorhanden, weil das Framework den Seiteninhalt ein zweites Mal als Datenpaket mitschickt.
Alle Indizien sprechen dafür, dass die Plattform dahinter mit einem Claude-Agenten gebaut wird: der einheitliche, erzählende Kommentarstil, die ausführliche Begründung jeder Entscheidung und das Fehlen jeder Regel, was davon an den Browser gehen darf. Das macht den Quelltext zu einem seltenen Einblick: Die Kommentare dokumentieren nicht nur, was der Code tut, sondern auch, welche Probleme es gab, wie sie gelöst wurden und was dabei durchgerutscht ist. Genau daran lässt sich zeigen, was ein KI-Agent gut baut, was Menschen besser machen und was ein klares NoGo ist.
Warum wir auf Claude tippen und nicht etwa auf ein Werkzeug von OpenAI? Weil wir selbst täglich mit Claude arbeiten und seine Handschrift kennen. Kommentare in ganzen Sätzen, die das Warum erzählen, Rückblicke wie „im ersten Versuch wurde dadurch …“, ein erklärender Block über fast jeder Funktion und eine Sprachkonvention, die sich ohne Ausnahme durch den ganzen Code zieht: So sieht Code aus, wenn Claude ihn schreibt und niemand die Kommentare danach sortiert. Code aus OpenAI-Werkzeugen liest sich in unserer Erfahrung anders. Beweisen lässt sich das von außen nicht, aber die Struktur spricht eine deutliche Sprache.
Und es zeigt etwas Grundsätzlicheres: Geliefert wird, ganz gleich, was im Code liegt. Das ist kein Vorwurf an einzelne Entwickler, sondern eine Warnung vor einer Marktentwicklung, die wir gerade überall beobachten.
Der Fall ist bewusst anonymisiert. Wir nennen weder Unternehmen noch Domain, Kunden oder Personen und geben die Kommentare nur sinngemäß wieder. Wörtliche Zitate wären über eine Suchmaschine auffindbar und würden die Anonymisierung aufheben. Es geht um die Muster, nicht um den Betreiber.
Was im Quelltext stand
Die Seite ist eine Next.js-Anwendung auf einer selbst entwickelten, mandantenfähigen Website- und Shop-Plattform. Neben dem eigentlichen Inhalt lieferte sie im Kopfbereich mehrere große Inline-Skripte aus, jedes davon ausführlich kommentiert:
Einen Wächter für Hydration-Fehler, der den vom Server gelieferten DOM mit dem Stand im Browser vergleicht und Abweichungen an einen eigenen Endpunkt meldet.
Einen Protokollierer, der für zehn Sekunden die DOM-Methoden appendChild, insertBefore, removeChild und replaceChild im Prototyp überschreibt, um fremde Änderungen am Dokument mitzuschreiben.
Einen Reparaturmechanismus für Fehler nach einem Deployment, der console.error überschreibt, auf Meldungen wie ChunkLoadError reagiert und die Seite mit einem Zeitstempel in der Adresse neu lädt.
Das Skript der News-Seite selbst, das alle Beiträge per Schnittstelle im Browser nachlädt, filtert und durchsuchbar macht.
Die Kommentare dazu sind auffallend einheitlich: ganze Sätze, Deutsch ohne Umlaute, jede Entscheidung begründet, oft mit einer kleinen Vorgeschichte, warum der erste Ansatz nicht funktionierte.
Was der KI-Agent gut gebaut hat
Kommentare, die das Warum erklären
Die meisten Entwickler kommentieren zu wenig, und wenn, dann das Was. Hier ist es umgekehrt. Ein Beispiel sinngemäß: Ein normales Neuladen der Seite reiche nach einem Deployment nicht, weil der Browser die alte Fassung aus seinem eigenen Zustand zurückgebe. Eine Adresse, die es noch nie gab, könne dagegen kein Zwischenspeicher beantworten. Deshalb der Zeitstempel, der nach dem Laden sofort wieder aus der Adresszeile entfernt wird.
Wer diesen Code in einem Jahr anfasst, versteht sofort, warum er so aussieht. Das ist eine echte Stärke von KI-Agenten: Sie haben die Begründung im Kontext und schreiben sie ohne Widerwillen auf. Im Repository ist das wertvoll. Wo es falsch ist, zeigt der Abschnitt zu den NoGos.
Defensive Grenzen für Laufzeit und Speicher
Jedes der Skripte begrenzt sich selbst. Der DOM-Vergleich bricht nach einer festen Zahl von Knoten und einer maximalen Tiefe ab. Der Protokollierer schaltet sich nach zehn Sekunden ab, die Beobachtung nach einer halben Minute. Alte Einträge werden nach fünf Sekunden verworfen, weil sie sonst ganze Teilbäume im Speicher halten. Alles steckt in try/catch, damit ein Fehler im Diagnosecode nie die Seite selbst mitnimmt.
Das ist sauberes Handwerk, und es entsteht bei einem Agenten fast nebenbei. Man muss es nicht einfordern, man muss es nur nicht wegoptimieren.
Werkzeuge in kurzer Zeit
Ein Hydration-Reporter, der die erste Abweichung zwischen Server- und Browserstand findet und samt Pfad meldet, ist kein kleines Projekt. Von Hand wäre das ein Tag Arbeit. Mit einem Agenten ist es eine Sitzung. Auch viele Details stimmen: Beitragsbilder bekommen den Titel als Alternativtext statt eines leeren alt-Attributs, der Hinweis nach dem Neuladen ist als role="status" ausgezeichnet, die Merkmalsfilter funktionieren ohne JavaScript, weil jede Auswahl ein Link ist. Die Security-Header der Seite sind ebenfalls vorbildlich, mit Content-Security-Policy samt Nonce und HSTS.
Was Menschen besser machen
Ursachen statt Symptome
Der Hydration-Wächter und der Neulade-Mechanismus sind beide Antworten auf Symptome. Sie machen Fehler sichtbar oder überdecken sie, aber keiner der beiden verhindert sie. Die eigentlichen Fragen wären: Warum rendert der Server etwas anderes als der Browser? Und warum fragt ein Browser nach einem Deployment nach Code, den es nicht mehr gibt?
Für das zweite Problem gibt es bekannte Lösungen, etwa ältere Build-Dateien eine Zeit lang weiter auszuliefern oder die Versionsverschiebung zwischen Client und Server gezielt abzufangen. Ein Agent, der mit einer Fehlermeldung beauftragt wird, baut bevorzugt eine Reparatur genau für diese Meldung. Den Schritt zurück, der fragt, ob man das Problem an der Wurzel verhindern kann, macht in der Regel ein Mensch. Das deckt sich mit dem, was wir in unserem Vergleich von KI-Code und menschlichem Review beschrieben haben.
Plattformlücken schließen statt umgehen
Ein Kommentar im News-Skript erklärt, der eingebaute Repeater der Plattform liefere auf dieser Instanz keine Beiträge und könne außerdem nicht nachladen. Deshalb hole die Seite ihre Daten direkt von der Schnittstelle. Aus Sicht des Agenten ist das eine vernünftige Lösung für die Aufgabe, die er bekommen hat. Aus Sicht der Plattform ist es der Anfang einer Parallelwelt: Die eigene Bausteinlogik wird nicht repariert, sondern umgangen, und die nächste Seite mit demselben Problem bekommt ihren eigenen Umweg.
Ob ein Fehler im Fundament behoben oder lokal umschifft wird, ist eine Architekturentscheidung. Die muss ein Mensch treffen, weil nur er den Überblick über alle Stellen hat, die das Fundament nutzen.
Prüfen, ob das Ergebnis hält, was der Kommentar verspricht
Das ist der folgenreichste Befund. Über einem leeren Container steht sinngemäß: Hier stehen die serverseitig gerenderten Beiträge. Das Skript baut daraus das Layout, und fällt es aus, bleibt eine schlichte, benutzbare Liste stehen. Im ausgelieferten HTML war der Container leer. Auf der gesamten Seite fand sich kein einziger Link auf einen Beitrag.
Für Besucher mit JavaScript fällt das nicht auf, weil das Skript die Beiträge nachlädt. Für Suchmaschinen und KI-Crawler, die kein JavaScript ausführen, ist es eine News-Seite ohne News. Der Kommentar beschreibt die Absicht, nicht den Zustand. Ein Agent schreibt beides mit derselben Überzeugung. Nur ein Blick in den tatsächlich ausgelieferten Quelltext zeigt den Unterschied, und diesen Blick muss jemand bewusst tun.
Ein Kommentar ist eine Behauptung über den Code, kein Beweis. Bei KI-generiertem Code gilt das besonders: Der Agent dokumentiert seine Absicht vollständig, auch dann, wenn die Umsetzung sie nicht einlöst.
Abwägen, was in Produktion laufen darf
Die Prototypen von DOM-Methoden zu überschreiben und console.error umzubiegen, ist als Diagnose auf einer Entwicklungsumgebung legitim. Auf jeder Seite für jeden Besucher ist es ein Eingriff, der mit jedem Skript eines Drittanbieters kollidieren kann. Ein Agent, der ein Fehlerbild einkreisen soll, greift zum wirksamsten Werkzeug. Ob dieses Werkzeug dauerhaft in Produktion bleiben darf, ist eine Risikoabwägung, die ein Mensch treffen sollte.
Dazu kommt das Gewicht: Die Seite war rund 239 KB groß, davon etwa 143 KB Datenpaket für die Hydration. Weil die Inline-Skripte darin als Text ein zweites Mal stecken, reisen auch alle Kommentare doppelt über die Leitung.
Was ein NoGo ist
Bis hierhin ging es um Qualität. Jetzt geht es um Menschen, die mit dem Code nichts zu tun haben. Im ausgelieferten Quelltext standen:
der Name einer Kundeninstanz mit ihrer Adresse auf der Plattform, samt Fehlergeschichte,
der Vorname einer Nutzerin, bei der nach einem Deployment etwas schiefging,
Ticketnummern aus dem Support, jeweils mit dem Problem dahinter,
interne Namen der Plattform und ihrer Werkzeuge sowie der Endpunkt für Fehlerberichte.
Kein Passwort, kein Schlüssel, kein Alarm eines Secret-Scanners. Und trotzdem liest jeder Besucher mit, welche Kunden die Plattform hat, wer von welchem Fehler betroffen war und wo es gerade hakt. Ein Wettbewerber bekommt daraus Marktwissen, ein Angreifer eine Landkarte. Die Betroffenen haben dem nie zugestimmt.
Warum ein Agent so etwas schreibt
Wer einem Agenten einen Fehler schildert, erzählt eine Geschichte: bei dieser Kundin, auf dieser Instanz, in diesem Ticket. Der Agent schreibt diesen Kontext in den Kommentar, denn er soll ja das Warum festhalten. Ob der Kommentar in einer Datei im Repository bleibt oder in einem Inline-Skript wörtlich an jeden Browser geht, unterscheidet er nicht. Das muss man ihm sagen, mit einer festen Regel. Fehlt sie, fehlt die Grenze. Genau diese Regel fehlte hier.
Dieselbe Logik haben wir bei öffentlichen Repositories mit Produktionsbezug beschrieben: Was im falschen Kontext sichtbar wird, lässt sich nicht zurückholen. Suchmaschinen, Archive und Crawler haben es dann längst gespeichert.
Der eigentliche Warnhinweis: Geliefert wird, egal was im Code liegt
Die Befunde sind kein Einzelfall und kein Skandal. Sie sind das erwartbare Ergebnis eines Marktes, der sich gerade selbst unter Druck setzt. KI-Agenten machen Entwicklung schneller und billiger, und genau das wird zum Problem: Wenn eine Plattform, ein Shop oder eine Funktion in Tagen statt Wochen entsteht, wird der Preis an dieser Geschwindigkeit gemessen. Drei Kräfte wirken dabei zusammen.
Kostendruck: Auftraggeber erwarten, dass KI die Rechnung kleiner macht. Die Stunden, die dabei wegfallen, sind oft genau die, in denen früher jemand den Code gelesen hat.
Zeitdruck: Wenn der Agent in einer Sitzung liefert, wird die Sitzung zum Maßstab. Review, Tests und ein Blick in den ausgelieferten Quelltext passen dann nicht mehr in den Zeitplan.
Unterbietung: Wer günstiger anbietet, gewinnt den Auftrag. Gespart wird dort, wo der Kunde nicht hinsieht, und in den Quelltext sieht kaum ein Kunde.
Das Ergebnis sieht man in diesem Fall: Die Seite funktioniert, der Kunde nimmt ab, die Rechnung geht raus. Dass im Quelltext Namen, Ticketnummern und Geschäftsregeln stehen oder dass Suchmaschinen eine News-Seite ohne News sehen, fällt bei der Abnahme niemandem auf. Es fällt erst auf, wenn es Folgen hat. Der Output leidet, und zwar nicht, weil die Werkzeuge schlecht sind, sondern weil niemand mehr dafür bezahlt wird, ihn zu prüfen.
KI senkt die Kosten für das Schreiben von Code, nicht die Kosten für Verantwortung. Wer nur noch das Schreiben bezahlt, bekommt Code, den niemand gelesen hat.
Für Auftraggeber heißt das: Ein auffällig niedriger Preis für KI-gestützte Entwicklung ist kein Beweis für Effizienz. Fragt nach, wer den Code liest, bevor er live geht, wie getestet wird und wer den ausgelieferten Quelltext prüft. Lautet die Antwort „der Agent“, fehlen gleich mehrere Schritte. Vor allem fehlt die Iteration durch den Menschen: jemand, der das Ergebnis ansieht, zurückgibt, nachschärft und erst dann freigibt.
Für Anbieter heißt das: Über den Preis lässt sich dieser Wettbewerb nicht gewinnen, wenn auf beiden Seiten derselbe Agent arbeitet. Unterscheiden kann man sich nur noch über das, was der Agent nicht leistet: Überblick, Prüfung und Verantwortung. Das gehört sichtbar ins Angebot, auch wenn es das Angebot teurer macht.
Der Unterschied: KI verantwortungsvoll einsetzen
Den Unterschied macht nicht, ob jemand KI nutzt, sondern wie. Bei uns arbeitet der Agent nie ohne Rahmen: mit einem Second Brain, in dem Wissen, Entscheidungen und Erfahrungen aus früheren Projekten liegen, mit festen Regeln pro Projekt, die ihm sagen, was er darf und was nicht, und mit menschlicher Kontrolle vor jedem Schritt, der live geht. Die KI unterstützt uns. Die Verantwortung bleibt bei uns.
Versprechen kann man viel. Wir bleiben bei dem, was wir verstehen. Deshalb bauen wir zum Beispiel kein eigenes CMS von Grund auf, auch wenn ein Agent das heute in wenigen Wochen hinstellen würde. Unser Kosmos dreht sich um Shopify und um die Werkzeuge drumherum, in denen wir uns ständig weiterbilden. Dort kennen wir die Grenzen, die Eigenheiten und die Fehlerbilder, und nur dort können wir die Arbeit des Agenten wirklich prüfen.
Der Selbsttest: Was unser eigener Quelltext verriet
Nach dieser Analyse haben wir dieselbe Prüfung auf nordalux.de angewendet, auf alle Seiten aus der Sitemap, das JavaScript-Bundle und die öffentlichen Tool-Dateien. Kundennamen, Ticketnummern oder Secrets fanden sich nicht.
Gefunden haben wir Kommentare mit Template-Pfaden, die jeden eingebundenen Baustein ankündigten. Logisch, aber nicht notwendig. Verraten haben sie nichts: Sie zeigten nur an, wo eine neue Sektion beginnt, und das erkennt man auch ohne Kommentar an der Struktur der Seite. Dazu kamen weitere Kommentare mit Arbeitsnotizen in den Styles einzelner Seiten.
Die Template-Kommentare entfernt jetzt eine Middleware, bevor das HTML den Server verlässt. Die übrigen Notizen hat unser KI-Agent, der uns bei der Entwicklung unterstützt, so umgestellt, dass sie im Template lesbar bleiben, aber nicht mehr ausgeliefert werden. Wir haben die Änderungen geprüft und freigegeben, ein automatisierter Test stellt sicher, dass nichts davon zurückkommt.
So verhinderst du das in eigenen Projekten
Inline-Skripte in Dateien auslagern, die durch den Build laufen. Ein Minifier entfernt Kommentare zuverlässig, ein Inline-Skript im Template wird dagegen wörtlich ausgeliefert.
Wo Inline-Code nötig ist, Kommentare der Template-Sprache verwenden statt HTML-, CSS- oder JavaScript-Kommentare. Die sind im Repository lesbar, erscheinen aber nie im Browser.
Dem Agenten eine feste Regel mitgeben, etwa in der CLAUDE.md: keine Kunden-, Personen- oder Instanznamen und keine Ticketnummern in Code, der ausgeliefert wird. Die Vorgeschichte gehört in den Commit oder ins Ticket.
Nach jedem Deployment einmal den tatsächlich ausgelieferten Quelltext lesen, nicht den im Editor. Besser noch: einen Test schreiben, der nach bekannten Mustern sucht.
Prüfen, ob die Seite ohne JavaScript noch ihren Inhalt zeigt. Das ist der einfachste Test dafür, ob ein Kommentar über serverseitiges Rendering stimmt.
Fazit
Der Quelltext zeigt einen Agenten, der sorgfältig, defensiv und ungewöhnlich gut dokumentiert arbeitet. Er zeigt aber auch, wo diese Sorgfalt endet: bei der Frage, ob ein Workaround das richtige Mittel ist, ob der Kommentar mit dem ausgelieferten Ergebnis übereinstimmt und ob eine Notiz überhaupt öffentlich sein darf. Das sind keine Programmierfragen, sondern Fragen von Überblick und Verantwortung. Sie bleiben beim Menschen, und sie kosten Zeit, die in einem Markt aus Kostendruck und Unterbietung als Erstes gestrichen wird. Genau davor warnt dieser Beitrag.
Wenn du wissen willst, was dein eigener Quelltext über dein Unternehmen verrät, oder ein KI-gestütztes Projekt vor dem Livegang prüfen lassen möchtest, sprich uns an. Mehr zu unserer Arbeitsweise findest du unter Custom Coding.
Tobias Graeger
Inhaber & Shopify-Entwickler
Tobias leitet alle Projekte persönlich. Mit über 50 abgeschlossenen Shopify-Projekten kennt er die Plattform vom Liquid-Template bis zur API-Integration. Sein Fokus: technisch saubere Lösungen, die mit dem Business mitwachsen.
LinkedInHat dir der Beitrag gefallen?
Ein Klick reicht und wir wissen, welche Themen wir weiter vertiefen sollen.
Feedback konnte gerade nicht gespeichert werden.
Das könnte euch auch interessieren
Weshalb wir fremden Code aufräumen, ohne dass jemand danach fragt
Bei einer ganz anderen Aufgabe stolperten wir über eine Shopify-Section, die Fehler warf, seit sie im Theme lag. Sie funktionierte trotzdem. Wir haben sie in derselben Sitzung neu geschrieben, still und ohne Rechnung. Hier ist der Vorher-Nachher-Vergleich mit allen Befunden.
Weshalb der Hardware-Schlüssel bei OpenAI Pflicht wird
Ab dem 1. September 2026 verlangt OpenAI für alle individuellen Daybreak-Konten einen Hardware-Sicherheitsschlüssel. Was sich dadurch am Login ändert, warum der YubiKey nur ein Weg von mehreren ist und worauf Teilnehmer sich vorbereiten sollten.