Nicht weil KI schlecht ist. Sondern weil Vibe Coding KI falsch nutzt.

Alle reden gerade davon. 22.000 Suchanfragen im Monat allein auf Deutsch bei Google. Y Combinator sagt, 25% ihrer Startups haben Codebases die zu 95% KI-generiert sind. Klingt nach Zukunft.

Ich zeige dir in diesem Newsletter warum das in 3 Monaten scheitert. Und was ich stattdessen mache.

Was ist Vibe Coding?

Andrej Karpathy hat den Begriff geprägt. Der Mitgründer von OpenAI. Seine Definition:

Fully giving in to the vibes.

Was heißt das konkret? Du gibst der KI einen Prompt. Die KI gibt dir Code zurück. Du guckst nicht rein. Du verstehst nicht was passiert. Du lässt es laufen und hoffst dass es funktioniert.

Und wenn es nicht funktioniert? Gibst du den Fehler der KI und hoffst nochmal.

Das fühlt sich produktiv an. Du baust in Stunden was früher Tage gedauert hat. Builder.io beschreibt das in seinem YouTube Video mit:

What feels like productivity.

Klingt gut. Funktioniert halt nicht.

Und ja: Für ein Wochenend-Projekt das du danach löschst, reichen Vibes. Karpathy hat das auch so gemeint. Aber für alles was in Produktion geht, was skalieren soll, was andere Menschen benutzen? Da brauchst du mehr.

Jetzt abonnieren

Warum Vibe Coding scheitert

1. Du wirst schneller, aber schwächer

Hier sind die Daten.

METR hat eine randomisierte kontrollierte Studie gemacht. Mit erfahrenen Entwicklern. Das Ergebnis: Mit KI-Tools waren sie 19% langsamer. Obwohl sie selbst dachten, sie wären schneller.

Lies das nochmal. 19% langsamer. Trotz KI.

CodeRabbit hat KI-generierten Code analysiert. Das Ergebnis: 1,7 mal mehr schwerwiegende Fehler. 2,74 mal mehr Sicherheitslücken. Nicht ein bisschen mehr. Fast dreimal so viele Sicherheitslücken.

Warum? Brian Kernighan hat das vor 50 Jahren erklärt:

Debugging is twice as hard as writing code.

Wenn du den Code nicht selbst schreiben kannst, kannst du ihn auch nicht debuggen. So einfach ist das.

Builder.io bringt es auf den Punkt:

You’re building code faster, but becoming a weaker developer.

Stell dir vor du baust eine Suchfunktion mit Vibe Coding. 10 Testuser. Alles funktioniert. Kein Debouncing, kein Caching, kein Rate Limiting. Aber 10 User sind halt kein Problem.

Dann kommt Black Friday. 50.000 User gleichzeitig. Totalabsturz. 12.000 Dollar Verlust pro Minute.

Das ist das Problem. Vibe Coding funktioniert im Kleinen. Es explodiert im echten Einsatz.

Und das Schlimmste: Je länger du so arbeitest, desto schwächer wirst du. Ständiges Auslagern lässt dein Problemlösen verkümmern. Deine mentalen Modelle verschwinden.

Der Unterschied zwischen einem Senior und einem Vibe Coder ist nicht der Code. Es ist das mentale Modell dahinter.

KI verstärkt was da ist. Wenn da nichts ist, verstärkt sie halt nichts.

2. Du arbeitest an der App statt am System

IndyDevDan hat den wichtigsten Satz zum Thema gesagt:

You work on the agents, not the application.

Der fundamentale Fehler von Vibe Coding: Du arbeitest AN der App. Aber du solltest AM System arbeiten, das die App baut.

Das ist der Paradigmenwechsel den Vibe Coding komplett verpasst.

Stell dir drei Stufen vor:

No-Loop. Das ist Vibe Coding. Blindflug. Kein Plan, kein System, hoffen dass es klappt.

In-Loop. Das ist wo die meisten Entwickler gerade sind. Du kontrollierst jeden Schritt manuell. Du guckst dir den Code an. Du verstehst was passiert.

Out-of-Loop. Das ist Agentic Engineering. Dein System übernimmt. Du steuerst das System.

