Zwei Jahre KI im Entwickleralltag: Was Copilot wirklich ersetzt hat und was nur Bequemlichkeit ist

Veröffentlicht am 9. Oktober • Zuerst erschienen auf tamiz.pro

Vor zwei Jahren konnte ich einen Copilot-Vorschlag nicht an einem Code Review vorbeibringen, ohne ihn umzuschreiben. Heute wird die Hälfte meiner Pull Requests mit KI-generiertem Code ausgeliefert, den ich kaum bearbeitet habe. Die Werkzeuge sind tatsächlich besser geworden. Die Frage, die niemand ehrlich stellt, ist, ob ich bei der eigentlichen Ingenieursarbeit schlechter geworden bin und ob meine Kolleginnen und Kollegen, insbesondere die Junior-Entwickler, stillschweigend ausgehöhlt werden von einem Assistenten, der jede Frage beantwortet, bevor sie sich durch sie durchkämpfen.

Das ist keine KI-kritische Tirade. Es ist eine technische Bestandsaufnahme einer Entwicklerin oder eines Entwicklers dessen, was sich verändert hat, was wirklich ersetzt wurde und was stillschweigend erodiert ist. Die Unterscheidung zwischen diesen beiden Kategorien ist das eigentliche Argument dieser Analyse.

Es gibt echte, messbare Kategorien von Arbeit, die KI-Coding-Assistenten tatsächlich automatisiert haben. Das sind keine Verluste. Das sind Gewinne.

Boilerplate und Grundgerüste. Eine React-Komponente nach Spezifikation generieren, einen CRUD-Endpoint schreiben, ein Dockerfile erstellen, ein Test-Fixture einrichten, das war intellektuell nie interessant. Diese Aufgaben haben Zeit und Aufmerksamkeit verbraucht, die Architekturentscheidungen oder Debugging hätten zukommen können. KI erledigt diese Aufgaben inzwischen gut. Eine Junior-Entwicklerin, die zwanzig Minuten mit einer Boilerplate-Vorlage verbringt, kann diese Zeit stattdessen nutzen, um den Datenfluss des Systems zu verstehen.

Dokumentation und API-Nachschlagen. Vor der KI habe ich mehr Zeit damit verbracht, TypeScript-Typdefinitionen zu lesen, als Code zu schreiben. Ich öffnete die Dokumentation einer Bibliothek, suchte nach der passenden Überladung und stellte fest, dass die Funktionssignatur, an die ich mich erinnerte, aus einer Version vor zwei Releases stammte. KI-Assistenten beantworten diese Fragen heute im Kontext, mit einer Genauigkeit, die sich dramatisch verbessert hat. Das ist reine Zeitersparnis ohne kognitive Kosten.

Regex, Datums-Parsing und String-Manipulation. Das war die Steuer, die Entwickler für die Arbeit mit Text zahlten. KI schreibt Regex-Muster, Datumsformatierungs-Utilities und String-Transformationen, die beim ersten Versuch funktionieren. Das ist eine echte Ablösung, nicht weil die Aufgabe schwer war, sondern weil der kognitive Aufwand, sie korrekt zu erledigen, in keinem Verhältnis zu ihrem Wert stand.

Testgenerierung für unkomplizierte Fälle. Unit-Tests für reine Funktionen, Snapshot-Tests und Grundgerüste für Integrationstests werden heute zuverlässig generiert. Die generierten Tests sind nicht immer aussagekräftig, aber die strukturelle Arbeit des Schreibens ist erledigt.

Wenn Ihre tägliche Arbeit von diesen Kategorien dominiert wird, hat KI Sie produktiver gemacht. Das ist eindeutig. Ich argumentiere nicht dagegen.

Der besorgniserregende Trend ist nicht die Ersetzung. Es ist die Ersetzung von Verständnis durch Vorschläge. Lassen Sie mich konkret beschreiben, was ich in meiner eigenen Arbeit und in der Arbeit der Junior-Entwickler in meinen Teams beobachtet habe.

