Ein System, das die Arbeit macht

Herzlich Willkommen zu den AI FIRST Insights! Wir entwickeln gerade unsere erste eigene Software. Viel zu bauen, kleines Team, wenig Zeit. Und die erste Frage, die wir uns gestellt haben, war dieselbe, die sich gerade fast jedes Unternehmen stellt: „Was können wir davon automatisieren?“

Das war aber die völlig falsche Frage.

Die Frage, die uns wirklich weitergebracht hat, war: “Wie bauen wir ein System, das unsere Software baut – und bei jeder Erledigung besser wird?”

In der letzten Ausgabe habe ich beschrieben, was „neu denken“ für uns heißt: eine Sache in ihre Einzelteile zerlegen, um sie so neu zusammenzusetzen, dass ein größerer Wert entsteht. Heute folgt der zweite Schritt: Wie die Einzelteile zum System werden.

Ich zeige dir, wie wir systemisch an das Design von Prozessen gehen und wie wir das auf unser Coding-System angewandt haben.

Los geht’s!

Von der Automatisierungs-Frage zur System-Frage

Bevor wir in unseren Entwicklungsprozess einsteigen, ein kurzer Exkurs.

Je länger ich im KI-Bereich arbeite, desto mehr habe ich mich unbewusst mit Systemtheorie beschäftigt. Ich bin kein Systemtheoretiker – aber eine Überzeugung hat sich bei mir immer weiter verfestigt: KI entfaltet ihre Wirkung erst dann wirklich, wenn wir das System, in dem sie arbeitet, mit KI im Kern neu denken. Ich sage auch gern, dass wir unsere Unternehmen so bauen müssen, dass KI darin möglichst gut arbeiten kann.

Wer nur einzelne Prozesse automatisiert, macht Bestehendes schneller. Wer das ganze System mitdenkt, verändert die Skala der möglichen Wirkung.

Aber was ist ein System überhaupt?

Die Systemtheorie sagt, dass ein System aus diesen Dingen besteht:

Elemente – die Teile.
Verbindungen – wie die Teile zusammenhängen.
Zweck – das Ergebnis, für das alles existiert.
Speicher - in dem sich Erfahrung ansammelt
Regeln - die festlegen, wer wann eingreift
Rückkopplung - was hinten gelernt wird, verändert vorne den Ablauf.

Das Verhalten eines Systems bestimmen die Verbindungen, nicht die Teile. Man kann jedes Element austauschen – solange Verbindungen und Zweck bleiben, verhält sich das System gleich. Innerhalb eines Systems gelten außerdem Prinzipien, die ich in KI als Betriebssystem ausführlicher beschrieben habe. Drei davon sind für heute entscheidend.

Vernetzung: Alle Schritte teilen sich ein gemeinsames Gedächtnis statt getrennter Werkzeuge und Chatverläufe.
Synthese: Das Ganze wird designt, statt jedes Teil einzeln zu optimieren.
Emergenz: Aus dem Zusammenspiel entsteht etwas, das kein Einzelteil allein könnte.

Was bedeutet das für die Automatisierungs-Frage? Wer einzelne Prozessschritte automatisiert, verändert die Struktur des Prozesses nicht. Schritt für Schritt wird schneller – aber kein Schritt weiß, was der andere gelernt hat. Es gibt keinen gemeinsamen Speicher, keine Rückkopplung. Der hundertste Durchlauf ist genauso klug wie der erste.

Ein System ist anders gebaut: Speicher und Rückkopplung sind von Anfang an eingeplant. Was am Ende eines Durchlaufs gelernt wird, fließt zurück und verändert den nächsten. Das macht aus Wiederholung Verbesserung – nicht nur Beschleunigung.

Im KI-Kontext verstärkt sich das: KI-Fähigkeiten verbessern sich gerade schneller, als irgendjemand sie manuell in Einzelschritte nachziehen könnte. Ein System mit sauber designten Verbindungen profitiert automatisch davon – weil die Verbesserung einer KI sofort allen verbundenen Stationen zugutekommt. Wer dagegen einzelne Schritte automatisiert hat, muss jeden davon separat anpassen. Das ist kein Tempo-Problem, das ist ein Strukturproblem.

