Ästhetik des Ungewissen: Kann Tech von Kunst lernen?

Der Kollaps des rein technischen Paradigmas

Wir haben die Softwareentwicklung traditionell als Tochter der Mathematik und der Ingenieurswissenschaften angesehen. Sie galt uns als das ultimative Bezugssystem der Vernunft – eine Disziplin, die ihre geistige Radikalität im Zeitalter der Aufklärung erhielt und darauf baute, die Welt durch absolute Logik, Kausalität und Berechenbarkeit beherrschbar zu machen.

Es stellt sich jedoch heraus, dass diese Verortung der Realität nicht gerecht wird. In einer hyperkomplexen Gegenwart, in der wir Systeme nicht mehr rein deterministisch konstruieren, sondern emergente, oft opake Software-Strukturen und KI-Modelle orchestrieren, stößt das rein rationalistische Paradigma an seine Grenzen. Die Aufklärung hat uns beigebracht, Methoden unter unvollständiger Information zu perfektionieren – aber nicht, wie wir umgehen, wenn Systeme eine rätselhafte Eigendynamik entwickeln, die sich der vollständigen Übersicht entzieht.

Die Kompetenzen des klassischen Ingenieurs reichen nicht immer aus, um mit Ambiguität, unvorhersagbaren Zuständen und qualitativen, semiotischen Gefügen sicher zu hantieren. Wer darauf trainiert ist, das Chaos rein mathematisch zu eliminieren, verstummt, wenn Kontrolle zur Illusion wird. Maschinenzeitalter, Industrialisierung und Ingenieursdisziplinen fußen in einem Bezugssystem aus Ursachen und Wirkungen – im Druck, der einen Kolben antreibt, in binären Zuständen (Wahr und Falsch), in Ordnung. Unordnung ist nicht erwünscht. Unerklärliche Phänomene werden vom Geist der Wissenschaft begrifflich kenntlich gemacht – als „Spukhaftes“ bei Einstein oder als „Dunkles“, wie bei dunkler Materie oder Energie. Wie der Kirche das heliozentrische Weltbild missfiel, passten nicht alle chaotischen Beobachtungen in die geordneten Bezugssysteme vernünftiger Wissenschaften. Chaos und Unvorhersagbares bedeuten Kontrollverlust, Erosion von Deutungshoheit und manchmal die Disruption der Methode. In der Softwareentwicklung trat zuletzt viel „dunkles Engineering“ zutage.

„Softwareentwicklung ist keine reine Ingenieurswissenschaft mehr. Sie wandelt sich zu einer kreativen Disziplin, in der die kompetente Arbeit mit Form, Stoff, Bedeutung und Ungewissheit essentiell wird.“

Warum? Weil die reine Herstellungstechnik zum Rohstoff degradiert wird.

• Code im Überfluss: Wenn generative KI fehlerfreien Standard-Code als zeichenbasierte Massenware ausspuckt, kollabiert der Marktwert des reinen Handwerks der Code-Erstellung. „Fehlerfreier Code“ ist kein Differenzierungsmerkmal mehr, sondern der absolute Mindeststandard. KI liefert selten nur Perfektion – häufiger eine überzeugend formulierte Unvollständigkeit, die erst unter Produktivlast sichtbar wird.
• Shift der Kompetenzen: Wenn die herstellende Seite der Entwicklung (operative Fleißarbeit wie Code-Schreiben) automatisiert ist, verschiebt sich der menschliche Kernwert auf Urteil unter Unsicherheit (Phronesis). Es geht um die Fragen: Wann legen wir uns fest? Wann modellieren wir weiter? Was nehmen wir weg? Welche Form gibt das System?
• Neue Rollen: Der Engineer wandelt sich vom Konstrukteur vernünftiger Kausalketten zum Komponisten und Kritiker, der Systeme kuratiert und deren Verwandlung beiwohnt.

Aber machen wir uns nichts vor: Diese Analogie hat schmerzhafte Grenzen.

Ein Künstler ist primär sich selbst und seinem Werk verpflichtet. Seine Fehler sterben mit ihm. Software dagegen scheitert öffentlich, skaliert das Desaster und hat echte Konsequenzen für Menschen und Gesellschaft. Nicht jede Software ist systemkritisch, aber viele systemkritische Infrastrukturen funktionieren nur mit Software. Wo die Kunst die Radikalität der Freiheit feiern kann, muss Engineering eine devote Disziplin der Verlässlichkeit bleiben. Der Transfer künstlerischer Kompetenz ist kein Freifahrtschein für romantische Willkür – sondern das Erlernen einer überfälligen Praxis für den Umgang mit dem Unbekannten.

