- Entgegen der verbreiteten Annahme, dass Künstliche Intelligenz Entwickler zu „Managern“ oder „Editoren“ macht, schlägt der Autor den Ansatz „programmieren wie ein Chirurg“ vor und betont eine Arbeitsweise mit Fokus auf die Kernaufgaben
- So wie ein Chirurg mit Unterstützung von Assistenzkräften nur auf die entscheidenden Teile einer Operation fokussiert ist, können Entwickler mit AI-Tools Nebenaufgaben delegieren und sich auf die eigentliche Problemlösung konzentrieren
- Wichtige Aufgaben, etwa UI-Prototyping, werden weiterhin direkt von Menschen erledigt, während Dokumentation, Bugfixing und Code-Erkundung von AI-Agenten übernommen werden
- Indem einfache Routineaufgaben an AI übertragen werden, lässt sich grunt work ohne Statushierarchie delegieren; dank 24/7-Verfügbarkeit können Aufgaben auch spät nachts oder in der Mittagspause angestoßen werden
- Dieser Ansatz steht in Verbindung mit Andrej Karpathys Konzept des „autonomy slider“ und legt nahe, dass sich die AI-Strategie je nach gewünschtem Autonomiegrad der Aufgabe unterscheiden sollte
Programmieren wie ein Chirurg: Kernkonzept
- Im Gegensatz zur gängigen Prognose, dass AI Entwickler zu Managern oder Editoren machen wird, schlägt der Autor eine Arbeitsweise nach dem Vorbild eines Chirurgen (Surgeon) vor
- Ein Chirurg operiert selbst, erhält aber Unterstützung vom Team für Vorbereitung und Nebentätigkeiten und konzentriert sich so nur auf die Kernarbeit, die seine spezielle Expertise erfordert
- Entwickler können AI ebenfalls wie Assistenzpersonal einsetzen, um sich auf kreative Kernarbeit zu konzentrieren
- Als UI-Prototyper verfolgt der Autor mit AI-Tools das Ziel, 100 % seiner Zeit in sinnvolle Arbeit zu investieren
- Durch das Delegieren von Nebenaufgaben, die AI übernehmen kann, wird die Produktivität maximiert
Nebenaufgaben, die sich an AI delegieren lassen
- Eine Liste unterstützender Aufgaben, die AI gut erledigen kann
- Verfassen von Guides zur Codebase vor größeren Änderungen
- Erstellen von Entwürfen für „Spike“-Code bei größeren Änderungsversuchen
- Beheben von TypeScript-Fehlern oder Bugs mit klarer Spezifikation
- Dokumentation für aktuell entwickelte Features schreiben
- Diese Aufgaben lassen sich asynchron im Hintergrund ausführen
- AI kann während der Mittagspause oder über Nacht arbeiten, sodass das Ergebnis am nächsten Tag direkt geprüft werden kann
- So kann man sich – wie „ein Chirurg, der einen vorbereiteten OP-Saal betritt“ – auf die Kernarbeit am Code konzentrieren, wenn alles vorbereitet ist
Autonomy Slider (Mind the autonomy slider)
- Zwischen Kernaufgaben und unterstützenden Aufgaben gibt es große Unterschiede in der AI-Nutzung
- Zentrales Design und Prototyping bleiben weiterhin menschliche Aufgaben; schnelle Feedbackschleifen und hohe Sichtbarkeit sind dort entscheidend
- Nebenaufgaben dagegen lassen sich effizient über längere Zeit autonom an AI delegieren
- Für lange unbeaufsichtigte Sessions bevorzugt der Autor Claude Code, zuletzt auch Codex CLI
- Diese Unterscheidung ähnelt Andrej Karpathys Konzept des „autonomy slider“
- Je nach Autonomiegrad sind andere Tools und Denkweisen nötig; beides zu verwechseln, ist riskant
AI und das Konzept des „Software-Chirurgen-Teams“
- Das Konzept des „Software-Chirurgen“ ist eine ältere Idee, die 1975 von Harlan Mills in „The Mythical Man-Month“ von Fred Brooks vorgeschlagen wurde
- Im Zentrum steht ein „chief programmer“, unterstützt von einem „copilot“ und Verwaltungspersonal
- Früher wurden diese Assistenzrollen von Menschen übernommen, heute kann AI sie in wirtschaftlich tragfähiger Form ersetzen
- Der Autor betont, dass dieser Wandel mehr bedeutet als bloße Kostensenkung
- Er entschärft Probleme der Statushierarchie
- Indem repetitive und monotone „grunt work“ an AI delegiert wird, lassen sich ungleich verteilte Aufgaben im Team reduzieren
- Da AI rund um die Uhr verfügbar ist, kann sie auch nächtliche Recherchen oder Codeanalysen übernehmen, die für menschliche Praktikanten nicht realistisch wären
Notion und die Ausweitung des „Arbeitens wie ein Chirurg“
- Der Autor beschreibt, dass dieser Ansatz bei Notion, wo er arbeitet, bereits praktisch umgesetzt wird
- Das Unternehmen fördert den Einsatz von AI-Coding-Tools aktiv, und auch die Codebase ist darauf ausgelegt
- Besonders für neu hinzukommende Entwickler in einer großen Codebase ist der Produktivitätsgewinn erheblich
- Auch auf Produktebene möchte Notion diese „Arbeitsweise wie ein Chirurg“ über Programmierer hinaus auf alle Wissensarbeiter ausweiten
- Das zentrale Ziel ist nicht, die Kernarbeit zu delegieren, sondern unwichtige, repetitive Nebenaufgaben zu identifizieren und zu delegieren, damit Menschen sich auf das Wichtigste konzentrieren können
7 Kommentare
Es scheint zu bedeuten, dass man sich auf die Kernaufgaben konzentrieren und die Randaufgaben der KI überlassen soll. Dem stimme ich weitgehend zu, und es scheint durchaus möglich, Aufgaben, die nicht zur Kerndomäne gehören und teilweise durch einige SaaS-Lösungen ersetzt werden, oder administrative Aufgaben durch KI zu ersetzen.
Noch umstrittener dürfte die Frage sein, ob sich auch Kernaufgaben durch KI ersetzen lassen. Letztlich wird sich der Trend wohl in die Richtung mit den besseren Ergebnissen bewegen. Wenn man sich anschaut, wie KI bei IOI- oder LeetCode-Problemen abschneidet, zeigt sie teils deutlich bessere Coding-Fähigkeiten als Menschen. Darüber vorschnell zu urteilen, übersteigt wohl meine Fähigkeiten, daher denke ich, dass wir abwarten sollten.
Diese Metapher ist ein völlig falscher Vergleich, der das Wesentliche verfehlt.
Eine Operation ist ein irreversibler Vorgang, Programmierung hingegen ein reversibler Vorgang (also sozusagen mit Save-and-Load-Möglichkeit).
Wenn auch Operationen reversibel wären, würden Chirurgen die Eingriffe ebenfalls eher untergeordneten Mitarbeitern überlassen, die operieren können, und selbst im Hintergrund entwerfen, Reviews machen oder managen. Wenn etwas schiefläuft, setzt man es eben einfach zurück.
Ich stimme zu. Ähnlich wird Software Engineering meiner Meinung nach auch oft mit Engineering im Bauwesen verwechselt.
Wenn man wirklich wie ein echter Chirurg programmieren will, müsste man das Programmieren nicht nur Leuten erlauben, die Informatik studiert haben? Wenn man die Zahl der Informatikstudienplätze erhöht, sollten sich die Programmierer vielleicht auch zusammenschließen und mal streiken ...
Warum gibt es keinen Coding-Assistenten!?
😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂
Hacker-News-Kommentar
Wenn ein unerfahrener Chirurg eine Operation beginnt im Glauben, dass Pflegekräfte oder der Anästhesist schon verhindern werden, dass Fehler passieren, kann der Patient sehr schnell sterben.
Nur weil man ein OP-Team braucht, heißt das nicht, dass die Ausbildung eines leitenden Chirurgen überflüssig wäre.
Das Problem ist die Haltung eines unerfahrenen Chirurgen, der denkt: „Ich muss das nicht extra lernen, die Pflegekraft reicht mir ja das Skalpell.“
Wenn man am Ende auf Kosten von Patienten lernen müsste, dann wäre das eben so, aber wenn nicht, sollte man zuerst auf die medizinische Fakultät gehen.
Deshalb spürt man im ganzen Text den Dunning-Kruger-Effekt (eine kognitive Verzerrung, bei der Menschen mit geringer Kompetenz ihre Fähigkeiten deutlich höher einschätzen, als sie tatsächlich sind).
Ich vertrete schon lange die Ansicht, dass Software Engineers The Mythical Man-Month lesen sollten.
In den letzten 25 Jahren haben sich Entwicklungsweisen stark verändert, etwa der Übergang von Waterfall zu Agile.
Wenn man aber mit LLM-basierter Entwicklung arbeitet, etwa mit Codex oder Claude Code, fühlt es sich eher so an, als kehre man zu Entwicklungsmustern der 70er und 80er Jahre zurück.
Heute kann man die Struktur durchdenken, fast so, als würde man eine Kathedrale entwerfen, und die Detailimplementierung delegieren.
Bei einer Operation arbeitet immer nur eine Person gleichzeitig, an Software können dagegen mehrere Menschen parallel arbeiten.
Es ähnelt eher einem Sportteam, und bei uns dauert es länger bis zur hohen Qualität, weil Übung und Coaching fehlen.
Dadurch kann man sich stärker auf das Design als aufs Coden konzentrieren.
Wenn man tatsächlich ein Hochhaus bauen würde, müsste man sich auch um die Qualität des Stahls und die Herkunft der Bolzen kümmern.
Das zu ignorieren wäre gefährlich.
Diese Metapher ist sowohl wörtlich als auch bildlich falsch.
Ein Chirurg ist nicht einfach nur ein Ausführender, sondern der Manager, der die gesamte Operation steuert, und tatsächlich ist der Anästhesist am wichtigsten.
Auch das Konzept von „einfacher Arbeit (grunt work)“ ist selbst schon eine falsche Sichtweise.
Sich selbst als Chirurgen und andere als Assistenzpersonal zu sehen, ist eine egozentrische Perspektive.
Wie in Brooks’ Konzept des „Chief Programmer“ kann ein leitender Entwickler dank der Unterstützung seines Teams arbeiten.
Der Autor sieht Juniors nicht als bloße Hilfskräfte, sondern als Mentees.
Es ist keine perfekte Metapher, aber die Botschaft zu AI-Coding-Tools verdient Respekt.
Als historisches Beispiel wurde angeführt, dass Operationen früher auch ohne Anästhesie möglich waren.
Zum Beispiel bei Framework-Erklärungen, die Programmierer mit Tischlern vergleichen: Auch echte Handwerker glätten nicht jeden einzelnen Teil perfekt.
Mir gefällt diese Metapher, und ich werde sie wohl künftig verwenden.
Eine weitere Metapher wäre die Werkstatt eines klassischen Malers.
Bei Rembrandt oder Rubens bereiteten Schüler die Leinwand vor und kolorierten Teile davon, während der Meister nur die entscheidenden Partien selbst malte.
Seit der Romantik entstand dagegen das Ideal des Künstlers, der alles allein vollendet.
Manche Programmierer möchten wie Turner allein erschaffen, aber ich möchte lieber wie Rembrandt das große Bild entwerfen und die Details an AI oder Juniors delegieren.
Die Codequalität muss gut sein, damit man schnell auf Nutzerfeedback reagieren kann.
Es geht nicht einfach darum, „schnell zu coden und fertig zu sein“, sondern um eine Struktur, die die Kosten von Änderungen reduziert.
Wenn ein rembrandtartiger Ansatz zu gutem Code führt, ist das in Ordnung, aber dafür gibt es bislang zu wenig Belege.
Ich habe Claude auch einige Monate genutzt, kam aber zu dem Schluss, dass es effizienter ist, direkt selbst zu coden.
Beim aktuellen Upgrade einer großen Datenbank von MySQL 8 auf 9 bat ich Claude jedoch, potenziell problematische Queries zu finden, und überraschenderweise lag es bei den meisten richtig.
Es war nicht perfekt, hat aber die Debugging-Zeit stark verkürzt.
Mir scheint es viel wertvoller, wenn ein LLM Risikopunkte identifiziert, als wenn es den Code direkt schreibt.
Wenn man bei einer alten Codebase einen Stack Trace anhängt, gibt das LLM oft eine erste Richtung fürs Debugging vor.
Beim Beheben von Performance-Problemen kann man es auch prüfen lassen, ob verschiedene Codepfade zum selben Ergebnis führen.
Das Schreiben von Code ist noch auf dem Niveau von Autocomplete, aber die Effizienz steigt eindeutig.
Ich musste an Dan Norths Vortrag Software Faster denken.
Besonders eindrücklich war die Aussage: „Software ist wie Chirurgie — man sollte nur das absolut Notwendige tun, um das Problem zu lösen.“
Der aktuelle Text ist davon allerdings ziemlich weit entfernt.
Deshalb fühle ich mich heute oft wie ein Chirurg, der ständig Amputationen durchführen muss.
Die Struktur des Chief Programmer Team scheint wieder in Mode zu kommen.
Diesmal in einer Form, bei der statt Menschen AI-Agenten Teil des Teams sind.
Fred Brooks’ Idee bekommt erneut Aufmerksamkeit.
Wenn man einem 10x-Entwickler ein fähiges Team zur Seite stellt, kann man die für Meetings oder Jira-Verwaltung verschwendete Zeit senken.
Wenn man schon hohe Gehälter zahlt, sollte man diese Zeit so wertvoll wie möglich nutzen.
Das Verständnis des Autonomie-Spektrums oder Delegations-Spektrums ist der Schlüssel, um AI-Coding-Tools gut zu nutzen.
Engineers sind Delegation nicht gewohnt, aber Gründer eignen sich das tendenziell schneller an.
Zur Formulierung „Der Chirurg konzentriert sich auf die wichtigen Dinge“ wurde angemerkt, dass in Wirklichkeit alle unterstützenden Aufgaben gleichermaßen wichtig sind.
Man sollte demütig die Unterstützung im Umfeld respektieren und die anderen ebenso supporten.