Vibe Coding ist nicht mal In-Loop. Es ist No-Loop. Kein Feedback, keine Kontrolle, keine Qualitätssicherung.

IndyDevDan sagt dazu:

Vibe Coding is not knowing and not looking. Agentic Engineering is knowing what will happen in your system so well you don’t need to look.

Standard-Tools reichen dafür nicht. Cursor out of the box. ChatGPT Copy-Paste. Das ist der niedrigste Einstieg. Du brauchst spezialisierte Agenten für DEINE Codebase. Nicht generische Tools für alle.

Roland von Never Code Alone zeigt das in seinem YouTube Video ganz praktisch:

Er hat ein Tool mit Vibe Coding gebaut. Ergebnis: DRY-Verletzungen überall (DRY = “Don’t Repeat Yourself” gleicher Code an mehreren Stellen statt einmal zentral). Obwohl er der KI gesagt hat: Sei DRY. Die KI hat Code dupliziert. Timestamps falsch berechnet. Und behauptet, alles wäre korrekt.

Oder guck dir den Ströer Blog an. Gemini CLI löscht Daten. Replit löscht die Datenbank. Das passiert wenn es keinen Closed Loop gibt. Keine Tests. Kein System. Nur Vibes.

Die Lösung ist nicht weniger KI. Die Lösung ist KI mit System.

Das Gegenmodell: So programmierst du wirklich mit KI

Stripe: Wie 1.300 PRs pro Woche wirklich funktionieren

Wenn du wissen willst wie Programmieren mit KI in groß aussieht, guck dir Stripe an.

Stripe hat ihr System “Minions” getauft und in zwei Blog-Posts auf stripe.dev erklärt: Part 1, Part 2. Keine Marketingversprechen. Engineering-Dokumente.

Die Zahlen:

• 1.300 Pull Requests pro Woche. Von Agenten erstellt. Kein Mensch schreibt den Code

• Hunderte Millionen Zeilen Code in der Codebase

• Über 3 Millionen automatisierte Tests

• Knapp 500 MCP Tools im internen “Toolshed”

• 10 Sekunden bis eine Agent-Sandbox bereit ist

Stripe verarbeitet 1,9 Billionen Dollar pro Jahr. Und ihr KI-System produziert jede Woche 1.300 PRs. Menschen prüfen den Code. Aber der Code kommt komplett von Agenten.

Ist das Vibe Coding? Nein. Das ist ein System:

1. Devbox-Pool: Isolierte Sandboxes, vorgewärmt, in 10 Sekunden bereit. Kein Zugriff auf Produktionsdaten

2. Agent Harness: Stripes eigener Coding-Agent, basierend auf dem Open-Source-Agent “Goose” von Block. Angepasst an ihre Codebase

3. Blueprints: Manche Schritte sind fest programmiert (Linting, Git-Push). Andere überlässt man der KI (Implementierung, Bug-Fixing). Die KI hat Freiheit wo sie Freiheit braucht

4. Rule Files: Kontextspezifische Regeln, an Verzeichnisse gebunden. Wenn der Agent in einen Ordner navigiert, werden die passenden Regeln geladen

5. Toolshed: Zentraler MCP Server mit knapp 500 Tools. Jeder Agent bekommt genau die Tools die für seine Aufgabe relevant sind

6. CI/Testing: Über 3 Millionen Tests. Jeder Agent darf maximal zwei CI-Runden laufen lassen. Danach geht die Aufgabe zurück an einen Menschen

7. Human Review: Jeder PR wird von einem Menschen geprüft bevor er gemerged wird

Und hier wird es interessant: Stripe synchronisiert dieselben Rule Files über Cursor, Claude Code und ihre Minions. Alle drei Plattformen lesen die gleichen Regeln. Das System ist tool-agnostisch.

Stripe nennt das:

Putting LLMs into contained boxes.

Die KI hat Freiraum. Aber innerhalb eines Systems das die Qualität garantiert.

Jetzt abonnieren

Dein Startpunkt: Spec-Driven mit jedem Coding Agent

Du brauchst nicht Stripes Budget. Du brauchst nicht alle Komponenten am ersten Tag. Du brauchst einen Startpunkt.

Und der Startpunkt ist überraschend einfach: Hör auf zu prompten und fang an zu planen.