Debugging ist zu Suchen-und-Einfügen geworden. Wenn ein Fehler auftritt, ist der Reflex nicht mehr: „Lass mich den Call Stack durchgehen und verstehen, warum das passiert ist.“ Sondern: „Lass mich die KI fragen, was dieser Fehler bedeutet und was ich ändern soll.“ Das funktioniert, bis die KI Ihnen eine plausible, aber falsche Erklärung gibt, und Sie sie anwenden, ohne sie zu überprüfen. Ich habe das in meinem Team wiederholt beobachtet. Ein Entwickler fügt einen von der KI vorgeschlagenen Fix für eine Race Condition ein, er scheint in Tests zu funktionieren, und dann tritt er in der Produktion unter Last auf, weil die KI vorgeschlagen hat, ein setTimeout hinzuzufügen, statt den asynchronen Ablauf wirklich zu verstehen. Der Fix war syntaktisch korrekt und semantisch falsch.

Typsicherheit wird umgangen. TypeScript existiert, um ungültige Zustände unrepräsentierbar zu machen. Wenn Sie Code von Grund auf schreiben, setzen Sie sich mit dem Typsystem auseinander. Sie fragen: „Was akzeptiert diese Funktion tatsächlich?“ Wenn Sie KI-generierten Code einfügen, überspringen Sie diese Auseinandersetzung. Der Code kompiliert. Die Typen sind falsch. Der Fehler erscheint drei Ebenen weiter unten in der Produktion. Ich habe Pull Requests geprüft, in denen die KI einen any-Cast generiert hat, um einen Typfehler zum Verschwinden zu bringen, und der Entwickler hat ihn gemerged, ohne zu hinterfragen, warum der Cast nötig war.

Architekturentscheidungen werden an Autocomplete ausgelagert. Das ist der Punkt, der mich am meisten beunruhigt. Wenn eine Junior-Entwicklerin fragt: „Wie sollte ich dieses Modul strukturieren?“ und die KI ein Muster zurückgibt, übernimmt sie es, ohne zu prüfen, ob es zum System passt. Die KI hat keinen Kontext zu den Konventionen Ihres Teams, Ihren Deployment-Beschränkungen oder Ihren Performance-Anforderungen. Sie gibt Ihnen eine Lehrbuchantwort, und Lehrbuchantworten scheitern in der Produktion, weil die Produktion kein Lehrbuch ist. Ich habe das bei Entscheidungen zum State Management, bei Datenbankschema-Designs und bei API-Vertragsentscheidungen gesehen. Der Vorschlag der KI war für sich genommen vernünftig. Er war falsch für das System.

Der Kampf wird übersprungen, und der Kampf war das Lernen. Das ist der philosophische Kern meines Arguments, aber ich werde es in der Technik verankern. Wenn Sie eine Funktion von Grund auf schreiben und sie scheitert, lernen Sie, warum sie gescheitert ist. Sie lernen die Semantik der Sprache, das Verhalten der Bibliothek, die Grenzen des Systems. Wenn Sie Code aus einem Prompt generieren und er funktioniert, lernen Sie nichts. Sie haben ein funktionierendes Feature. Sie haben kein Verständnis. Sechs Monate später, wenn dieses Feature unter anderen Rahmenbedingungen angepasst werden muss, können Sie es nicht anpassen, weil Sie nie das mentale Modell aufgebaut haben. Sie können es nur neu generieren und hoffen, dass der neue Prompt etwas Kompatibles hervorbringt.

Das ist keine Hypothese. Ich habe ein Teammitglied, das seit achtzehn Monaten KI-gestützt entwickelt. Dessen Codeausgabe ist umfangreich und generell funktional. Aber wenn ich es bitte, die Begründung hinter einer nicht offensichtlichen Designentscheidung in seinem eigenen Code zu erklären, kann es das nicht. Es bittet die KI, es ihm zu erklären. Die KI gibt eine plausible Erklärung. Es nickt. Es versteht nicht.

Ich argumentiere nicht, dass KI nicht genutzt werden sollte. Ich nutze sie täglich. Ich argumentiere, dass es ein Spektrum gibt und wir unbemerkt zum falschen Ende desselben abrutschen.

