Kaizen in Conductor — 8 Versionen, 24 Monate, kein Big Bang

TL;DR

Kaizen ist das japanische Prinzip kleiner, kontinuierlicher Verbesserungen — und der eigentliche Operations-Modus hinter Conductor, meinem Agentic-Coding-Stack. v1.0 lief Mai 2024 als monolithisches Mega-Plugin. v8.1.0 läuft Mai 2026 als 13-Plugin-Ökosystem. Acht Major-Versionen in 24 Monaten = im Schnitt eine Major alle 3 Monate. Keine davon ein Big Bang. Jede genau einen alten Designfehler gefixt. Dieser Post zeigt: was Kaizen in Software konkret heißt, wo Toyotas Lean-Manufacturing-Wurzeln liegen, wie sich das in Conductor manifestiert, und unter welchen Bedingungen das für andere Indie-Builder-Stacks übertragbar ist.

Featured: Stilisierte Kaizen-Treppe — kleine Schritte, gleiche Richtung.

Inhaltsverzeichnis

• Was Kaizen ist (kurz)
• Die Toyota-Wurzel
• Conductor als Kaizen-Übung
• Die 1%-Logik im Code-Alltag
• Was nicht Kaizen ist
• Drei Praxis-Heuristiken
• FAQ

Was Kaizen ist (kurz)

Kaizen (改善) ist japanisch für “Veränderung zum Besseren”. Im Kern eine Disziplin: was können wir morgen 1% besser machen als heute? Nicht radikal. Nicht laut. Nicht als Big Bang.

Drei Eigenschaften unterscheiden Kaizen von beliebigen “Iteration”-Konzepten:

1. Inkrementell. Jede Verbesserung ist klein. Nicht “wir refaktorieren das ganze System neu”.
2. Kontinuierlich. Nicht ein-Workshop-im-Jahr. Sondern: jeden Tag eine Frage stellen.
3. Geteilt. In Toyota war Kaizen explizit Pflicht für alle Linienarbeiter, nicht nur für Manager. Im Indie-Modus heißt das: nicht nur der “Big Plan” wird verbessert, sondern jede Workflow-Komponente.

Die Toyota-Wurzel

Kaizen wurde als Begriff Anfang der 1950er Jahre im Toyota Production System (TPS) institutionalisiert. Masaaki Imais Buch “Kaizen: The Key to Japan’s Competitive Success” (1986) hat den Begriff im Westen populär gemacht. Toyota nutzte Kaizen explizit, um die Fertigungslinie kontinuierlich zu verbessern — mit ~1.000.000+ implementierten Mitarbeiter-Vorschlägen pro Jahr in Spitzenzeiten (Toyota Production System Yearly Report 1998).

Der entscheidende Insight: kleine Verbesserungen kumulieren über Zeit zu größerer Wirkung als seltene Großvorhaben. 1% pro Tag über 365 Tage = Faktor 37,8 ((1.01)^365). 1% pro Woche über 52 Wochen = Faktor 1,68. Frequenz schlägt Magnitude.

Toyota hat diese Mathematik real ausgenutzt — und ist heute der konstant profitabelste Autohersteller der Welt. Kaizen ist keine japanische Spiritualität; es ist Lean-Manufacturing-Mathematik.

Conductor als Kaizen-Übung

Conductor ist mein produktiver Agentic-Coding-Stack. Acht Major-Versionen über 24 Monate. Jede hat einen Designfehler korrigiert — nicht alle gleichzeitig.

Beobachtung: keine dieser Versionen war ein “alles-auf-einmal”-Sprung. Jede hat genau einen alten Schmerz adressiert.

Auch v5.0 (Rollback) ist Kaizen-konform: kleiner Schritt versucht, gemessen, schlecht, zurück. Das ist nicht Failure. Das ist die Disziplin von Kaizen. Toyota hat unzählige Fertigungslinien-Experimente gerollbackt — die Idee ist nicht “jede Veränderung muss funktionieren”, sondern “wir probieren in kleinen Schritten und behalten nur, was misst sich besser”.

Mehr Details zu den einzelnen Versionsbrüchen: Was bei Agentic Coding nicht funktioniert.

Die 1%-Logik im Code-Alltag

Conductor-Versionen sind die Makro-Ebene. Aber Kaizen passiert auch täglich, im Mikro:

Keine dieser Aktivitäten ist ein “Big Project”. Aber zusammen produzieren sie ein System, das nach 2 Jahren signifikant anders aussieht als am Anfang.

Konkretes Beispiel aus letztem Monat (April 2026): das marketing-pilot-Plugin hatte einen Bug, der bei mehrsprachigen Posts den Hash-Tag-Generator zu früh stoppte. Ein 12-Zeilen-Fix. Hat 35 Minuten gekostet. Macht das marketing-pilot-Plugin von “funktional” zu “wirklich produktiv”. Drei Wochen später wurde aus dieser Verbesserung der Anlass, marketing-pilot von Experimental in Produktion zu schieben.

Kein einzelner 35-Min-Fix wäre ein “Release” wert. Kumuliert haben aber genug solcher Fixes v8.1.0 ergeben.

Was nicht Kaizen ist

Drei Anti-Patterns, die ich selbst gemacht habe und die zeigen, was Kaizen NICHT ist:

1. “Wir bauen das System neu”