Das funktioniert mit jedem CLI-basierten Coding Agent:

• Claude Code (Anthropic). Das nutze ich. Terminal-basiert, tiefe Codebase-Analyse, eigenes Skills-System

• Cursor (Anysphere). IDE mit Agent-Mode und CLI. Stripe nutzt intern beide

• Goose (Block). Open Source. Der Agent den Stripe als Basis für ihre Minions geforkt hat

• Aider (Open Source). Über 100 Sprachen, funktioniert mit jedem LLM

Plus Codex, Cline, Gemini CLI und andere. Das Tool ist nicht der Punkt. Das System dahinter ist der Punkt.

Für mich war der Superpowers-Workflow in Claude Code der Startpunkt. Spec-driven statt prompten und hoffen.

Was macht der konkret?

Brainstorming. Die KI stellt dir Rückfragen. Nicht “mach mir eine App.” Sondern: Was genau soll die App können? Für wen? Warum so und nicht anders? Die KI hinterfragt deine Annahmen bevor eine Zeile Code geschrieben wird.

Implementierungsplan. Nach dem Brainstorming entsteht ein strukturierter Plan. Welche Dateien werden geändert. In welcher Reihenfolge. Welche Abhängigkeiten. Das ist der Unterschied. Vibe Coder prompten und hoffen. Ich plane und delegiere.

Skills als Qualitätssicherung. Zusätzliche Regeln steuern WIE implementiert wird. Einmal definiert, immer aktiv. Das ist im Prinzip das gleiche wie Stripes Rule Files. Nur halt für einen Solo-Entwickler statt für ein Enterprise-Team.

Weniger Bugs. Bessere Architektur. Code den ich wirklich verstehe. Das waren die Ergebnisse ab der ersten Woche.

Aber Superpowers ist eigentlich nur ein Startpunkt.

Das eigentliche Ziel ist ein System das zu DEINER Firma passt. Zu deiner Codebase. Zu deinen Anforderungen. Nicht ein generisches Tool das für alle gleich funktioniert.

Guck dir nochmal an was Stripe macht. Die haben nicht Cursor oder Claude Code out of the box genommen und gehofft. Die haben ihr eigenes System drumherum gebaut. Eigene Blueprints. Eigene Rule Files. Eigene MCP Tools. Und dann das gleiche Regelsystem über alle drei Plattformen synchronisiert.

1.300 PRs pro Woche sind das Ergebnis von jahrelanger Systemarbeit. Nicht von einem besseren Prompt.

So mappt Stripes System auf deins:

• Stripes Blueprints = Deine CLAUDE.md + Skills (oder .cursorrules in Cursor, oder Aider-Conventions)

• Stripes Rule Files = Dein Kontext-Engineering. Projektspezifische Regeln die dein Agent automatisch liest

• Stripes Toolshed = Deine MCP Server

• Stripes CI/Testing = Deine Tests + Linting

• Stripes Agent Harness = Dein CLI Coding Agent. Claude Code, Cursor, Codex, Aider, Goose. Egal welcher

Superpowers ist Schritt 1. Es zeigt dir wie spec-driven Development funktioniert. Es gibt dir schnelle Ergebnisse. Aber das Ziel ist dein eigenes System. Eins das du selbst gebaut hast. Das du verstehst. Das mit dir wächst.

Und jedes Problem das du löst wird ein Skill, ein Rule File, eine Konvention. Einmal gebaut, immer nutzbar. Das System wächst mit dir. Das ist der Unterschied: Du investierst nicht in schnelle Ergebnisse die morgen wertlos sind. Du investierst in ein System das jeden Tag besser wird.

Jetzt abonnieren

Die Beweise

Hier sind meine Ergebnisse. Nicht theoretisch. Gebaut und im Einsatz.

Email Agent für Kunden: Ein KI-Agent der Support-Emails beantwortet. Accuracy von 93,8% auf 99,2% gebracht. Systematisch iteriert, nicht vibe-gecodet. Das sind 6 Prozentpunkte die den Unterschied machen ob ein Kunde eine richtige oder falsche Antwort bekommt.

SEO-System. Keyword-Datenbank mit über 170 Keywords plus automatisierter /seo Command. In einer Woche gebaut. Mit Superpowers geplant. Ohne System hätte ich drei Wochen gebraucht.

