KI macht gute Entwickler wirksamer

12 Min. Lesezeit

Das Werkzeug wurde klüger. Der Job wurde anspruchsvoller.

Der billige Teil der Software-Entwicklung war lange das Tippen. Selbst das wird gerade Monat für Monat billiger.

Das heißt nicht, dass Software einfach geworden ist. Es heißt nur, dass die Arbeit, die immer schon zählte, nicht mehr hinter Boilerplate, Gerüsten, Syntaxsuche und mechanischem Refactoring versteckt ist.

Das ist keine historische Ausnahme. Software ist seit Jahrzehnten die Leiter der Abstraktion hinaufgestiegen. Grace Hoppers Compiler nahm Entwicklern ab, für jede Aufgabe in Maschinenbefehlen denken zu müssen. Sprachen, Standardbibliotheken, Betriebssysteme, Frameworks und Werkzeuge haben danach immer wieder dasselbe getan. Spring nahm Berge von Enterprise-Verkabelung ab. Vue nahm viel von der spröden Browser-Zeremonie ab. Jede erfolgreiche Schicht verbreitete sich, weil sie Details entfernte, die Entwickler ausbremsten.

KI-Assistenten fürs Programmieren sind der neueste Schritt in genau dieser Linie, kein übernatürlicher Bruch mit ihr. Sie abstrahieren eine weitere Reibungsschicht weg: Syntax-Erinnerung, Boilerplate-Erzeugung, Framework-Klebstoff, Umbauten im ersten Wurf und viel Erkundung im Repository. Das alte Muster bleibt gleich. Wenn eine Detailebene billiger wird, wird Urteilsvermögen auf der nächsthöheren Ebene knapp.

Gerade für nicht-technische Entscheider ist das wichtig, weil viele jede neue Abstraktion sofort als Beweis lesen, dass Programmierung zu Fließbandarbeit wird. Das ist sie nicht. Fließbandarbeit wird berechenbarer, wenn man Urteilsvermögen entfernt. Software wird wirksamer, wenn sich Urteilsvermögen auf weniger, aber wichtigere Entscheidungen konzentriert.

Und dieses Urteilsvermögen sitzt viel häufiger bei Entwicklern, als Organisationen sich eingestehen wollen. Die Menschen, die als „bloße Coder“ behandelt werden, verstehen oft am besten, wie das Geschäft tatsächlich läuft, sobald es auf Datenbanken, Integrationen, Ausnahmen, Kundendaten, Auswertungen und die hässlichen Randfälle trifft, die nie in irgendeiner Präsentation standen. Vielleicht tragen sie nicht den offiziellen Titel eines Fachexperten. Trotzdem haben sie oft das betriebspraktisch wichtigste Verständnis davon, was das System wirklich tut.

Genau darin liegt eine der zentralen Lügen in The Last Batch, Folge 1: Never Missed a Run Publishes on June 18, 2026. Come back then. , unserer Telenovela aus der Software-Welt, und später taucht sie immer wieder auf. Die offiziellen SMEs kennen Fragmente, Geschichte, Rituale und Schutzsprache. Die Entwickler wissen, wo die Regeln tatsächlich laufen, woher die Zahlen wirklich kommen und wo die Realität zuerst brechen wird. Die Führung stellt sich trotzdem auf die Seite der Menschen mit SME-Etikett und behandelt Entwickler als Hände. Dieses Muster ist nicht im entscheidenden Sinne fiktional. Es passiert ständig. Entwickler werden als Umsetzer an den Rand gedrängt, die das Geschäft angeblich nicht verstehen können, obwohl sie oft am klarsten sehen, wie dieses Geschäft tatsächlich funktioniert.

Darum ist es ein teurer Führungsfehler, Entwickler auf Coder zu reduzieren. Wenn KI mehr von der mechanischen Codierung entfernt, bleibt noch offensichtlicher Urteilsarbeit übrig: Absichten auslegen, Widersprüche auflösen, Folgen nachverfolgen und der Organisation unangenehme Wahrheiten über ihre eigenen Abläufe sagen.

