Softwarentwicklung: Weg mit dem Zehnmal-so-produktiv-mit-KI-Imposter-Syndrom!
Dieser Artikel ist eine Übersetzung. Das Original ist hier(öffnet im neuen Fenster) erschienen.
Vor einigen Monaten überkamen mich Selbstzweifel. Ich war eigentlich immer von meinen Fähigkeiten als Entwickler überzeugt, aber plötzlich konnte ich mich beim Scrollen durch Linkedin und Twitter des Gefühls nicht erwehren, dass ich mit meinen Fähigkeiten hoffnungslos hinterherhinkte. Die Programmierarbeit hatte sich anscheinend – glaubte man diesen Quellen – von der mittelalterlichen Praxis, Code in einen Editor zu tippen, wegentwickelt. Echte Entwickler waren bereits 10- bis 100-mal produktiver als ich.
Ich hoffe, mit diesem Artikel all jenen zu helfen, die ähnliche Ängste haben.
Ich bin von Natur aus skeptisch, daher falle ich normalerweise nicht auf solche Behauptungen rein. Meistens rolle ich nur mit den Augen, zum Beispiel, wenn mir jemand erzählt, ein einfaches pflanzliches Heilmittel könne alle Krankheiten heilen. Aber die schiere Zahl dieser Behauptungen zur Produktivität von Entwicklern hat mich dann doch nervös gemacht. Was, wenn ich falsch lag? Verpasste ich den Anschluss und würde arbeitsunfähig werden, wenn ich nicht sofort tiefer in KI einstieg?
Auf dem Weg zum KI-Dinosaurier?
Die KI, die ich kannte, und die KI, von der diese Leute redeten, unterschieden sich durch eine Menge schicker Schlagworte. Diese Leute nutzten "KI-Agenten", "denkende" Modelle, die im Internet surfen, Tests durchführen und ihre eigenen Fehler korrigieren.
Während ich ab und zu ein Chatfenster öffnete, um etwas Code bat und das Fenster wieder schloss, sobald ich meine Antwort hatte, überließen diese Entwickler Claude die volle Kontrolle und ließen Agenten fünf PRs für sich erstellen, während sie ihren Morgenkaffee tranken. Wurde ich zum KI-Dinosaurier? Zum " Old man yells at cloud(öffnet im neuen Fenster) "?
Teilweise rührte meine Besorgnis daher, dass ich es durchaus für möglich hielt, dass sich die KI verändert hatte, ohne dass ich es bemerkte. Ich nutzte KI nämlich nicht sehr oft, weil ich sie nicht besonders mag. Das Überprüfen von Code macht mir weit weniger Spaß als das Schreiben. Hatte ich jetzt den Anschluss verloren, weil ich stur daran festhielt, Spaß am Programmieren haben zu wollen?
Kopfsprung in die KI-Programmierung
Schließlich beschloss ich, mich einfach kopfüber in die KI-Programmierung zu stürzen. Ich probierte Claude Code, Cursor, Roo Code und Zed aus, weil sie agentenbasierte Programmierung versprachen. Ich bat die KI, alle möglichen Arten von Code für alle möglichen Projekte zu schreiben. Ich probierte verschiedene Modelle aus und verglich sie miteinander. Ich habe sogar ein paar Dinge per Vibe-Coding programmiert, ohne den Code auch nur einmal manuell zu bearbeiten.
Und das war ... tatsächlich OK. Obwohl immer behauptet wird, dass sich die KI derzeit rasant verbessert, fühlte es sich ungefähr genauso an wie vorher. KI kann gut Standardcode schreiben, vor allem in Javascript und ganz besonders in React. Sie kann aber nicht gut mit Standards und Dienstprogrammen der Codebasis Schritt halten. Außerdem hat sie tendenziell Schwierigkeiten mit Sprachen wie Terraform – und sie halluziniert immer noch Bibliotheken, was zu erheblichen Sicherheitslücken führt.
Künstliche Intelligenzen haben nach wie vor Schwierigkeiten, den Kontext einer größeren Codebasis zu erfassen, selbst mit einer guten Eingabeaufforderung und einer CLAUDE.md-Datei. Wird eine Bibliothek verwendet, die nicht zu den Favoriten von Stackoverflow gehört, wird sie selbst nach einer agentenbasierten Suche in der Dokumentation verunstaltet.
Manchmal machen Agenten coole Sachen, zum Beispiel, wenn sie die Tests reparieren, die sie selbst kaputtgemacht haben. Oft verschwenden sie jedoch nur Zeit und Tokens mit einem Hin und Her, das nicht sichtbar zu irgendeinem Wissensgewinn führt. Der beste Anwendungsfall bleibt für mich das Schreiben einzelner Skripte, zum Beispiel, wenn ich keine Lust habe, mich für ein einziges Skript in die Grundlagen einzuarbeiten, etwa um eine benutzerdefinierte ESLint-Regel zu schreiben.
Die düsteren Warnungen, dass ich hoffnungslos abgehängt würde, wenn ich nicht sofort KI verwendete, haben sich als unbegründet erwiesen. Es ist nicht schwer, das Programmieren mit KI zu lernen. So weit, so offensichtlich?
Dinosaurier, hier kommt dein Asteroid!
Die Meinungen in der KI-Programmierer-Community gehen auseinander, ob KI das Programmieren so vereinfacht, dass sogar ein Höhlenmensch es könnte – oder ob es so schwierig ist, dass nur ein Prompt-Ingenieur mit Spezialkenntnissen es kann. Eigentlich muss man nur ein paar Dinge lernen, aber die lernt man schnell.
Man lernt, Aufgaben in kleinere Segmente aufzuteilen, damit die KI im Kontextfenster nicht den Überblick verliert. Manche Tools wie Claude Code können das sogar ein bisschen selbst und manchmal sogar verlässlich. Und man lernt zu erkennen, wann die KI das Ziel so weit verfehlt, dass man selbst übernehmen muss.
Ein kompetenter Entwickler erarbeitet sich das in weniger als einer Woche nicht übermäßiger KI-Nutzung. Wenn KI aber wirklich jederzeit 2-mal, 10-mal oder 100-mal besser werden könnte, wie überall behauptet wird, wäre alles, was man über die Nutzung von KI gelernt hat, sowieso hinfällig.
Jedesmal, wenn ich auf KI stieß, die "ganz okay" funktionierte, machte mich das seltsamerweise nervöser statt ruhiger. Denn es hieß, dass ich das Geheimrezept nicht finden konnte, mit dem alle anderen so produktiv wurden. Ich hatte es einfach nicht drauf: Dinosaurier, triff deinen Asteroiden, sein Name ist KI!
Schließlich retteten mich ein paar Dinge aus dieser Krise. Eines davon war dieser Artikel von Ludicity(öffnet im neuen Fenster) , der den Behauptungen der KI-Befürworter direkt widersprach.
Doch es gab noch anderes, das mich von dem x10-KI-Imposter-Syndrom befreit hat.
Einfach mal nachgerechnet
Beginnen wir mit einer einfachen Rechnung zur 10- bis 100-fachen Produktivität. Eine 10-fache Produktivität bedeutet zehnmal so viele Ergebnisse, nicht zehnmal so viele Codezeilen. Was man früher in einem Quartal geliefert hat, schafft man nun in anderthalb Wochen. Diese Zahlen sollten selbst den gläubigsten KI-Jünger nachdenklich machen.
Alle Produktideen, Story-Point-Verhandlungen, Bugfixes, Code-Reviews, Wartezeiten für Deployments, Tests und Qualitätssicherung, die traditionell drei Monate Arbeit brauchen, sollen nun in sieben Arbeitstagen erledigt werden? Dafür müsste die Produktivität an jedem einzelnen der Flaschenhälse verzehnfacht werden.
Jeder Softwareentwickler, der schonmal an echtem Code in einem echten Unternehmen gearbeitet hat, weiß, dass das unmöglich ist. Das Hin und Her von drei Monaten Code-Review lässt sich nicht in anderthalb Wochen komprimieren.
Code-Review bedeutet:
- den Reviewer taggen
- hoffen, dass er sich schnell darum kümmert (schwierig, wenn er zehnmal so viel Code wie früher prüfen muss)
- in der Zwischenzeit etwas anderes machen
- eine Benachrichtigung erhalten (vielleicht direkt, vielleicht auch zwei Stunden, nachdem der Reviewer für den Abend offline gegangen ist)
- wieder zurück in den Review-Kontext wechseln
- die Kommentare lesen
- darauf reagieren
- den Vorgang wiederholen
Ein Unternehmen mit guten Standards und Kommunikationsprozessen kann diesen Vorgang ziemlich effizient gestalten. Aber zehnmal so effizient, um zehnmal so viel Arbeit zu bewältigen? Das ist schlicht unmöglich.
Ein Großteil der Programmierarbeit ist nicht Code-Schreiben
Die menschlichen Prozesse bei der Softwareentwicklung in Unternehmen haben sich nicht wesentlich verändert. Produktmanager nutzen vielleicht ChatGPT für "Recherchen", aber sie produzieren nicht plötzlich zehnmal so viel gut geprüfte, gut begründete und tolle Storys wie vorher. Sie können nicht zehn Nutzerinterviews auf einmal führen. Dasselbe gilt für Designer und QA-Tester. Sie können nicht einfach zehnmal so viele Projektmanager einstellen. Mit jeder Neueinstellung sinken die Erträge, da Netzwerkeffekte und Bürokratie zunehmen.
Selbst wenn wir davon ausgehen, dass sich die Steigerung ums 10- bis 100-Fache nur auf den eigentlichen Prozess des Codeschreibens bezieht, sollten wir die Rechnung skeptisch betrachten. Wie viel der Programmierzeit verbringen wir wirklich damit, Tasten auf der Tastatur zu drücken?
Wahrscheinlich weniger, als wir denken. Ein Großteil unserer wertvollen Programmierzeit besteht aus Lesen und Nachdenken – oft, während wir auf die Kompilierung, die Aktualisierung einer Seite oder die Ausführung von Tests warten. LLMs machen rustc nicht schneller.
Vibe-Coding kann nach hinten losgehen
Das Ergebnis von LLMs ist oft fehlerhaft, sie halluzinieren oder erreichen nicht die Codebase-Standards. Je größer die Codebasis, desto häufiger treten diese Fehler auf. Dann kann man neu prompten, was das Problem sofort lösen oder eine Riesenzeitverschwendung sein kann. Oder man repariert den Code selbst. Dann ist man aber wieder ein einfacher x1-Programmierer – oder sogar weniger, weil man über dem ganzen Vibe-Coding vergessen hat, wie man programmiert.
Lässt man sich voll auf das Vibe-Coding ein und guckt sich den Code überhaupt nicht mehr an, stößt man ab einer bestimmten Größe der Codebasis an eine Produktivitätsgrenze. Und wenn das passiert, muss man damit rechnen, dass Standards und geeignete Abstraktionen komplett fehlen.
Die Arbeit von einem Jahr in zwei Tagen
Ich glaube, manchmal verlieren die Leute aus den Augen, wie groß eine zehnfache Verbesserung tatsächlich ist – so groß wie der Unterschied zwischen einem Kleinbus und einem rekordverdächtigen Überschalljet. Würden wir eine zehnminütige Autofahrt durch die Stadt in einem Zehntel der Zeit schaffen, wenn wir zehnmal so schnell fahren?
Nein, weil eine einzige rote Ampel unsere gesamte Zeit aufbrauchen würde. Auch F1-Autos verlangsamen in Kurven ihr Tempo auf Minibusgeschwindigkeit. Egal, was man macht: Man tut es die meiste Zeit nicht in Höchstgeschwindigkeit.
Eine hundertfache Steigerung der Produktivität würde bedeuten, die Arbeit von einem Jahr künftig in zwei Tagen zu schaffen. Dass Zahlen dieser Größenordnung völlig absurd sind, muss man wohl kaum näher erklären.
Gibt es die x10-Programmierer tatsächlich?
Auf die Debatte darüber, ob es x10-Programmierer tatsächlich gibt, will ich mich eigentlich gar nicht einlassen, aber ich muss wohl. Meine Antwort ist: manchmal, irgendwie.
Für mich waren in der Vergangenheit Programmierer vor allem dann zehnmal so viel wert wie andere, wenn sie die Fähigkeit hatten, unnötige Arbeit zu verhindern. Wenn sie zum Beispiel einen Projektmanager von einem unrealistischen Ziel abbrachten. Wenn sie einen anderen Programmierer davon abhielten, einen unnötigen Microservice zu entwickeln.
Oder wenn sie in Entwicklererfahrung investierten, die allen überall ein bisschen Zeit sparte. Wenn sie ihre Arbeit dokumentierten, damit zukünftige Programmierer schneller einsteigen konnten. Mit der Zeit kann sich all das so summieren, dass ein Entwickler unternehmensweit zehnmal so viel Zeit einspart, wie die Programmierung gedauert hat.
Schneller ja, aber nicht so schnell
Solche Aufgaben gibt es aber nicht immer. Selbst tolle Programmierer können nur in bestimmten Situationen zehnmal so produktiv sein. Irgendwann muss jeder Programmierer einfach Features entwickeln. Ein toller Entwickler schafft das vielleicht doppelt so schnell wie ein Junior-Entwickler, aber er stößt auf dieselben Flaschenhälse. Bei allen Unzulänglichkeiten von Story Points habe ich noch nie einen Entwickler erlebt, der zehnmal so viele geschafft hat wie ein durchschnittlicher Programmierer.
Insbesondere tragen KI-Programmierassistenten kaum dazu bei, unnötige Arbeit zu vermeiden. Im Gegenteil verleitet KI oft dazu, etwas zu überstürzen oder überzudimensionieren. Ist unter gleichbleibenden Bedingungen ein schneller Programmierer auch ein besserer? Ja, aber nicht zehnmal so gut – und es ist schwierig, alle anderen Faktoren konstant zu halten.
Je mehr man sich darauf konzentriert, Aufgaben so schnell wie möglich zu erledigen, desto leichter übersieht man wichtige Zeitsparmaßnahmen, die den Gesamtaufwand reduzieren.
Also lügen die KI-Befürworter?
Ich glaube, Leute, die solche Behauptungen zu KI aufstellen, gehören in eine der folgenden Gruppen – sortiert nach dem Grad der Böswilligkeit:
- gutmütige Typen, die sich und andere falsch einschätzen
- Menschen mit starkem persönlichem oder finanziellem Invest in den Erfolg von KI (KI-Start-up-Gründer, Investoren usw.)
- Chefs, die ganz bewusst versuchen, ihren Entwicklern ein Gefühl von Unsicherheit zu geben, damit sie nicht kündigen, sich nach anderen Jobs umsehen oder Gehaltserhöhungen fordern.
Der gutmütige Programmierer, der schlecht rechnen kann
Nach meiner Erfahrung kann KI selten und kurzzeitig schubweise die Produktivität auf das Zehn- oder Hundertfache steigern. Wenn ich mir von einer KI in wenigen Minuten eine benutzerdefinierte ESLint-Regel schreiben lasse, für die ich sonst stundenlang in Dokumentationen und Tutorials hätte recherchieren müssen, ist das eine echte Verbesserung in Sachen Zeit- und Arbeitsaufwand. Momente wie diese gibt es mit KI tatsächlich. Viele Nicht-Programmierer haben diese Magie in den ersten Tagen nach dem Programmieren einer App mit Lovable erlebt.
Das Problem ist: Produktivität skaliert nicht. Ich schreibe pro Jahr nicht mehr als eine ESLint-Regel. Der Produktivitätsschub war nur deshalb möglich, weil mir der Code egal war und ich nicht vorhatte, ihn für den nächsten Programmierer lesbar aufzubereiten.
Müsste ich im Job ständig ESLint-Regeln schreiben, würde ich einmalig Zeit investieren zu lernen, wie ESLint funktioniert. Danach würde ich kaum mehr Zeit brauchen, um eine Regel selbst zu schreiben als sie zu vibecoden – vor allem, wenn man die Zeit einberechnet, die ich zusätzlich brauche, um den Code für Menschen so lesbar zu machen, dass ich ihn auch nach sechs Monaten noch verstehe.
Jeder stößt an die Ertragsgrenze
Irgendwann kommt jeder Vibe-Programmierer an einen Punkt, an dem sich der Ertrag deutlich verringert. Seine Website wird gehackt und er muss Zeit investieren, um zu lernen, wie Sicherheit funktioniert. Die App wird zu groß für Kontextfenster, sieht nicht mehr einheitlich aus und funktioniert auch nicht mehr konsistent. Echte Frontend-Entwickler, die wissen, was sie tun, werden eingestellt, um ein einheitliches Design und eine einheitliche Benutzererfahrung zu implementieren.
Die Illusion von Produktivität basiert auch oft auf Vorurteilen und blinden Flecken. Wenn man aus den Tiefen eines Konzerns zu einem Start-up kommt, wird man davon umgehauen, wie viel produktiver jeder Entwickler ist. Das kann man leicht der KI zurechnen.
Jede Technologie landet auf dem Boden der Tatsachen
Manche Leute sind von der neuen Technologie von KI so begeistert, dass sich die Arbeit damit für sie anfühlt, als würden sie mehr schaffen als je zuvor. Mir ging es so mit Python. Als ich es das erste Mal benutzte, fühlte ich mich, als hätte ich Raketentreibstoff getrunken. Aber jede Technologie kehrt irgendwann auf den Boden der Tatsachen zurück.
Der x10-KI-Hype in seiner ehrlichen Form wird sicher oft von Leuten befeuert, die einfach noch in der Flitterwochenphase sind oder noch nicht darüber nachgedacht haben, was eine zehnfache Steigerung mathematisch bedeutet. Mich würde nicht überraschen, wenn KI vielen Programmierern hilft, bestimmte Aufgaben 20 bis 50 Prozent schneller zu erledigen. Aber da es Flaschenhälse gibt, lässt sich das nicht in eine Produktivitätssteigerung von 20 Prozent übersetzen – und schon gar nicht in eine Verzehnfachung.
Wer ein KI-Start-up hat, wird KI als Wundermittel verkaufen
Ich habe wirklich nichts gegen KI-Start-ups. Aus Sicherheitsgründen wäre ich vielleicht etwas besorgt, wenn jemand das API von OpenAI an sein Gesundheitsstartup anbinden wollte, aber das wäre ich auch bei jedem anderen Start-up im Gesundheitsbereich mit dem Motto "move fast and break things" .
Ich sage nicht, dass Start-up-Gründer oder -Investoren böse oder gar unehrlich sind. Ich möchte nur sagen – mit der trockenen Stimme des Wirtschaftslehrers aus der Oberstufe: "Anreize sind wichtig."
Ist man Chef eines KI-Start-ups und alle anderen KI-Start-ups erzählen Investoren, dass sie dank KI die Produktivität um zehn Prozent steigern können, ist der Anreiz ganz einfach: Erzähle das auch – öffentlich und privat. Basiert das eigene Start-up auf KI, hat man großes Interesse daran, KI als Wundermittel für jeden Lebensbereich zu verkaufen.
Lassen wir uns nicht verrückt machen!
Wird man als Programmierer von seinem Chef gefragt: "Hey, du schaffst dank KI jetzt zehnmal so viel, genau wie die anderen Programmierer, stimmt's?" , hat man ein großes Interesse daran, Ja zu sagen. Und wenn jeder andere Programmierer aus denselben Gründen Ja sagt, lügt der Chef nicht(öffnet im neuen Fenster) , sondern gibt nur weiter, was er gehört hat.
Allen, denen das wie mir Angst macht, möchte ich sagen: Das ist nichts Neues. CEOs sind keine unvoreingenommenen Quellen. Führungskräfte behaupten schon immer, dass alles von Agile bis Meyers-Briggs unbegrenzte Produktivität freisetzt. Es wird immer neue Schlagworte auf Linkedin geben, davon dürfen wir uns nicht verrückt machen lassen. Besser hören wir ganz auf, durch das dämliche Linkedin zu scrollen.
Schiere Boshaftigkeit
Wenn Aussagen Menschen beunruhigen, steckt manchmal aber auch Absicht dahinter. Dabei sind auch Vorgesetzte, die ihren Angestellten ein Gefühl von Unsicherheit im Job vermitteln, nichts Neues. Wer erinnert sich nicht an das Narrativ, ein dreimonatiges Bootcamp könne genauso kompetente Programmierer hervorbringen wie ein vierjähriges Studium – also nicht zu aufmüpfig werden, sonst wirst du von einem Geisteswissenschaftler ersetzt, der sich beruflich neu orientiert.
Nach ein paar Jahren wurde den Leuten klar, dass Bootcamp-Absolventen in der Regel völlig unvorbereitet für die tatsächliche Softwareentwicklung waren, da ihnen die entsprechenden Grundlagen nicht vermittelt worden waren.
Bootcamps und KI sind nur beispielhaft für die vielen Versuche, durch fadenscheinige Behauptungen im hochprofessionellen, hochpreisigen Feld der Softwareentwicklung die Preise zu drücken. Es sind rhetorische Mittel, die ein Gefühl der Unsicherheit erzeugen sollen. Vorgesetzte können dich zwar nicht feuern und durch KI ersetzen, aber sie können dir Angst davor machen, so dass du dich nicht traust, mehr Gehalt zu verlangen.
Diese Absicht steht sicherlich hinter einem Teil der Behauptungen zu x10-Programmierern. Bei wie vielen genau, weiß ich nicht. Wahrscheinlich nicht bei vielen. Bei allem Misstrauen der heutigen Zeit glaube ich grundsätzlich an das Gute im Menschen.
Wo ist die Primärquelle?
Was mir aufgefallen ist: Die Leute, die Hype-Artikel über die Steigerung der Produktivität durch KI schreiben, sind oft nicht diejenigen, die sie in der Praxis auch erzielen. Die Autoren sind oft Gründer, Manager oder Investoren, die großspurige Behauptungen über anderer Leute Produktivität aufstellen. Grundsätzlich spricht nichts gegen Sekundärquellen, aber wenn sich keine Primärquelle finden lässt, sollte man die Richtigkeit von Informationen hinterfragen.
Zeigen echte Entwickler, wie sie ihre Produktivität mit KI steigern, sind sie meist deutlich differenzierter und zurückhaltender mit Lobpreisungen. In solchen Präsentationen sieht KI nicht viel anders aus als die Technik, mit der wir gearbeitet haben, bevor wir so verunsichert wurden: ein cooler Textgenerator, der manchmal Wunder vollbringt, aber oft klare Anweisungen braucht.
Zum Totlachen ist der Einsatz von KI in Open-Source-Projekten, wo jeder die Produktionsprozesse mitverfolgen kann. Mit ein paar Youtube-Videos habe ich mehr gelernt (in dem Ludicity-Artikel oben ist ein tolles Beispiel verlinkt. Spoiler: Der Youtuber hat den Heiligen Gral der Produktivität beim Programmieren auch nicht gefunden).
Man muss nicht maximal produktiv sein
Selbst als ich den fixen Gedanken überwunden hatte, dass irgendwo eine geheime Truppe Programmierer lauert, die zehnmal so produktiv, groß, stark und sexy sind wie ich, war ich nicht ganz beruhigt. Das liegt daran, dass ich immer noch nicht besonders gerne mit KI arbeite.
Vibe-Coding ist todlangweilig, wenn die erste Begeisterung sich gelegt hat. LLM-generierten Code zu lesen, nervt. Höflich darum zu bitten, eine echte, nicht halluzinierte Bibliothek zu verwenden, tut weh. Aber was, wenn ich mit Vibe-Coding wirklich 20 Prozent schneller wäre als beim normalen Programmieren? Darf ich dann nicht mehr "normal" programmieren – weil ich auch mehr Output erzielen könnte?
Doch. Man darf ein bisschen Produktivität zugunsten der Jobzufriedenheit opfern. Man muss es in unserem Job sogar. Hasst man seinen Job, brennt man aus. Nur ein Teil der Programmierarbeit ist Programmieren. Der Rest ist Problemlösung, Systeme entwerfen, über Abstraktionen nachdenken und mit anderen Menschen zusammenarbeiten. All das macht man besser, wenn man es gern tut. Man darf stolz auf seine Arbeit und das Handwerk sein. Davon profitiert langfristig auch die Codebasis.
Spaß muss sein
Es kommt nicht drauf an, ob digitale Musik objektiv besser klingt als Schallplatten und es hundertmal schneller geht, bei einem Streamingdienst automatisch das nächste Lied abzuspielen, als eine Schallplatte umzudrehen. Wenn es dich glücklicher macht, eine 70 Jahre alte Schallplatte anzuhören, dann tu das! So hörst du sicher mehr Musik als bei einem "produktiveren" Streamingdienst, den du nicht leiden kannst. Du schreibst mehr und besseren Code auf die Art, die dir liegt.
Das Argument funktioniert übrigens auch umgekehrt. Wenn du gern mit KI programmierst, mach das! Wenn es dich begeistert, mehr Code zu schreiben als je zuvor, ist das super. Egal, wie man hinkommt, dieses Gefühl von Begeisterung sollte man haben.
Wie man bei KI als Führungskraft vorangeht
Es schadet Unternehmen, Programmierern ständig Angst zu machen, dass sie zu wenig leisten. Sie verlieren dadurch die Lust, in dem Unternehmen zu arbeiten. Diese Denkweise führt dazu, dass Entwickler aus schlechten Kennzahlen (wie der Zahl an Codezeilen) das Maximum herausholen. Sie vernachlässigen Code-Reviews, häufen technische Schulden an und das kommt das Unternehmen langfristig teuer zu stehen.
Unrealistische zehnfache Erwartungen führen unweigerlich zu überstürzter und damit minderwertiger Arbeit. Programmierer brauchen Raum zum Atmen. Sie müssen sich die Zeit nehmen können, Dinge richtig zu machen. Grundlage für eine gute Codebasis ist eine Balance zwischen dem Fokus auf Gegenwart und Zukunft. Ich habe derzeit das Glück, bei einem Unternehmen zu arbeiten, das so denkt, aber viele haben das nicht.
Programmierer dürfen keinen Ärger bekommen, weil sie zu wenige Tokens verwenden. Softwareentwickler sind hochqualifizierte Fachleute in einem wettbewerbsintensiven Bereich. Sie sind übereifrig im Ausprobieren und Verwerfen neuer Sprachen und Tools.
Wer diesen Leuten so viel Geld bezahlt, sollte auch drauf vertrauen, dass sie nach einem Pro-Plan verlangen werden, sobald wirklich ein supertoller Produktivitätsschub verfügbar ist. Wer sich Sorgen macht, bei all den Vorteilen der KI-Programmierung abgehängt zu werden, sollte sich für einen LLM-Team-Plan anmelden, eine Schulung veranstalten und abwarten, was dabei herauskommt. Mehr ist nicht nötig.
Fazit
Es gibt kein geheimes Heilmittel, das alle Krankheiten heilt, wenn man nur den richtigen Facebook-Gruppen folgt. KI bringt keine Programmierrevolution, wenn man nur mit dem Vibe-Coding anfängt. Du verpasst nichts. Vertraue auf dich. Du bist gut genug.
PS: Scrolle niemals durch Linkedin. Oder Twitter. Niemals.
Übersetzung: Juliane Gunardono