Was fordert das Critical Design Engineering Manifest?

Critical Design Engineering: Ein Manifest für den Umgang mit KI-Code

Michael Dobler

Autor Dr. Web

5. September 2026

2 Min. Lesezeit

Sobald KI-Agenten immer größere Teile des Frontend-Codes schreiben, verschiebt sich die Arbeit der Entwickler vom Tippen zum Prüfen. Die australische Produktdesignerin Pip Shea hat dafür ein Manifest vorgelegt, das ein Aktivisten-Papier von 2011 fortschreibt. Elf knappe Thesen sagen, wie Design Engineers die Kontrolle behalten, statt jeden Vorschlag der Maschine durchzuwinken.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Critical Design Engineering beschreibt eine Haltung, keine neue Stellenausschreibung: den kritischen Blick auf Code, den heute immer öfter ein Modell erzeugt. Pip Shea, Produktdesignerin bei der Forschungsagentur CSIRO, stellte ihre elf Thesen unter eine freie Lizenz und befeuert eine Debatte, die Agenturen und Inhouse-Teams gerade konkret betrifft.

Das Wichtigste in Kürze

Das Manifest überträgt das „Critical Engineering Manifesto“ von 2011 auf die Ära der KI-Agenten; Autorin ist Pip Shea (CSIRO).
Kernidee: Code gilt als Gestaltungsmaterial, jedes generierende Werkzeug zugleich als Fähigkeit und als Risiko.
Zwei Thesen zielen direkt auf die Praxis, das „Warum“ einer Entscheidung gehört ins Repository, und die Freigabe zählt als Unterschrift.
Für DACH-Teams zählt die Haftungsfrage, denn die Verantwortung für ausgelieferten Code bleibt beim Anbieter, nicht beim Modell.

Woher kommt das Manifest, und was will es?

Weißes Papier mit Text „Manifest“, Aufkleber „Code“ und Stempel „freigegeben“ — Critical Design Engineering: Code als Gestaltungsmaterial zwischen Entwurf und Technik, basierend auf dem Critical Engineering Manifesto von 2011

Das Papier ist ausdrücklich ein Remix. Julian Oliver, Gordan Savičić und Danja Vasiliev veröffentlichten 2011 das „Critical Engineering Manifesto“, zehn Thesen, die jede Technik als Machtfrage lasen.^[1] Shea überträgt diese Haltung auf die Softwaregestaltung. Ein Critical Design Engineer bewegt sich bewusst zwischen Entwurf und Technik und behandelt Code als Gestaltungsmaterial, dem er zugleich misstraut.^[2]

Den Kern bildet ein Doppelblick auf die Werkzeuge. These 1 nennt jedes Tool, das an ihrer Stelle generiert, „zugleich Fähigkeit und Bedrohung“. These 4 mahnt, hinter der Faszination der KI-Ausgabe den steuernden Kontext zu erkennen.

Warum trifft das den Agenturalltag?

Die eigentliche Verschiebung betrifft die tägliche Arbeit. Je mehr Code aus dem Modell fällt, desto mehr wird aus dem Schreiben ein Freigeben. Genau hier setzt Shea an: These 5 verlangt, das „Warum“ einer Entscheidung ins Repository zu schreiben, weil der Code nur festhält, was entschieden wurde, nicht warum. These 9 macht die Freigabe zur Unterschrift; die Verantwortung bleibt bei der Person, die den Code einreicht.

Das Manifest greift damit ein Muster auf, das an anderer Stelle bereits sichtbar wurde: dass KI-Agenten das gemeinsame Verständnis im Code aushöhlen und dass Teams zunehmend hinter der KI aufräumen. Wie ein Design Engineer sein Wissen für Agenten strukturiert, zeigt der Fall der elf ladbaren KI-Skills.

These 3 zieht daraus eine Gestaltungsregel: sichtbare Nähte statt nahtloser Automatik, damit Nutzer ein System noch verstehen und anpassen können. Für Agenturen, die Software an Kunden übergeben, entscheidet das über eine wartbare Lösung oder eine Blackbox.

Ein Modell schreibt den Code in Minuten, die Verantwortung dafür lässt sich nicht mitgenerieren. Die Haftung bleibt bei dem, der freigibt, und genau das sollten Teams schriftlich festhalten.
— Markus Seyfferth, Chefredakteur Dr. Web

Das Manifest auf einen Blick

Herkunft, Umfang und die drei Thesen, die den Freigabe-Alltag am stärksten betreffen

2011

Ursprung: das Critical Engineering Manifesto, das Pip Shea neu fasst

durchnummerierte Thesen (0 bis 10) statt zehn wie im Original

frei

unter der GNU Free Documentation License veröffentlicht und remixbar

Drei Thesen für die Freigabepraxis

These 3

Sichtbare Nähte statt nahtloser Automatik, damit Nutzer ein System verstehen und anpassen können.

These 5

Das „Warum“ einer Entscheidung gehört ins Repository, weil der Code nur festhält, was entschieden wurde.

These 9

Die Freigabe ist eine Unterschrift: „to push is to sign your name“.

Was heißt das konkret für DACH-Teams?

Für den deutschsprachigen Raum steht die Haftung im Vordergrund. Ob Mensch oder Agent den Code geschrieben hat, ändert nichts daran, dass die Verantwortung für das ausgelieferte Produkt beim Anbieter bleibt, nicht beim Modell. Shea nennt die Zusammenführung von Code, These 10, „die begehrteste und zugleich gefährlichste Form der Preisgabe“.

Praktisch lässt sich das Manifest auf wenige Gewohnheiten herunterbrechen. Die Begründung jeder Änderung gehört in den Commit oder in ein Entscheidungsprotokoll, geprüft wird vor dem Merge statt danach, und die Freigabe zählt als bewusste Zusage. Keine dieser Regeln braucht neue Software, nur Disziplin.

Für Teams, die KI-Code produktiv einsetzen, sind die elf Thesen eine Checkliste für die eigene Freigabepraxis. Lesen Sie das Manifest gerne im Original und gleichen Sie es mit Ihrem Review-Prozess ab.