KI-gestützt oder KI-abhängig: Woran sich der Unterschied erkennen lässt

In meinem LinkedIn-Beitrag - 5 Brutal Truths After 15+ Years as a Dev - geht es um Eigenschaften, die sich über Jahre im Beruf herausbilden und die kein KI-Werkzeug ersetzt. Für Unternehmen, die gerade entscheiden, wem sie ein bestehendes Software-System anvertrauen, ist genau das relevant: Werkzeuge wie Claude Code, Codex, Gemini CLI oder ein DeepSeek-basierter Harness verändern, wie schnell Code entsteht - nicht, wer davon tatsächlich profitiert und wer sich nur noch auf sie verlässt.

Lesbarer Code ist kein Nice-to-have

Funktionierender Code ist nicht automatisch guter Code. Code wird öfter gelesen als geschrieben - von künftigen Kolleginnen und Kollegen, dem nächsten externen Entwickler oder dem eigenen zukünftigen Ich. KI-gestützte Codegenerierung liefert oft Lösungen, die auf den ersten Blick laufen, aber niemand außer dem Tool selbst nachvollziehen kann. Genau das ist die Definition von technischer Schuld: Sie fällt nicht sofort auf, sondern erst, wenn jemand die Stelle ändern muss.

Ohne KI debuggen können

Der eigentliche Praxistest zeigt sich nicht bei der Erstellung, sondern beim Debugging: Kann ein Fehler eingegrenzt werden, auch wenn kein KI-Werkzeug eine Antwort parat hat? Wer bei jedem unbekannten Problem sofort auf ein Tool angewiesen ist, verliert genau dort die Übersicht, wo es später am meisten kostet - bei den Rand- und Fehlerfällen, die das Tool nicht kennt, weil sie zu spezifisch für das jeweilige Software-System sind.

Warum Code-lesen aussagekräftiger wird als Code-schreiben

Eine klassische Take-Home-Aufgabe verliert gerade an Aussagekraft: Wenn ein LLM den Code ohnehin schreiben kann, zeigt eine makellos abgegebene Lösung wenig darüber, wer sie tatsächlich verstanden hat. Aussagekräftiger wird das Gegenteil - bestehenden, fremden Code lesen, erklären und bewerten können. Kann jemand nachvollziehen, warum eine Lösung so aufgebaut ist, welche Kompromisse dahinterstecken und wo die Schwachstellen liegen? Diese Fähigkeit lässt sich nicht outsourcen, weil sie kein Erzeugen ist, sondern ein Urteil - die eigentliche Qualität zeigt sich zunehmend an Entscheidungen und Architekturmeinungen, nicht mehr an der reinen Fähigkeit, Code zu produzieren.

Ego ist auch hier ein Warnsignal

Ein Muster, das sich über Jahre wiederholt: Wer eigene Fehler nur ungern zugibt oder Kritik an der eigenen Lösung als persönlichen Angriff behandelt, korrigiert Kurs später und teurer - meist erst, wenn sich das Problem in Produktion zeigt, statt frühzeitig im Review. Dasselbe Ego, das anderswo zu überkomplexen, kaum wartbaren Architekturentscheidungen führt, zeigt sich hier auf individueller Ebene.

Reibung kostet mehr, als die Stundenrate zeigt

Ein schwieriger, aber technisch brillanter externer Entwickler ist am Ende oft teurer als ein zuverlässiger, unkomplizierter. Unklare Kommunikation, fehlende Verlässlichkeit oder Alleingänge verursachen Kosten, die sich nicht auf der Rechnung zeigen, aber im Projektverlauf spürbar werden - verpasste Abstimmungen, doppelte Arbeit, Entscheidungen, die neu verhandelt werden müssen. Zuverlässigkeit zahlt sich über die Laufzeit einer Zusammenarbeit meist mehr aus als reine technische Cleverness.

Weiterbildung als Unterscheidungsmerkmal

Wer neue Technologien und Ansätze nur verfolgt, wenn ein Projekt sie zwingend verlangt, bleibt irgendwann stehen. Wer aus eigenem Interesse dranbleibt, bringt eine breitere Bandbreite an Lösungsansätzen mit - und erkennt eher, wann eine neue Technologie tatsächlich einen Unterschied macht und wann sie nur glänzt.

KI-gestützt statt KI-abhängig

Der eigentliche Unterschied liegt nicht darin, ob KI-Werkzeuge genutzt werden - inzwischen tun das die meisten. Er liegt darin, ob sie das Fundament ersetzen oder nur beschleunigen, was ohnehin verstanden wird.

Der KI-gestützte Entwickler

Nutzt Gen-AI für Boilerplate, erste Entwürfe und das Durchsuchen großer Codebasen, prüft und versteht das Ergebnis aber selbst.

Der KI-abhängige Entwickler

Übernimmt generierte Lösungen ohne dieses Verständnis - was so lange gut geht, bis ein Fall auftritt, den das Werkzeug nicht vorgesehen hat. Der eine baut technische Schuld ab, der andere baut sie auf.