„Die nächste Generation von Software wird nicht von Maschinen geschrieben – sondern von Menschen, die gelernt haben, mit Unsicherheit, Ambiguität und Ästhetik umzugehen.“

1. Ambiguität ertragen: Der leere Raum als Chance

Problem: Die Tech-Krankheit der binären Konditionierung

Programmierer sind (mal mehr, mal weniger) auf das Binäre konditioniert: Ein Bug existiert oder nicht; ein System läuft oder stürzt ab. An, Aus. Diese binäre Konditionierung – als Erbe des rationalistischen Weltbilds – führt zur Lähmung, sobald Probleme komplex, qualitativ diffus, opak oder zu menschlich werden. Chaos ist nicht gern gesehen.

• Beispiel: Ein Team diskutiert wochenlang im Vakuum über eine starre API-Spezifikation, obwohl das eigentliche Problem noch gar nicht verstanden ist. Man versucht, den Nebel wegzuberechnen, bevor man ihn betreten hat.
• Folge: Starre Gebilde und bollwerkhafte Architekturen auf falschen, teils erzwungenen Annahmen, die beim ersten Kontakt mit der Realität zerbrechen.

Lösungsoption: Die künstlerische Kompetenz im Trüben zu fischen

Ein Maler beginnt mit der absoluten Leere der Leinwand und erträgt die existenzielle Angst vor ihr. Leere ist gradenlos: Sie fordert heraus und offenbart jede Unfähigkeit der Gestaltung. Kunst kapituliert nicht vor dem Unbekannten; sie existiert im Raum der Ambiguität. Ein Maler lernt, dass sich Qualität erst im Prozess offenbart – im Spannungsraum zwischen Maler und Gemälde. Es gibt keine „einzig wahre“ Lösung; der Schaffensprozess spielt jenseits binärer Konditionierung.

Transfer für Tech:

• Softwarearchitekten müssen lernen, Ambiguität nicht sofort durch starre, protzige Spezifikation zu erschlagen.
• Wer Lösungen zu früh determiniert und durch bekannte Patterns reflexhaft festlegt, um Spukhaftes aus dem Sichtfeld zu schieben, baut Systeme, die nicht wirklich an reale Bedingungen angepasst sind.
• Künstlerische Kompetenz im Transfer bedeutet, Gestaltung als Prozess zu begreifen – mit der Demut zu akzeptieren, dass man die Zukunft heute noch nicht berechnen kann. Engineering muss das Unbekannte und Chaotische mitdenken.

„Ein guter Engineer schreibt keinen Code, der heute funktioniert – er schreibt Code, der sehr wahrscheinlich auch morgen noch funktioniert, obwohl niemand weiß, was morgen kommt.“

Konkrete Umsetzung: Systeme, die anpassbar sind

• Das Privileg des Wartens (die Grenze der Metapher): Das „Ertragen der Leere“ als Tugend zu preisen, ist leicht – wenn man den Spielraum dafür hat. Wo Systeme verlässlich funktionieren müssen, ist White Space oft Luxus. Juniors, Teams unter VC-Druck oder kritische Infrastruktur (Medizin, Finanzen) können nicht im Ungefähren verweilen. Dort sind Determinierung und die Eliminierung von Doppeldeutigkeiten Pflicht – Risiko- und Schadensminimierung. Die Kompetenz liegt darin zu erkennen, wo Ungewissheit kreativer Raum ist – und wo sie Fahrlässigkeit bedeutet.

• Aus der Praxis: Ich habe oft erlebt, dass Events und Schnittstellen definiert wurden, bevor klar war, welches Problem Nutzerinnen und Nutzer nachts wach hält. Oft wären zwei Wochen Warten, fünf Interviews – weniger Code, mehr Insights – die bessere Wahl gewesen, auch wenn das wie Stillstand wirkt. Am Ende spart man Implementierung, wenn man drei klare Zustände und einen echten Fehlerfall findet, den Workshops vorher nicht benennen konnten. Keine Romantik des Unbekannten – sondern Gespür dafür, wann Robustheit gegen die Realität wichtiger ist als defensive Code-Massen.

2. Negative Capability: Die Kunst des bewussten Nicht-Wissens

Problem: Der Hype-Junkie-Reflex

Im modernen Engineering rennen wir panisch dem nächsten Hype hinterher (Microservices! Serverless! AI-native!). Nüchtern betrachtet ist diese Jagd nach dem neuesten Stack selten rational – sie ist wohl eher psychologisch begründet. Wir stopfen Frameworks in die Architektur, um Orientierungslosigkeit zu betäuben.

