- AI-Coding-Agenten steigern die Geschwindigkeit beim Schreiben von Code drastisch, doch der wichtigste Teil der Entwicklung bleibt weiterhin Verständnis und Problemlösung
- Mit LLMs lässt sich zwar schnell Code erzeugen, aber wegen mangelnden Verständnisses des Gesamtkontexts wird mehr Zeit für Nachbearbeitung und Verständnis benötigt
- Dadurch entsteht eine Lücke zwischen Erwartungen an die Produktivität und der tatsächlichen Effizienz, und Entwickler verbringen statt mit kreativer Arbeit mehr Zeit mit wiederholenden und belastenden Aufgaben wie Tests, Refactoring und Dokumentation
- Ähnlich wie beim früheren „Dilemma des Tech Leads“ führt das Verschieben komplexer Aufgaben auf AI oder Senior-Entwickler zugunsten kurzfristiger Ergebnisse langfristig zu sinkender Teamkompetenz und Risiken
- LLMs sollten als leistungsstarke Junior-Engineers betrachtet werden, und durch die Anwendung bewährter Entwicklungsprozesse auf die Zusammenarbeit mit AI muss eine Struktur für nachhaltige Software Delivery geschaffen werden
Problembewusstsein: Was wichtiger ist als das Codieren selbst
- Softwareentwicklung ist in erster Linie Problemlösungsarbeit
- Das eigentliche Codieren ist nur der letzte Teil des gesamten Denk- und Analyseprozesses eines Entwicklers
- Entwickler leisten neben dem Schreiben von Code viele weitere Aufgaben wie Domänenverständnis, Zerlegung von Anforderungen, Abstraktion, Berücksichtigung von Nebenwirkungen, schrittweises Testen und Fehlerbehebung
- Klassischer Entwicklungsablauf: erst gründlich nachdenken, dann Code schreiben
- Im Zeitalter des AI-Codings wandelt sich das Muster zu erst Code, Verständnis später
Der Wandel durch AI-Coding: ein Paradigma, in dem Code zuerst erzeugt wird
- AI-Coding-Agenten wie Claude Code erzeugen Code schnell, können den Gesamtkontext des Systems aber nicht vollständig erfassen
- Der menschliche Prozess aus Review, Test und Integration bleibt unverzichtbar, und das nachträgliche Verstehen von AI-generiertem Code kostet viel Zeit
- Im Marketing wird die höhere Codiergeschwindigkeit betont, doch die tatsächliche Produktivitätssteigerung bei der Auslieferung funktionierender Software ist gering
- Entwickler investieren mehr Zeit in wiederholende und schwierige Aufgaben wie Tests, Deduplizierung, Dokumentation und Infrastrukturmanagement für die von der AI erzeugten Ergebnisse
- Die Freude am eigentlichen Codieren nimmt ab, während repetitive Arbeit zunimmt
Das alte Dilemma technischer Führungskräfte
- Wenn ein Engineer die Rolle des Tech Leads übernimmt, trägt er die Verantwortung für die technische Delivery des Teams
- Wenn sich die Erfahrung im Team auf eine Person konzentriert, entsteht ein Ungleichgewicht in der Produktivität
- Es entsteht ein Konflikt zwischen zwei Strategien: faire Verteilung (mit Fokus auf Wachstum der Teammitglieder) und Konzentration der Arbeit (mit Fokus auf schnelle Entwicklung)
- Die Konzentration bringt kurzfristig große Vorteile, verursacht durch die Bündelung von Erfahrung aber langfristige Risiken für das Team, etwa fehlende Absicherung, Burnout und Schwierigkeiten bei der Unterstützung
- Für eine gesunde Teamkultur braucht es einen Weg, Wachstum und Effizienz auszubalancieren
Der Kern guter Führung: Balance zwischen Prozessen und Wachstum
- Damit das Know-how erfahrener Engineers vom gesamten Team übernommen werden kann, müssen verschiedene Entwicklungsprinzipien und Frameworks angewendet werden
- Beispiele: Extreme Programming, Code Review, schrittweise Auslieferung, modulares Design, Test-Driven Development, Pair Programming, Dokumentation, Continuous Integration usw.
- Das übergeordnete Ziel: Nacharbeit minimieren, Zusammenarbeit maximieren und individuelles Wachstum fördern
Zusammenarbeit mit AI-Agenten: eine neue Rolle für Team Leads
- Moderne LLM-basierte Coding-Agenten ähneln extrem schnellen Junior-Entwicklern
- Im Unterschied zu klassischen Juniors haben LLMs zwei klare Merkmale: keine Lernfähigkeit und keine Geschwindigkeitsbegrenzung
- AI konzentriert sich nicht auf Qualitätsverbesserung, sondern fortlaufend auf mehr Geschwindigkeit, während menschliches Kontext- und Domänenverständnis fehlt
- Zwei Muster der Zusammenarbeit:
- AI-basierte Engineering-Arbeit: auch wenn sie langsamer ist, zielt sie auf effiziente und nachhaltige Teamarbeit
- Vibe Coding: konzentriert sich auf schnelle Resultate, häuft aber nach und nach nicht mehr behebbare Unordnung an
- Das ähnelt dem traditionellen blinden Fleck des Codewachstums im Silicon Valley: Auf kurzfristige Gewinne folgt das Erreichen einer Wachstumsgrenze
Praktische Wege, um die Falle des AI-Codings zu überleben
- LLMs kennen ihren jeweiligen Kontext nicht und produzieren daher wahllos Code
- Engineers müssen der AI klare Strukturen, Standards und Prozesse geben, um rohe Ausgaben in echte Services zu überführen
- Es braucht ein neues Playbook, das die Best Practices klassischer Entwicklungszyklen eng auf die Zusammenarbeit mit AI anwendet
- Wichtige Einsatzmöglichkeiten von AI je Phase:
- Spezifikationsdefinition: Analyse von Edge Cases, Fokus auf den Zielumfang
- Dokumentation: Sicherung wiederverwendbarer Leitfäden und Nachweise
- Moduldesign: besseres Verständnis durch Begrenzung des Kontexts
- Test-Driven Development: Testfälle vor der Implementierung erzeugen, Regressionen verhindern
- Coding-Standards: Stil und Qualität aufrechterhalten
- Monitoring: automatische Analyse von Logs und Gewinnung von Erkenntnissen
Fazit
- Software Delivery besteht nicht nur aus dem Schreiben von Code; entscheidend ist der Aufbau einer effizienten Struktur für die Zusammenarbeit von AI und Menschen
- Wenn LLMs als ultraschnelle Junior-Entwickler betrachtet und bewährte Entwicklungsprozesse angewendet werden, lässt sich skalierbare, hochwertige Software bereitstellen
2 Kommentare
Hacker-News-Kommentare
Ich würde gern ein anti-AI-Argument sehen, das nicht einfach auf der Behauptung basiert, „Technologie mache Menschen faul“. Wer ernsthaft schon einmal versucht hat, mit einem LLM Code zu erzeugen, merkt, dass der Zyklus aus Planung–Strukturierung–Testen–Rückblick weiterhin sehr wichtig ist. Wenn man unachtsam einfach loslegt, geht es schnell kaputt. Wendet man diesen Zyklus gut an, kann man viel Zeit darauf verwenden, die Architektur zu entwerfen, die ich mag, und das resultierende Verhalten zu testen. Da das LLM die einfachen Teile schnell erledigt, bleiben am Ende die weniger interessanten und wenig gewürdigten Aufgaben bei uns hängen. In Bereichen, in denen AI Fachwissen besonders gut zur Geltung bringt, zeigt sich der Unterschied in der Haltung sehr deutlich zwischen Menschen, die die Arbeit selbst genießen, und solchen, die das Denken daran genießen. Wer gern denkt, kann sich dank AI fast vollständig auf diesen Bereich konzentrieren. Wer dagegen das direkte Tippen und Hantieren mag, dem nimmt AI eher genau den Teil weg, den er liebt
Beim Thema AI-Codegenerierung halte ich nicht die Idee, Technologie mache Menschen faul, für die wichtigere Kritik, sondern dass sie einem das tiefe Verständnis des von der AI erzeugten Codes nimmt. Der Kern der Arbeit eines Softwareingenieurs ist nicht das Erzeugen von Code, sondern das Entwerfen des Gesamtsystems. Entscheidend sind dabei das mentale Modell darüber, wie der Code funktioniert, und die Domänenexpertise; der Code ist ein daraus abgeleitetes Ergebnis. In Projekten ab einer gewissen Größe ist es ohnehin schwer, Code vollständig zu kennen, wenn man ihn nicht selbst geschrieben hat. Wenn man dieses mentale Modell nicht aufbaut, folgen weitere Probleme. LLM-basierte Coding-Agenten haben Grenzen beim Schlussfolgern auf Syntaxebene und dadurch Schwächen bei der Skalierbarkeit
Wenn ich meine eigene Sicht beschreibe: Ich benutze gelegentlich AI-Tools wie Cline, tippe aber zunehmend wieder mehr direkt selbst. Der Grund ist, dass Coding in den meisten Fällen nur durch Prompt-Schreiben ersetzt wird. Wenn Prompt-Schreiben und Inferenzzeit kürzer sind als die Zeit, die ich zum direkten Coden brauche, nutze ich AI, aber das trifft meist nur zu, wenn es um Geschwindigkeitsgrenzen bei Refactorings geht. Bei den meisten Aufgaben brauche ich direkt vielleicht 10 Minuten, mit AI schreibe ich einen Prompt, lasse ihn laufen und bin in 8 Minuten fertig. Wenn alles fehlerfrei klappt, spare ich 2 Minuten; wenn aber Korrekturen oder ein erneuter Prompt nötig sind, dauert es eher 10–12 Minuten, und ich habe auch noch AI-Credits verbraucht — im schlimmsten Fall also das schlechteste Ergebnis. Wenn ich das so durchrechne, komme ich zu dem Schluss, dass Handarbeit in Bezug auf Codequalität und Zeitaufwand sicherer ist
Zur Behauptung, Technologie mache Menschen unachtsam: Allgemein gibt es viele Fälle, in denen Technologie Menschen gerade sorgfältiger macht. Das Problem ist, dass diese AI-Technologie die Nutzer mit hoher Wahrscheinlichkeit zur Unachtsamkeit verleitet. Mich interessiert nicht der spaßige Teil des Codens; ich bevorzuge das Design selbst, also die Architektur. Wenn ich meine Absicht direkt in Code umsetzen könnte, würde ich das tun. Aber eine Chatbot-Oberfläche vermittelt diese Absicht nur indirekt und unvollständig, sodass sich mein mentales Modell und mein tatsächliches Verständnis des Codes bei der Nutzung für High-Level-Codeaufbau schnell voneinander entfernen und ein instabiles Fundament hinterlassen. Man könnte zwar Zeile für Zeile gründlich reviewen, aber das widerspricht dem Sinn des Werkzeugs. AI-Coding fördert durch das Gefühl, „10-mal schneller“ zu sein, die Kluft zwischen Implementierungsdetails und Gesamtverständnis. Tatsächlich ist es ein zentraler beworbener Vorteil von AI-Coding, weniger über die strukturellen Teile nachdenken zu müssen, aber genau diese Verständnislücke verursacht später Probleme. Gute Automatisierung ist verlässlich und vorhersehbar, sodass man nur die übergeordneten Invarianten verstehen muss, aber Chatbot-Code gibt diese Garantie nicht und erzeugt am Ende eine Struktur, in der man doch alles manuell verifizieren muss. Sicherheit und Zuverlässigkeit wirken hier eher noch schwerer erreichbar
Ich sehe die Logik „Konzentriere dich auf den denkenden Teil“ so oft, dass sie mir inzwischen abgedroschen vorkommt. Das Problem ist: Ich bezweifle, dass jemand ohne mehrjährige Praxiserfahrung allein durch Nachdenken wirklich tiefgehende Arbeit leisten kann. Letztlich besteht ohne eigene praktische Erfahrung die Gefahr, dass sogar das Denken selbst immer oberflächlicher wird
Meine Ansicht ist einfach: Debugging ist härter als Schreiben, also ist es besser, den Code selbst zu schreiben, als Code zu debuggen, den ich nicht geschrieben habe
Wenn ich solche Diskussionen lese, frage ich mich jedes Mal, ob der Autor überhaupt dieselben Tools benutzt wie ich. Mit Claude Code kann ich fast alles erzeugen lassen, von einfachem Boilerplate bis zu komplexen Algorithmen, selbst in sehr verwirrenden großen Codebasen. Natürlich liegt es nicht zu 100 % richtig, aber es ist sehr nah dran. Außerdem schlägt es oft Algorithmen vor, auf die ich selbst nicht gekommen wäre. Diese Tools sparen mir mindestens den Faktor 10 an Zeit
Der Artikel ist in Ordnung, aber ich sehe zwei Scheinannahmen. Erstens bleibt es auch dann zwingend nötig, ausreichend zu erkunden, vorab nachzudenken und zu entwerfen, wenn erfahrene Entwickler LLMs benutzen. Um LLMs richtig einzusetzen, denke ich sogar mehr nach als früher, vergleiche verschiedene Designvarianten und skizziere die Gesamtstruktur. Früher habe ich diesen Prozess nicht dokumentiert, heute halte ich ihn als Designdokument fest. Zweitens gibt es die Behauptung, ein LLM sei wie ein Junior-Entwickler, der nicht wächst — aber die beiden sind völlig verschieden. Ein menschlicher Berufseinsteiger ist eine Person, ein LLM ist ein Werkzeug. Oft heißt es, Zusammenarbeit mit Juniors schaffe kumulativen Wert, mit LLMs dagegen nicht, aber auch das halte ich für falsch. Selbst wenn das LLM nicht lernt, lerne ich, es viel effizienter zu zähmen und besser einzusetzen. Da wir uns noch in der frühen Phase befinden, LLMs gut in Produkte einzubinden, zeigt sich ganz natürlich ein zusammengesetzter Wachstumswert
Dem Satz „Auch wenn das LLM nicht lernt, lerne ich“ stimme ich zu, aber ich wünsche mir trotzdem, dass LLMs aus der Interaktion mit dem Nutzer tatsächlich lernen. Was ich möchte, ist, den Inhalt einer Sitzung in einer Datei speichern/laden zu können, sodass das LLM den gesamten zuvor gelernten Kontext lückenlos versteht. Manche Frontend-UIs können Sitzungen speichern und wiederherstellen, aber wichtig wäre: a) Dieses „Wiederanlernen“ sollte das aktuelle context window des LLM nicht beeinflussen (idealerweise gäbe es dieses Konzept gar nicht mehr), und b) es müsste absolut verlustfrei sein. Ansätze wie Zusammenfassen und dann weitermachen oder RAG existieren bereits, aber sie haben alle grundlegende Grenzen, etwa Informationsverlust oder die Tatsache, dass Wiederherstellung nur möglich ist, wenn die aktuelle Interaktion sie auslöst. Wenn ich dem LLM zum Beispiel gestern eine Funktion erklärt und die Sitzung gespeichert habe, möchte ich, dass es nach der Wiederherstellung heute auch bei einer völlig unabhängigen Frage den alten Kontext vollständig mit einbezieht. Gleichzeitig sollte man bei Bedarf ausdrücklich auch mit einer clean slate neu anfangen können
Das stimmt. Da in der Gesamtproduktivität von Software die Denkzeit einen viel größeren Anteil ausmacht als die Zeit fürs eigentliche Schreiben von Code, führt eine Beschleunigung des Coding-Teils durch LLMs nicht automatisch zu dramatischen Veränderungen bei Gesamtproduktivität oder Personalbedarf
Für mich ist es ebenfalls Standard, mit dem Prompt DO NOT WRITE ANY CODE YET zu beginnen. So finde ich zuerst heraus, was das LLM tun will, und sichere mir die Kontrolle. Mir macht das Design selbst mehr Spaß als das Schreiben von Code — also Logik, Problemlösung, Systemintegration und Ähnliches
Es gibt Funktionen wie den Ask-Modus von Copilot oder den Plan/Chat-Modus von GPT-5 Codex, mit denen man planen kann, ohne Code-Dateien zu verändern. Ich habe Codex ein paar Tage benutzt, und wenn man genügend Anweisungen gibt, ist es ausgezeichnet
Ich bevorzuge es ebenfalls meistens, das LLM zuerst nach einem konkreten Ausführungsplan zu fragen, etwa mit „Erzähl mir zuerst den Plan“
Dieser Artikel beruft sich ausschließlich auf Marketingmaterial von Microsoft, um eine Produktivitätssteigerung von 10 % zu behaupten, während in einer Harvard-Studie tatsächlich eher ein Produktivitätsrückgang von 10 % gemessen wurde. Mir wären Artikel lieber, die zuerst unabhängige Forschung zitieren und nicht die PR eines einzelnen Unternehmens
Einer der zentralen Punkte, die der Artikel nicht vollständig transportiert, ist für mich Casey Muratoris Aussage, dass „AI im Grunde bedeutungslos ist, wenn man mit einer auf Lernen ausgerichteten Haltung programmiert“. Persönlich finde ich, dass AI-Codegeneratoren nur für einmaligen oder wegwerfbaren Code wirklich nützlich sind. In Bereichen, in denen ich ernsthaft lernen will, habe ich das Gefühl, dass der Lerneffekt maximal ist, wenn ich die Codeerzeugung nicht an AI abgebe. Es gibt sicher Menschen, für die „AI-driven Engineering“ sinnvoll ist, aber zumindest für mich macht es mehr Spaß, Codeblöcke direkt mit der Hand zu schreiben, und am Ende wird auch das Ergebnis besser. Zugehöriges Video, 5 Minuten
Seit ich Claude Code benutze, verbringe ich deutlich mehr Zeit mit Denken. Früher hätte ich nie 400 bis 600 Wörter gebraucht, um ein gewünschtes Feature zu beschreiben, heute ordne ich viel mehr Informationen gründlich. Diese Überlegungen führen zwar zu schnelleren und besseren Ergebnissen, aber gleichzeitig ist mein Verständnis des Codes etwas geringer als früher. Der Behauptung, erfahrene Entwickler dächten weniger nach, wenn sie Claude Code nutzen, kann ich jedoch nicht zustimmen. Wahrscheinlich verwenden viele Leute Agenten einfach ineffizient, etwa indem sie fast nur Prompts schreiben, aber das ist aus meiner Sicht nicht die Schuld des Agenten
Wenn ich diese Diskussionen sehe, denke ich, dass wir gerade noch in einer uneindeutigen Übergangsphase sind. Vielleicht werden Diskussionen wie die heutige schon nächstes Jahr als „zu verkopft“ gelten. Es erinnert mich an die Zeit vor und nach der Verbreitung des Internets, als es viele Zweifel gab wie „nur ein vorübergehender Trend“ oder „eine Fehlinvestition“
Was solchen Artikeln oft fehlt, ist Folgendes
Ich hätte gern einen Artikel, der einfach die Vor- und Nachteile sowie die Trade-offs von AI-Codeassistenz systematisch ordnet. Ohne moralische Wertung (gut/schlecht), einfach als Diskussion. Ich gebe zu, dass es besonders schwer ist, nüchtern an die Sache heranzugehen, wenn „Coding-Fähigkeit“ Teil der eigenen Identität ist
Ich sage mir jeden Tag selbst: „Halte noch 30 Jahre durch, dann geh in Rente.“ Zehn Jahre im Machine Learning, müde vom Sitzen vor dem Computer und müde von der Arbeit. Ich würde am liebsten einfach nur im Gras herumliegen
Das Diagramm „Denken & Coden vs. Denken & Überarbeiten“ ist interessant. Als ich zuletzt Codex benutzt habe, hatte ich eigentlich erwartet, dass AI vor allem viel an meinem Code ändern würde. In Wirklichkeit ging aber enorm viel Zeit verloren, wenn die Ursache des Problems überhaupt nichts mit dem Code zu tun hatte. Kürzlich habe ich lange nur den Code untersucht, weil es ein Authentifizierungsproblem gab, und am Ende stellte sich heraus, dass die Ursache eine fehlerhafte IPv6-Konfiguration der VM war
Dem kann ich zustimmen. Wenn man mit AI codet, fällt so viel Nachbearbeitung an, dass es sehr schwer wird, das Ganze tatsächlich ins Business zu integrieren und zu warten.
Selbst wenn man aus der Perspektive einer gemeinsamen Entwicklung möglichst viel Pingpong betreibt und so vorgeht, kommt es oft vor, dass einem Teile des Codes wieder entfallen, weil man sie nicht selbst geschrieben hat.
Ich denke, klare Grenzen sind auf jeden Fall nötig.