Systeme entwerfen, die sich selbst bauen
Die meisten Softwareentwickler, Tech Leads und DevOps-Engineers beginnen ihre Laufbahn als Builder, als Menschen, die bauen.
Sie bauen Systeme, Apps, Komponenten, Themes, Patterns, Module und Pipelines. Sie optimieren Layouts, beheben Randfälle, sichern die Kompatibilität und bringen Systeme Commit für Commit voran. Die Arbeit ist präzise, praxisnah und zutiefst technisch.
Doch irgendwann verschiebt sich etwas.
Die besten Praktiker hören nicht auf zu bauen, aber sie beginnen, in Systemen zu denken.
Vom Builder zum Systemdenker
Der Wandel: vom Ergebnis zu den Regeln
Als Builder liegt der Fokus auf dem Ergebnis: Komponenten, Templates, Seiten, Features, Bibliotheken, Anwendungen.
Als Systemdenker verschiebt sich der Fokus auf die Regeln: Einschränkungen, Wechselwirkungen, Feedback-Schleifen.
Statt zu fragen „Wie sieht diese Komponente aus?“, stellen Systemdenker andere Fragen: Welche Regeln gelten für diese Komponente? Was darf mit ihr interagieren? Wie verhält sie sich bei Veränderungen? Wie bleibt die ursprüngliche Absicht über die Zeit erhalten?
Dieser Wandel führt ganz natürlich zu agentischen Systemen.
Wenn Design aufhört, statisch zu sein
Moderne Designsysteme enthalten bereits Logik: Tokens definieren Einschränkungen, Komponenten definieren Struktur, Patterns definieren Verhalten.
Dennoch hängen die meisten Systeme weiterhin von aufwendiger menschlicher Orchestrierung ab.
KI-Agenten bringen ein anderes Modell mit: Systeme können ihre eigenen Regeln durchsetzen, Entscheidungen fortlaufend validieren, auf den Kontext reagieren und sich intern koordinieren.
Hier entwickelt sich Design von der Dokumentation zu ausführbarer Logik.
Wohin die Reise geht
Der Fokus liegt jetzt darauf, diese Ideen in realen, funktionierenden Systemen umzusetzen, nicht als Experimente, sondern als Fundament.
1. Tiefere Integration von KI-Agenten in Design-Tools (Figma)
Auf dem Weg zu agentischen Designsystemen
Design-Tools sollten keine passiven Leinwände sein.
Das Ziel: KI-Agenten in Figma zu integrieren, die Design-Tokens und Komponenteneinschränkungen verstehen, Entscheidungen in Echtzeit validieren, Designabsichten in Regeln auf Systemebene übersetzen und als Partner auftreten, nicht als bloße Exporteure.
Damit rückt Design weiter nach vorn, dorthin, wo die Absicht erhalten bleibt, statt später erraten zu werden.

2. Skalierbare Verwaltung von KI-Agenten
Ziel: 150 Agenten, einer pro Komponente
Statt einer einzigen Allzweck-KI setzen Teams zunehmend auf viele spezialisierte Agenten.
Jede Komponente bekommt ihren eigenen Agenten mit definierten Verantwortlichkeiten, klaren Grenzen und einem Bewusstsein für verwandte Komponenten.
Das spiegelt wider, wie gesunde Systeme wachsen: durch Spezialisierung, Koordination und klare Verträge.
3. Agenten mit echten Fähigkeiten, Werkzeugen und Plugins
Agenten müssen handeln können.
Das heißt, sie brauchen Skills (Barrierefreiheits-Know-how, Designvalidierung, Performance-Bewusstsein), Werkzeuge (Linter, Test-Runner, Design-APIs) und Plugins (Storybook, Drupal, CI-Pipelines, Figma-Integrationen).
Ein Agent ohne Werkzeuge bleibt Theorie. Ein Agent mit Werkzeugen wird selbst Teil des Systems.
4. Intelligentere automatisierte funktionale Abnahmetests
KI-gesteuert und absichtsbewusst
Klassische Tests prüfen das Ergebnis. Agentengesteuerte Tests verstehen das Verhalten.
Im Mittelpunkt stehen KI-Agenten, die User Journeys durchdenken, funktionale Tests, die die Absicht verstehen statt nur Selektoren, Systeme, die Tests gemeinsam mit den Komponenten weiterentwickeln, und weniger fragile Tests bei zugleich höherem semantischem Vertrauen.
Testen wird zu einer weiteren Schicht der Systemintelligenz.
TDD & BDD im Zeitalter der KI: Warum KI-Agenten 100 % mehr Test-First-Entwicklung verlangen
Warum das wichtig ist
Teams bauen Systeme, die ihre Schöpfer überdauern, sich laufend anpassen und langfristige Designentscheidungen weitertragen.
In dieser Welt lässt sich manuelle Kontrolle nicht skalieren. Gut definierte Regeln dagegen schon.
Designer, Entwickler und KI-Agenten müssen innerhalb desselben logischen Rahmens arbeiten: ein gemeinsames System aus Einschränkungen und Absichten.

Der Weg vom Builder zum Systemdenker bedeutet nicht, die Umsetzung aufzugeben. Es geht darum, Systeme als mehr zu sehen als eine Sammlung von Einzelteilen.
Der nächste Schritt ist, die Regeln zu entwerfen, mit denen Systeme denken, sich anpassen und weiterentwickeln können.
Softwareentwickler, Tech Leads und DevOps-Engineers, die diesen Schritt gehen, bauen nicht mehr nur, sie schaffen die Voraussetzungen dafür, dass Systeme sich selbst bauen.