- Je schneller plausibel wirkende Ergebnisse erzeugt werden, desto leichter fällt das Wiederholen ohne echtes Verständnis, und wenn man das Training zur Entwicklung von Urteilsvermögen überspringt, wird die langfristige Kompetenz geschwächt
- Bei vertrauten Mustern ist die Hilfe groß, doch bei unbekannten Problemen, mehrdeutigen Bedingungen, unvollständigen Informationen und widersprüchlichen Vorgaben bricht oberflächliche Nachahmung leicht zusammen und das tatsächliche Können wird sichtbar
- Starke Ingenieur:innen delegieren mechanische Aufgaben wie Boilerplate, Zusammenfassungen, Test-Scaffolding und beschleunigte Recherche, behalten aber Problemdefinition, Review, Auswahl und Verwerfen selbst in der Hand
- Der hohe Wert von Software Engineering liegt mehr im Urteilsvermögen als in der Code-Produktion; wichtiger wird die Fähigkeit, verborgene Einschränkungen zu erkennen, falsche Problemstellungen zu bemerken und vage Debatten in Trade-offs zu verwandeln
- Besonders zu Beginn der Karriere und im organisatorischen Betrieb sind Maßstäbe zum Schutz von echtem Verständnis wichtiger; je klarer man trennt, was delegiert wird und was man selbst übernimmt, desto mehr wird KI zu einem Werkzeug, das den Wert von Menschen steigert
Fehlermuster, die entstehen, wenn man das Denken auslagert
- A.I. verarbeitet Aufgaben wie Codegenerierung, Meeting-Zusammenfassungen, Begriffserklärungen, Entwurfsentwürfe und Status-Updates schnell, kann aber ebenso leicht die Gewohnheit fördern, nur plausibel wirkende Ergebnisse ohne Verständnis zu liefern
- Wer maschinell erzeugte Antworten so wiederholt, als wären sie das eigene Verständnis, ahmt nur den Anschein von Kompetenz nach, ohne tatsächliche Fähigkeiten aufzubauen
- Je stärker erzeugte Ergebnisse das eigene Verständnis ersetzen, desto eher überspringt man das Training des Urteilsvermögens und tauscht langfristige Kompetenz gegen kurzfristige Wirkung ein
- In Situationen, die sich nicht mit Templates abarbeiten lassen — etwa bei unbekannten Problemen, mehrdeutigen Bedingungen, unvollständigen Informationen oder widersprüchlichen Vorgaben — bricht oberflächliche Nachahmung leicht zusammen
-
Analogie: Abschreiben bei Prüfungsantworten
- Man kann durch Abschreiben gute Noten halten, doch sobald man in eine Situation kommt, die echtes Verständnis verlangt, zeigt sich das fehlende Fundament
- Ohne die Intuition, die durch eigenes Arbeiten entsteht, ist es schwer, über unbekannte Probleme zu schlussfolgern oder auf veränderte Bedingungen zu reagieren
- Wer Antworten von A.I. immer wieder übernimmt, leiht sich nur die äußere Form von Routine, ohne echte Routine aufzubauen
-
Analogie: Taschenrechner
- Ein Taschenrechner ist ein gutes Werkzeug, das Zeit spart; verlässt man sich jedoch ohne Zahlgefühl auf ihn, kann man nicht mehr prüfen, ob ein Ergebnis plausibel ist
- Ingenieur:innen mit Fundament können KI-Ausgaben prüfen, Fehler herausfiltern und sie korrigieren oder verwerfen
- Ingenieur:innen ohne Fundament nutzen KI nicht, sondern werden von der KI mitgezogen — besonders riskant in Rollen, in denen Genauigkeit und Verantwortung für Ergebnisse entscheidend sind
-
Analogie: Selbstfahrendes Auto
- Autonomes Fahren reduziert Müdigkeit und bewältigt Alltagssituationen, doch wer sich darauf verlässt, bevor er Fahren versteht, ist eher ein Passagier mit Eingriffsrecht
- In nicht standardisierten Situationen wie schlechter Sicht, komplexen Straßen, unvorhersehbaren anderen Fahrzeugen, Systemfehlern oder plötzlichen Gefahren zeigt sich das tatsächliche Können
- Auch A.I. ist stark bei allgemeinen Mustern und vertrauten Strukturen, aber Engineering weicht ständig davon ab: sich ändernde Anforderungen, subtile Bugs, unklare Zuständigkeiten, konkurrierende Architekturziele, partielle Daten, organisatorische Reibung und Trade-offs ohne perfekte Antwort
Wie herausragende Ingenieur:innen A.I. einsetzen
- Herausragende Ingenieur:innen nutzen A.I. nicht weniger, sondern noch aktiver, ohne jedoch das Denken selbst abzugeben
- Mechanische Aufgaben wie das Schreiben von Boilerplate, das Zusammenfassen von Dokumentation, das Erzeugen von Test-Scaffolding, Refactoring-Vorschläge, das Erkunden möglicher Fehlerursachen, beschleunigte Recherche und das Verdichten wiederkehrender Arbeit delegieren sie gern
- Stattdessen formulieren sie schärfere Fragen, definieren nicht die sichtbare Anfrage, sondern das eigentliche Problem, und geben Klarheit und Kürze Vorrang vor glatten, aber inhaltlich leeren Formulierungen
- Sie beschränken sich nicht darauf, vorhandenes Wissen im System neu zu kombinieren, sondern erzeugen neues Wissen mit hohem Wert
- Die so gewonnene Zeit investieren sie erneut in höherwertiges Denken und Urteilen
Die tatsächliche Quelle von Wert
- Software Engineering wurde lange mit Code-Produktion gleichgesetzt, doch dort liegt nicht der höchste Wert
- Wäre das Erzeugen syntaktisch korrekten Codes die Kernaufgabe, würde KI tatsächlich große Teile des Berufs direkt ersetzen — in Wirklichkeit liegt der Kern jedoch im Urteilsvermögen
- Wertvolle Ingenieur:innen erkennen verborgene Einschränkungen, bevor sie Störungen verursachen, bemerken, dass das Team das falsche Problem löst, verwandeln vage Debatten in klare Trade-offs, finden fehlende Abstraktionen und debuggen nicht nur Code, sondern die Realität
- KI kann solche Arbeit unterstützen, aber sie nicht an ihrer Stelle übernehmen
- In Zukunft werden die Ingenieur:innen den größeren Wert schaffen, die Designprinzipien, Domänenverständnis, Muster, Kontext und Entscheidungsrahmen hervorbringen, durch die KI nützlicher wird
- In diesem Umfeld werden Ingenieur:innen nicht von KI ersetzt, sondern gewinnen mehr Hebelwirkung, indem sie oberhalb der Roh-Ausgabe arbeiten
Größeres Risiko für Ingenieur:innen am Anfang ihrer Laufbahn
- Dieses Problem ist besonders zu Beginn der Karriere wichtig
- Die ersten Jahre sind die Phase, in der sich Grundkompetenzen wie Debugging-Gefühl, Systemintuition, Präzision, Geschmack, skeptische Prüfung, Problemzerlegung und die Fähigkeit, zu erklären, warum etwas funktioniert, herausbilden
- Diese Fähigkeiten entstehen durch Reibung, Versuch und Irrtum, das Korrigieren von Fehlern, das Verfolgen von Grundursachen und Erfahrungen, in denen Annahmen an der Realität zerbrechen
- Wenn KI im Lernprozess alle Schwierigkeiten entfernt, gewinnt man zwar kurzfristige Effizienz, überspringt aber die Phase, in der Fähigkeiten geschärft werden
- Für ein oder zwei Quartale mag das effizient wirken, doch dabei kann man still die Fähigkeiten verpassen, die die Zukunft tragen sollen
- Unterstützungssysteme können zwar dafür sorgen, dass etwas funktionstüchtig aussieht, aber sie erzeugen nicht stellvertretend echte Fähigkeit
Für Urteilsvermögen gibt es keine Abkürzung
- Allein durch das Lesen erzeugter Erklärungen wird Routine nicht in den Kopf übertragen, wenn man die Arbeit nicht selbst macht
- Wer das Schlussfolgern lange auslagert, findet keinen Weg, am Ende dennoch starkes Schlussfolgern zu besitzen
- Mechanische Arbeit auszulagern, Recherche zu beschleunigen und wiederkehrende Aufgaben zu verdichten, ist möglich und wünschenswert
- Doch man kann nicht den Prozess der Kompetenzbildung überspringen und dennoch am Ende über diese Kompetenz verfügen
- Der zentrale Irrtum einer naiven KI-Nutzung besteht darin, zu glauben, man spare Zeit, während man in Wirklichkeit nur die Rechnung für schwaches Urteilsvermögen, oberflächliches Verständnis und geringe Anpassungsfähigkeit nach hinten verschiebt
Die Trennlinie und ihre Implikationen für Organisationen
- Wenn KI dabei hilft, Verständnis schneller aufzubauen, tiefer zu denken und auf höherem Niveau zu arbeiten, steigt der Wert von Menschen
- Wenn KI dabei hilft, Verständnis, Schwierigkeit und die Verantwortung für das eigene Schlussfolgern zu vermeiden, sinkt der Wert von Menschen
- Der eine Weg wirkt wie Zinseszins, der andere höhlt aus und führt leicht in einen Zustand der Austauschbarkeit
- Die Zukunft begünstigt nicht Ingenieur:innen, die KI einfach nur nutzen, sondern jene, die präzise unterscheiden, was delegiert wird und was sie selbst verantworten, und Zeitersparnis in besseres Denken verwandeln
Warum das noch stärker auf die Gesundheit von Organisationen wirkt
- Auch Engineering-Management steht an derselben Grenze und muss zwischen einer Nutzung, die Verständnis beschleunigt, und einer, die Verständnis imitiert, unterscheiden
- Starke Führung muss glatte Ergebnisse von echtem Urteilsvermögen unterscheiden können; wer nur Geschwindigkeit, Eloquenz und Präsentationsstärke belohnt, übersieht Signale technischer Tiefe
- Wenn Arbeit mit geringem Verständnis und hoher sprachlicher Glätte zunimmt, sinkt nicht nur die Qualität individueller Ergebnisse, sondern das Wissensumfeld der gesamten Organisation wird schwächer
- Reviews werden schwächer
- Design-Diskussionen werden oberflächlicher
- Dokumentation wird glatter, aber weniger nützlich
- Mit der Zeit verliert die Organisation die Fähigkeit, selbst die Klarheit und das technische Urteilsvermögen hervorzubringen, auf die sie angewiesen ist
- Deshalb liegt der Kern nicht in der bloßen Einführung von KI-Tools, sondern im Schutz der Bedingungen, unter denen echtes Denken, Lernen und Handwerkskunst überleben
- Schon im Hiring braucht es Wege, nicht nur äußerliche Eloquenz, sondern echtes Verständnis zu erkennen
- Interviews sollten statt polished answers den Denkprozess prüfen
- Bewertungen sollten statt bloßer Output-Menge Klarheit, Tiefe, solides Urteilsvermögen und langfristig wirksame technische Beiträge belohnen
- Auch Teamdesign und Kultur werden stark beeinflusst
- Es muss verhindert werden, dass starke Ingenieur:innen ihre Zeit übermäßig damit verbringen, plausibel wirkende, aber oberflächliche Arbeit aufzuräumen, die von Menschen stammt, die ihr Denken ausgelagert haben
- Gelingt das nicht, werden High Performer zu Verstärkern für alle anderen aufgerieben, was leicht zu Frustration, sinkenden Standards und Abwanderung führt
- Die organisatorische Qualität im Zeitalter der KI hängt letztlich stärker davon ab, ob Führung weiterhin zwischen Hebelwirkung und Abhängigkeit, Beschleunigung und Nachahmung sowie echter Kompetenz und überzeugend wirkendem Output unterscheiden kann
1 Kommentare
Hacker-News-Meinungen
Je öfter ich dieses Argument lese, desto besser erscheint mir die Eleganz der Formulierung, aber ich habe immer noch das Gefühl, dass es noch nicht ganz den Rang eines Aphorismus erreicht
Damit ein Satz so wie „the medium is the message“, „you ship your org chart“ oder „9 mothers can't make a baby in a month“ bei vielen Menschen mit wenigen Worten einschlägt, braucht es Jahre bis Jahrzehnte, in denen die Bedeutung immer weiter zugespitzt wird
Und wir wissen nicht einmal, wie man Bedeutungsbildung mit RL behandelt, also kann AI das auch nicht für uns übernehmen
Eigentlich heißt es korrekt: „9 women can't make a baby in one month“
Durchs Selbermachen lernen. Dieser eine Satz wirkt für mich eher wie ein Aphorismus
Intelligence amplification, not artificial intelligence klingt ganz gut
Gekürzt wird daraus IA, not AI, und auf Spanisch wird daraus „AI, no IA“, was noch lustiger ist
Geschmack und Urteilsvermögen kann AI nicht hervorbringen
Wenn man 100 Amerikaner nach der Bedeutung dieses Aphorismus fragen würde, könnten vermutlich nur sehr wenige McLuhans eigentliche Aussage korrekt erfassen
Ich denke, man kann AI im Großen und Ganzen auf zwei Arten nutzen
Die eine ist, sie als Hilfe beim Schreiben von Code, den ich besitze und verstehe, einzusetzen, und die andere, AI als eine Art Abstraktionsschicht zu verwenden und ihr Schreiben und Wartung des Codes zu überlassen
Letzteres ist in Bereichen okay, in denen Lebensdauer kurz ist und weder Codequalität noch mein eigenes Verständnis besonders wichtig sind, etwa bei Prototypen, Beispielen oder Referenzen
Das Problem entsteht eigentlich dann, wenn man Aufgaben, die Typ 1 brauchen, mit Typ 2 angeht und dabei sich selbst und andere täuscht
Es wirkt schnell und einfach, aber am Ende verpfändet man damit gewissermaßen die Codebasis, und ab da beginnt aus meiner Sicht auch der Kompetenzabbau
Features werden weiter ausgeliefert und äußerlich sieht alles in Ordnung aus, aber in dem Moment, in dem etwas kaputtgeht, merkt man, dass man den eigenen Code nicht einmal mehr debuggen kann, ohne das Modell erneut zu fragen
Es gibt auch viele Engineers, die ohne moderne IDE, Sprachen mit Speicherverwaltung oder Bibliotheken aus GitHub oder dem Paketmanager gar nicht arbeiten könnten
Deshalb fühlt sich AI-Abhängigkeit für mich nicht grundsätzlich völlig anders an
Auch die Bedeutung des Wortes Engineer kann sich verändern, und tatsächlich gibt es schon jetzt „web developer“, die nur mit Webflow oder WordPress arbeiten
Wenn man eine strenge Definition anlegt, gibt es im Bereich Software Engineering kaum tatsächliche zertifizierte Engineers, und in manchen Ländern sind damit sogar formale Qualifikationen und Titel verbunden
Am Anfang der Karriere hätte man mit genug Zeit fast alles gemacht, aber heute gibt es eine lange Liste von Dingen, die ich zwar könnte, aber nicht mache, weil sie mir keinen Spaß machen
Wir wissen nicht, ob AI am Ende so viel kostet wie ein Slack-Abo, so viel wie ein Teammitglied oder ob der Dienst verschwindet und man extra jemanden einstellen muss, der noch Zugang zu AI hat
Deshalb ist es etwas ganz anderes, von AI abhängig zu sein, als von einer IDE abhängig zu sein, die lokal oder Open Source sein kann
Wer etwa 10 Jahre Berufserfahrung hat, versteht den Fluss und die Logik von Code so gut, dass er mit AI trotzdem Code erzeugen und die eigene Arbeitsweise verbessern kann
Anfänger dagegen kennen Fluss und Logik oft nicht und neigen dann dazu, einfach zu kopieren und einzufügen, deshalb glaube ich nicht, dass AI solchen Leuten mehr Raum zum Denken gibt
Die heutige Art, AI zu nutzen, fühlt sich für mich anstrengender an als die Programmierung der letzten 20 Jahre
Besonders ermüdend ist der Prozess, ein Problem vorzugeben, Vorschläge zu bewerten, die richtige Richtung auszuwählen, seltsame Vorschläge auszusortieren und dann alles weiter zu verfeinern, bis es fast passt
Danach lässt man das Coding 1 bis 5 Stunden laufen, und manchmal kommt dabei ein Ergebnis heraus, für das ich selbst mindestens 2 bis 3 Wochen gebraucht hätte
Aber wenn ich so fünf Stunden lang überwiegend planungsorientiert arbeite, bin ich völlig ausgelaugt, und das ist eine andere Art von Erschöpfung als bei reinem Programmieren
Es fühlt sich zwar an, als würde ich etwas lernen, aber ehrlich gesagt auch eher wie Manager-Arbeit
Wenn man mit einem LLM langsam ein Problem definiert und nach einer plausiblen Lösung sucht, muss man die ganze Zeit konzentriert bleiben, sodass der frühere Flow-Zustand kaum noch entsteht
Man verarbeitet ständig riesige Mengen an Output und muss immer wieder das Wesentliche herausfiltern, und selbst wenn das Ergebnis insgesamt gut ist, liegt es fast immer irgendwo leicht daneben, was ziemlich stört
Wegen der typischen seltsamen Fehler und Denkdefizite von LLMs muss man außerdem dauerhaft wachsam bleiben, und schon das Interpretieren dieses unmenschlichen Kommunikationsstils ist ermüdend
Gleichzeitig denke ich aber auch, dass pacing oder procrastination für Menschen vielleicht eine Art Druckablassventil sein können
Es gibt ohnehin viele Engineers, die von Anfang an nicht gut denken können, und AI ändert an dieser Tatsache nichts
Das ist einer der Gründe, warum im Bereich Software Engineering so vieles kaputtgegangen ist, und AI kann das nicht lösen, sondern möglicherweise nur das noch größere Chaos vorübergehend hinauszögern
Selbst Leute, die sich an der Uni mit Schummeln durchgeschlagen haben, brauchten am Ende doch kritisches Denken, um nicht aufzufliegen
Man will es vielleicht nicht hören, aber sogar gut schummeln zu können erfordert ziemlich viel Denkleistung
Ich glaube, wer AI auf irgendeiner Ebene das Denken überlässt, hat es ursprünglich ohnehin nicht wertgeschätzt
Wie bei „use it or lose it“ gibt es immer mehr Forschung, die das stützt, und trotzdem erscheinen weiter Texte, die sagen, der Einsatz von LLMs in der Softwareentwicklung sei schon okay und unser eigentlicher Wert liege ja in der Denkfähigkeit
Einer der schönen Aspekte dieser Arbeit ist, dass einem selbst dann plötzlich eine Lösung einfällt, wenn man völlig in etwas anderes vertieft war
Jetzt wird AI zu einem Werkzeug, das Gedanken schnell in Handlung umsetzt
Früher verlor ich manchmal den Faden, bevor ich überhaupt einen Ansatz greifen konnte, aber jetzt kann ich mit dem Handy innerhalb weniger Minuten eine Idee zumindest teilweise real machen und dann zu dem zurückkehren, was ich gerade getan habe
Besonders wichtig ist, dass ich nicht mehr befürchten muss, eine Idee zu verlieren, nur weil ich den Blick kurz abwende
Ich baue numba gerade neu, und mir fällt es schwer, mir vorzustellen, das nur von Hand zu tun
Als ich es vor einigen Jahren versucht habe, war es extrem schmerzhaft, langsam und chaotisch
Es lag auch daran, dass sich auf Abstraktionen, die sich über Jahre angesammelt hatten, endlos kleine Dinge stapelten
Diesmal mache ich es mit einem LLM neu, und Aufgaben, die eigentlich Wochen gedauert hätten, sind manchmal über Nacht fertig
Trotzdem schaue ich mir den Code selbst an, prüfe auch den generierten C-Output und halte die Architektur weiter unter Kontrolle, damit sowohl ich als auch das LLM künftig gut damit arbeiten können
Ob das mein Denken ersetzt, weiß ich nicht so recht
Wenn ich monatelang alles manuell geschrieben und überarbeitet hätte, hätte ich wahrscheinlich mehr über Compiler oder Transpiler gelernt, aber dann hätte ich mich auch nur damit beschäftigt
Stattdessen bleibt mir jetzt sogar noch Zeit, NFS-Server-Unterstützung für ein benutzerdefiniertes Dateisystem in Golang zu schreiben
Inzwischen habe ich Systeme gebaut, bei denen Agenten die für ein ganzes Feature nötigen Änderungen finden, sie in der Planungsphase sehr fein aufdröseln und die Umsetzung dann fast auf Anhieb korrekt erledigen
Im vergangenen Jahr habe ich immer weniger Code selbst gelesen, und ich frage mich oft, ob das Wohlgefühl, das ich gegenüber dem aktuellen System empfinde, nicht zu groß ist
Ich habe so oft hohe Genauigkeit und Erfolgsraten gesehen, dass ich inzwischen instinktiv nicht mehr misstrauisch bin
Ich warte ständig darauf, dass es irgendwann richtig schiefgeht, aber seltsamerweise passiert dieser Moment nicht wirklich
Natürlich gab es kleine Auslassungen und Rücknahmen, aber die gab es früher auch schon
Der Unterschied ist, dass ich früher zu dem Code, den ich mir mühsam erarbeitet hatte, eine viel persönlichere Beziehung hatte
Heute grabe ich bei Problemen weniger im Code selbst, sondern eher darin, warum das System nicht eigenständig auf die richtige Antwort gekommen ist oder warum es das Ganze vor der Implementierung im Plan nicht vollständig sichtbar gemacht hat
Der größte Vorteil von AI in Software ist, dass man Code schneller erstellen kann
Der größte Nachteil ist, dass sie einen dazu verführt, ihn noch viel schneller erstellen zu wollen
Deshalb nutze ich AI nicht für persönliche Projekte
Ich möchte meinen Kopf scharf halten
Bei Projekten, in denen es selbst um AI geht, mag es Ausnahmen geben, aber ich benutze AI nicht, um diesen Code zu schreiben
Bei der Arbeit im Unternehmen ist es mir dagegen egal
Wenn der Manager möchte, dass mit Claude komplett vibe coding betrieben wird, dann ist das eben so, denn die Kosten der dadurch entstehenden technischen Schulden trage nicht ich