Hauptgedanke

Ein mit Claude Code gebautes System zur Wettbewerbsbeobachtung holt die Videos, Artikel und Newsletter ab, übersetzt, klassifiziert, historisiert und aktualisiert sie. Was ein Product Manager stundenlang tat, geschieht ohne ihn. Aber die Arbeit fällt nicht auf null: Sie ändert ihre Natur.

Man muss sagen, was man sucht und was man ausschließt, prüfen, dass das System nicht stillschweigend eine Quelle verpasst hat, nachlesen, was es produziert hat, nach jeder Änderung testen und wieder übernehmen, wenn es schwer danebenliegt — was vorkommt, manchmal direkt nachdem es etwas Brillantes geleistet hat.

Die Bilanz bleibt deutlich positiv, aber sie bemisst sich an der Art der Arbeit ebenso wie an Stunden: Man tauscht eine lange, vorhersehbare Ausführung gegen eine kurze, unregelmäßige Beaufsichtigung.

Ergänzt durch „Qualität gehört denen, die liefern“ (2026-06-03). Dieselbe Verlagerung zeigt sich im Beruf der QA, und dort nimmt sie eine deutlichere Form an. Was wegfällt, ist die repetitive Ausführung: die manuellen Tests, die immer wieder durchgespielt werden, die Regressionen, die bei jeder Lieferung Bildschirm für Bildschirm nachgeprüft werden. Was bleibt, ist die Rahmensetzung — festlegen, was geprüft wird, für welche Risiken, nach welchen Kriterien und mit welchem Automatisierungsgrad. Die Verlagerung ist also nicht nur quantitativ: Sie verändert die Position der Funktion in der Kette, denn die Rahmensetzung muss geschrieben werden, bevor der Code existiert, während die Ausführung erst danach kommen konnte.

Ergänzt durch „Vier Tage vibe coding…“ (2026-07-28). Die Verlagerung nimmt eine dritte Form an, wenn nicht mehr eine Nebenaufgabe delegiert wird, sondern das Bauen selbst. Über hundertachtzig Commits in vier Tagen, ohne eine Zeile zu schreiben: Was bleibt, ist steuern, gegenlesen, testen, korrigieren, entscheiden, neu ansetzen, beobachten, noch einmal erklären. Die Last sinkt nicht, sie ändert ihren Rhythmus — statt einer langen, gleichmäßigen Ausführung eine ständige Beaufsichtigung, getaktet nach der Geschwindigkeit des Werkzeugs. Das ist die Seite, die euphorischen Bilanzen fehlt: Diese Leistungsfähigkeit gibt es nicht umsonst, und wer steuert, wird zugleich Architekt im Tagesgeschäft, Tester, Reviewer und Leitplanke.

Warum das wichtig ist

Das vermeidet zwei spiegelbildliche Fehler bei der Bewertung einer Automatisierung: den Gewinn so zu rechnen, als verschwände die Aufgabe ganz, und zu schließen, sie habe nichts verändert, weil ein Rest bleibt.

Es sagt auch, welche Kompetenz nötig wird: eine Anfrage einrahmen und einen falschen Output erkennen zu können, statt die Aufgabe schnell ausführen zu können.

Nuancen und Grenzen

Die Beaufsichtigung ist unregelmäßig und wird deshalb schlecht eingeschätzt: Wochenlang kostet sie fast nichts, dann sehr viel an dem Tag, an dem ein falscher Output unbemerkt durchgegangen ist und als Grundlage einer Entscheidung gedient hat.

Und sie lässt sich nicht an jemanden delegieren, der die Aufgabe nie von Hand erledigt hat: Eine Wettbewerbsbeobachtung zu erkennen, die das Wesentliche verpasst hat, setzt voraus, dass man weiß, wie eine korrekte aussieht.

Offene Fragen

• An welchen Signalen erkennt man, dass ein automatisierter Output falsch ist, wenn man gerade aufgehört hat, das Material selbst zu erstellen?