Das produktive Muster: Sie verstehen die Aufgabe. Sie schreiben den Code. Sie bitten die KI, ihn zu prüfen, Verbesserungen vorzuschlagen oder Randfälle zu finden. Die KI ist ein zweites Augenpaar. Sie bleiben der primäre Autor. Dieses Muster erhält die Weiterentwicklung der Fähigkeiten und beschleunigt gleichzeitig die Ausgabe.

Das bequeme Muster: Sie beschreiben, was Sie wollen. Die KI generiert Code. Sie fügen ihn ein. Sie testen ihn. Wenn er funktioniert, liefern Sie aus. Die KI ist der primäre Autor. Sie sind das Zustellvehikel. Dieses Muster erzeugt Ausgabe und baut gleichzeitig Fähigkeiten ab.

Der Unterschied ist nicht im ausgelieferten Code sichtbar. Er wird sechs Monate später sichtbar, wenn das System geändert werden muss oder wenn ein Fehler auftritt, der Verständnis statt Mustererkennung erfordert. Im ersten Fall haben Sie das mentale Modell. Im zweiten Fall nicht.

Ich habe auf der Grundlage dieser Bestandsaufnahme gezielte Anpassungen vorgenommen. Das sind keine Regeln. Es sind Praktiken.

Ich schreibe zuerst und frage dann. Bei allem Nicht-Trivialen, bei jeder Funktion mit Geschäftslogik, bei jeder Architekturentscheidung, bei jedem Code, der geteilten Zustand berührt, schreibe ich die erste Version selbst. Dann bitte ich die KI, ihn zu prüfen. Ich frage, was ich übersehen haben könnte, welche Randfälle existieren, ob mein Ansatz eine bessere Alternative hat. So bleibe ich in der Autorenrolle und nutze die KI als Mitarbeiter.

Ich frage nach dem „Warum“, bevor ich nach dem „Was“ frage. Wenn die KI einen Fix vorschlägt, ist meine erste Frage nicht: „Soll ich das anwenden?“ Sondern: „Warum tritt dieser Fehler auf, und warum behebt dieser Fix die Ursache?“ Wenn die Erklärung der KI nicht mit meinem eigenen Verständnis des Systems übereinstimmt, gehe ich weiter nach. Wenn die Erklärung etwas offenbart, das ich nicht wusste, lerne ich. Wenn sie zeigt, dass die KI das System nicht versteht, ignoriere ich den Vorschlag.

Ich prüfe generierten Code auf Typsicherheit und Annahmen. Jeder KI-generierte Codeblock durchläuft eine Prüfung, die speziell nach any-Casts, impliziter Typumwandlung, unvalidierten Eingaben und versteckten Annahmen über die Umgebung sucht. Die KI kennt Ihr Deployment-Ziel, Ihre Datenbeschränkungen oder die Konventionen Ihres Teams nicht. Sie optimiert auf Code, der korrekt aussieht, nicht auf Code, der im Kontext korrekt ist.

Ich schütze die Lernkurve von Junior-Entwicklern. In meinem Team gilt für die ersten drei Monate einer neuen Mitarbeiterin oder eines neuen Mitarbeiters die Praxis: „Schreibe es zuerst selbst.“ Danach wird KI-gestützte Entwicklung gefördert, aber das Code Review verlangt ausdrücklich, dass die Entwicklerin oder der Entwickler ihr bzw. sein Verständnis des eingefügten Codes erklärt. Wenn sie oder er es nicht erklären kann, wird der Code nicht ausgeliefert. Das ist für uns nicht verhandelbar.

KI hat Entwickler nicht dümmer gemacht. KI hat es Entwicklern ermöglicht, dümmer zu sein und trotzdem funktionale Ausgabe zu erzeugen. Die Werkzeuge sind wirklich besser geworden. Die Produktivitätsgewinne sind real. Die Ersetzung von Boilerplate-Arbeit ist ein klarer Netto-Vorteil.

