yk.camelcase.work
Yevhen Kim
techai

KI macht Entwickler nicht kleiner. Sie legt nur offen, worauf es wirklich ankommt.

Es gibt dieses einfache Argument, das man gerade dauernd hört: Wenn KI Code schreiben kann, dann wird der Entwickler automatisch weniger wichtig. Klingt schlüssig. Ist aber nur dann schlüssig, wenn man den Job auf Tippen reduziert. Und genau das war bei Softwareentwicklung noch nie die ganze Wahrheit.

Code schreiben ist ein Teil der Arbeit. Klar. Aber eben nicht der Kern von allem.

Der eigentliche Wert steckt meistens woanders: das Problem richtig verstehen, fehlenden Kontext bemerken, zwischen zwei mittelmäßigen Optionen die weniger schlechte wählen, Unsinn früh erkennen, bevor er sich im System festfrisst. Genau da trennt sich gute Entwicklung von bloßer Produktion. Und genau da hilft KI nicht einfach "anstelle des Menschen". Sie verschiebt nur, wo man genau hinschauen muss.

Eine Microsoft-Studie mit 860 Entwicklern passt ganz gut dazu. Die Aussage ist im Grunde simpel: Nur ein relativ kleiner Teil des Arbeitstags geht überhaupt fürs eigentliche Schreiben von Code drauf, obwohl viele KI-Tools fast nur dafür gebaut wirken. Das allein müsste einem schon zu denken geben.

Wenn also ausgerechnet dieser Teil schneller oder billiger wird, dann heißt das nicht, dass der Entwickler kleiner wird. Es heißt nur, dass die bequemen Teile kleiner werden.

Und ehrlich: Viel davon wird niemand vermissen. Boilerplate, Testgerüste, Routineumbauten, all das Zeug, das man macht, aber nicht liebt. Wenn KI das beschleunigt, gut. Der Punkt ist nur: Die schwierigen Teile verschwinden nicht. Sie treten eher deutlicher hervor.

Was jetzt stärker zählt, ist Richtung. Nicht bloß Output.

Was jetzt stärker zählt, ist Urteilsvermögen. Nicht bloß Geschwindigkeit.

Was jetzt stärker zählt, ist die Fähigkeit zu merken, dass ein Vorschlag zwar ordentlich aussieht, aber inhaltlich trotzdem schief ist.

Genau deshalb finde ich die aktuelle Debatte oft etwas schräg. Viele reden so, als ob schneller erzeugter Code automatisch denselben Wert hätte wie gute technische Entscheidungen. Hat er nicht. Ein Modell kann dir in Sekunden einen brauchbar aussehenden Ausschnitt liefern. Es kann dir genauso schnell etwas hinstellen, das auf den ersten Blick vernünftig wirkt und dir später die Architektur aufweicht.

Das ist ja das Tückische daran: KI produziert oft Dinge, die plausibel aussehen. Und Plausibilität wird im Alltag leicht mit Qualität verwechselt.

Deshalb steigen die Anforderungen an Entwickler eher, als dass sie sinken.

Kontext wird wichtiger. Wer den besseren Kontext liefert, bekommt meist auch die besseren Ergebnisse.

Prüfen wird wichtiger. Schneller Output macht Nachdenken nicht optional.

Architektur wird wichtiger. Wenn Implementierung billiger wird, werden Fehler auf Systemebene teurer.

Und auch der Prozess wird wichtiger. Wenn Teams mit Tools wie Copilot schneller durch Teile der Umsetzung gehen, dann darf Review nicht lockerer werden, sondern eher strenger. Sonst verteilt man denselben Mist wie früher, nur effizienter.

Ich glaube deshalb schon länger nicht mehr an die alte Idee, ein guter Entwickler sei vor allem jemand, der besonders viel Code besonders schnell von Hand produzieren kann. Das war vorher schon ein schwaches Modell. Jetzt wirkt es einfach nur noch alt.

Die eigentliche Frage ist heute nicht mehr, ob KI Code schreiben kann. Natürlich kann sie das. Die wichtigere Frage ist: Wer kann mit dieser Geschwindigkeit umgehen, ohne unsauber zu werden? Wer kann Aufgaben sinnvoll delegieren, ohne dabei das Denken mit abzugeben? Wer schützt noch die Form des Systems, wenn alles drumherum schneller wird?

Genau dort wird der gute Entwickler gebraucht.

Nicht weniger als vorher. Eher mehr.

Nur anders. Strenger. Mit weniger Ausreden.

Quellen

Geschrieben vonYevhen Kim

Wenn dieser Artikel hilfreich war, gibt es im Journal weitere Notizen zu Architektur, AI-Workflows, Delivery und Engineering-Praxis.