So weit das Denkmodell.

Jetzt zeige ich dir, was es bei uns konkret bedeutet.

So haben wir unser Coding-System gebaut

Wir haben die Entwicklung unseres Produkt-Prototypen nicht damit begonnen, am Whiteboard ein perfektes Coding-System zu entwerfen. Im Gegenteil: Wir sind mit Claude Code und Codex losgelaufen und haben Prompt für Prompt eingesprochen.

Nach ein paar Stunden war uns klar, dass wir nie fertig werden, wenn wir so weitermachen. Eine witzige Erkenntnis, wenn man bedenkt, dass noch vor wenigen Jahren der meiste Code händisch(!) getippt wurde.

Also haben wir uns gefragt, was der erwartete Output ist und wo im Prozess der Flaschenhals entsteht:

Wir wollen Features, die der Spezifikation entsprechen und technisch funktionieren
Die Qualität unserer Spezifikation ist der Flaschenhals Nr. 1
Die Qualität der Tests des Codes ist der Flaschenhals Nr. 2

Wir haben vom Ziel zurück gearbeitet und uns gefragt, wie der Input aussehen muss, damit KI daraus so autonom wie möglich neue Features baut, die eine möglichst geringe Anzahl an Iterationsschleifen benötigen.

Aus dieser Rückwärts-Frage entstanden die Verbindungen zwischen den Phasen unseres Prozesses, die wir natürlich in Skills übersetzt haben.

Im Kern läuft heute jede Anweisung an den Coding-Agent durch 6 Phasen:

1) Anforderungen definieren.

Am Anfang steht ein Meeting, in dem wir diskutieren, was wir überhaupt bauen wollen und was “gut” bedeutet. Das Gespräch wird transkribiert – ein Skill baut daraus die erste Struktur, gleiche Felder, gleiche Logik. Die verfeinern wir gemeinsam, bis die fachliche Frage klar ist: Was soll jemand an dieser Stelle im Produkt tun und erreichen? Unsere Ideen werden auf First Principles gechallenged, um blinde Flecken in unserem Denken aufzudecken und den ersten Input zu schärfen.

Inzwischen kommen weitere Anforderungen direkt aus dem Produkt: Ein Skill liest stündlich das Nutzerfeedback der Plattform und legt zu jeder Meldung ein fertiges Dossier an – was gemeldet wurde, wie der Stand im Code ist, ein Plan und eine Empfehlung. Die Entscheidung ob wir das umsetzen, trifft ein Mensch. Die Umsetzung läuft danach durch dieselben sechs Phasen.

2) Technisch übersetzen.

Ein zweiter Skill liest die fertige Briefing-Seite und zieht heraus, was dafür technisch gebaut werden muss. Aus „Nutzer sollen ihre Antwort einsprechen können“ wird der Ticket-Kandidat „Spracheingabe-Baustein“ – nach Aufwand klassifiziert und mit der Quellseite verknüpft. Ein Mensch bestätigt die Liste der Ticket-Kandidaten. Taucht dabei ein Muster zum zweiten Mal auf, markiert der Skill es als wiederverwendbaren Baustein. Aus mehreren ähnlichen Tickets werden eins – das System lernt, ohne dass jemand es anfasst.

3) Spezifizieren.

Ein dritter Skill macht aus dem Kandidaten ein vollständiges Ticket. Er prüft dabei unsere bisherigen Architektur-Entscheidungen und benachbarte Tickets. Und bei allem, was man später sehen kann, baut er einen klickbaren Dummy – bevor eine einzige Zeile echter Code existiert. So diskutieren wir an etwas, das man anklicken kann, statt an einem Konzeptpapier. Erst nach Freigabe geht das Ticket in die Umsetzung.

4) Bauen.

Ein Coding-Agent setzt das Ticket um, wobei er ein ganzes Set an Skills und Subagenten nutzt. Er arbeitet sich selbstständig durch Korrekturschleifen, wobei wir jede auf maximal drei Runden begrenzt haben, um Token-Explosionen zu vermeiden. Ist das Problem nach drei Schleifen nicht gelöst, geht es zurück an einen Menschen.

5) Testen.

