- In der Softwareentwicklung liegt der Engpass nicht beim Schreiben von Code, sondern in verschiedenen menschenzentrierten Prozessen wie Code-Reviews, Wissensweitergabe, Tests, Debugging sowie Zusammenarbeit/Kommunikation
- Dank LLMs ist die Codegenerierung selbst sehr einfach geworden, doch die Kosten und die Belastung für Verständnis, Verifizierung und Vertrauen sind eher noch gestiegen
- Schnelle Codegenerierung erzeugt mehr Belastung für Reviewer, Integratoren und Wartungsverantwortliche, ohne dass das gesamte Team dadurch tatsächlich schneller wird
- Code zu verstehen ist der schwierigste Teil, und auch wenn LLMs Code erzeugen, ist Qualität ohne Vertrauen und geteilten Kontext im Team nicht gewährleistet
- LLMs sind stark für Prototyping und Automatisierung, können aber die Grundlagen der Softwareentwicklung wie sorgfältiges Design, Reviews und geteilten Kontext nicht ersetzen
Der wahre Engpass beim Schreiben von Code
- Über viele Jahre hinweg war das eigentliche Schreiben von Code nicht der Engpass im Software Engineering
- Die realen Engpässe entstehen bei Code-Reviews, Mentoring und Wissensvermittlung durch Pair Programming, Tests, Debugging sowie durch die Kosten von Zusammenarbeit und Kommunikation
- Ticketverwaltung, Planungsmeetings, Agile-Meetings und andere komplexe Abläufe bremsen zusätzlich
- Diese Prozesse zur Qualitätssicherung erfordern in der Praxis deutlich mehr Zeit und Nachdenken als das eigentliche Schreiben von Code
- Durch LLMs nähern sich die Kosten für die Erzeugung von funktionierendem Code jedoch Null
- Die Kosten für Codeverständnis, Tests und Vertrauensbildung steigen dagegen eher noch
- Die anfängliche Umsetzung geht schneller, aber mehr Code muss reviewed, integriert und gewartet werden, was die Belastung erhöht
LLMs verändern die Natur der Arbeit – sie beseitigen sie nicht
- LLM-Tools wie Claude beschleunigen die Erstimplementierung, aber wenn in kürzerer Zeit mehr Code in ein System gelangt, erhöht das am Ende die Belastung für diejenigen, die Reviews und Wartung übernehmen
- Besonders in den folgenden Situationen verschärft sich diese Belastung
- Es ist unklar, ob der Autor den von ihm eingereichten Code selbst ausreichend versteht
- Der erzeugte Code verwendet ungewohnte Muster oder verletzt bestehende Konventionen
- Randfälle und unbeabsichtigte Nebenwirkungen sind nicht klar erkennbar
- Dadurch wird die Codeproduktion zwar einfacher, die Verifizierung aber schwieriger, sodass sich die Gesamtgeschwindigkeit des Teams letztlich nicht erhöht
- Unter Entwicklern gab es schon immer Witze über „Copy-and-Paste-Engineering“, aber mit LLMs wird dieses Phänomen noch deutlich verstärkt
Codeverständnis ist die eigentliche Schwierigkeit
> „Die größten Kosten von Code liegen nicht im Schreiben, sondern im Verstehen“
- Dank LLMs geht die Codeproduktion zwar schneller, aber Verhalten zu erschließen, subtile Bugs zu finden oder langfristige Wartbarkeit sicherzustellen wird dadurch keineswegs einfach
- Besonders schwierig wird es, wenn Reviewer generierten Code nicht von direkt geschriebenem Code unterscheiden können oder wenn die Gründe für den gewählten Lösungsweg schwer nachvollziehbar sind
Teams sind weiterhin auf Vertrauen und geteilten Kontext angewiesen
- Softwareentwicklung ist grundsätzlich auf Zusammenarbeit ausgelegt und hängt vollständig von gemeinsamem Verständnis, Alignment und Mentoring ab
- Wenn Code schneller erzeugt wird, als er diskutiert und reviewed werden kann, entsteht leicht die Illusion, die Qualität sei bereits abgesichert, obwohl das Team sie tatsächlich noch gar nicht bestätigt hat
- Dadurch steigt die psychologische Belastung für Reviewer und Mentoren, was die Geschwindigkeit des gesamten Teams auf neue Weise verlangsamen kann
LLMs sind mächtig, lösen das Grundproblem aber nicht
- Für schnelles Prototyping, Scaffolding und Automatisierung sind LLMs sehr wertvoll, aber sie beseitigen nicht die Notwendigkeit von klarem Denken, sorgfältigen Reviews und tiefgehendem Design
- Die Kosten für das Schreiben von Code selbst sind gesunken, aber die Kosten dafür, dass ein Team Code gemeinsam versteht und ihm Bedeutung gibt, haben sich nicht verändert
- Der wahre Engpass liegt weiterhin beim „Verstehen und Zusammenarbeiten“
7 Kommentare
Ich bin genau der Entwickler, dem die in diesem Artikel vorgestellten Fähigkeiten fehlen und der stark von LLMs abhängig ist.
Wegen meiner fehlenden technischen Kenntnisse ist es schwierig, ohne KI entsprechend dem WBS zu arbeiten, aber …
Was könnte ich zumindest tun, um die Review-Zeit der Senior-Entwickler zu verkürzen?
Nebenbei wäre es schön, wenn ich dabei auch mein eigenes Wissen aufbauen könnte …
Wenn man die Review-Zeit verkürzen will, muss man selbst entscheiden und erklären können, aus welchem Hintergrund der eigene Code entstanden ist und warum man sich unter verschiedenen Implementierungsmethoden genau dafür entschieden hat. Dafür sollte man Punkt 3. auch am Wochenende oder in der freien Zeit kontinuierlich üben, und es ist hilfreich, bekannte Bibliotheken oder Code, den andere auf GitHub hochgeladen haben, zufällig durchzusehen und dabei Dinge wie Codestruktur und Implementierungsstil zu analysieren.
Vielen Dank für Ihre freundlichen Worte!!
Und trotzdem wirkt es düster, wenn man sieht, dass Personal abgebaut wird ... Wie sollen 4 Leute 12 Projekte stemmen? Zumal eine Person dabei auch noch Management machen muss ...
schluchz Das muss wirklich sehr anstrengend für Sie sein.
Hacker-News-Kommentare
Als erfahrener Mentor, der ambitionierte, aber noch unerfahrene Praktikanten anleitet, habe ich beobachtet, wie sie an einem einzigen Tag Code im Umfang von einer oder sogar zwei Wochen produzieren. Aber meine Arbeit ist dadurch eher schwieriger geworden als leichter. Bei Code-Reviews zeigt sich, dass sich die Praktikanten mit dem von ihnen geschriebenen Code nicht tief genug auseinandergesetzt haben, sodass mein Feedback nicht gut ankommt. Einfache Bugs oder kleine Probleme sind fast verschwunden, aber die verbleibenden Probleme sind subtiler und komplexer und viel schwerer zu erklären. Außerdem tauchen neue Arten von Bugs auf, die ich früher nie gesehen habe. Code, der äußerlich völlig in Ordnung wirkt, funktioniert in Wirklichkeit manchmal überhaupt nicht, und vieles sieht zwar fertig aus, ist aber schon in den Grundlagen kaputt. Juniors, die mit LLMs zusammenarbeiten, neigen eher dazu, auf einmal komplexen Code zu produzieren, der in vielerlei Hinsicht Probleme für Zusammenarbeit und Wartung verursacht und nur so aussieht, als sei er abgeschlossen, statt einfachen, diskussionswürdigen Code einzureichen. Dadurch fühlt es sich so an, als würde die traditionelle Methode der „schrittweisen Verbesserung“, bei der man einen PR bis zur Endqualität verfeinert, nicht mehr richtig funktionieren. Wenn man Feedback gibt, wird oft nicht der ursprüngliche PR korrigiert, sondern gleich ein völlig neuer Ansatz vorgeschlagen — der dann häufig wieder neue Probleme erzeugt. Am Ende investieren Seniors in diesen einen PR oft viel mehr Zeit als Juniors. Die Juniors fühlen sich dabei vielleicht sehr produktiv, aber gleichzeitig wird das Feedback der Senior-Reviewer spürbar weniger warm oder ermutigend als früher. Letztlich war die einzig halbwegs wirksame Maßnahme, viele Testfälle zwingend vorzuschreiben, aber selbst diese Tests stoßen wegen ähnlicher Probleme an ihre Grenzen
Wenn ich solchen Code sehe, der „fertig aussieht, aber überhaupt nicht funktioniert“, muss ich an ein Offshore-Softwareprojekt im Wert von 250.000 Dollar denken, das ich früher erlebt habe. Auf dem Papier schien alles korrekt zu sein, in Wirklichkeit war es jedoch ein völlig inkonsistentes System. Weil man sich nur auf die Auslegung der Spezifikation fixiert und offensichtlichen Menschenverstand übersehen hatte, wurde am Ende das ganze Projekt sofort verworfen. Bemerkenswert ist, dass so etwas dank LLMs jetzt automatisiert und kostenlos wird
Ich kann diesem Problem vollständig zustimmen. Auch nach meiner persönlichen Erfahrung kann man mit LLMs zwar sehr schnell Tausende Zeilen Code erzeugen, aber die wirklich schwierigen Aufgaben sind Code-Review, Bugfixing, Prüfung auf Sicherheitslücken, Refactoring und das Entfernen überflüssigen Codes. Am Ende war es oft produktiver, direkt selbst zu programmieren. Der realistischste Einsatz von LLMs ist, sie nur für Autovervollständigung oder kleine Code-Snippets zu nutzen. Wenn ein Junior ein LLM dazwischenschaltet und ich die Dinge dann noch einmal weitervermitteln muss, sinkt die Effizienz eher noch. Menschen, die derzeit das Gefühl haben, mit LLMs produktiver zu sein, könnten dieses Gefühl in Wirklichkeit nur deshalb haben, weil sie genau diese wichtigen Aufgaben einfach überspringen oder ihnen gar keine Aufmerksamkeit schenken. Tatsächlich tragen dann nur die wenigen Leute, denen Produktqualität wirklich wichtig ist, die Last, enorme Mengen an Code bewältigen zu müssen. Sie werden manchmal als unnötig pedantisch missverstanden, sind aber in Wahrheit die eigentlichen Hauptfiguren, die den Nutzern das bestmögliche Produkt liefern wollen. Eine echte Lösung sehe ich nicht, eher im Gegenteil: Die Lage wird sich wohl weiter verschlechtern. Entwickler, die ausschließlich mit LLMs trainiert wurden, werden weiter in die Branche strömen, und die Unternehmen, die diese Tools bauen, werden weiter übertriebenes Marketing betreiben. Am Ende steigt nur die Last, Qualität aufrechtzuerhalten
Dieses Phänomen der „effort inversion“, bei dem Seniors mehr Aufwand in einen PR stecken als Juniors, erlebe ich ebenfalls. Bei mir nutzen PR-Autoren AI zum Schreiben von Blogposts oder Pressemitteilungen, und wenn ich als Fachexperte das Ergebnis bekomme, vervierfacht sich mein Arbeitsaufwand beinahe, weil ich alle möglichen AI-Halluzinationen und Fehler korrigieren muss. Eigentlich sollen sie meine Arbeit unterstützen, aber inzwischen muss ich ihnen helfen. Und weil die AI-Halluzinationen jedes Mal anders ausfallen, ist es jedes Mal wieder neue Arbeit. Ich habe dieses Phänomen den Führungskräften bereits geschildert, und wenn es so weitergeht, wird nächstes Jahr vermutlich die Hälfte des PR-Personals verschwinden. Wenn niemand gebraucht wird, der E-Mails in ChatGPT kopiert und mir das Ergebnis zurückschickt, kann ich das auch selbst tun
Ich würde gern mehr Details zu dem Teil hören, in dem du sagst: „Beim Review kam mein Feedback nicht richtig an.“ Ich habe ein ähnliches Problem und wäre dankbar, wenn du mögliche Lösungen oder Einsichten teilen könntest
Wenn ich noch meinen Gedanken hinzufügen darf: Frühere Generationen haben durch Refactoring oder Unit-Tests ganz natürlich ein tiefes Verständnis für Softwarestruktur und Design aufgebaut. Wenn LLMs künftig sogar Unit-Tests generieren, verlieren Entwickler womöglich die Gelegenheit zu Selbstreflexion und Lernen — Fragen wie „Was brauche ich eigentlich?“, „Wie könnte man das einfacher machen?“ werden dann gar nicht mehr gestellt. Genau darin sehe ich den Unterschied zwischen „Entwickler“, „Engineer“ und „Architekt“. LLMs oder „vibe coding“ fördern eine solche Denkweise niemals. In Sprachen mit geringer Syntaxlast wie Go werden solche Designfehler im Review leichter sichtbar. Die Struktur von Unit-Tests in Go eignet sich gut, um die Komplexität von Code zu diagnostizieren. Letztlich brauchen wir bessere Test- und Review-Methoden. Fuzz-Tests, Unit-Tests und Integrationstests allein reichen nicht aus. Ich denke, wir brauchen automatisierte Test-Frameworks, die logisch prüfen können, ob die Verzweigungen im Code tatsächlich korrekt aufgerufen werden und ob die Erfüllungsbedingungen gelten
Dank LLMs nähern sich die Einführungskosten neuer Software zwar beinahe null, aber die Kosten dafür, diesen Code tiefgehend zu verstehen, zu testen und ihm zu vertrauen, fühlen sich höher an als je zuvor. Nach meiner Erfahrung ist von LLMs erzeugter Code allerdings auch nicht unbedingt viel schlechter als der viele Altcode, den irgendwer hinterlassen hat und zu dem man niemanden mehr fragen kann, oder als Code, der irgendwo online herumliegt. Im Gegenteil: LLMs schreiben Testcode, ohne wie Menschen genervt zu sein oder aus Müdigkeit Dinge einfach durchzuwinken. Meine Philosophie beginnt mit der Annahme, dass „jeder Code potenzielle Schulden“ ist. Deshalb mache ich mir über die Vertrauenswürdigkeit von Code nicht allzu viele Sorgen. Ich habe tatsächlich große Codebasen mit AI aufgebaut und sie ausreichend gut zum Laufen gebracht — allerdings nur in Domänen, die sich verifizieren lassen und viele Tests und Iterationen erlauben. Unterm Strich hat LLM-Output die Codeproduktion beschleunigt, aber die intellektuelle Stimulation des eigentlichen Programmierens verringert, sodass sich auch mein Gehirn träger anfühlt. Stattdessen gehen wir eher in eine Ära über, in der vorgelagerte Denkarbeit wie Anforderungsdefinition und Design viel wichtiger wird
Auch ohne LLMs litt die Branche bereits nicht an „zu wenig Code“, sondern war durch Marktnachfrage und Kapitalgrenzen in ihrer Entwicklungsgeschwindigkeit beschränkt. Tooling ist so gut geworden, dass das reine Programmieren nicht mehr der Kernpunkt ist. Die Umgebung ist völlig anders als in der Frühzeit. Ich muss an eine alte Geschichte aus Bill Gates’ Jugend denken, als schon die bloße Fähigkeit zu programmieren eine knappe Ressource war. Ein Unternehmen stellte den 16-jährigen Gates und Paul Allen ein, weil es dringend war, und war allein schon davon beeindruckt, dass sie einfach schnell Code schreiben konnten. Heute ist die wichtigere Frage: „Was entwickelt man überhaupt, und trägt sich daraus ein Geschäft?“
Passendes Video
Ich stimme der Aussage zu, dass Programmieren wegen der Marktnachfrage nie der eigentliche Engpass war. Schon vor dem AI-Boom sagte Marc Andreessen, es gebe zwar reichlich Kapital, aber zu wenige gute Ideen, in die man investieren könne. Ich glaube nicht, dass das die Realität perfekt beschreibt, aber zumindest in den Daten wirkt seine Aussage plausibel
Wie in den alten Anekdoten über Bill Gates ist die Fähigkeit, hochwertigen Code zu schreiben und tief zu verstehen, nach wie vor eine knappe Ressource. Der Unterschied zu früher ist nur, dass die Branche diese Fähigkeit heute nicht mehr besonders hoch bewertet
Aus Sicht der Analyse von AI-Impact neigen wir dazu, Effizienz zu überschätzen. Die reale Wirtschaft ist jedoch sehr viel komplexer und hat Engpässe an ganz anderen Stellen. Selbst wenn die Codeproduktion um das 100-Fache steigt, ist unklar, ob das tatsächlich nützlich ist
Wenn man heute manche Erfahrungsberichte liest, wirkt das ziemlich deprimierend. Wenn ein Junior einen riesigen Codeklumpen übergibt, der nicht funktioniert, nicht selbst getestet oder verifiziert wurde, nicht sauber verdichtet ist und ohne Dokumentation, Kommentare oder Erklärung daherkommt, dann ist das an sich schon eine „auf Menschen installierte Version eines LLM“. Entscheidend sind letztlich kritisches Denken und Verantwortungsbewusstsein für das Ergebnis. Ich glaube sogar, dass ein LLM eher zuverlässiger auf Feedback reagiert als ein traditioneller Junior-Softwareingenieur
Auch ich hielt das Schreiben von Code einmal für den Engpass, habe aber über zehn Jahre gelernt, dass die wirklich schwierige Aufgabe darin besteht, Technologie mit dem Business in Einklang zu bringen. Selbst in Umgebungen wie B2B oder SaaS, in denen man komplexe Codehaufen für Kunden mit jeweils unterschiedlichen Anforderungen pflegt, läuft alles gut, wenn die Technologie sauber auf das Geschäft ausgerichtet ist. Heute ist die Technologie weit genug, sodass es nun vor allem auf das Ego der Entwickler und ihre Fokussierung auf Kundennutzen ankommt. Man muss darüber nachdenken, was Kunden tatsächlich wollen, ob sie dafür bezahlen würden und ob überhaupt eine Weboberfläche nötig ist. Die „Cat-Toy-Features“, die Entwickler zu ihrer eigenen Befriedigung bauen, sind der wahre Grund für steigende Cloud-Kosten. Noch trauriger ist, dass sich dieses grundlegende Problem auch nicht lösen lässt, indem man aggressive Incentives, Stock Options oder hohe Gehälter anbietet. Es braucht jemanden — wenigstens eine Person — mit einem echten Sendungsbewusstsein dafür, gute Software zu bauen, die direkt mit Kunden spricht und es wirklich richtig machen will
In Organisationen waren die Momente, in denen LLMs mir wirklich geholfen haben, eher bei persönlichen Projekten oder Side Projects. Wenn ich eine App baue, um ein kleines Problem zu lösen, wird das Schreiben von Code wegen Zeitmangels tatsächlich zum großen Engpass. Für solche Projekte liegt meine LLM-Nutzung bei 100 %
Dem stimme ich hundertprozentig zu. Wenn ich täglich ein bis zwei Stunden in Claude Code investiere, habe ich gegen Ende des Wochenendes meist ein brauchbares Ergebnis, das sich tatsächlich verwenden lässt. Mit wenig Zeitaufwand lassen sich Ideen validieren und Experimente leicht durchführen. Ich denke, solche LLM-Tools schaffen auch in professionellen Organisationen enormen Wert. Alle möglichen internen Tools und Automatisierungssysteme, für die sonst im Alltag nie Zeit wäre, lassen sich schnell prototypen. Wenn ein Kollege eine Datenbankabfrage oder eine einfache Automatisierung braucht, kann er Claude fragen, das Ergebnis reviewen und es direkt einfügen. Mein Projekt mcp-front[0] verfolgt genau dieses Ziel: Menschen, die keine Engineers sind, dabei zu unterstützen, wiederkehrende Aufgaben in ihrem Bereich selbst zu erledigen
mcp-front GitHub
Ehrlich gesagt ist es in meiner aktuellen Karrierephase schwer, noch wochenlang alles hineinzustecken, und dank meiner langjährigen Erfahrung denke ich ohnehin immer auch an nichtfunktionale Anforderungen und die langfristige Perspektive. Selbst wenn ich Dinge wie Tests überspringen würde, gäbe es am Ende immer noch genug, worüber man weiter nachdenken müsste
Mich erinnert das an das berühmte Zitat von Robert C. Martin: „Wir verbringen mehr als zehnmal so viel Zeit mit dem Lesen von Code wie mit dem Schreiben“
Passendes Zitat
Leider führt sein Clean-Code-Stil in der Praxis manchmal gerade dazu, dass der Kontext zersplittert und die eigentliche Absicht noch schwerer erkennbar wird
Noch schlimmer ist, dass sich womöglich nur die Schreibzeit verkürzt, während die Lesezeit steigt, sodass die Gesamtarbeit am Ende gar nicht abnimmt
Niemand hat den Artikel von Joel Spolsky vom 2. Oktober 2000 erwähnt, deshalb verlinke ich ihn hier
Joel on Software: Painless Functional Specifications (2000)
Der wahre Engpass ist nicht der Code, sondern die Funktionsspezifikation. Wichtiger ist es, klare Spezifikationen dafür zu erstellen, wie Software funktionieren soll — in Englisch, Diagrammen, User Stories usw. Wenn die Spezifikation gut steht, kann ein LLM durchaus in einem Zug hervorragende Lösungen, Tests und Integrationstests erzeugen. Wenn das zu groß wird, sollte man die Spezifikation nicht in einer einzigen Markdown-Datei verwalten, sondern sie wie ein Wiki nach Funktionen aufteilen und über Links und Referenzen organisieren. Nicht die Schwierigkeit der Implementierung, sondern wie viel Mühe man in die Spezifikation steckt, ist die eigentliche Wettbewerbsfähigkeit
Der Verfasser stimmt der Ansicht des Autors nicht zu. Aus Sicht großer Unternehmen mag Code nicht der Engpass sein, aber aus Sicht von Startups waren begrenzte Ressourcen und effiziente Planung wichtiger, und in vielen Fällen war gerade das Erstellen von tatsächlich funktionierendem Code selbst der größte Engpass. Solche Diskussionen lassen sich letztlich nicht verallgemeinern, wenn es darum geht, „wie nützlich AI/LLMs sind“. Für manche Teams war Code der Engpass, für andere nicht
Wie jeder weiß, ist der Code, den LLMs erzeugen, oft chaotisch und nicht einmal reviewbar. Wenn ein Junior merkwürdigen LLM-Code einreicht und man nach dem Grund fragt, kennt er ihn selbst nicht und sagt nur, das LLM habe ihn erzeugt. Dieser Trend erhöht letztlich nur „Rauschen“ und Overhead in der Wartung. Wenn sich die Einführung von LLMs nicht vermeiden lässt, wird man Reviews und Wartung am Ende wohl ebenfalls LLMs überlassen müssen. Das Ergebnis wird natürlich noch komplizierterer Spaghetti-Code sein. Realistisch betrachtet ist Qualität für die meisten Unternehmen aber ohnehin nicht besonders wichtig; solange LLM-Code irgendwie halbwegs funktioniert, reicht das vielen. Oder es genügt, bei Bedarf einfach noch mehr LLM obendraufzuschichten, bis es am Ende irgendwie gelöst ist