Technische Menschen wissen das meist längst im Rückenmark. Sie haben das Muster oft genug erlebt, um es sofort wiederzuerkennen: Die Maschine wird besser, die Abstraktion steigt, und der dumme Teil des Jobs schrumpft. Der schwierige Teil nicht. Er wird nur schwerer als etwas auszugeben, das angeblich schon immer simpel war.

Übrig bleibt der teure Teil:

• entscheiden, was das System tun soll
• entscheiden, welche Kompromisse tragbar sind
• erkennen, wo die KI selbstbewusst falsch liegt
• wissen, was getestet, beobachtet und begrenzt werden muss
• verstehen, wie sich das neue Feature in der hässlichen Realität verhält, die bereits existiert

Darum sind die besten KI-Nutzer in der Software-Entwicklung meist nicht die Menschen mit den cleversten Prompts. Es sind die mit dem reichsten inneren Modell davon, wie Systeme scheitern.

Die Arbeit ist wirklich in höhere Schichten gerutscht

Wer GitHub Copilot oder Claude Code ein paar Wochen ernsthaft nutzt, sieht das Muster schnell.

Das Modell kann den Handler schreiben. Es kann das Testgerüst erzeugen. Es kann die Klasse umbauen. Es kann die Oberfläche aufsetzen. Es kann das alte Modul erklären. Es kann sogar einen Fix für die Auslieferung vorschlagen, der plausibel aussieht.

Was es nicht zuverlässig kann: entscheiden, ob diese Route überhaupt in diesen Service gehört, ob der Test das Richtige beweist, ob das Refactoring die Domäne klarer macht, ob die UI einen kaputten Prozess kaschiert oder ob der Deployment-Fix aus einem lokalen Patch gerade eine globale Haftung macht.

Darum ist Building Products in the Age of AI wichtig. Der Engpass hat sich verschoben. Die Tipparbeit ist geschrumpft. Das Urteilsvermögen nicht.

Deshalb wirken starke produktorientierte Entwickler plötzlich fast übermenschlich. Nicht weil das Werkzeug sie magisch gemacht hätte. Sondern weil das Werkzeug die Reibung um Arbeit entfernt, die sie ohnehin schon richtig steuern konnten.

Ein fähiger Solo-Produktentwickler kann heute Arbeitsanteile abdecken, die früher auf Frontend, Backend, QA, Dokumentation und Teile der Produktklärung verteilt waren. Nicht perfekt. Nicht in jedem Kontext. Aber oft genug, um die Wirtschaftlichkeit spürbar zu verändern.

Die Verdichtung ist real.

Die alte Teamform war auch eine Antwort auf Koordinationskosten und Tipparbeit. KI greift beides an.

Warum Veteranen überproportional profitieren

Der Vorsprung erfahrener Entwickler ist nichts Mystisches. Er ist konkret.

Sie wissen, wo Software lügt.

Sie wissen, dass eine fröhliche Demo trotzdem ein transaktionales Chaos verbergen kann. Sie wissen, dass ein grüner Unit-Test den Produktionsfehler trotzdem verfehlen kann. Sie wissen, dass die Integration, die „eigentlich simpel“ sein sollte, meist der Teil mit zwanzig Jahren Sediment ist. Sie wissen, bei welchen Randfällen Paranoia angemessen ist und welche nur Dekoration sind.

Wenn die KI drei Optionen vorschlägt, verwerfen Veteranen oft zwei davon in Sekunden. Nicht weil sie in irgendeinem abstrakten IQ-Sinn schlauer wären. Sondern weil sie diese zwei Varianten schon scheitern sahen, oft mehr als einmal, unter anderen Namen und mit besseren Folien.

Darin liegt der Hebel.

Das Modell liefert sofortige Entwürfe, Alternativen, Gerüste und Kontext. Die Erfahrung sagt, wo man drücken muss, wo man misstrauen sollte, wo Vereinfachung nötig ist und wo die Maschine gestoppt werden muss, bevor aus Dynamik Schaden wird.

