Niemand weiß, was er tut. Nicht im banalen, leicht selbstabsolvierenden Sinn der Flurgespräche, wenn jemand die Schultern hebt und sagt, wir improvisieren alle. In einem präziseren, beunruhigenderen, vor allem strukturelleren Sinn: die Komplexität der technischen Objekte, die wir gebaut haben, hat die Verstehensfähigkeit jedes einzelnen Menschen überschritten. Nicht aus Mangel an Intelligenz oder Bildung. Aus einem Grund, der mit der Natur dieser Objekte selbst zu tun hat.
Den Großteil der Technikgeschichte hindurch war es möglich, mindestens eine Person zu finden, die ein Artefakt als Ganzes verstand. Das römische Aquädukt, der mechanische Webstuhl, die Dampflokomotive, sogar ein Flugzeug aus dem Zweiten Weltkrieg: kompliziert, ja, aber letztlich auf ein einheitliches Wissen zurückführbar. Eine ausreichend ausgebildete Ingenieurin konnte die Kausalkette von einem Ende zum anderen ziehen. Sagen: ich weiß, wie es funktioniert, warum es funktioniert, was passiert, wenn es bricht. Diese Möglichkeit war kein Detail. Sie war das Fundament der Idee technischer Kompetenz — und mit ihr der Verantwortung.
Dieses Fundament ist nicht mehr da.
Die Schwelle
Der Bruchpunkt war nicht plötzlich. Er hat sich über Jahrzehnte angesammelt, unsichtbar wie alle schichtenweisen Veränderungen. Jede über die vorige gelegte Abstraktion löste ein Problem und erzeugte ein neues: die darunterliegende Schicht undurchsichtig zu machen. Wer heute Anwendungscode schreibt, kennt das Framework nicht wirklich. Wer das Framework kennt, kennt die Runtime nicht. Wer die Runtime kennt, kennt das Betriebssystem nicht ganz. Wer das Betriebssystem kennt, kennt den Microcode des Prozessors nicht. Und niemand, wirklich niemand, kennt die ganze Abhängigkeitskette, die ein einzelnes Install-Kommando aus dem Netz zieht und Teil der Software macht.
Keine polemische Übertreibung. Eine sachliche Beschreibung. Ein durchschnittliches Software-Projekt 2026 hat hunderte direkte und tausende transitive Abhängigkeiten. Jede von jemand anderem geschrieben, mit eigenen Abhängigkeiten, eigenen Schwachstellen, eigenen Architekturentscheidungen in einem Kontext, den niemand stromabwärts je rekonstruieren wird. Software auszuführen heißt heute zu vertrauen. Nicht im edlen Sinn zwischen Personen, sondern im erkenntnistheoretischen Sinn dessen, der auf Verifikation verzichtet, weil sie materiell unmöglich ist.
Es gab eine Zeit, in der das Wort „Ingenieur“ die Möglichkeit totaler Kontrolle über das Arbeitsobjekt einschloss. Diese Zeit ist vorbei. Sie kommt nicht zurück.
Wissen als Skalenillusion
Das Problem ist nicht, dass wir wenig wissen. Es ist, dass das Wissen, das wir besitzen, nicht maßstäblich zur Komplexität dessen ist, was wir betreiben. Wir wissen Dinge. Sogar viele. Doch das Wissen, das ein modernes verteiltes System verstehen ließe, ist nicht die Summe individueller Kenntnisse: es ist Wissen, das einen Geist verlangte, der gleichzeitig Schichten zusammenhalten könnte, die ihrer Natur nach für Trennung entworfen sind.
Abstraktion, der grundlegende Mechanismus computationalen Denkens, funktioniert genau, weil sie versteckt. Verdienst und Falle zugleich. Eine gut entworfene Schnittstelle befreit dich davon, zu wissen, was darunter passiert. Wenn aber etwas schiefgeht, entdeckst du, dass „darunter“ eine Welt liegt, die niemand im Raum kennt — und vielleicht niemand auf der Welt als Ganzes. Nicht weil das Wissen nicht existierte, sondern weil es unrettbar zwischen tausenden Personen verteilt ist, die nie miteinander gesprochen haben.
Eine neue erkenntnistheoretische Bedingung. Ohne Vorbild in der Technikgeschichte, mit wenigen Analogien in der Geistesgeschichte. Am ehesten Adam Smiths Arbeitsteilung — mit einem entscheidenden Unterschied: Smith sprach von einem Produktionsprozess, in dem jede Arbeiterin ihren Teil verstand. Hier versteht niemand wirklich auch nur den eigenen Teil, weil dieser auf anderen Teilen ruht, die per Definition entgleiten.
Die zerbrochene Verantwortungskette
Wenn niemand das System als Ganzes versteht, hat die Frage, wer verantwortlich ist, keine befriedigende Antwort. Nicht aus Mangel an Kandidaten, sondern weil der Begriff der Verantwortung selbst voraussetzt, was hier fehlt: die Möglichkeit zu wissen.
Verantwortung heißt etymologisch: antwortenkönnen. Rechenschaft ablegen. Aber wie über eine Entscheidung Rechenschaft ablegen, die in einem nicht ganz verstehbaren Kontext gefällt wurde? Wie für ein System einstehen, dessen Verhalten aus Interaktionen zwischen Komponenten emergiert, die kein einzelner Akteur entworfen oder vorgesehen hat?
Das Recht, das darüber viel mehr nachgedacht hat als die Informatik, hat die Idee der Sorgfaltspflicht entwickelt: man muss nicht alles verstehen, es genügt, mit der vernünftigerweise von der Rolle erwarteten Sorgfalt zu handeln. Pragmatischer Kompromiss, der jahrhundertelang trug. Er trug, weil der Abstand zwischen wissbarem Wissen und nötiger Entscheidung durch Studium und Erfahrung schließbar war. Heute ist dieser Abstand nicht mehr schließbar. Kein Engagementproblem: ein struktureller Abstand, durch die Komplexität des Objekts erzeugt, nicht durch die Inadäquatheit des Subjekts.
Die jüngere EU-Gesetzgebung ahnt das, ohne es zu erklären. CRA, PLD, AI Act: alle versuchen, Verantwortungsketten in einem Kontext zu rekonstruieren, in dem diese Ketten physisch zerbrochen sind. Mit klassischen Mitteln: Doku-Pflichten, Konformitätsbewertungen, Risikomatrizen. Ernsthafte, oft willkommene Versuche. Aber sie ruhen auf einer stillen Annahme: dass irgendwo jemand weiß.
Der Hersteller muss die Risiken seines Produkts dokumentieren. Aber er kennt die transitiven Abhängigkeiten seines Codes nicht. Der Importeur muss die Konformität prüfen. Aber Konformität ist gegenüber Standards definiert, die Eigenschaften beschreiben, die niemand in der Praxis verifizieren kann. Der Nutzer soll informiert einwilligen. Aber die Information für eine echte Einwilligung verlangte Kompetenzen, die selbst der Software-Autor nicht hat.
Kein Zynismus. Die genaue Beschreibung einer Lage, die wir Schritt für Schritt geschaffen haben, in gutem Glauben — jedes Mal das unmittelbare Problem lösend und jedes Mal ein Gramm Undurchsichtigkeit dem Gesamtsystem hinzufügend.
Der Mythos der Spezialisierung
Ein häufiger Einwand: Spezialisierung löst es. Niemand muss alles verstehen, jedem genügt sein Teil, das Ganze wird funktionieren. Arbeitsteilung des Wissens — attraktiv, weil es die Grundsatzfrage umgeht.
Es funktioniert nicht. Weil die Grenzen zwischen den „Teilen“ willkürlich und durchlässig sind. Ein Sicherheitsproblem zieht durch alle Schichten. Eine normative Anforderung schneidet quer durch Frontend, Backend, Infrastruktur, Drittanbieter. Eine vor fünf Jahren in einem nicht mehr existierenden Kontext getroffene Architekturentscheidung beschränkt heute Entscheidungen, die der Ursprünger nicht hätte vorhersehen können.
Spezialisierung funktioniert, wenn Komponenten wirklich unabhängig sind. Software ist es nicht. Sie besteht aus Abhängigkeiten, im Wortsinn: jeder Teil hängt von anderen ab, und das Verhalten des Ganzen ist aus dem der Teile nicht ableitbar. Was die Systemtheorie Emergenz nennt — und Emergenz ist genau der Gegner der Spezialisierung. Der heimtückischste Bug lebt immer im Raum zwischen Spezialisierungen, wo niemand hinsieht, weil niemand denkt, das sei sein Gebiet.
Die Inkompetenz der Gesetzgebenden
Ein besonderer Fall verdient Aufmerksamkeit, nicht aus Anklage, sondern strukturell erhellend: die Inkompetenz derer, die Normen schreiben.
Eine Gesetzgeberin, die Software-Regeln schreibt, ist erkenntnistheoretisch in derselben Lage wie alle: sie kann das System als Ganzes nicht verstehen. Anders als ein Dev oder Architekt hat sie aber nicht einmal das partielle Wissen aus Alltagsnutzung. Sie operiert auf Beschreibungen von Beschreibungen, auf Abstraktionen von Abstraktionen, durch Beratungen vermittelt, die wiederum Spezialistenwissen vermitteln.
Kein Argument gegen Regulierung. Im Gegenteil: ein Argument über die Natur möglicher Regulierung. Was nicht ganz verstehbar ist, zu normieren, ist kein Versagen, es ist die Ausgangsbedingung. Die Frage ist nicht, ob Gesetzgebende kompetent sind — sie können es nicht im vollen Sinn sein, und nicht aus eigener Schuld. Die Frage ist, ob die produzierten Normen robust genug sind, trotz struktureller Inkompetenz derer, die sie geschrieben, anzuwenden, zu prüfen haben.
Manchmal ja. Die DSGVO hat mit allen Grenzen ein Vorsorgeprinzip eingeführt, das funktioniert, gerade weil es kein technisches Verständnis verlangt: sie behandelt personenbezogene Daten als gefährlich, unabhängig davon, ob du die spezifischen Mechanismen verstehst. Eine Norm, für Inkompetenz entworfen — und sie wirkt besser als viele, die Kompetenz voraussetzen.
Sokrates im Dev-Zyklus
Sokrates wird mit der Häufigkeit und Ungenauigkeit aller zu nützlicher Sätze ein Zitat zugeschrieben: „ich weiß, dass ich nichts weiß.“ Als Demutsgeste zitiert, manchmal als intellektuelle Eitelkeit. In der radikalen Version der platonischen Apologie ist der Punkt unbequemer: Sokrates sagt nicht bloß, sein Wissen sei begrenzt. Er sagt, wer zu wissen glaubt, sei in schlechterer Lage als wer weiß, dass er nicht weiß — denn der ergänzt seine Unwissenheit um die Illusion.
Auf die Tech-Gegenwart angewandt, gewinnt die These ein Gewicht, das Platon nicht hätte ahnen können. Die Software-Industrie ruht auf einer doppelten Wissens-Illusion: der Bauenden (die zu kontrollieren glauben) und der Nutzenden (die zu verstehen glauben). Beide funktional. Ohne die erste schriebe niemand Code, weil vollständige Ehrlichkeit lähmend wäre. Ohne die zweite nutzte niemand Software, weil echte informierte Einwilligung Massenablehnung erzeugte.
Wir funktionieren dank einer freiwilligen Aussetzung des erkenntnistheoretischen Unglaubens. Nicht anders als Finanz, Politik oder jedes komplexe System, in dem Vertrauen Verstehen ersetzt.
Mit einem Unterschied. Finanz und Politik haben institutionelles Bewusstsein ihrer epistemologischen Fragilität entwickelt. Zentralbanken existieren, weil wir wissen, dass das Finanzsystem sich nicht selbst reguliert. Verfassungen existieren, weil wir wissen, dass Macht sich nicht selbst begrenzt. Die Informatik hat noch nichts Vergleichbares. Keine Institutionen für die Bedingung, dass niemand weiß. Standards, Best Practices, Zertifizierungs-Frameworks: alles Werkzeuge, die die Möglichkeit des Wissens voraussetzen, anstatt seine Unmöglichkeit zu bearbeiten.
Entscheiden ohne zu wissen
Der Alltag in der Tech: entscheiden ohne zu wissen. Nicht im dramatischen Sinn einer Blindwette, sondern im gewöhnlichen, leicht zermürbenden Sinn dessen, der täglich Entscheidungen mit mehrjährigen Folgen trifft, gestützt auf Informationen, die er als unvollständig erkennt, in Kontexten, die sich ändern werden, für Anforderungen, die provisorisch sind.
Eine Schätzung ist eine subjektive Wahrscheinlichkeitsangabe als Prognose ausgegeben. Eine Architekturwahl ist Glaubensakt an die Stabilität nicht stabiler Bedingungen. Ein Refactoring ist eine Wette darauf, dass gegenwärtige Kosten durch zukünftige Vorteile aufgewogen werden, die niemand garantieren kann. Jeder Sprint ist angewandte Erkenntnistheorie unter Zeitdruck, geleitet von Leuten, die keine Erkenntnistheorie studiert haben und nicht dafür bezahlt werden, über die Bedingungen ihres Wissens nachzudenken, sondern Ergebnisse zu liefern.
Keine Anklage. Eine Beschreibung. Und der Punkt ist nicht, es sollte anders sein: es kann nicht anders sein. Strukturelle Inkompetenz ist kein zu lösendes Problem. Sie ist die Bedingung, in der wir operieren — solange wir Systeme bauen, deren Komplexität die Verstehenskapazität ihrer Bauenden übersteigt.
Die Frage ist nicht, sie zu eliminieren. Sondern sie zu bewohnen.
Die Inkompetenz bewohnen
Wenn Kompetenz im klassischen Sinn vollständiger Beherrschung nicht mehr erreichbar ist, ist das, was wir so nennen, etwas anderes geworden. Kein Wissen, sondern Können in Abwesenheit von Wissen. Eine Form praktischer Klugheit, näher an der aristotelischen Phronesis als an der Episteme: nicht Kenntnis erster Ursachen, sondern die Fähigkeit, in besonderen, unsicheren Situationen gut zu handeln.
Die gute Tech-Person heute ist nicht jene, die mehr weiß. Es ist, wer ihre Unwissenheit besser handhabt. Wer weiß, wo die Grenzen ihres Verständnisses liegen, fragen kann, weiß wann anhalten, Systeme baut, die vorhersehbar statt katastrophal versagen. Alles Kompetenzen — aber Kompetenzen über die eigene Inkompetenz. Meta-Kompetenzen, wenn man ein hässliches Wort für eine wichtige Idee akzeptiert.
Hier ein Paradox, das offen anzuschauen lohnt. Die Profikultur des Software belohnt Wissen und bestraft Nichtwissen. Wer zugibt, nicht zu verstehen, verliert Kredit. Wer in einem Meeting „weiß ich nicht“ sagt, gilt als schwach. Wer ehrlich schätzt, wird im Vergleich zu Optimisten bestraft. Das ganze Anreizsystem maskiert Inkompetenz statt sie zu managen — und produziert das Gegenteil: nicht erkannte, nicht gemanagte, nicht metabolisierte Inkompetenz. Gefährliche Inkompetenz.
Eine reife Profikultur täte das Umgekehrte. Sie ginge davon aus, dass niemand das System ganz versteht, und baute Prozesse, Werkzeuge, Institutionen, die unter dieser Bedingung funktionieren. Keine Utopie: das ist Ingenieurskunst der Unwissenheit, und genau das tun wir, wenn wir automatische Tests schreiben (wir prüfen, weil wir unserem Verstehen nicht trauen), Code Reviews machen (wir suchen Fehler im blinden Fleck), das Prinzip minimaler Rechte anwenden (wir begrenzen den Schaden unserer Unwissenheit).
Keine Palliativa. Die anspruchsvollsten Praktiken, die die Branche hervorgebracht hat — und alle im Kern Techniken zur Verwaltung von Inkompetenz. Niemand nennt sie so, weil der Name unbequem wäre. Aber sie sind es.
Ehrlichkeit als Methode
Vielleicht ist die einzige verfügbare Antwort auf strukturelle Inkompetenz keine Lösung, sondern eine Haltung: erkenntnistheoretische Ehrlichkeit als tägliche Praxis. Wissen, dass man nicht weiß, nicht als leere Formel, sondern als operativer Ausgangspunkt jeder Entscheidung.
Keine Lähmung. Entscheiden im Bewusstsein, blind zu entscheiden — und Sicherungsnetze proportional zu diesem Bewusstsein bauen. Dokumentieren nicht nur, was getan wurde, sondern warum und unter welchen Annahmen — denn diese Annahmen werden sich als falsch erweisen, und wer nachkommt, muss nicht die Lösung verstehen, sondern die Argumentation, die sie hervorbrachte. Aufhören, Schätzungen als Versprechen und Architekturen als Monumente zu behandeln.
Kein revolutionärer Vorschlag. Die Beschreibung dessen, was die Besten ohnehin tun — oft im Stillen, oft gegen die umgebende Kultur. Strukturelle Inkompetenz ist kein zu besiegender Feind. Sie ist das Gelände, auf dem wir gehen, und die einzige Wahl ist zwischen offenen oder geschlossenen Augen.
Wir, als Spezies, haben eine Welt gebaut, die wir nicht verstehen können. Keine Tragödie. Vielleicht das Menschlichste, das wir je getan haben.
Was du mitnimmst
Inkompetenz ist strukturell, nicht persönlich: ein durchschnittliches Software-Projekt ruht auf tausenden transitiven Abhängigkeiten, die niemand je geprüft hat.
Spezialisierung rettet nicht: die heimtückischsten Bugs leben im Raum zwischen den Spezialisierungen, wo niemand hinsieht.
Die DSGVO funktioniert, weil sie für die Inkompetenz entworfen ist (Daten sind per default gefährlich); Normen, die Kompetenz voraussetzen, scheitern.
Automatische Tests, Code Reviews, das Prinzip der minimalen Rechte: alles Techniken einer Ingenieurskunst der Unwissenheit — niemand nennt sie so, weil der Name unangenehm wäre.
Ein guter Tech-Profi heute ist nicht, wer am meisten weiß, sondern wer seine Unwissenheit am besten managt: Meta-Kompetenz, eher aristotelische Phronesis als Episteme.
Fragen & Antworten
Was heißt: Inkompetenz ist strukturell, nicht persönlich?
Dass die kumulierte Komplexität moderner technischer Objekte — ein Stack mit Millionen transitiven Abhängigkeiten, ein KI-Modell mit Milliarden Parametern, eine Cloud mit tausenden vernetzten Diensten — die kognitive Kapazität des Einzelnen überschritten hat. Keine Frage von Bildung oder Intelligenz: es ist physisch unmöglich, dass eine Person die ganze Kausalkette eines Artefakts beherrscht, an dem sie mitbaut.
Wie sind wir dahin gekommen?
Durch Schichtung, nicht durch Bruch. Jede über die vorige gelegte Abstraktionsebene löste ein Problem und schuf ein neues: die untere undurchsichtig zu machen. Die Anwendungs-Entwicklerin kennt das Framework nicht wirklich; wer das Framework kennt, kennt die Runtime nicht; wer die Runtime kennt, kennt den Microcode des Prozessors nicht. Niemand kennt die ganze Abhängigkeitskette, die ein einzelnes Install-Kommando lädt und in die Software einbaut.
Wenn niemand das System versteht, wer haftet bei Fehlern?
Genau die Frage, die die EU-Regulierung (CRA, PLD, AI Act) ex post zu formalisieren versucht: Verantwortung wandert zum Hersteller, unabhängig von feinem Verständnis des Objekts. Eine juristische, keine erkenntnistheoretische Antwort. Der klassische Begriff ‚technische Kompetenz als Voraussetzung von Verantwortung’ trägt nicht mehr — wir bauen Verantwortungssysteme auf nicht mehr existierenden Fundamenten.
Was lässt sich konkret tun, wenn vollständiges Verständnis unmöglich ist?
Aufhören, so zu tun, als hätte man es. Drei operative Schritte: aggressive Observability — wenn du das System nicht verstehen kannst, musst du es zumindest in Echtzeit messen; strukturell multidisziplinäre Teams — Kompetenz wird kollektiv; ‚Wie funktioniert es’-Doku durch verifizierbare Verhaltensverträge ersetzen, also ‚was wir garantieren’ statt ‚was drin ist’.
Der Autor