sales-engine. Ein neues SaaS. Auf Hetzner gehostet. €20 im Monat statt €150 bei Azure. Hetzner, Docker, Dokploy. Das ist kein Prototyp. Das läuft in Produktion.

Newsletter Digest. n8n holt jeden Morgen 19 Newsletter aus Gmail. Claude Code bewertet sie gegen mein aktuelles Thema und erstellt einen Morning Report. 95 Minuten manuelles Lesen runter auf 2 Minuten. 6 Nodes in n8n statt 200 Zeilen Python. Das ist mein System in Aktion: n8n orchestriert, Claude Code denkt. Und ich sehe auf einen Blick was relevant ist.

Hätte ein Vibe Coder das geschafft? Vielleicht den Prototyp. Aber nicht das System das danach jeden Tag besser wird.

KI verstärkt was da ist

Ohne System verstärkt Vibe Coding nur Chaos. Mehr Code, mehr Bugs, mehr technische Schuld.

Mit System verstärkt KI alles was du kannst. Mehr Projekte, weniger Fehler, bessere Ergebnisse.

Du musst nicht bei null anfangen. Fang mit einem Brainstorming-Workflow an. Bau deinen ersten Implementierungsplan. Und dann bau weiter. Bis du ein System hast das dir gehört.

Danke fürs Lesen.

Wenn du Fragen hast oder mir zeigen willst wie du mit KI codest, schreib mir gerne auf LinkedIn.

Bis nächste Woche,

Markus

Du kennst das. Du scrollst durch YouTube, siehst ein Video über KI-Workflows, denkst “das guck ich später” und drückst auf Speichern.

Das Video landet auf dem Friedhof. Zwischen 246 anderen.

Das Problem ist nicht YouTube. Das Problem ist: Es gibt keinen Weg von “gutes Video gesehen” zu “etwas damit anfangen”. Kein System. Keine Pipeline. Nur eine Liste die immer länger wird.

Bis ich mir einen gebaut habe. 30 Sekunden aktive Zeit. Vom Handy.

YouTube transkribieren reicht nicht

Die meisten Leute suchen “YouTube Video transkribieren” und bekommen halt Text. Sonix, YouTube-Untertitel, Whisper. Alles transkribiert. Keins davon versteht, worum es im Video geht.

Stell dir vor du hast einen 45-Minuten-Vortrag transkribieren lassen. Was hast du jetzt? 20 Seiten Text. Und du musst halt trotzdem selbst rausfinden, was davon relevant ist.

Transkribieren ist wie ein Stenograf. Der schreibt alles mit. Aber er sagt dir nicht, was wichtig ist.

Was du eigentlich brauchst ist ein Berater. Jemand der das Video guckt und sagt: “Das sind die drei Kernaussagen. Diese Zitate kannst du nutzen. Und so passt das zu deinem Projekt.”

Das ist der Unterschied zwischen YouTube Video in Text umwandeln und YouTube Video analysieren. Zwischen Transkript erstellen und Content erstellen.

Mein 30-Sekunden-Workflow

So funktioniert mein System. Vier Schritte:

1. Ich sehe ein YouTube-Video das mich inspiriert.

   Egal ob auf dem Handy, beim Frühstück, in der Bahn.

2. Ich schicke den Link in meinen Telegram-Bot.

   Dazu schreibe ich meine Gedanken. “Darüber könnte ich posten” oder “Das passt zu meiner Newsletter-Recherche über KI-Workflows”.

3. Gemini bekommt das Video und analysiert es.

   Nicht transkribieren. Analysieren. Was sind die Kernaussagen? Welche Zitate kann ich nutzen? Wie passt das zu meiner Idee?

   Gemini versteht Videos nativ. Wenn du einen YouTube-Link schickst, “schaut” Gemini das Video. Kein Transkriptions-Umweg. Echte Video-Analyse.

4. Ein fertiger Post-Entwurf landet in meinem Second Brain.

   Automatisch. Ich muss nichts kopieren, nichts formatieren, nichts manuell verschieben.

Warum Gemini KI und nicht ChatGPT oder Claude? Weil Gemini Videos nativ versteht. ChatGPT und Claude brauchen erst ein Transkript. Gemini nimmt den YouTube-Link und arbeitet direkt mit dem Video. Das ist einfach eine andere Liga für meinen Claude Code Workflow.