Hier liegt noch ein weiterer Hebel, den weniger erfahrene Menschen oft übersehen. Mit genug Jahren im Beruf muss man nicht immer jede Zeile auf die alte Art lesen, um zu einer belastbaren Erkenntnis zu kommen. Man kann das Repository durch den Agenten befragen. Warum gibt es diese Grenze? Was würde brechen, wenn diese Regel wandert? Wo wird Zustand doppelt gehalten? Welches Modul besitzt die Entscheidung wirklich? Und dann hört man auf die Antworten so, wie ein erfahrener Mechaniker auf einen Motor hört. Der Wert liegt nicht in blindem Vertrauen. Der Wert liegt darin, dass tiefe Erfahrung in der Unterhaltung selbst Wahrheit, Ausweichbewegung und strukturellen Geruch erkennbar macht.

Genau hier kippt das Denken weniger erfahrener Leute oft in Ritual. Sie hören, dass generierter Code falsch sein kann, was stimmt, und springen dann zur Standardreaktion: alles manuell lesen und durch Pull Requests schicken. In der Praxis wird daraus oft nur eine weitere gut gemeinte Form von Theater. Das Team starrt auf KI-erzeugte Diffs, die niemand vollständig im Kopf hält, schreibt ein paar Kommentare, klickt auf Freigabe und nennt das Risikomanagement. Wie Pull Requests waren nie für Ihr Team gedacht zeigt, werden sie nicht plötzlich sinnvoller, nur weil der Code aus einem Modell kam.

Das stärkere Muster sieht anders aus. Nutze den Agenten als Hochgeschwindigkeitsschnittstelle zum Repository, nutze Tests und Ausführung, um Realität festzunageln, und nutze erfahrenes Urteilsvermögen, um zu entscheiden, welche Antworten tragfähig genug sind. Das ist keine ausgelassene Prüfung. Es verschiebt Prüfung auf die Ebene, auf der Erfahrung tatsächlich kumuliert.

Darum trifft The Gray Beard and the Machine bei älteren Entwicklern einen Nerv. Das Werkzeug entwertet die Jahrzehnte nicht. Es macht sie härter nutzbar.

Und ja, das verändert, was eine Person leisten kann.

Ein ernstzunehmender Entwickler mit Produkturteil, Disziplin beim Ausliefern, brauchbarem Gestaltungsgeschmack und KI-Unterstützung kann heute Dinge bauen, für die vor Kurzem noch ein ganzes Feature-Team gebraucht wurde. Die ehrliche Schlussfolgerung ist nicht, dass Teams immer unnötig waren. Die ehrliche Schlussfolgerung ist, dass ein guter Teil der Teamstruktur auf Reibung, Übersetzung und Werkzeugkosten reagierte. Wenn genug davon wegfällt, wird die Person brutal wirksam, die das ganze Produkt im Kopf halten kann.

Warum Unerfahrene Frankenstein-Systeme bauen

Weniger erfahrene Nutzer bekommen ebenfalls Geschwindigkeit. Das ist real. Das Problem ist, was sie damit tun.

Der Assistent klingt kompetent. Er erklärt selbstbewusst. Er entschuldigt sich elegant. Er stimmt Kritik sogar in einem seltsam schmeichelhaften Ton zu. „Du hast recht“ ist vielleicht der gefährlichste Satz in der ganzen Oberfläche.

Also machen unerfahrene Leute einfach weiter.

Ein Repository-Muster aus einem Tutorial. Eine Service-Schicht aus dem nächsten. Ereignisgetriebene Sprache aus einem dritten. Eine State-Management-Lösung in React aus irgendeinem Forum. Tests, die vor allem Implementierungsdetails festzurren. Eine Cache-Schicht, die niemand brauchte. Eine Queue, weil das Modell beschlossen hat, dass Skalierung später wichtig werden könnte. Drei Benennungsschemata. Vier Abstraktionsstile. Ein stolzes kleines Monster, zusammengenäht aus populären Beispielen.

Alles wirkt modern. Nichts gehört zusammen.

Das ist die eigentliche Gefahr von KI für weniger erfahrene Entwickler. Nicht Faulheit. Nicht moralische Schwäche. Nicht mangelnder Einsatz.

Es fehlt ein inneres Systemmodell.

