- Die Behauptung, KI steigere die Produktivität von Ingenieuren um das 10- bis 100-Fache, ist nicht realistisch
- Wer KI-Coding-Tools tatsächlich intensiv nutzt, merkt, dass die Effizienzgewinne begrenzt sind und es nur bei wiederholenden, einfachen Aufgaben zeitweise zu einem Produktivitätsschub kommt
- Engpässe in der Softwareentwicklung (Code-Review, Zusammenarbeit, Planung usw.) lassen sich mit KI nicht überwinden; eine Verzehnfachung der Gesamtarbeit ist unmöglich
- Der Mythos vom 10x-Ingenieur entsteht aus unterschiedlichen Motiven wie verzerrten Kennzahlen, Interessen von Akteuren in der Branche oder dem Schüren von Unsicherheit in Organisationen
- Die eigene Art zu entwickeln und die Freude daran zu bewahren, führt langfristig zu besseren Ergebnissen und zu einer gesunden Organisationskultur
Skepsis gegenüber dem Mythos vom KI-10x-Ingenieur
Produktivitätsangst und praktische Erfahrungen mit KI-Tools
- Auf LinkedIn, Twitter usw. verbreitet sich die Erzählung, KI erhöhe die Produktivität von Ingenieuren um das 10- bis 100-Fache, wodurch viele Entwickler Angst haben, abgehängt zu werden
- Der Autor hat ebenfalls verschiedene KI-Agenten zur Codegenerierung (Claude Code, Cursor, Roo Code, Zed usw.) praktisch eingesetzt, doch bei einfachen, wiederholenden Aufgaben waren sie zwar bequem, in komplexer realer Arbeit gab es jedoch keine grundlegende Transformation
- In JavaScript (insbesondere React) lässt sich repetitiver Code (Boilerplate) schnell schreiben
- Bei eigenen Codebase-Standards oder ungewöhnlichen Bibliotheken kann die KI jedoch nicht richtig mithalten
- Bei Sprachen wie Terraform ist die Leistung schwächer, weil die KI damit weniger vertraut ist
- Durch Halluzinationen kann sie Bibliotheken erfinden, die es gar nicht gibt, und dadurch sogar Sicherheitslücken verursachen
- Das Kontextverständnis von KI ist noch begrenzt. Je komplexer die tatsächliche Codebase ist, desto häufiger kommt es zu wiederholten Prompts, Fehlern und Zeitverschwendung
- Letztlich nutzt der Autor KI für kleine Skripte oder nicht-kritische Aufgaben, während er komplexe oder wichtige Aufgaben weiterhin selbst erledigt
Das Problem, Produktivität in der Softwareentwicklung zu quantifizieren
- Die Behauptung, die Produktivität lasse sich mit KI um das 10- bis 100-Fache steigern, ist eine von der Realität losgelöste Zahl
- 10x- oder 100x-Produktivität bedeutet nicht einfach mehr Codezeilen, sondern, dass eine Aufgabe, die 3 Monate dauert (gesamte Entwicklung, Code-Review, QA usw.), in 1,5 Wochen abgeschlossen ist
- In der Softwareentwicklung gibt es viele Engpässe wie Planung, Schätzung von Story Points, Bugfixes, Code-Review, Warten auf Deployments, Tests und QA
- Damit das Ziel erreichbar wäre, müssten all diese Schritte im gleichen Verhältnis 10-mal schneller werden
- Tatsächlich nimmt das eigentliche Codieren nur wenig Zeit ein; viel Zeit fließt in Verstehen, Entwurf, Prüfung und Kommunikation
- Realistisch gesehen lassen sich Code-Review, Zusammenarbeit, Kommunikation und QA nicht mit KI verkürzen
- Die eigentlichen Engpässe in der technischen Arbeit liegen bei Menschen, Prozessen und Kommunikation
- LLMs (Large Language Models) sparen Tastaturzeit, aber Zeit für Codequalität, Tests und Reviews wird weiterhin benötigt
- Auch wenn KI die Geschwindigkeit beim Schreiben von Code vorübergehend erhöhen kann, hat sie wegen höherer Fehlerraten, unzureichender Code-Standards und erneuter Prompting-Schleifen keinen entscheidenden Einfluss auf die Gesamtproduktivität
- Eine 10-fache Produktivität ist praktisch ein nahezu unmögliches Ziel
Die Wirklichkeit und die Grenzen des 10x-Ingenieurs
- Hinsichtlich der Existenz eines „10x-Ingenieurs“ lautet die Einschätzung: vorübergehend und begrenzt ist so etwas möglich
- Der wichtigste Grund ist die Fähigkeit, unnötige Arbeit zu verhindern (unnötige Entwicklung bereits in der Planungsphase vermeiden, Developer Experience verbessern, Dokumentation usw.), die sich mit der Zeit aufbaut
- Aber nicht jeder Ingenieur begegnet solchen Situationen ständig
- Außergewöhnliche Ingenieure können unnötige Arbeit verhindern oder durch Systemverbesserungen die Effizienz der gesamten Organisation erhöhen, doch Fälle, in denen jemand dauerhaft das 10-Fache leistet, gibt es praktisch kaum
- KI-Coding-Tools tragen kaum dazu bei, unnötige Arbeit zu vermeiden
- Im Gegenteil können KI-Empfehlungen zu übermäßiger Implementierung führen oder eine falsche Architektur nahelegen
- Schnelles Codieren bedeutet nicht automatisch, ein guter Ingenieur zu sein
Hintergründe und Motive des 10x-KI-Mythos
Die meisten Behauptungen über „10-fache Produktivität“ gehen auf folgende Faktoren zurück
- Gutmeinende Ingenieure, die Messfehler machen
- Mit KI-Tools kann man für kurze Momente explosive Effizienzgewinne erleben (z. B. das automatische Schreiben einer benutzerdefinierten ESLint-Regel)
- Wiederholen sich solche Aufgaben jedoch, schrumpft der Produktivitätsunterschied am Ende stark
- Technische Neuheit und die Anpassung an eine neue Umgebung können anfangs die Illusion übermäßiger Effizienz erzeugen
- Anreize und Stakeholder
- Gründer von KI-Startups, Investoren usw. zitieren für den geschäftlichen Erfolg häufig übertriebene Zahlen
- Auch Ingenieure oder Führungskräfte können überhöhte Produktivität anführen, um Erwartungen in der Organisation zu erfüllen
- Böswillige Absichten
- Manche Führungskräfte verbreiten übertriebene Behauptungen mit der Absicht, Unsicherheit unter Ingenieuren zu erzeugen und Unruhe in der Organisation wie Jobwechsel oder Gehaltsforderungen zu verhindern
- Die Angst, dass durch KI jeder leicht ersetzbar werde, kehrt zyklisch wieder (ähnlich wie frühere Debatten über Coding Bootcamps)
KI-Ergebnisse in realen Open-Source- und Praxisprojekten
- In den meisten realen Beispiele für KI-bedingte Produktivitätssteigerungen besteht eine Distanz zwischen dem Verfasser und dem Ingenieur, dessen Produktivität angeblich gestiegen ist.
- Beispiele für den Einsatz von KI-Tools, die echte Ingenieure selbst belegt haben, zeigen ein realistisches Bild ohne Übertreibung
- Die Ergebnisse des KI-Einsatzes in Open-Source-Projekten liegen meist unter den Erwartungen oder enden als Fehlschläge
- In öffentlichen Demos oder realen Beispielen von Ingenieuren wirkt KI manchmal wie Magie, meistens unterscheidet sie sich jedoch nicht wesentlich von einem herkömmlichen „Textgenerator“
Wichtiger als „Produktivität“: die eigene Art zu entwickeln bewahren
- Mit KI lässt sich Code manchmal schneller schreiben, doch für den Autor steht weiterhin die Freude am Codieren selbst im Vordergrund
- Wenn man KI-Coding nicht bevorzugt oder keinen Spaß daran hat, ist es in Ordnung, auf einen Teil der Produktivität zu verzichten
- Selbst wenn man ein gewisses Maß an Ineffizienz in Kauf nimmt, führt das Arbeiten auf eine Weise, die zu einem selbst passt, langfristig zu gesünderen und besseren Ergebnissen
- Wer mit Freude arbeitet, kann besser Probleme lösen, entwerfen und mit Kollegen zusammenarbeiten
- Freude und Flow sind für langfristige Produktivität und Codequalität wichtiger; wer nur krampfhaft der Produktivität hinterherjagt, erhöht das Burnout-Risiko
- Umgekehrt gilt: Wenn KI-Coding wirklich Spaß macht und hilft, kann man es aktiv nutzen
Ratschläge für eine gesunde Organisationskultur
- Bei der Einführung von KI-Tools ist es schädlich für die Produktivität einer Organisation, bei allen Ingenieuren unrealistische Erwartungen und Unsicherheit auszulösen
- Die Besessenheit, Produktivität zu maximieren, führt zu Qualitätsverlust, einer schlechteren Codebase und langfristigen Schäden
- Es ist wünschenswert, Ingenieuren ausreichend Autonomie und Vertrauen zu geben und den Einsatz von KI je nach passender Arbeitsweise selbst wählen zu lassen
- In Organisationen ist es wichtig, Möglichkeiten zur KI-Nutzung bereitzustellen, dabei aber eine Atmosphäre zu schaffen, die Autonomie garantiert
- Wenn LLMs und KI-Innovationen beim Coding wirklich eine 10-fache Produktivität bringen, werden Entwickler das ganz natürlich selbst herausfinden
Fazit
- Die Revolution des 10x-Ingenieurs durch KI ist eher ein Mythos, und in Wirklichkeit gibt es kein verborgenes Geheimrezept, das man verpasst
- Das Wichtigste ist Vertrauen in die eigenen Fähigkeiten und die eigene Arbeitsweise
- Soziale Netzwerke (insbesondere LinkedIn und Twitter) verstärken übertriebene Mythen; man kann sie getrost ignorieren
10 Kommentare
Gab es wirklich Leute, die 10x wörtlich als das Zehnfache interpretiert haben? Ich dachte natürlich, das sei eine übertriebene Formulierung für Marketing bzw. Selbst-PR, aber dass das so ernst genommen wird, irritiert mich.
Auch wenn es nicht gleich 10x sind, gibt es doch etliche Organisationen, die eine ernsthafte Überzeugung in Bezug auf Nx haben. Sie ersetzen Personalkosten durch AI-Kosten und erwarten noch mehr Leistung darüber hinaus …
Dass das keine völlig unbegründete Illusion ist, liegt auch daran, dass Dinge wie „Der PM will mal eben ein einfaches PoC ausprobieren“ oder Tools für wiederkehrende Aufgaben schnell zusammengebaut sind.
Ob es unter Entwicklern Leute gibt, die das wirklich glauben … je nach eigener Situation ist die Stimmung in der Branche jedenfalls so verbreitet, dass man sich durchaus verunsichert fühlen kann.
Schon für die Kommunikation mit nicht-technischen Rollen und mit Führungskräften halte ich solche ernsthaften Diskussionen für notwendig.
Natürlich bestreite ich nicht, dass es der Produktivität hilft. Ich halte 10x (beim aktuellen Stand der KI) natürlich für unrealistisch, und da der Originalbeitrag ausdrücklich sagt: „10x ist nicht drin“, habe ich gerade das als ziemlich befremdlich empfunden und deshalb diesen Kommentar geschrieben, aber meine Formulierung war wohl nicht besonders gut.
Da die Produktivität von AI, wie Sie sagen, ein übertriebener Ausdruck für Marketing/Selbst-PR ist, denke ich, dass auch der betreffende Text ein wenig übertrieben ist.
Deshalb wirkt der Inhalt, ob es wirklich jemanden gab, der 10x tatsächlich als das Zehnfache interpretiert hat, ein wenig wie Haarspalterei, und ich vermute, dass dies den Unmut ausgelöst hat.
Anscheinend haben Sie geantwortet, ohne den Originaltext zu lesen. Im Original wurde an keiner Stelle todernst getan ...
Dass die Nutzung von DataTube.tv, dem vom Autor entwickelten Tool zum Finden viraler YouTube-Ideen, im Vergleich zu Viewtrap um „ein Vielfaches“ höher sei, ist dann natürlich wohl auch eine übertriebene Formulierung für Marketing/Selbst-PR, oder?
Vielleicht liegt es am Online-Kontext, oder Sie sind einfach grundsätzlich so, aber die meisten Kommentare waren mit einer kritischen Haltung geschrieben.
Ich würde mir wünschen, dass Sie das mit etwas offenerem Blick betrachten.
Ich dachte mir, dass es zum AI-Hype auch das Gegenteil gibt, daher habe ich zum eigentlichen Beitrag keine besonderen Gedanken ...
Dieser Kommentar ist schon heftig; es ist beängstigend, dass man sich sogar frühere Beiträge heraussucht und dann erneut kommentiert, obwohl Sie sich heute gerade erst angemeldet haben
Wenn ich Ihren Kommentar sehe und auch meine eigene Historie durchgehe, scheint mir darunter kein einziger Kommentar zu sein, für den ich mich besonders schämen müsste. Ist es ein Problem, die Dinge aus einer kritischen Perspektive zu betrachten? Lebt man nur dann gut, wenn man wie Sie gar keine Kommentare schreibt ...
Wie bitte? Die Zahl 10 wurde doch sogar schon in Monate umgerechnet ... Wenn Sie sich an dem Ausdruck gestoßen haben, dass ich todernst wirke, kann ich das verstehen. Das Zigendfache von Datatube ist eine quantitative Kennzahl. Na ja, es wird ohnehin nicht betrieben, aber ...
Hacker-News-Kommentare
Ich verstehe nicht, warum ausgerechnet im Software Engineering so verbissen am Mythos der „10x-Produktivität“ festgehalten wird; im Maschinenbau, in der Elektrotechnik, im Bauwesen oder in der Chemietechnik gibt es dieses Konzept nicht.
Ein großartiger Engineer zeichnet sich dadurch aus, Risiken zu reduzieren und Systeme innerhalb vielfältiger Randbedingungen entwerfen zu können.
Entwurf bedeutet, eine Domäne über Modelle zu verstehen und den Gültigkeitsbereich sowie die Grenzen dieser Modelle zu erfassen.
„10x“ gibt es nicht, es gibt nur die Verantwortung für gute Systeme.
Wenn es einen „10x“-Softwareentwickler gibt, dann wäre es jemand, der Vorfälle wie Datenlecks verhindert; ich würde lieber sehen, dass solche Ereignisse um den Faktor 10 zurückgehen.
Ich stimme ebenfalls einem großen Teil dieses Artikels zu.
Ich bin ein großer Fan von Entwicklung mit AI-Tools, aber die Behauptung von 10x Produktivität fand ich nie überzeugend.
Dank LLMs gehen manche Aufgaben wie das Tippen von Code zwar 2- bis 5-mal schneller, aber das ist nur ein Teil der Gesamtarbeit.
Tatsächlich glauben viele Engineers wohl, dass bestimmte Aufgaben um 20–50 % schneller werden können, aber ich stimme zu, dass das weder zu 20 % mehr Gesamtproduktivität noch zu einer 10x-Steigerung führt.
Natürlich können Menschen, die AI wirklich gut einsetzen, mehr als den gefühlten 0,2x-Zuwachs erleben, aber wegen der inhärenten Komplexität der Softwareentwicklung ist 10x in den meisten Fällen unrealistisch.
Wenn ich AI nutze, muss ich sie ständig beaufsichtigen, deshalb fühlt es sich für mich nicht besonders effizient an.
Manchmal beeindrucken mich die Vorschläge von Copilot, weil sie perfekt zu meinem Gedankengang passen, aber insgesamt wirkt es weniger wie ein sehr guter Junior Developer als wie ein „betrunkener Senior Developer“, der nicht richtig zuhört.
Die Hälfte des generierten Codes kompiliert nicht einmal, und selbst wenn doch, funktioniert er nicht richtig.
Meiner Erfahrung nach bringt AI im Bereich des Neuschaffens keine gewaltigen Produktivitätssprünge, ist aber sehr hilfreich bei Exploration, Lernen, dem Lösen von Blockaden und beim Schreiben repetitiven Codes.
Die eigentliche Veränderung passiert jedoch bei Side Projects.
Früher war ich oft zu müde, um Zeit in Nebenprojekte zu investieren, jetzt kann ich Ideen schnell und mit deutlich weniger mentalem Aufwand in die Realität umsetzen, auch wenn der Code nicht perfekt ist.
Auch AI-Engineering-Skills lassen sich frei ausprobieren, ohne Einschränkungen durch Deadlines, Datenschutz oder Tool-Vorgaben.
Ich denke auch bei den Leuten, die als „10x-Engineers“ gelten, wird der Produktivitätsgewinn durch AI gering ausfallen.
Die besten Entwickler, die ich kenne, zeichnen sich vor allem durch zwei Dinge aus: ein enormes Gedächtnis mit Detailwissen über alle möglichen Sprachen und Bibliotheken sowie fast wundersame Kreativität und Problemlösungsfähigkeit.
Beeindruckend ist, dass sie auch ohne Formeln oder Theorie zu einer originellen und sauberen Lösung kommen, die für das Problem am besten passt.
Wenn man mit AI Pair Programming macht und zu einer ähnlichen Lösung gelangen will, braucht die AI endlose Versuche und Iterationen und bremst das geniale menschliche Gegenüber eher aus.
Gleichzeitig ist das Fähigkeitsspektrum so breit, dass für Leute wie mich durch AI durchaus ein 10-facher Produktivitätssprung möglich sein kann.
Ich habe nicht Software studiert und entwickle wegen meines Perfektionismus sehr langsam; mit AI kann ich schnell eine miserable erste Version bauen, was bei der Umsetzung von Ideen sehr hilfreich ist.
Ich bin ebenfalls für AI-Assistenten in der Entwicklung und denke, dass es in manchen Situationen Geschwindigkeitsgewinne von 2x bis 10x geben kann.
Meistens wird „10x“-Produktivität jedoch übertrieben verwendet und soll bedeuten, dass der gesamte Entwicklungsprozess von Anfang bis Ende zehnmal schneller geworden sei.
Realistisch betrachtet werden viele Teile des gesamten Entwicklungsprozesses außerhalb des Codings nicht um den Faktor 10 schneller.
Dafür überspringt man in sehr kleinen Teams oder bei Solo-Arbeit tatsächlich viele umständliche Prozesse, wodurch es praktisch zu großen Geschwindigkeitsgewinnen kommen kann.
In diesem Sinne leben wir plötzlich in einer Zeit, in der kleine Teams und Solo-Entwicklung konkurrenzfähig werden.
Danke an Simon für den Kommentar.
Dieser Kommentar vermittelt wirklich den Eindruck, dass der Artikel gelesen wurde.
Ich erkenne an, dass es in manchen sprach- oder toolspezifischen Rollen tatsächlich echte Produktivitätssteigerungen um den Faktor 2 gibt.
Ich habe jahrzehntelang vom Traum der Automatisierung in der Softwareentwicklung gelebt, und LLMs haben diesen Traum auf völlig andere Weise verwirklicht.
Frühere CASE-Tools, UML, IDEs und Ähnliches versprachen, dass man sich „auf die eigentliche Logik konzentrieren“ könne, doch LLMs erzeugen einfach direkt ausführbaren Code aus natürlicher Sprache.
Viele Entwickler erleben, wie alte Initiationsriten wegbrechen, und haben Angst, in einer neuen Welt zurückzufallen — eine Art Impostor-Syndrom.
Dadurch stellt sich erneut die Frage, was Software Engineering überhaupt ist.
LLMs sind die ultimative Form früherer CASE-Tools, aber dieser Wandel kam zu schnell und ist verwirrend und disruptiv.
Selbst Menschen, die die „heilige Sprache“ der Software Engineers nicht beherrschen, erhalten plötzlich Macht, und viele Engineers stellen sich fundamental die Frage: „Was mache ich hier eigentlich gerade?“
Jetzt verstehe ich endlich, wie sich Künstler gefühlt haben müssen, als sie Stable Diffusion sahen.
Von AI erzeugter Code ist am Ende oft falsch, voller Bugs und überladen mit seltsamen Konventionen oder unnötigem Ballast.
Alles das zu korrigieren kostet am Ende oft genauso viel Zeit, wie es direkt selbst zu bauen.
Selbst wenn man verschiedene Modelle ausprobiert oder Prompts verfeinert, fühlt es sich so an, als bliebe wirklich hochwertiger Code, den ich tatsächlich will, noch außer Reichweite.
So wie bei Stable Diffusion Menschen ohne geschulten Blick oft nicht erkennen, dass etwas seltsam ist, merken Leute ohne Erfahrung mit AI-Code oft nicht, dass damit etwas nicht stimmt.
Neulich habe ich merkwürdigen Code eines Kollegen angesehen: Er ließ sich nicht einmal ordentlich im Debugger verwenden und war voller Probleme, und der Kollege gestand schließlich, dass er „einfach nach Gefühl programmiert“ habe.
Wenn ich mir die Welt heute ansehe, habe ich das Gefühl, dass Kapital die Arbeit immer weiter zerstört.
Niedrige Löhne, schlechte Arbeitsbedingungen, Überwachung, KPI-Druck, unethische Unternehmen und Kurzzeitverträge — die Realität der meisten Arbeitenden verschlechtert sich zunehmend.
Wir waren bislang zu gut geschützt, um das wirklich zu spüren, doch nun sehen auch wir uns einer instabilen Zukunft gegenüber.
„Software Engineering“ wird am Ende wohl zu Arbeit am Vibe werden.
Viele Berufe lassen sich durch Software ersetzen, aber es gab schon immer die Realität, dass Manager keine SWEs einstellen wollten, wenn diese keinen nachweisbaren Wert liefern konnten.
Mit der Einführung von AI werden Manager massenhaft Code produzieren lassen, den sie selbst nicht verstehen, und wenn in drei Jahren alles auseinanderfällt, rufen sie wieder SWEs, um es zu reparieren.
Es ist sogar gut möglich, dass dadurch mehr hochschwierige und hochbezahlte Jobs entstehen, die genau diese „von AI nicht lösbaren Probleme“ beheben.
LLMs schreiben direkt Code, ohne formale Modelle oder Diagramme.
Ich hätte vielmehr gern, dass AI solche formalen Entwürfe oder Diagramme erzeugt.
Solche Tools helfen beim Verständnis von Code und bei der Klärung des Designs.
Ich wünschte, AI würde auch diesen Bereich unterstützen.
Der Engpass in der Softwareentwicklung ist nicht Tippgeschwindigkeit oder Generierung, sondern Verifikation und Verständnis.
Selbst wenn ein LLM perfekt funktionieren und ohne Unsinn oder Halluzinationen arbeiten würde, müsste ein gewissenhafter Entwickler den Code Zeile für Zeile prüfen.
Weil Menschen Code nicht 10-mal schneller verstehen können, kann es in der Praxis sogar länger dauern, automatisch erzeugten Code zurückzuverfolgen und die verborgenen Absichten darin zu entschlüsseln.
Von „10x Produktivität“ kann man nur sprechen, wenn man die Ausgaben ungeprüft weiterreicht oder mit sehr einfachem Code arbeitet, bei dem Fehler kaum relevant sind.
In echter Produktionssoftware, wo Fehler schnell katastrophal werden, bleibt menschliche Kognition der Engpass, und LLMs verlagern die Last nur vom Schreiben auf das Prüfen — damit ziehen sie die Gesamtproduktivität unter Umständen sogar nach unten.
Diese Diskussion wirkt für mich wie ein Spiegel der Produktivität durchschnittlicher Entwickler.
Wenn man die Technik eines Projekts versteht und die Arbeit gut zerlegen kann, lässt sich die Codekomplexität im Voraus abschätzen und AI kann in angemessenen Einheiten Aufgaben erhalten.
AI ist keine Magie; es gibt eine Obergrenze für die Komplexität dessen, was sie schreiben kann.
Wenn man diese Grenze und die Technik des eigenen Projekts gut versteht, kann man Komponenten so zerlegen, dass sie unterhalb dieser Grenze bleiben, und die AI entsprechend anweisen.
Dieser Ansatz funktioniert ziemlich gut.
Das ist fast tautologisch.
Wenn man die Anweisungen für AI so vereinfacht, dass sie gut funktionieren, funktioniert sie natürlich gut.
In der Praxis muss man der AI aber alles übermäßig detailliert vorkauen, und selbst dann muss man die Ergebnisse sorgfältig nachprüfen und kann ihnen nicht trauen.
Das Zerlegen und Erklären für die AI kann am Ende umständlicher sein, als den Code direkt selbst zu schreiben.
Wenn die AI ausnahmsweise sofort die richtige Antwort liefert, ist das effizient, aber realistisch betrachtet verschwendet man oft Zeit und Mühe mit wiederholten Korrekturen oder baut am Ende doch alles neu.
Besonders riskant ist, dass der strukturierte und ordentlich aussehende Code der AI in Wirklichkeit oft falsch ist.
Die wirklich schwierigen und zeitintensiven Teile sind das Design komplexer Abschnitte.
Triviale Teile kann man einfach eingeben, aber die Lösung komplexer Teile kostet die eigentliche Zeit.
Zwischen den Zeilen dieses Kommentars schwingt für mich ein „Ich halte mich für überdurchschnittlich“ mit.
Vielleicht ist eher das Gegenteil der Fall.
Während schwächere Entwickler bedeutungslose Auto-PRs einreichen und das von AI erzeugte Ergebnis bewundern, sind Entwickler mit höherem Anspruch davon womöglich gar nicht beeindruckt.
Weil man schwer unterscheiden kann, wem man vertrauen sollte, ohne wirklich mit jemandem gearbeitet zu haben, bleibe ich neutral.
Sowohl AI als auch Menschen haben Grenzen.
Was man am Ende braucht, ist langweiliges Projektmanagement.
Wenn die Anforderungen sauber sind, das Design stimmt und man genug Informationen in kleine Arbeitspakete zerlegt, kann man der AI sagen: „Implementiere GitHub-Issue #42“, und dabei fernsehen.
Aber wenn man sagt: „Bau mir Facebook“, scheitert das natürlich.
Ein weiteres Gebiet, auf dem AI mir sehr geholfen hat, ist die Fehlersuche.
Ich arbeite hauptsächlich an numerischen Simulationen, und ein Problem, an dem ich mehrere Tage festhing — ein Skalierungsfehler in einer Formel wegen ein paar fehlender Klammern — wurde nach kurzer Beschreibung der Datei und des Symptoms von chatgpt schnell identifiziert.
AI weist mich manchmal sehr klar auf Dinge hin, die ich übersehen habe.
Das macht einen zwar nicht zum 10x-Entwickler, aber bei sinnvoller Nutzung spürt man einen großen positiven Effekt.
Bei mir ist es ähnlich.
Code mit AI zu erzeugen ist eher mittelmäßig, aber beim Debugging ist sie ein echter Produktivitätssprung.
So etwas wie eine extrem kluge „Rubber Duck“.
(Aus Sicht eines Hobbyentwicklers) Dank LLMs ist Entwicklung viel einfacher geworden, wenn spät in der Nacht der Kopf nicht mehr richtig mitmacht.
Ich habe dank AI ebenfalls unzählige Stunden gespart.
Für mich fühlt es sich irgendwo zwischen 10x und unendlich an.
Ich halte mich nicht für einen 10x-Engineer.
Warum ich produktiver bin als Kollegen im Unternehmen, liegt daran, dass ich Systemdesign und geschäftliche Anforderungen nicht einfach als unklare Tickets ungeprüft übernehme.
Dass AI meine Kollegen nicht vereinfacht, liegt daran, dass sie ihre Gewohnheit, Dinge unnötig kompliziert zu machen, gar nicht ändern.
Dieses Problem löst AI nicht.
Mein Gehalt ist im Unternehmen schließlich auch nicht doppelt so hoch wie das meiner Kollegen.
Daran ändert auch die Einführung von AI-Tools nichts.
Dieser Artikel setzt erst einen viel zu hohen Maßstab mit „10x“ und dokumentiert dann die persönliche Anstrengung des Autors, diesen zu übertreffen.
Deshalb, glaube ich, teilt er AI-Befürworter in drei Gruppen ein: Leute, die sich täuschen; Leute, die etwas verkaufen; und skrupellose Manager, die mit Ängsten spielen.
Persönlich empfinde ich Beschwerden über „Halluzinationen“ ein wenig als ein „Signal“.
Ich finde, die Diskussion über Halluzinationen ist unbedingt notwendig.
Die Debatte über LLMs läuft viel zu extrem ab — entweder völlig nutzlos oder Entwicklerersatz.
Zum Beispiel hat Claude 4 Sonnet einmal fälschlich behauptet, Godbolt liege bei etwas zum clang-Compiler falsch.
Trotzdem hat mir die gesamte Session sehr geholfen, man muss nur im Kopf behalten, dass man Ergebnisse kritisch betrachten sollte.
Halluzinationen existieren real, und man sollte Resultaten gegenüber immer wachsam bleiben.
Danke für deinen Kommentar, und deine Texte über AI haben mir geholfen, mein Impostor-Syndrom zu überwinden.
Im Artikel wurden nur Leute kategorisiert, die behaupten, „wiederholt 10x-Erfolge“ erzielt zu haben; es war keine pauschale Aussage über alle AI-Befürworter.
Ich frage mich, ob du tatsächlich eine Methode gefunden hast, Halluzinationen ganz zu vermeiden.
Gerade bei Terraform erfindet ein LLM etwa nicht existierende Properties, und auch in JS kommt es bei seltener genutzten Bibliotheken weiterhin oft zu Irrtümern.
Wenn Beschwerden über „Halluzinationen“ ein Signal sind, dann ist dieser Gedanke selbst auch ein Signal …
(kurzer Widerspruch)
Dieser 10x-Maßstab ist branchenweit ohnehin überzogenes Marketing.
Zum Beispiel: Sam Altmans 10x-Behauptung
Cursor-AI-Produktivitätswerbung
AI-augmented 10x developers
Nehmen wir an, jemand, der keine Web-Apps bauen kann, lernt sechs Wochen lang täglich vier Stunden (120 Stunden) und schafft es gerade so, eine zu erstellen.
Wenn dieselbe Person stattdessen mit AI wie Claude Code dasselbe Web-App-Projekt an zwei Wochenendtagen (12 Stunden) umsetzt, wäre das eine 10-fache Produktivitätssteigerung.
So ähnlich ist es mir tatsächlich passiert.
Dinge, die ich früher wegen fehlender Motivation oder Energie nicht geschafft hätte, kann ich dank AI jetzt an einem Wochenende erledigen.
Aber bei der ersten Methode steckt ein Lernprozess drin, der beim nächsten Änderungswunsch hilfreich sein könnte.
Ehrlich gesagt ist es ein ziemliches Chaos, eine AI wie Claude Code eine Web-App jenseits von React scaffolden zu lassen.
Jemand ohne Erfahrung in App-Entwicklung baut an einem Wochenende nicht einfach so eine ausgereifte App.
Schon beim ersten Login eines Nutzers kann alles sofort auseinanderfallen.
Langfristig ergibt diese Rechnung meiner Meinung nach keinen Sinn.
Mit LLMs baut man anfangs schnell eine App, aber die Fähigkeit zur Wartung sinkt immer weiter, und irgendwann passt das komplexer gewordene System nicht mehr ins „Context Window“ und lässt sich nicht mehr sinnvoll verwalten.
Im Ergebnis kann die Produktivität sogar gegen null gehen.
Du hast dein Gehirn und die Lernerfahrung praktisch ausgelagert; die App existiert zwar, aber Wachstum oder Lernen haben kaum stattgefunden.
Willst du das wirklich direkt deployen?
Realistisch betrachtet ist das nicht vergleichbar.
Schon der Output eines 1x-Entwicklers ist schwer zu messen, und ihn dann noch zu multiplizieren ist erst recht sinnlos.
Ich habe das Gefühl, dass AI die „Side-Quest-Produktivität“ stark erhöht.
Für all die Dinge, die man aus Bequemlichkeit immer aufgeschoben hat — Mockups erstellen, Tests schreiben, Bibliotheken extrahieren, dokumentieren und Ähnliches — ist AI ideal.
Vielleicht verkürzt sie die Zeit für die eigentliche Feature-Entwicklung nicht, aber inklusive solcher Nebenarbeiten wird das Ergebnis ein Stück vollständiger.
Ich hoffe, dass mir diese Zusatzarbeiten künftig Zeit bei der Fehlersuche sparen.
(Persönliche Erfahrung)
Das gilt nur für meinen speziellen Fall, aber bei uns im Unternehmen ist es mit LLM-generiertem Testcode üblich, dass er viel zu eng an den Implementierungscode gekoppelt ist.
Es gibt starken Missbrauch von Patterns wie Test Spies.
Dadurch entstehen viele fragwürdige Tests, die statt des Verhaltens aus Nutzersicht nur interne Implementierungsdetails prüfen.
Die Tests brechen bei Implementierungsänderungen viel zu oft, sodass sie eher Belastung als Produktivitätsgewinn sind.
Das ist nicht nur ein Problem von LLMs; Entwickler, die ohnehin schon schlecht testen, verschlimmern das Problem mit LLMs nur noch.
Bei Entwicklern ohne Erfahrung mit TDD und gut gestaltetem Testcode verstärken LLMs solche Anti-Patterns.
Der Ausdruck „Side-Quest-Produktivität“ gefällt mir.
AI ist nicht „tausend Schnitte des Todes“, sondern eher „ein neues Leben aus tausend Pflastern“.
Ich stimme dem Konzept der „Side Quests“ zu.
Die große Veränderung ist eigentlich, dass ich dank AI Tools oder Features bauen kann, die ich ohne AI gar nicht gebaut hätte.
Es geht nicht nur darum, zwei Wochen zu sparen, sondern darum, dass überhaupt ein neues Ergebnis entsteht.
Die Erwartungen an LLMs liegen höher als die Realität, aber in vielen Situationen sind sie tatsächlich sehr nützlich.
Je nach „Zoom-Level“ waren die Ergebnisse deutlich besser, je stärker ich Aufgaben heruntergebrochen habe — von grobem „vibe coding“ bis hin zu „Schreib mir diese Funktion“.
Auch jenseits der Codegenerierung sind sie effektiv, etwa beim Erlernen neuer Technologien.
Wenn meine Rolle viele Meetings oder viel Managementarbeit umfasst, nimmt der Nutzen von LLMs ab.
Ich denke, künftig könnten LLMs auch für PR-Workflows, das Aufräumen von Commits oder die Neuordnung von Reihenfolgen eingesetzt werden.
Selbst wenn man es nur dafür nutzt, Ingenieuren zu widersprechen, die reflexartig oft sagen „geht nicht“ oder „nicht umsetzbar“, scheint das ehrlich gesagt schon einen X10-Effekt zu haben.
Ich habe oft erlebt, wie Leute Nicht-Entwickler als ahnungslose Laien behandeln und dann pauschal behaupten, etwas ginge nicht.