Aber die Erosion des grundlegenden Verständnisses ist ebenso real, und sie ist in Metriken nicht sichtbar. Sie wird sichtbar, wenn das System weiterentwickelt werden muss, wenn ein neuartiges Problem auftaucht und wenn eine Entwicklerin oder ein Entwickler auf einen Fehler stößt, der keinem Muster in den Trainingsdaten der KI entspricht. Zu diesem Zeitpunkt hat der Entwickler, der zwei Jahre lang Code generiert, ohne ihn selbst zu schreiben, keinen Rückfallpunkt. Sie oder er hat kein mentales Modell. Es bleibt nur das Werkzeug.

Die Entwickler, die erfolgreich sein werden, sind nicht diejenigen, die KI am haeufigsten nutzen. Es sind diejenigen, die sie richtig einsetzen, die zuerst schreiben und dann fragen, die verstehen, bevor sie einfuegen, und die die KI als Mitarbeiter behandeln und nicht als Ersatz fuer ihr eigenes Denkvermoegen.

Die KI ist besser geworden, waehrend ich weg war. Ich glaube nicht, dass wir duemmer geworden sind. Aber ich glaube, dass manche von uns bequemer werden, und Bequemlichkeit im Engineering ist ein langsamer, unsichtbarer Fehlermodus, der sich aufstaut, bis das System zusammenbricht. Die Frage fuer jeden Entwickler lautet nicht, ob er KI nutzen sollte. Sie lautet: Nutze ich KI, um mein Verstaendnis zu erweitern, oder um es zu ersetzen?

Die Antwort auf diese Frage ist in deinen Pull Requests nicht sichtbar. Sie zeigt sich in deiner Faehigkeit zu debuggen, Architekturen zu entwerfen und zu erklaeren, warum der Code so funktioniert, wie er funktioniert. Wenn du diese letzte Frage fuer deinen eigenen Code nicht beantworten kannst, hat dir die KI nicht geholfen. Sie hat nur die Abrechnung aufgeschoben.

Weitere Analysen zu den Auswirkungen von KI auf Entwickler-Workflows und Engineering-Praktiken finden Sie in Tamiz's Insights mit laufender Berichterstattung ueber die Tools und Trends, die das moderne Software-Engineering praegen.

Sollte ich Coding-Assistenten mit KI komplett nicht mehr verwenden?

Nein. Das waere ein schlechter Tausch. KI-Assistenten verbessern die Produktivitaet bei Boilerplate, Dokumentation und Routineaufgaben ganz klar. Das Risiko liegt nicht in der Nutzung von KI, sondern darin, KI so einzusetzen, dass man kein eigenes Verstaendnis aufbaut. Das produktive Muster ist: zuerst schreiben, dann fragen und immer das Generierte pruefen.

Wie erkenne ich, ob ich im bequemen Muster oder im produktiven Muster arbeite?

Der einfachste Test: Koennen Sie den von Ihnen geschriebenen Code einem anderen Entwickler erklaeren, ohne auf die KI zu verweisen? Koennen Sie eine Aenderung an diesem Code aus ersten Prinzipien debuggen? Koennen Sie erklaeren, warum Sie einen bestimmten Ansatz gegenueber Alternativen gewaehlt haben? Wenn die Antwort auf eine dieser Fragen lautet: Ich muesste die KI fragen, dann arbeiten Sie bei dieser Aufgabe im bequemen Muster.

Gilt das auch fuer KI-Tools ueber Coding-Assistenten hinaus?

Ja. Dieselbe Dynamik gilt fuer KI-generierte Dokumentation, KI-gestuetztes Architekturdesign und KI-generierte Testsuiten. Das Muster ist universell: Wenn das Werkzeug die Antwort liefert, bevor Sie das Verstaendnis aufgebaut haben, ueberspringen Sie das Lernen. Die Loesung ist dieselbe: zuerst selbst einsteigen, dann fragen und immer pruefen.

Mit Vorlagen lassen sich haeufige Fragen schnell beantworten oder Snippets zur Wiederverwendung speichern.

Sind Sie sicher, dass Sie diesen Kommentar verbergen moechten? Er wird in Ihrem Beitrag ausgeblendet, bleibt aber ueber den Permalink des Kommentars weiterhin sichtbar.

Fuer weitere Massnahmen koennen Sie diese Person blockieren und/oder einen Missbrauch melden.