KI sollte Denken nicht ersetzen, sondern fördern
(koshyjohn.com)- Je schneller plausibel wirkende Ergebnisse erstellt werden, desto leichter wird bloße Wiederholung ohne Verständnis; wenn man das Training zur Entwicklung von Urteilsvermögen überspringt, schwächt das die langfristige Kompetenz
- Bei vertrauten Mustern ist die Hilfe groß, aber bei unbekannten Problemen, mehrdeutigen Bedingungen, unvollständigen Informationen und widersprüchlichen Einschränkungen bricht oberflächliche Nachahmung leicht zusammen, und das tatsächliche Können wird sichtbar
- Starke Engineers delegieren mechanische Aufgaben wie Boilerplate, Zusammenfassungen, Test-Scaffolding und beschleunigte Recherche, übernehmen aber Problemdefinition und Review sowie Auswahl und Verwerfen selbst
- Der hohe Wert im Software Engineering liegt eher im Urteilsvermögen als in der Codeproduktion; wichtiger wird die Fähigkeit, verborgene Einschränkungen zu erkennen, falsche Probleme zu bemerken und vage Debatten in Trade-offs zu verwandeln
- Gerade zu Beginn der Karriere und in der Organisationsführung werden Maßstäbe zum Schutz von echtem Verständnis noch 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 beim Auslagern des Denkens
- A.I. erledigt Aufgaben wie Codegenerierung, Meeting-Zusammenfassungen, Begriffserklärungen, erste Architekturentwürfe und Status-Updates schnell, kann aber ebenso leicht die Gewohnheit erzeugen, nur plausibel wirkende Ergebnisse ohne Verständnis zu liefern
- Wer die Antwort der Maschine wiederholt, als wäre sie das eigene Verständnis, ahmt nur einen zustand scheinbarer Kompetenz nach, ohne echte Fähigkeiten aufzubauen
- Je mehr erzeugte Ergebnisse das eigene Verständnis ersetzen, desto öfter wird das Training von Urteilsvermögen übersprungen, und man tauscht langfristige Kompetenz gegen eine kurzfristige äußere Wirkung ein
- In Situationen, die sich nicht per Template lösen lassen — etwa unbekannte Probleme, mehrdeutige Bedingungen, unvollständige Informationen oder widersprüchliche Einschränkungen — bricht oberflächliche Nachahmung leicht zusammen
-
Die Analogie zum Abschreiben in Prüfungen
- Man kann gute Noten halten, indem man Antworten abschreibt, doch sobald man in eine Situation kommt, die wirkliches Verständnis erfordert, zeigt sich das fehlende Fundament
- Ohne die Intuition, die durch eigenes Arbeiten entsteht, ist es schwer, über ungewohnte Probleme nachzudenken oder auf veränderte Bedingungen zu reagieren
- Wer Antworten von A.I. immer wieder übernimmt, leiht sich nur die äußere Form von Erfahrung, ohne tatsächliche Erfahrung aufzubauen
-
Die Taschenrechner-Analogie
- Ein Taschenrechner ist ein gutes Werkzeug, das Zeit spart, aber wer sich ohne Zahlgefühl darauf verlässt, kann nicht mehr prüfen, ob ein Ergebnis überhaupt plausibel ist
- Engineers mit Fundament können KI-Ausgaben prüfen, Fehler herausfiltern und sie korrigieren oder verwerfen
- Engineers ohne Fundament nutzen KI nicht, sondern werden von der KI mitgezogen — besonders gefährlich ist das in Rollen, in denen Genauigkeit und Verantwortung für Ergebnisse entscheidend sind
-
Die Analogie zum autonomen Fahren
- Autonomes Fahren reduziert Ermüdung und bewältigt Alltagssituationen, aber wer sich darauf verlässt, bevor er Fahren versteht, ist eher ein Passagier mit Bedienrechten
- Bei nicht standardisierten Situationen wie schlechter Sicht, komplexen Straßen, unvorhersehbaren anderen Fahrzeugen, Systemausfällen oder plötzlichen Gefahren zeigt sich das tatsächliche Können
- Auch A.I. ist stark bei allgemeinen Mustern und vertrauten Strukturen, doch Engineering weicht ständig davon ab: sich ändernde Anforderungen, subtile Bugs, unklare Ownership, konkurrierende Architekturziele, partielle Daten, organisatorische Reibung und Trade-offs ohne perfekte Antwort
Wie starke Engineers A.I. nutzen
- Starke Engineers nutzen A.I. nicht weniger, sondern aktiver — sie geben jedoch das Denken selbst nicht ab
- Mechanische Aufgaben wie Boilerplate schreiben, Dokumente zusammenfassen, Test-Scaffolding erzeugen, Refactoring-Vorschläge machen, mögliche Fehler untersuchen, Recherche beschleunigen oder repetitive Arbeit komprimieren delegieren sie gern
- Stattdessen formulieren sie schärfere Fragen, definieren nicht nur die sichtbare Anfrage, sondern das eigentliche Problem, und priorisieren Klarheit und Knappheit vor glatten, aber inhaltsleeren Formulierungen
- Sie bleiben nicht bei der Rekombination vorhandenen Wissens im System stehen, sondern schaffen neues, hoch relevantes Wissen
- Die so gewonnene Zeit investieren sie wieder in höherwertiges Denken und Urteilen
Die eigentliche Quelle des Werts
- Software Engineering wurde lange mit Codeproduktion gleichgesetzt, doch dort liegt nicht der höchste Wert
- Wäre das Schreiben syntaktisch korrekten Codes der Kern, dann würde A.I. tatsächlich große Teile des Berufs direkt ersetzen; der eigentliche Kern ist jedoch Urteilsvermögen
- Wertvolle Engineers erkennen verborgene Einschränkungen, bevor sie Störungen verursachen, merken, wenn ein Team am falschen Problem arbeitet, verwandeln vage Debatten in klare Trade-offs, finden fehlende Abstraktionen und debuggen die Realität statt nur den Code
- A.I. kann solche Arbeit unterstützen, aber sie nicht übernehmen
- Engineers, die künftig mehr Wert schaffen, werden eher diejenigen sein, die Designprinzipien, Domain-Verständnis, Muster, Kontext und Entscheidungs-Frameworks hervorbringen, durch die A.I. nützlicher wird
- In diesem Umfeld werden Engineers nicht von A.I. ersetzt, sondern gewinnen mehr Hebelwirkung, indem sie eine Ebene über dem Roh-Output arbeiten
Größeres Risiko für Engineers am Karriereanfang
- Dieses Problem ist besonders zu Beginn der Karriere wichtig
- Die ersten Jahre sind die Phase, in der Grundfähigkeiten entstehen: Debugging-Gefühl, Systemintuition, Präzision, Geschmack, skeptisches Prüfen, Problemzerlegung und die Fähigkeit zu erklären, warum etwas funktioniert
- Diese Fähigkeiten entstehen durch Reibung, Versuch und Irrtum, das Korrigieren von Fehlern, das Verfolgen von Ursachen und Erfahrungen, in denen Vorstellungen an der Realität scheitern
- Wenn A.I. im Lernprozess alle Schwierigkeiten entfernt, gewinnt man kurzfristige Effizienz, überspringt aber die Phase, in der Fähigkeiten geschärft werden
- Für ein oder zwei Quartale mag das effizient wirken, doch man kann still und leise genau die Fähigkeiten verpassen, die die Zukunft tragen
- Support-Systeme können dafür sorgen, dass etwas funktional aussieht, aber sie erzeugen nicht anstelle von Menschen echte Fähigkeit
Für Urteilsvermögen gibt es keine Abkürzung
- Allein durch das Lesen erzeugter Erklärungen wird Erfahrung nicht einfach in den Kopf übertragen, ohne dass man selbst arbeitet
- Es gibt keinen Weg, über längere Zeit das Schlussfolgern auszulagern und am Ende trotzdem stark darin zu werden
- Mechanische Arbeit auszulagern, Recherche zu beschleunigen und repetitive Aufgaben zu komprimieren ist möglich und sinnvoll
- Aber man kann nicht den Prozess der Kompetenzbildung selbst überspringen und trotzdem am Ende über diese Kompetenz verfügen
- Der zentrale Irrtum naiver A.I.-Nutzung besteht darin zu glauben, man spare Zeit, während man in Wirklichkeit nur die Rechnung in Form von schwachem Urteilsvermögen, oberflächlichem Verständnis und geringer Anpassungsfähigkeit auf später verschiebt
Die Trennlinie und ihre Bedeutung für Organisationen
- Wenn A.I. hilft, Verständnis schneller aufzubauen, tiefer zu denken und auf höherem Niveau zu arbeiten, steigt der Wert von Menschen
- Wenn A.I. dabei hilft, Verständnis, Schwierigkeit und Verantwortung für das eigene Schlussfolgern zu vermeiden, sinkt der Wert von Menschen
- Der eine Pfad wirkt wie Zinseszins, der andere höhlt aus und führt leicht in einen Zustand, in dem man austauschbar wird
- Die Zukunft begünstigt Engineers, die nicht einfach nur A.I. verwenden, sondern präzise unterscheiden, was sie delegieren und was sie selbst verantworten, und die eingesparte Zeit in besseres Denken umsetzen
Warum das noch stärker auf die Gesundheit von Organisationen wirkt
- Auch Engineering-Management steht an derselben Grenze und muss zwischen Nutzung, die Verständnis beschleunigt, und Nutzung, die Verständnis nur imitiert, unterscheiden
- Starke Führung muss glatte Ergebnisse von echtem Urteilsvermögen unterscheiden können; wenn nur Tempo, Sprachgewandtheit und Präsentation belohnt werden, gehen die Signale technischer Tiefe verloren
- Wenn sich Arbeit mit wenig Verständnis und hoher Sprachgewandtheit ausbreitet, sinkt nicht nur die Qualität einzelner Outputs, sondern das Wissensumfeld der Organisation selbst wird schwächer
- Reviews werden schwächer
- Architektur- und Design-Diskussionen werden oberflächlicher
- Dokumentation wirkt glatter, ist aber weniger nützlich
- Mit der Zeit verliert die Organisation die Fähigkeit, selbst die Klarheit und technischen Urteile hervorzubringen, von denen sie abhängt
- Deshalb liegt der Kern nicht in der Einführung von A.I.-Tools an sich, sondern darin, die Bedingungen zu bewahren, unter denen echtes Denken, Lernen und Handwerk überleben
- Schon im Hiring braucht es Wege, nicht nur scheinbare Sprachgewandtheit, sondern echtes Verständnis zu erkennen
- Interviews sollten eher den Denkprozess als polished answers prüfen
- Bewertungen sollten statt Output-Menge eher Klarheit, Tiefe, gesundes Urteilsvermögen und nachhaltige technische Beiträge belohnen
- Auch auf Teamdesign und Kultur hat das große Auswirkungen
- Starke Engineers sollten ihre Zeit nicht übermäßig darauf verwenden müssen, plausibel wirkende, aber oberflächliche Arbeit aufzuräumen, die von Menschen stammt, die ihr Denken ausgelagert haben
- Wenn das nicht verhindert wird, werden High Performer als Verstärker für alle außer sich selbst aufgebraucht, was leicht zu Frustration, sinkenden Standards und Abwanderung führt
- Die Qualität von Organisationen im Zeitalter der A.I. hängt letztlich stärker davon ab, ob die Führung weiterhin Hebelwirkung und Abhängigkeit, Beschleunigung und Nachahmung sowie echte Kompetenz und überzeugend wirkenden 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