Ein echtes Beispiel:

Ich baue gerade ein KPI-Dashboard für eine Vertriebsorganisation. Vertriebscockpit, Tagessteuerung, Leaderboard. Das Problem: Ich bin kein Dashboard-Experte. Ich weiß wie man Code schreibt, aber nicht wie man ein Dashboard designt, das ein CEO jeden Morgen aufmacht.

Also habe ich zwei der besten YouTube-Videos genommen, wo explizit erklärt wird wie man optimal so ein Dashboard designt. Mein Prompt: “Erstelle einen Step-by-Step Guide für Dashboard-Design basierend auf diesem Video.”

Gemini hat aus zwei Videos einen kompletten Design-Guide gemacht. Diesen Guide habe ich als Claude Code Skill geladen. Und dann hat Claude Code damit das Dashboard gebaut.

Das Ergebnis ist ultra simpel und geil geworden. Nicht weil ich plötzlich Dashboard-Experte bin. Sondern weil ich das Wissen von Experten extrahiert habe. Easy. Direkt in Claude Code. In einer Session.

Letzte Woche habe ich genau über dieses Dashboard geschrieben:

Echte Zahlen

Das ist kein Konzept. Ich nutze das gerade jeden Tag.

• 21 Sessions in 13 Tagen. Nicht ein Experiment. Mein täglicher Workflow.

• 240 Zeilen Python. Das gesamte Tool. Eine Datei. Zwei Dependencies.

• 0 Euro Kosten. Gemini API Free Tier reicht locker für den Alltag.

• 30 Sekunden vom YouTube-Link zur fertigen Analyse. Vom Handy.

Was ich damit mache:

Newsletter-Recherche: Video gucken, Link schicken, Kernaussagen und Zitate extrahieren. Fertig.

Post-Entwürfe: “Analysiere im Kontext dieser Post-Idee: [meine Idee].” Gemini liefert Argumente, Beispiele, Struktur.

Skills lernen: Tutorial-Video schicken mit “Erstelle einen Step-by-Step Guide.” Das ist genau das, was ich mit dem Dashboard gemacht habe. Funktioniert halt echt gut.

Im Premium-Bereich gibt’s den YouTube-Video Skill zum Download. Ein Claude Code Skill den du mit einem einzigen Prompt installierst. Du brauchst nur einen kostenlosen Gemini API Key.

In dem Video siehst du wie einfach das aufsetzen ist:

Read more

Früher hätte so ein Projekt Monate gedauert. Ein ganzes Team. Designer, Backend-Entwickler, Frontend-Entwickler. Heute mache ich das in ein paar Tagen. Alleine. Backend, Frontend, User Login, Datenbank, Deployment. Mein Job ist nicht mehr coden. Mein Job ist managen. Ich sage der KI was sie bauen soll, prüfe die Ergebnisse, und gebe Feedback.

Aber die meiste Arbeit beim Entwickeln ist nicht das Coden. Es ist das Testen.

Weil der CEO will das Dashboard auch auf seinem Handy sehen. Und auf seinem Laptop. Und auf dem großen Bildschirm im Büro. Das heißt, jede Komponente muss auf Desktop, Tablet und Mobile funktionieren. Jede Card, jede Tabelle, jeder Chart. Und jedes Mal wenn ich was ändere, muss ich das alles nochmal durchtesten. Manuell. Seite für Seite. Gerät für Gerät.

Und KI hat mir dabei nicht geholfen. Ich hab es versucht. Hab Claude gesagt: “Teste mal mein Dashboard.” Und Claude hat gefragt: Welche Seiten? Welche Daten? Was ist richtig und was ist falsch?

Gute Fragen. Aber ich hatte keine Antworten die ich einfach übergeben konnte. Also hab ich es wieder manuell gemacht.

Bis diese Woche.

Warum die meisten Entwickler KI falsch nutzen

Die meisten nutzen KI wie einen besseren Autocomplete.

Copilot schreibt Code-Zeilen. ChatGPT beantwortet Fragen. Aber keins davon versteht eigentlich was du baust. Du gibst der KI eine Aufgabe. Sie macht was. Du gibst ihr die nächste. Sie hat die erste vergessen.