Ohne Systemwissen erkennt der Nutzer nicht, wann die KI mitten im Satz den architektonischen Dialekt wechselt. Er erkennt nicht, welche Komplexität wesentlich ist und welche nur vorgeschlagen wurde, weil das Modell sie irgendwo daneben gesehen hat. Er erkennt nicht, wann eine Testsuite dekorativ statt schützend ist. Er erkennt nicht, wann die Codebasis klingt, als würden fünf verschiedene Blogposts in einem Schrank streiten.

Darum ist Vibe Coding Isn’t Software Development kein Graubart-Gejammer. Es ist eine Beschreibung dessen, was passiert, wenn Erzeugung schneller läuft als Urteilsvermögen.

Wenn das Repository schon schief steht

Genau das ist wichtig: Die Assistenten erzeugen nicht nur Schnipsel. Sie erzeugen oft ganze Arbeitspakete. Endpunkte. Tests. Refactorings. Konfiguration. Dokumentation. Migrationsentwürfe. Gerade deshalb wird ein schlechtes Repository so gefährlich.

Wenn die bestehende Codebasis schon Muster mischt, Regeln dupliziert, ohne Tests lebt und sich durch einen Wust widersprüchlicher Markdown-Dateien erklärt, kommt der Assistent nicht wie ein strenger Senior-Entwickler herein und räumt auf. Er übernimmt meist zuerst die schlechten Gewohnheiten des Raums.

Ich habe das direkt in einer vibe-gecodeten Python-Codebasis gesehen: keine Tests, dafür ein Stapel von Claude-Spec-Dateien, die in verschiedene Richtungen zogen. Der Assistent versuchte ständig, genau das neu zu kombinieren, was schon da war: halbe Muster, widersprüchliche Anweisungen, lose Abstraktionen und eine Menge selbstbewusst formulierter Klebstoff-Code. Er mischte Zuständigkeiten, weil das Repository selbst diese Vermischung längst normalisiert hatte.

Das ist die Falle, die nicht-technische Führung oft übersieht. Sie glaubt, KI gleiche eine schwache Codebasis aus, weil das Modell breiter wirkt als die Menschen, die sie gebaut haben. In der Praxis verstärkt das Modell oft die lokale Kultur des Repositorys. Wenn die Codebasis Widerspruch lehrt, lernt der Assistent Widerspruch. Wenn die Markdown-Anleitung sich selbst widerspricht, erfüllt der Assistent eine Anweisung, indem er zwei andere verletzt. Wenn es keine Tests gibt, hat er keinen ernsthaften Grund anzuhalten.

Der Ausweg ist nicht noch ein Stapel hübscherer Spezifikationsdateien. Der Ausweg ist überprüfbare Realität.

In dieser Python-Codebasis begann der wirkliche Fortschritt erst, als mit Hilfe der KI Tests aufgebaut, Verhalten festgezurrt und Widersprüche aus den Markdown-Anweisungen entfernt wurden. Erst als das Repository ausführbare Grenzen statt konkurrierender Wünsche bekam, wurde der Assistent deutlich nützlicher. Urteilsvermögen brauchte es immer noch. Aber der Spielraum für die falsche Art von Improvisation wurde kleiner.

Genau darauf weisen auch externe Befunde hin.

• GitClears Report Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality beschreibt steigende Code-Churn, mehr hinzugefügten und kopierten Code sowie weniger Wiederverwendung.
• Anthropic warnt in Building effective agents vor sich aufschaukelnden Fehlern in agentischen Systemen und betont ausdrücklich, dass Programmieragenten dort am besten funktionieren, wo Lösungen durch automatisierte Tests überprüfbar sind.
• OpenAI erklärt in Why language models hallucinate, dass Modelle plausible, aber falsche Ausgaben produzieren und strukturell zum Raten gedrängt werden, wenn gute Grenzen und Auswertungen fehlen.

Zusammen ergibt das eine ziemlich harte praktische Einsicht. Ein KI-Assistent in einem chaotischen Repository ist keine Reinigungskraft. Er ist ein Brandbeschleuniger mit guten Manieren. Wenn er die Codebasis verbessern statt die Verwirrung vertiefen soll, brauchst du Tests, weniger widersprüchliche Anweisungen und jemanden mit genug Systemurteil, um lokalen Gleichklang von tatsächlicher Korrektheit zu unterscheiden.

