- Moderne technische Systeme haben sich zu so komplexen Strukturen entwickelt, dass keine einzelne Person das Ganze verstehen kann
- Mit der zunehmenden Softwareentwicklung und Nutzung von AI steigt die Zahl der Fälle, in denen Entwickler Systeme bauen, ohne die internen Mechanismen zu verstehen
- Simon Wardley warnt vor den Risiken, Systeme ohne Verständnis zu bauen, Adam Jacob weist darauf hin, dass AI die Art der Entwicklung verändert, und Bruce Perens betont, dass die Komplexität die Grenze bereits überschritten hat
- Louis Bucciarelli zeigt am Beispiel des Telefonsystems, dass Technologie über viele Ebenen verflochten ist und niemand zu einem vollständigen Verständnis gelangen kann
- Der Artikel hebt hervor, dass AI diese Komplexität zwar verschärft, Menschen aber tatsächlich schon seit Langem mit Technik auf der Basis nur teilweisen Verständnisses umgehen
Technische Komplexität und die Grenzen des Verstehens
- Nach dem Niedergang von Twitter wird auf LinkedIn intensiv über technisches Verständnis und Komplexität diskutiert
- Beiträge von Simon Wardley, Adam Jacob und Bruce Perens werden als thematisch miteinander verknüpft vorgestellt
- Wardley warnt vor den Gefahren, Systeme zu bauen, ohne die grundlegenden Prinzipien zu kennen
- Der Ausdruck „Magic“ bezeichnet kritisch Frameworks, die ihre interne Funktionsweise verbergen; als typisches Beispiel wird Ruby on Rails genannt
- Jacob weist darauf hin, dass AI die Art der Softwareentwicklung grundlegend verändert
- AI steigert die Effizienz, führt aber auch dazu, dass Entwickler arbeiten, ohne die darunterliegende Struktur zu verstehen
- Perens merkt an, dass die von Wardley befürchtete Situation bereits Realität geworden ist
- Aufgrund der Komplexität moderner CPUs und Betriebssysteme verstehen viele Entwickler die tatsächlichen Funktionsprinzipien falsch
Louis Bucciarellis Beispiel des „Telefons“
- Bucciarelli diskutiert in seinem Buch Designing Engineers von 1994 die Grenzen technischer Literalität
- Die meisten Menschen können nicht auf physikalischer Ebene erklären, wie ein Telefon funktioniert
- Im Kommunikationsnetz greifen Routing, Signalverarbeitung, Satellitenübertragung, Unternehmensbetrieb und regulatorische Strukturen als mehrschichtige Elemente ineinander
- Er kommt zu dem Schluss: „Niemand weiß vollständig, wie sein eigenes Telefon funktioniert“
- Das steht sinnbildlich dafür, dass komplexe technische Systeme das vollständige menschliche Verständnis übersteigen
Technische Interviews und die „Grenzen des Wissens“
- Der Autor erinnert sich an ein Gespräch mit Brendan Gregg aus seiner Zeit bei Netflix
- Gregg sagte, dass er in Vorstellungsgesprächen die Wissensgrenzen von Bewerbern und ihre Reaktion darauf bewertet habe
- Er führte Interviews unter der Annahme, dass „niemand das gesamte System vollständig versteht“
- Dieser Ansatz zeigt, dass die Fähigkeit, Nichtwissen einzugestehen, genauso wichtig ist wie technische Kompetenz
Das Wesen der Komplexität und der Einfluss von AI
- Die Sichtweisen von Wardley, Jacob, Perens und Bucciarelli machen auf unterschiedlichen Ebenen die Unvermeidlichkeit von Komplexität deutlich
- Wardley: Risiken des Bauens ohne Verständnis
- Jacob: Effizienz und Entfremdung durch AI
- Perens: die Realität bereits vorhandener Komplexität
- Bucciarelli: die Unmöglichkeit, das Gesamtsystem vollständig zu verstehen
- Der Artikel räumt ein, dass AI dieses Problem verschärfen wird, erinnert aber zugleich an die lange Realität menschlichen Umgangs mit Technik auf Basis nur teilweisen Verständnisses
Zusammenfassung der Leserdiskussion
- In den Kommentaren wird vielfach die Sorge geäußert, dass AI Lernen und Verständnis schwächt
- Einige weisen darauf hin, dass „LLMs den Code schreiben und dadurch die Kette des Verständnisses unterbrochen wird“
- Wardley erklärt, dass Verständnis früher in einer hierarchischen Kette erhalten blieb, LLMs diese Kette jedoch auflösen
- Andere Leser entgegnen, es sei verfrüht anzunehmen, dass „die Vorteile von AI größer sind als die Risiken“
- Insgesamt treten der Verlust technischen Verständnisses im Zeitalter von AI und der Abbruch von Lernprozessen als zentrale Streitpunkte hervor
1 Kommentare
Hacker-News-Kommentare
Was mir am heutigen Programmieren Sorgen macht: Es gibt immer mehr „Mittelschicht-Entwicklung“, bei der man weder die obere Ebene (den Zweck des Produkts) noch die untere Ebene (die Art der Implementierung) versteht.
Früher kannte man vielleicht das Business nicht, verstand aber die Bedeutung des Codes; heute herrscht die Stimmung, dass man nicht einmal mehr wissen muss, wie der Code funktioniert.
Wenn ich Claude benutze, habe ich das Gefühl, dass meine Kontextwahrnehmung allmählich nachlässt. In einer Entwicklungskultur, in der es reicht, wenn Tests grün sind und der Button klickbar ist, fühle ich mich, als gäbe es für mich nichts mehr zu lernen oder beizutragen.
Gerade in großen Unternehmen fehlt es oft an Transparenz. Ich habe schon Überstunden gemacht, um einen Termin zu halten, nur um später festzustellen, dass der Termin verschoben worden war, ohne dass ich es wusste.
Wenn ich nur als Werkzeug behandelt werde, dann erfülle ich eben nur diese Rolle. Wenn aber echte Ownership gewünscht ist, dann braucht man auch einen Platz am Tisch, an dem Entscheidungen getroffen werden.
Früher habe ich Zeit mit repetitiven Setup-Arbeiten verschwendet, jetzt kann ich mich auf die Kernfunktionen konzentrieren. Dadurch kann ich die Gesamtstruktur im Kopf sogar besser behalten.
Zum Beispiel könnte man im IDE ein paar Zeilen markieren und per Sprache sagen: „Ändere diesen Teil bitte so“, und es würde sofort übernommen.
Wenn die Geschwindigkeit hoch genug wäre, könnten Maus- plus Sprachsteuerung auch ein hervorragendes Accessibility-Tool sein.
Ich denke sogar, dass LLMs diese Komplexität eher verringern könnten. Ich mag ein sinnvolles Maß an Abstraktion, aber ich mag es nicht, das Innenleben gar nicht mehr zu kennen.
In diesem Beitrag geht es um das Phänomen, dass Menschen Abstraktion (abstraction) nutzen, ohne das Innere zu kennen.
Aber das ist ein natürlicher Entwicklungsschritt. Irgendjemand hat diese Abstraktion entworfen und so gebaut, dass die obere Ebene sie verwenden kann.
Die Logik „Ich kenne den Wi‑Fi-Treiber nicht, also muss ich meinen Code auch nicht verstehen“ geht nicht auf.
Früher entwickelte man Denkvermögen, indem man sich direkt mit der „notwendigen Komplexität“ auseinandersetzte; heute fungiert man oft nur noch als eine Art Rohrleitung.
Die Lösung wäre, Abstraktionen statt in einer universellen Sprache in einer DSL (domänenspezifischen Sprache) zu kapseln. Bei SaaS halte ich einen DSL-first-Ansatz für besser als API-first.
Ich glaube nicht, dass AI zwangsläufig schlimmer ist. Entscheidend ist, dass man die Abstraktionen versteht, auf denen man aufbaut.
Der Dependency-Tree ist in der Praxis das größte Problem.
Schon ein Node.js-Projekt hat Hunderte abhängige Pakete. Meistens ist es in Ordnung, die Interna nicht zu kennen, aber wenn Interfaces häufig brechen, wird es riskant.
Viele Teams verfolgen weder EOL noch Schwachstellen. Die Realität ist oft, dass man nicht einmal weiß: „Wird das überhaupt noch gewartet?“
Aber schon vor AI gab es viele Projekte, die wegen Versionskonflikten in Dependency Hell geraten sind.
Niemand muss alles wissen, aber Unwissen, das die Grundlagen verdrängt, ist gefährlich.
Beim Kochen etwa muss man keinen Weizen anbauen, aber wenn man nicht einmal weiß, wie man ein Ei brät, ist das problematisch.
Wenn Unternehmen jedes Essen standardisiert zubereiten und liefern würden, wäre das dann Fortschritt oder Rückschritt?
Wenn Roboter eines Tages die Lebensmittelproduktion vollständig übernehmen, spielt es vielleicht keine Rolle mehr, ob man kochen kann.
Man muss doch nicht gleich Materialwissenschaft verstehen, nur um Abhängigkeiten zu vermeiden.
Untere Schichten wie CPU-Instruktionen und Cache sind seit Jahrzehnten gründlich validiert und dokumentiert.
Von LLMs erzeugter Code ist dagegen längst nicht so vertrauenswürdig und könnte morgen schon Refactoring brauchen.
Ich kenne zwar nicht jedes Detail der unteren Ebenen, aber ich verstehe, wie mein eigener Code funktioniert.
Die unteren Ebenen nicht zu kennen und den eigenen Verantwortungsbereich nicht zu kennen, sind zwei völlig verschiedene Dinge.
Die eigentliche Gefahr heute ist, dass Codefragmente entstehen, die niemand versteht.
Ich stimme der Behauptung nicht zu, dass AI die Lage verschlimmert.
Im Gegenteil: LLMs haben fast das gesamte verfügbare Wissen gelernt und können Fragen wie „Wie funktioniert ein Telefon?“ systematisch erklären.
Menschen haben die Grenze, oft nicht einmal zu wissen, was sie nicht wissen; LLMs können dagegen fast alles abdecken, sofern es als Sprache ausdrückbares Wissen ist.
Natürlich sind sie bei Schlussfolgern oder Codegenerierung schwächer, aber ihre Fähigkeit zur Wissensintegration ist Menschen überlegen.
Echte Dokumentation können sie nicht ersetzen. Aber sie sind äußerst nützlich, um – ähnlich wie Menschen – darauf hinzuweisen, „wonach man suchen sollte“.
Gutes Design sorgt dafür, dass ein System funktioniert, ohne dass man das Ganze kennen muss.
Das Problem ist nicht ein von AI erzeugtes System, sondern dass wir seine Fehlermuster und Grenzen noch nicht gut kennen.
Am Ende ist entscheidend, wie wir Menschen und AI so aufeinander abstimmen, dass die benötigten Systeme entstehen – diese organisatorische Designfähigkeit ist der Kern.
Ich kenne das Innenleben von Computern nicht vollständig, löse Probleme aber mit praktischer Skript-Automatisierung.
Ich muss kein x86-Assembly studieren, um mit Python Infrastruktur zu verwalten.
Trotzdem finde ich, dass erfahrene Entwickler die Verantwortung haben, dieses Wissen weiterzugeben. Ich würde diese Rolle später auch gern übernehmen.
Man sollte die Neugier nicht verlieren und aktiv das Gespräch mit erfahrenen Entwicklerinnen und Entwicklern suchen.
Aber es ist frustrierend, wie sehr die Wichtigkeit von Grundlagenverständnis ignoriert wird, egal wie oft man sie betont.
Ich kann Fragen wie „Was passiert eigentlich, wenn man eine URL eingibt?“ tatsächlich beantworten.
Ich habe als Reaktortechniker auf einem U-Boot der US Navy gearbeitet und dort alles von Elektroniktheorie bis System-Fehlersuche gelernt.
Später bin ich in die IT gewechselt und habe mit derselben Haltung Dokumentation und Experimente bis ins Detail verfolgt.
Diese Gewohnheit hilft mir bei der Problemlösung enorm, weil Verknüpfungen zwischen scheinbar zufälligem Wissen entstehen.
Auch der Wikipedia-Artikel zu VMEbus ist lesenswert.
Allerdings bin ich wohl ein Sonderfall, weil ich es nicht aushalte, etwas nicht zu wissen.