Das ist wie ein Praktikant mit Amnesie. Jeden Morgen erklärst du ihm den Job von vorne.

Und das Problem wird schlimmer, je mehr du reinwirfst. Mehr Kontext, mehr Dateien, mehr Erklärungen. Man denkt halt, das hilft. Aber das Gegenteil passiert. Die KI wird langsamer, ungenauer, teurer.

Ich hab das beim E2E Testing gemerkt. Ich wollte, dass Claude mein Frontend testet. Vertriebscockpit, Tagessteuerung, Kapazitätsplanung, Leaderboard. Alle Komponenten, alle Zustände. Und hab versucht, ihm alles auf einmal zu erklären.

Das Ergebnis war Müll.

Weil das Problem nicht die KI war. Das Problem war, wie ich ihr den Kontext gegeben habe.

Drei Ansätze, zwei Sackgassen

Bevor ich die Lösung gefunden hab, bin ich zweimal gescheitert.

Versuch 1: curl.
Claude Code testet am liebsten die API. Aber curl sieht nicht ob eine KPI-Card auf dem Handy abgeschnitten ist oder ob der Chart auf dem Tablet richtig skaliert. Komplett blind für alles Visuelle.

Versuch 2: Chrome DevTools MCP.
Ein Browser, den die KI fernsteuert. Klingt gut. Aber jeder Klick schickt den kompletten Seitenbaum ins Kontextfenster. Bei einem Dashboard mit 20 Komponenten pro Seite wird die KI nach ein paar Schritten halt einfach zu langsam.

Versuch 3: playwright-cli.
Ein Kommandozeilen-Tool von Microsoft für KI-Agents. Schreibt alles auf die Festplatte statt ins Kontextfenster. 4x weniger Token. Und mit Sonnet 4.6 unfassbar schnell.

Aber das Tool allein war nicht die Lösung. Das Tool war nur der erste Baustein.

Claude Code Skills: Kontext in 3 Schichten

Die eigentliche Lösung sind 3 Markdown-Dateien. Kein Framework. Kein neues Tool. Einfach 3 Dateien, die der KI sagen was sie wissen muss.

Der Skill: Was kann das Tool?

Stell dir ein Rezept vor. Ein Rezept sagt nicht “koch was Gutes.” Es sagt: Du hast diese Zutaten, diese Werkzeuge, diese Schritte.

Mein Skill beschreibt die playwright-cli. Browser öffnen, Seiten besuchen, Elemente anklicken, Screenshots machen. Mehr nicht. Und genau das reicht. Die KI muss nicht wissen wie Playwright intern funktioniert. Sie muss wissen was sie damit tun kann.

Der Agent: Wer führt aus?

Jetzt stell dir den Koch vor. Der Koch kennt das Rezept. Aber er hat auch seine Rolle: “Du bist ein QA-Tester. Du bekommst eine User Story. Du testest sie Schritt für Schritt. Du machst bei jedem Schritt einen Screenshot. Und du sagst mir ob es funktioniert oder nicht.”

Mein Agent bekommt eine einzige User Story. Nicht das ganze Dashboard. Nicht alle Tests. Eine Story. Er testet sie und gibt mir ein klares PASS oder FAIL zurück. Mit Screenshots.

So sieht eine echte User Story aus:

- name: "CEO sieht 5 KPI-Cards auf dem Vertriebscockpit"
  url: "http://localhost:3000/protected/dashboard"
  workflow: |
    Navigiere zu /protected/dashboard
    Verifiziere dass der Titel "Vertriebscockpit" sichtbar ist
    Verifiziere dass genau 5 KPI-Cards sichtbar sind: 
      Ziel, Neukunden, Umsatz, Cash-In, Pipeline
    Verifiziere dass alle 5 Cards vollständig sichtbar sind
      (keine Card ragt über den rechten Bildschirmrand hinaus)
    Verifiziere dass keine Card abgeschnitten ist
      (alle Euro-Beträge und Prozentwerte sind vollständig lesbar)
    Verifiziere dass jede Card einen farbigen Status-Punkt hat
      (grün, gelb oder rot)