Klassische Falle. Im IBM-Vista-Projekt habe ich das mehrfach gesehen — neue Architektin oder neuer CTO kommt, sagt “alles neu”. 80 Folien später ist 6 Monate Implementations-Stillstand entstanden. Kaizen sagt: nicht neu bauen. Den bestehenden Schritt verbessern.

Mein eigener Fehler 2025: Conductor v5.0 war im Kern ein “ich baue den Orchestrator neu”-Schritt. Funktioniert nicht. Rollback. v6.0 war wieder Kaizen-konform — eine spezifische Komponente (MCP-State) verbessert.

2. “Wir warten bis es perfekt ist”

Wabi-Sabis Gegenteil. Wer Kaizen ernst nimmt, akzeptiert: jede einzelne Verbesserung darf unfertig sein, solange sie misst sich besser. Conductor v2.0 hatte selber Bugs. War besser als v1.0. Ship.

3. “Wir machen eine Strategie-Klausur dazu”

Process-Overhead. Im Indie-Modus killt eine Strategie-Sitzung jede Kaizen-Energie. Eine Frage am Frühstückstisch (“was nervt am auto-test-Plugin?”) ersetzt drei Workshops.

Drei Praxis-Heuristiken

Wenn du Kaizen in deinem eigenen Workflow testen willst:

Heuristik 1: Eine Frage pro Tag

Jeden Morgen eine Frage stellen: “Was hat gestern am meisten geknirscht?” Antwort ist meistens ein konkreter Reibungspunkt. Behebung in 30-60 Min. Das ist eine Kaizen-Iteration.

Heuristik 2: Schreibe es auf

Wer Verbesserungen nicht festhält, verliert sie. Bei mir: CHANGELOG.md in jedem Repo, plus knowhow-Plugin-Eintrag in Conductor. Toyota nennt das den Kaizen-Vorschlags-Bogen.

Heuristik 3: Mess vorher und nachher

Eine Verbesserung ist nur eine, wenn sie messbar ist. Bei Conductor v5.0 hat Rollback nur funktioniert, weil ich gemessen hatte (Antwort-Latenz, Output-Qualität) — sonst hätte ich nicht gewusst, dass v5.0 schlechter war als v4.0.

Im Indie-Modus reichen oft sehr einfache Metriken: “Hat dieser Plugin-Aufruf in der letzten Woche mein Workflow beschleunigt?” — Ja/Nein. Keine BI-Tools nötig.

Wo das hingeht

Conductor v9 ist die nächste Kaizen-Iteration. Drei spezifische Schritte, jeder klein:

1. Cross-Repo-Convention-Versioning (~2 Wochen)
2. Subagent-State-Passing als First-Class-Konzept (~3 Wochen)
3. Multi-LLM-Sub-Task-Routing (~4 Wochen)

Insgesamt vermutlich 2-3 Monate Arbeit, verteilt über 6-8 Monate Kalenderzeit. Kein Big Bang. Eine Major-Version, aber sie ist die Summe vieler kleiner Korrekturen.

Wenn du selbst einen Agentic-Coding-Stack mit Kaizen-Disziplin baust und Notes austauschen willst: schreib mir auf LinkedIn.

FAQ

Was unterscheidet Kaizen von “Agile”?

Agile (Scrum, XP, Kanban) ist eine konkrete Methodik mit Zeremonien (Sprint Planning, Retro, Stand-Up). Kaizen ist ein zugrundeliegendes Prinzip — kontinuierliche Verbesserung in kleinen Schritten — das in Agile praktiziert werden kann, aber älter und allgemeiner ist (Toyota hat Kaizen 30 Jahre vor dem Agilen Manifest 2001 angewandt).

Funktioniert Kaizen für Solo-Founder oder nur in Teams?

Beides. Im Solo-Modus ist Kaizen sogar einfacher, weil kein Konsens nötig ist. Du entscheidest morgens, was du heute verbesserst, und tust es. Die schwierigere Disziplin ist die Kontinuität — niemand fragt dich nach 3 Wochen, ob du noch dranbleibst.

Ist Kaizen mit Big-Bang-Releases vereinbar?

Nicht wirklich. Wer Kaizen ernst nimmt, vermeidet Big-Bang-Releases als Default. Aber: Major-Versionen können Kaizen-Releases sein. Conductor v7.0 ist eine Major-Version (Hooks-System), aber sie ist die Summe von ~12 vorbereitenden kleinen Schritten. Nicht eine Riesen-Idee, sondern Konsolidierung.

Welches Buch empfiehlst du zum Einstieg?

Masaaki Imai: “Kaizen: The Key to Japan’s Competitive Success” (1986) für die Toyota-Wurzel. Eher trockene Management-Lektüre, aber definitiv. Robert Maurer: “The Spirit of Kaizen” (2012) ist zugänglicher und überträgt das Prinzip auf individuelle Praxis.

Wie messe ich, ob mein Kaizen funktioniert?

Nach 6 Monaten: vergleiche deinen aktuellen Workflow mit dem von vor 6 Monaten. Wenn er fühlbar anders ist — und besser misst (Output pro Stunde, Frustration pro Tag, Bug-Inzidenz) — funktioniert Kaizen. Wenn er nur “anders” ist ohne klare Besserung, hast du Bewegung verwechselt mit Verbesserung.

Geschrieben am 17. Mai 2026 in Hamburg. Diese Methodik ist nicht meine Erfindung — sie ist 70 Jahre Toyota plus 24 Monate Conductor. Wenn du diesen Post hilfreich findest, verlinke ihn.