• Beispiel: Ein Team peitscht eine Kubernetes-Architektur durch, obwohl ein einfacher Docker-Container gereicht hätte.
• Folge: Over-Engineering, technische Dekoration und die Abkehr davon, das Problem zu sezieren, Rahmenbedingungen zu verstehen und elegant zu lösen.

Möglicher Ausweg: Keats’ Erbe für das Engineering

Der Dichter John Keats prägte Negative Capability – die Fähigkeit, in Unsicherheiten, Mysterien und Zweifeln zu existieren, ohne irritiert nach harten Fakten und sofortiger Auflösung zu greifen.

Transfer für Tech:

• Ein ‚künstlerisch geschulter‘ Engineer hält das Nicht-Wissen aus – er rennt nicht weg.
• Er beobachtet mit Aufmerksamkeit, ohne vorschnelle Einordnung, versteht Nuancen und widersteht dem Reflex, das hippe Erstbeste wie ein Pflaster über Unwägbarkeiten zu kleben.
• Es ist die hohe Schule des bewussten Nicht-Tuns, bis die Natur des Problems Form annimmt.

„Der schlechteste Engineer ist nicht der, der scheitert – sondern der, der aus Angst vor Orientierungslosigkeit das Falsche perfekt konstruiert.“

Konkrete Umsetzung: Technologieauswahl mit Bedacht

• Technologieauswahl:

  • Nicht: „Wir nehmen Kubernetes, weil der Markt uns Struktur und Zugehörigkeit verspricht!“
  • Sondern: „Wir halten das Vakuum aus, reduzieren Abhängigkeiten auf ein Minimum und entscheiden erst, wenn die Erkenntnisse uns zwingen.“

• Architekturentscheidungen:

  • Nicht: „Wir bauen Microservices, um Komplexität durch Zersplitterung zu entkommen!“
  • Sondern: „Wir designen agnostisch genug, dass sich morgige Paradigmen schmerzfrei einfügen lassen.“

3. Reduktion und Dissonanz: Code als Partitur

Problem: Die Feature-itis

Ingenieurmäßiges Denken, das im Lösen aufgeht, neigt zur Akkumulation: Feature-itis, Over-Engineering. Weil wir es können, bauen wir es ein – nicht nur Features, sondern Zierwerk und die 17. Abstraktionsebene. Heraus kommen digitale Landschaften, überfrachtet wie ein barockes Schloss vor dem statischen Kollaps.

• Beispiel: Ein Frontend-Team türmt (React, Next.js, Tailwind, TypeScript, Zustand, GraphQL, Docker, Kubernetes, AWS Lambda, Redis, PostgreSQL, Prisma, tRPC, Zod, Jest, Cypress, Storybook) auf – für eine einfache Landingpage. Monumentales Missverhältnis der Mittel.
• Folge: Unübersichtlichkeit, explodierende Wartungskosten, Verlust von Lesbarkeit und formaler Präzision.

Lösung: Die Minimal-Music-Ästhetik

In der Musik von Steve Reich oder Philip Glass lebt die Wirkung von Mustern, Pausen und radikaler Reduktion. Künstler wissen: Weglassen stärkt das Werk.

Transfer für Tech:

• Elegante Software wird nicht akkumuliert – sie ist wie Minimal Music.
• Code ist nicht nur Funktionsliste – er kann Partitur sein.
• Ein exzellenter Engineer schreibt Code, um ein Problem mit minimalem digitalen Material im Raum stehenzulassen. Wegnehmen ist Kompetenz, nicht Unvermögen.

„Perfektion ist nicht, wenn man nichts mehr hinzufügen kann – sondern wenn man nichts mehr wegnehmen kann.“

Konkrete Umsetzung: Weniger ist mehr

• Die unschöne Wahrheit über technische Schulden: Tech-Essays romantisieren gern „Schulden als kalkulierte Dissonanz“, die man später auflöst. In der Musik löst der Komponist selbst auf. In der Software trägt sie fast immer das nächste Team und die Kunden. Technische Schulden (ein Begriff, den ich kaum noch hören kann) sind selten Kunst – meist Extraktion hypothetischer Ressourcen aus der Zukunft. Reduktion heißt knallharter Verzicht: Features gar nicht erst bauen. Wenn tausende Zeilen Code per KI entstehen, fällt das schwer – obwohl heute PRs/Tag und Token/Monat zählen, geht es um fokussierte Relevanz.

4. Der Artefakt-Charakter: Vom Tool zum Werk

Problem: Software als Wegwerfprodukt

Die digitale Welt wurde zum zynischen Gebrauchsgegenstand – flüchtig, austauschbar, optimiert auf den nächsten Klick. KI treibt Software weiter in den Strudel der Inflation. Viele MVPs sind nicht nur minimal viable, sondern qualitativ minimal – oft nur Prototypen.