Das ist kein Code. Das ist eine Beschreibung. Auf Deutsch. “Navigiere zu dieser Seite. Guck ob 5 Cards da sind. Guck ob nichts abgeschnitten ist.”

Das ist der Trick: Nicht alles auf einmal. Sondern eine Sache richtig.

Der Command: Was soll passieren?

Und jetzt der Küchenchef. Der Küchenchef sagt nicht jedem Koch einzeln was er tun soll. Er gibt den Auftrag raus: “Heute Abend servieren wir ein 5-Gänge-Menü.” Und jeder Koch weiß was er zu tun hat.

Mein Command heißt /ui-review. Er findet alle User Stories automatisch. Und dann startet er für jedes Dashboard einen eigenen Agent. Drei Dashboards, drei Agents, parallel.

Hier zwei Beispiele Reports:

73 User Stories. In 12 Dateien. Vertriebscockpit, Tagessteuerung, Kapazitätsplanung. Responsive-Tests für jede Auflösung. Der Agent versteht die Workflows auf Deutsch und klickt sich durch die App wie ein echter Nutzer.

Tagsüber coden. Nachts testen lassen.

Diese Woche hab ich das gebaut. Und direkt benutzt.

Zum Coden nehme ich Opus. Zum Testen Sonnet. Opus ist gründlicher. Sonnet ist schneller. Zusammen ergibt das einen Loop der sich selbst korrigiert.

Ich mache eine Änderung. Sonnet testet das Frontend. Klickt sich durch die App. Guckt ob Buttons funktionieren, ob Formulare validieren, ob die Navigation stimmt.

Und wenn was kaputt ist, kriege ich halt sofort Feedback. Opus fixt es. Sonnet testet nochmal.

Und das Beste daran: Ich muss nicht mal dabei sein.

Tagsüber implementiere ich. Abends starte ich die Tests. 73 Stories laufen über Nacht durch. Drei Agents parallel, einer pro Dashboard. Jeder Agent nimmt sich eine Story, testet sie, macht Screenshots, nimmt sich die nächste.

Morgens mache ich den Laptop auf. Und da liegen die Ergebnisse. Fertig sortiert. Hier funktioniert was nicht, hier ist ein visueller Fehler, hier hat sich ein Wert verschoben. Keine Checkliste die ich abarbeiten muss. Sondern ein fertiger Report mit Screenshots.

Das ist Testautomatisierung. Aber nicht so wie du sie kennst.

Das ist kein Testing-Trick

Hier ist was mich eigentlich beschäftigt.

Code kann gerade wirklich jeder generieren. Das ist kein Vorteil mehr. Jeder kann sich ein Dashboard zusammenklicken lassen. Die Frage ist halt: Funktioniert es? Auf jedem Gerät? Mit echten Daten? Und hält es, wenn du nächste Woche was änderst?

Das Entscheidende ist nicht, dass ich jetzt schneller teste. Das Entscheidende ist, wie ich mit KI umgehe.

Die meisten geben der KI Aufgaben. Einzelne Aufgaben. “Schreib mir das.” “Teste das.” “Erklär mir das.”

Ich gebe ihr ein System. Skill, Agent, Command. 3 Dateien. Und das System weiß dann selbst was zu tun ist.

Und das ist der eigentliche Unterschied. Nicht welches KI-Modell du benutzt. Nicht welches Tool. Sondern ob du der KI jedes Mal alles von vorne erklärst. Oder ob du einmal ein System baust, das selbst weiß was zu tun ist.

Wer den Agent meistert, meistert Wissensarbeit.

Und das System gehört mir. 3 Markdown-Dateien. Die kann ich in jedes Projekt mitnehmen. Das Vertriebsdashboard mit den 73 Tests heute, das nächste Kundenprojekt morgen. Einmal gebaut, immer nutzbar.

Der CEO sieht sein Dashboard auf dem Handy. Auf dem Laptop. Auf dem Bildschirm im Büro.

Und ich muss nicht mehr hoffen, dass alles funktioniert.

Ich weiß es.

3 Markdown-Dateien. Einmal gebaut, immer nutzbar.

Danke fürs Lesen.

Wenn du Fragen hast oder mir erzählen willst wie du KI in deinen Projekten einsetzt, schreib mir gerne auf LinkedIn.

Bis nächste Woche,

Markus