Jedes Feature läuft durch zwei Testschichten. Die erste ist automatisch: Über 1.400 Tests laufen bei jedem Commit sofort durch – sie prüfen, ob das Neue etwas Bestehendes bricht. Die zweite ist gezielt: Für jedes neue Feature entstehen acht bis zwölf spezifische Szenarien – vom normalen Durchlauf bis zu dem, was bei einem Abbruch passiert. Ein Mensch klickt sie durch und meldet nur zurück: bestanden oder nicht. Den finalen Knopf, der das Feature live schaltet, drückt immer ein Mensch. Und über der ganzen Kette gilt eine Regel: Niemand darf sagen „das sollte funktionieren“ – weder Mensch noch KI. Erlaubt sind nur zwei Aussagen: „getestet, hier ist der Beleg“ oder „nicht geprüft“. Im Wort „sollte“ verstecken sich genau die Fehler, die später teuer werden.

6) Lernen.

Jeder Skill führt einen Lern-Log als ein gemeinsames Gedächtnis, welches in GitHub liegt. Taucht ein Fehler auf, wird er als datierte Regel in die Arbeitsanweisung geschrieben, die ihn verursacht hat. Zuletzt hatten wir eine Bezahlfunktion für fertig erklärt. Getestet war nur der Normalfall – die Zahlung geht durch. Was passiert, wenn sie fehlschlägt, hatte niemand geprüft. Aufgefallen ist das erst, als genau dieser Fall eintrat. Wir haben den Fehler behoben und die Test-Anweisung um eine Regel ergänzt: Bei allem, was Geld oder Zugriffsrechte betrifft, wird der Fehlerfall immer mitgetestet. Dieser Fehler kann jetzt nicht mehr durchrutschen – das System fängt ihn ab.

Diese sechs Stationen sind nur die Oberfläche. Dahinter steckt mehr: Allein der Coding-Agent arbeitet mit Dutzenden eigener Arbeitsanweisungen, und auch der klickbare Dummy hat seinen eigenen kleinen Prozess. Wir haben also innerhalb des Systems diverse Sub-Systeme gebaut. Egal, wie tief man hineinzoomt, überall gilt dasselbe Prinzip: Die KI macht die Arbeit, ein Mensch bestätigt an einer klar definierten Stelle. Und alle Stationen schreiben in dieselbe Struktur – ein gemeinsames Gedächtnis. Es gibt keine zweite Wahrheit in E-Mails oder Chats.

Leg den Exkurs vom Anfang daneben, und du findest alle Bestandteile wieder: Der Zweck kam aus der Rückwärts-Frage. Die Elemente sind die Skills, die Agenten und wir als Team. Die Verbindungen sind die Stationen, deren Ergebnis jeweils das Eingabeformat der nächsten ist. Der Speicher ist die Datenbank mit den Lern-Logs und die Wissensbasis. Die Regeln sind die Stopps und die Verifikationsregel. Und die Rückkopplung ist der Weg vom Fehler zur datierten Regel.

Wir haben den Großteil der letzten Wochen in den Aufbau des Systems gesteckt. Seitdem beschleunigt es unsere Umsetzung jeden Tag. Sobald wir Klarheit darüber haben, was wir bauen wollen, kann das System den Großteil der Umsetzung übernehmen und uns an den kritischen Stellen reinholen. Heute purzeln Features im Stundentakt raus. Egal wie schnell wir Prompts in unseren Agent gesprochen hätten, das hätten wir sonst niemals geschafft.

4 Fragen an das System

Ich habe mich gefragt, wie sich dieses systemische Denken auf andere Bereiche übertragen lässt. Du kannst dir dafür vier Fragen stellen:

Gedächtnis: Wo schreiben und lesen alle Schritte dieselbe Struktur? Eine Quelle der Wahrheit, nicht fünf Tools.
Verzahnung: Ist das Ergebnis jedes Schritts genau das Eingabeformat des nächsten? Designe die Schnittstelle, nicht den Schritt.
Human in the Loop: Was erledigt die KI, und wo genau bestätigt ein Mensch? Platziere den Menschen dort, wo Fehler teuer oder unumkehrbar wären. Nimm den menschlichen Flaschenhals aus der reinen Umsetzung komplett raus.
Rückkopplung: Wo wird aus einem Fehler oder einer Erkenntnis eine Regel, die einen früheren Schritt verändert und dadurch verbessert?