• Beispiel: Ein hastiges API-Design, das nach drei Jahren vollständig refaktorisiert werden muss, weil niemand die Intention derer versteht, die es für erste Nutzertests hingeworfen haben.
• Folge: Digitaler Müll, toolifizierter AI-Slop und der Verlust von Handwerkskunst – plus wachsende Wertlosigkeit.

Lösung: Code als zeitloses Artefakt

Kunst will Artefakt schaffen – nicht weil es nützlich ist, sondern wegen innerer Wahrheit und struktureller Integrität.

Transfer für Tech:

• Weil KI das mechanische Handwerk übernimmt, rückt der Mensch in die Rolle von Kurator und Kritiker.
• Code ist Manifestation von Geist – Werk mit ästhetischem Wert. Software erfüllt zugleich Nutzen; dafür braucht es Verständnis und gestalterische Kompetenz. KI gewichtet Standardmuster und generiert Beliebiges statt Besonderes – Kuratoren werden wichtiger.
• Manchmal ist Software so ausbalanciert und selbsterklärend wie eine Skulptur. Artefakte dieser Qualität brauchen enorm menschliches Zutun: KI repliziert, hat aber keinen Geschmack. Urteilskraft wird im Mensch-Maschinen-Loop entscheidend.

„Guter Code ist kein reines Werkzeug – er ist ein Artefakt. Er überdauert nicht, weil er mechanisch funktioniert, sondern weil er im Inneren architektonische Schönheit ausstrahlt.“

Manche Artefakte überdauern Jahrtausende – nicht weil sie nützlich im Alltag blieben, sondern weil in ihrer physischen Form Geist, Astronomie und Handwerk verschmolzen. Der antike Mechanismus von Antikythera ist dafür das drastischste Beispiel: ein verlorenes, fast mystisches Werkzeug, in dem Ästhetik und Funktion eins wurden. Unser AI-Slop hingegen verrottet oft schon nach drei Jahren, weil weder Intention noch Integrität in der Substanz saßen.

Konkrete Umsetzung: Handwerkskunst statt Massenware

• Von der digitalen Kathedrale zur ehrlichen Kapelle: Die Kathedralen-Metapher hinkt. Kathedralen entstanden oft durch Ausbeutung und dogmatische Ideologie. Wer im Tech „zeitlose Kathedralen“ baut, maskiert oft Hero-Engineering. Die meiste Software muss keine Kathedrale sein – eine gut gezimmerte Kapelle genügt. Artefakt-Charakter zeigt sich in Ethik und Intention, nicht in monumentaler Unvergänglichkeit. Maschinen haben beides vorerst nicht.

• Handwerk ohne Monumentalismus: Schnittstellen, die in zwei Jahren noch lesbar sind, weil ihre Semantik ehrlich ist. Dokumentation, die sich wie ein klarer Essay liest. Code-Reviews, die Rhythmik und Lesbarkeit ernst nehmen. Struktur, die Orientierung gibt – keine neuen Rätsel.

Fazit: Die Synthese der Stilblüte

Der Tech-Sektor braucht keine besseren Tippmaschinen – das erledigt die Automatisierung. Was wir brauchen, sind kreative Denker, holistische Gestalter und pragmatische Architekten, die Chaos strukturieren, ohne Lebendigkeit und Sinn zu töten.

Trifft aufklärungsgeprägtes Engineering auf die kompetente Haltung des Kunstschaffens, entsteht keine glatte Illusion von Kontrolle, sondern eine spannungsreiche Symbiose. Denn machen wir uns nichts vor: Software wird selten zur reinen Kunst – sie bleibt gefangen in bürgerlicher Funktionalität, während das Kunstschaffen sich entrückt und neue Perspektiven eröffnet. Genau in dieser Spannung liegt der Gewinn: Software bleibt funktional, doch ihr Herstellungsprozess kann vom Kunstschaffen lernen, um in chaotischeren Zeiten angebrachter zu wirken.

• Code wird nicht mehr nur nach Fehlerfreiheit bewertet – das ist Maschinen-Mindeststandard.
• Er wird vielmehr danach bewertet, wie viel menschliches Urteil, Reduktion und Nachhaltigkeit ihm zugrunde liegen.
• Wer diesen Shift vollzieht, bricht aus dem Korsett des binär konditionierten Technikers aus – und weiß, wo Poesie endet und gesellschaftliche Verantwortung beginnt.

„Die nächste Generation von Software wird nicht von Maschinen gestaltet – sondern von Menschen, die gelernt haben, mit Unsicherheit, Ambiguität und Schönheit umzugehen. Das ist die humane Revolution im Tech-Space.“