Prozessmenschen optimieren jetzt die falsche Ebene

Genau das sollte jeden Methodenverkäufer, jeden Zeremonienfreund und jeden Manager nervös machen, der Software-Auslieferung noch immer vor allem als Weiterreichen von Tickets zwischen spezialisierten Menschen versteht.

Zwanzig Jahre lang versuchte ein großer Teil der Prozesskultur, Programmierung über standardisierte Übergaben zu „verbessern“:

• wer Anforderungen schreibt
• wer sie in Tickets übersetzt
• wer sie aufnimmt
• wer sie reviewt
• wer sie freigibt
• wer nach oben berichtet

Diese ganze Apparatur war schon zweifelhaft, als Tipparbeit und Gerüstbau noch viel Zeit fraßen.

Mit KI wird es schlimmer.

Jetzt kann die Arbeit in einer engen Schleife passieren: Idee, Entwurf, Kritik, Test, Umbau, Auslieferung. Der teure Teil ist nicht das Verschieben von Arbeitspaketen zwischen Rollen. Der teure Teil ist, ob die Person in dieser Schleife genug Urteilsvermögen hat, um sie zu steuern.

Wenn Organisationen auf KI mit mehr Vorlagen, mehr Kontrollpunkten, mehr Rollentrennung und mehr „Führung“-Theater reagieren, optimieren sie also die falsche Schicht. Sie verwalten die mechanische Hülle um Entwicklung, während der eigentliche Hebel längst nach oben gerutscht ist: in Synthese, Architektur, Produktsinn und technisches Urteilsvermögen.

Darum wird viel Gerede über Prozessverbesserung schlecht altern. Es war ohnehin zu stark auf sichtbare Aktivität fixiert. Jetzt verteidigt es einen Ablauf, der um einen Engpass herum gebaut wurde, der nicht mehr dominiert.

Wenn du vorhersehbare Auslieferung willst, brauchst du weiterhin Tests, Feedback, Beobachtbarkeit und diszipliniertes Deployment. Du brauchst weiterhin The Engine of Predictable Software Delivery. Aber du brauchst weniger Theater um die Menschen herum, die die Arbeit machen, und mehr Respekt für das Urteilsvermögen, das sie in die Schleife einbringen.

Niemand wurde ersetzt. Der Job hat sich verändert.

Der Job bleibt Produktentwicklung. Er bleibt Software-Entwicklung. Er bleibt unordentliche, politische, technische und mehrdeutige Arbeit.

Aber der Schwerpunkt hat sich verschoben.

Weniger Zeit fließt in Tippen, Übersetzen und Gerüste. Mehr Zeit in Rahmung, Tests, Begrenzung, Integration und Entscheidung. Die Abstraktionsebene ist gestiegen. Der Bedarf an Urteilsvermögen ist mitgestiegen.

Das ist keine Geschichte darüber, dass Entwickler verschwinden. Es ist eine Geschichte darüber, dass mittelmäßige organisatorische Abstraktionen zuerst verschwinden.

Profitieren werden die Menschen, die Produktabsicht, Systemverhalten, Nutzerrealität und technische Konsequenzen in einem Gespräch zusammenhalten können. Manchmal bleibt das ein Team. Manchmal ist es eine erschreckend fähige Einzelperson mit KI-Werkzeugkette und genug Narbengewebe, um glatter Ausgabe nicht zu trauen.

Wenn du die Telenovela-Version dieses Musters sehen willst, zeigt unsere Serie aus der Software-Welt The Last Batch, Folge 6: Outside the Door Publishes on July 23, 2026. Come back then. , was passiert, wenn Führung entscheidet, dass „hired hands“ tippen dürfen, aber nicht urteilen. Das Badge spricht die hässliche Wahrheit aus: Kompetenz ist willkommen, bis sie den falschen Komfort bedroht.

Das ist die eigentliche Verschiebung.

Die Maschine hat Urteilsvermögen nicht überflüssig gemacht.

Sie hat Urteilsvermögen nur unmöglich gemacht, hinter Prozess zu verstecken.