Wer eine dieser Fragen offen lassen muss, hat eine Sammlung von Einzellösungen.

Wir haben systemisches Denken nie bewusst erlernt. Unser KI-Betriebssystem und jetzt das Coding-System waren unser Trainingsplatz. Die vier Fragen funktionieren überall dort, wo Arbeit in wiederkehrenden Schritten durch mehrere Hände läuft:

Marketing-Kampagnen: Ein Briefing-Format als Gedächtnis, aus dem alle Kanal-Assets entstehen. Die Performance-Daten der letzten Kampagne fließen als Regeln zurück ins Briefing. Jede Kampagne startet auf dem Niveau, das die vorherige erreicht hat.
Vertrieb: Gesprächsnotizen in fester Struktur, daraus entstehen Angebot und Nachfassen. Jeder verlorene Deal verändert die Qualifizierungsfragen für den nächsten.
Monatsabschluss in der Buchhaltung: Belege und Abweichungen laufen durch eine feste Prüfkette. Jede einmal erklärte Abweichung wird zur automatischen Prüfregel für den nächsten Monat.

Und wo passt es nicht? Überall dort, wo Arbeit einmalig ist oder die Rückkopplung nichts zu lernen hätte – ohne Wiederholung gibt es keinen Lerneffekt. Und dort, wo die Komplexität so hoch ist, dass sich die Verzahnung nicht sauber definieren lässt – dann wird das System zur Bastelei. In beiden Fällen ist eine einfache Automation die ehrlichere Wahl.

Ich habe natürlich einen Skill gebaut, der dich beim Systemdesign unterstützt:

System-Design Skill

Der Weg ist das Ziel

Einen Prozess in seine Einzelteile zu zerlegen und als System (mit KI im Kern) neu zusammenzusetzen ist natürlich kein Spaziergang im Park. Was sich hier im Artikel möglicherweise als “ist ja klar” liest, war für uns eine steile Lernkurve, die längst noch nicht abgeschlossen ist.

Was zur Wahrheit dazugehört:

Man versteht die Bausteine am Anfang nicht vollständig. Wir haben die Verzahnung oft umgebaut, weil sich erst im Betrieb zeigte, welche Information der nächste Schritt wirklich braucht. Die automatische Verbesserung im Betrieb, von der oben die Rede war, funktioniert erst, seit die Verzahnung stimmt. Das System selbst muss iteriert werden – es steht nie beim ersten Wurf.
Vollautomatisierung ist eine Falle. Viele unserer menschlichen Qualitätstore existieren, weil vorher Dinge passiert sind, die wir so nicht wollten. Mehr Autonomie ist nicht automatisch besser. Die Kunst liegt darin, die wenigen Stellen zu finden, an denen ein Mensch unverzichtbar ist – und dort konsequent zu stoppen. Auf der anderen Seite hatten wir teilweise noch Menschen in Prozessen eingesperrt, die KI schon längst eigenständig ausführen konnte.
Die Verstärkung hat eine Bedingung. Die Lern-Logs/das Gedächtnis füllen sich automatisch – aus den Anpassungen, die wir vornehmen. Aber das gilt nur für Arbeit, die durch das System läuft. Der schnelle Fix am System vorbei ist verlockend, und genau in dem Moment lernt das System nichts. Wer diese Disziplin nicht hält, hat nach drei Monaten wieder eine Sammlung von Einzellösungen. Das erfordert harte Disziplin in der eigenen Arbeitsweise.

So ist es nunmal mit allen Dingen. Man lernt nur, wenn man es selbst macht.

🏁 Fazit

Ein System aus einem Zweck, Elementen, Verbindungen, einem Speicher, Regeln und Rückkopplung. Bestehende Prozesse in Systeme verwandeln und dabei KI als wesentliches Element mitdenken, ist aus meiner Sicht eine der wichtigsten Fähigkeiten im KI-Zeitalter.

Bevor du also das nächste mal einen Prozess automatisieren willst, frage dich: