KI kann coden: Warum viele Entwickler aufgeben

Warum ein einziger Fehlschlag noch kein Urteil ist – und warum sich Entwickler- und PO-Rolle gerade beide verschieben.

Kaum ein Thema erzeugt in Entwickler-Communities aktuell so viel Reibung wie KI beim Programmieren.

Auf der einen Seite: Leute, die erzählen, dass sie mit KI ganze Features, Migrationen oder sogar komplette Prototypen bauen. Auf der anderen Seite: Leute, die nach einem einzigen missglückten Versuch sagen:

„Funktioniert nicht. KI kann einfach nicht coden.“

Beide Beobachtungen sind ehrlich gemeint. Aber nur eine davon hält einer genaueren Betrachtung stand.

Der typische Ablauf, der zur Enttäuschung führt

Ich sehe (und erlebe selbst) immer wieder dasselbe Muster:

Eine Aufgabe wird der KI in einem Satz gegeben, ohne Kontext, ohne Beispiele, ohne Einschränkungen.
Das Ergebnis ist nicht perfekt. Es kompiliert nicht, trifft nicht die Architektur, übersieht einen Edge Case.
Statt nachzuhaken, wird das Ergebnis verworfen.
Fazit: „KI kann das nicht.“

Das Problem dabei ist selten die KI. Das Problem ist die Erwartung, dass ein einziger Prompt wie ein fertiges Ticket funktioniert, das ein Senior-Entwickler beim ersten Lesen richtig versteht.

Das tut es bei einem echten Kollegen auch nicht. Neue Teammitglieder bekommen Kontext, Rückfragen, ein Review, eine zweite Iteration. Bei KI wird dieser Prozess oft komplett übersprungen und dann als „hat nicht funktioniert“ verbucht.

Was tatsächlich funktioniert: Hartnäckigkeit statt Resignation

Aus eigener Erfahrung: KI-Coding-Tools liefern selten beim ersten Versuch das, was ich am Ende brauche. Aber sie liefern fast immer etwas Brauchbares, wenn ich dranbleibe.

Was in der Praxis wirklich einen Unterschied macht:

Kontext nachliefern, statt den Prompt einfach zu wiederholen. Welche Datei, welches Pattern, welche Konvention gilt hier?
Den Ansatz wechseln, wenn eine Lösung nicht passt, statt dieselbe Formulierung dreimal zu wiederholen. Manchmal hilft es, das Problem kleiner zu schneiden. Manchmal hilft es, die KI erst den Plan skizzieren zu lassen, bevor Code entsteht.
Fehler als Eingabe nutzen, nicht als Endpunkt. Eine Fehlermeldung zurück in den Chat zu kopieren, bringt oft mehr als ein neuer Anlauf von vorne.
Ergebnisse reviewen wie Code von einem Junior, nicht wie eine Blackbox-Antwort. Kritisch lesen, nachfragen, korrigieren.
Mehrere Anläufe einplanen. Wer nach dem ersten Versuch aufhört, behandelt ein iteratives Werkzeug wie ein Orakel.

Das ist kein Trick, sondern im Grunde ganz normales Debugging- und Pairing-Verhalten. Nur eben mit einem Werkzeug, das ungeduldig ausprobiert und schnell wieder verworfen wird, weil die erste Antwort nicht sofort sitzt.

Warum der Zeitpunkt des Urteils so wichtig ist

Ein zweiter Punkt, der bei der Debatte oft fehlt: Wann genau wurde getestet?

Die Modelle, die aktuell im Umlauf sind, unterscheiden sich in ihren Fähigkeiten teils massiv von dem, was noch vor wenigen Monaten verfügbar war. Es vergehen aktuell kaum ein paar Wochen ohne ein neues Modell oder ein spürbares Update eines bestehenden.

Was das bedeutet:

Eine schlechte Erfahrung von vor einem halben Jahr sagt wenig über die aktuelle Leistungsfähigkeit aus.
„Ich habe das mal ausprobiert“ ist ohne Zeitangabe fast wertlos als Aussage.
Wer einmal getestet und dann abgeschlossen hat, urteilt über einen Stand, der oft schon wieder überholt ist.

Das heißt nicht, dass jedes neue Modell alle Probleme löst. Aber es heißt: Ein pauschales, dauerhaftes „geht nicht“ ist bei einem sich so schnell verändernden Werkzeug eine riskante Aussage.

Wer beruflich mit Software zu tun hat, kommt aktuell kaum daran vorbei, das Thema in kurzen Abständen erneut zu prüfen, statt sich auf einen einmaligen Eindruck zu verlassen.

Wie sich der Job des Entwicklers dadurch verändert

Für Entwickler verschiebt sich gerade spürbar, worauf es ankommt.

Früher stand oft im Zentrum: Wie schnell und sauber schreibe ich selbst Code?

Heute kommen zusätzliche Fähigkeiten dazu, die zunehmend wichtiger werden:

Aufgaben so schneiden und beschreiben, dass eine KI sie sinnvoll bearbeiten kann, statt sie mit vager Sprache zu überfordern.
Ergebnisse schnell und kritisch bewerten können, statt jede Zeile selbst zu tippen. Das verlangt eher mehr Code-Verständnis, nicht weniger.
Architektur- und Qualitätsentscheidungen bewusst treffen, weil die KI diese Entscheidungen nicht zuverlässig allein trifft.
Iterativ statt linear arbeiten. Der erste Entwurf ist ein Ausgangspunkt, keine Lieferung.
Werkzeuge aktuell halten. Wer sich vor einem Jahr eine Meinung gebildet hat und dabei stehen bleibt, verpasst reale Fortschritte.

Die Rolle verschiebt sich also stückweit von „Code selbst produzieren“ zu „Code-Erzeugung orchestrieren, prüfen und verantworten“. Das ist kein Abwerten der Fähigkeiten, die Softwareentwicklung ausmachen, sondern eine Verlagerung, wo diese Fähigkeiten am meisten Wert schaffen.

Wie sich der Job des Product Owners parallel verändert

Auf der Produktseite passiert etwas Vergleichbares, nur mit anderen Symptomen.

Ich habe an anderer Stelle beschrieben, wie ich mir mit KI-Skills den PO-Alltag leichter mache und warum technisches Verständnis für Product Owner gerade wichtiger wird statt unwichtiger. Beides hängt direkt mit diesem Thema zusammen.

Für Product Owner heißt das konkret:

Prototypen entstehen schneller, wodurch Ideen früher greifbar werden, aber auch die Erwartung steigt, dass „es doch schon fast fertig aussieht“.
Die Grenze zwischen Anforderung und Umsetzung verschwimmt. Wer eine Idee klar genug beschreiben kann, bekommt oft direkt einen ersten Entwurf zu sehen, nicht erst nach dem nächsten Sprint.
Technisches Grundverständnis wird wichtiger, um einschätzen zu können, was ein KI-generierter Prototyp wirklich taugt und was nur oberflächlich funktioniert.
Geduld wird auch hier zur Kernkompetenz. Genau wie bei Entwicklern führt ein einziger missglückter Versuch schnell zu vorschnellen Schlüssen über das, was mit KI im Produktalltag möglich ist.

Auch Product Owner sind also nicht nur Zuschauer dieser Entwicklung. Sie erleben dieselbe Dynamik aus einer anderen Perspektive: schneller experimentieren können, aber auch schneller Fehlschlüsse ziehen, wenn der erste Versuch nicht überzeugt.

Der gemeinsame Nenner

So unterschiedlich die Rollen sind, das Muster dahinter ist erstaunlich ähnlich:

Wer nach dem ersten Versuch aufhört, sieht nur einen Bruchteil dessen, was möglich ist.
Wer hartnäckig bleibt, unterschiedliche Ansätze probiert und Fehler als Information statt als Endpunkt behandelt, bekommt spürbar bessere Ergebnisse.
Wer sein Urteil nicht regelmäßig aktualisiert, urteilt über einen technischen Stand, der in wenigen Monaten schon wieder ein anderer ist.

Das gilt für Entwickler beim Coden genauso wie für Product Owner bei Anforderungen, Prototypen und Priorisierung.

Fazit

KI kann sehr wohl coden. Nur eben nicht immer beim ersten Versuch und nicht ohne Kontext, Nachfragen und Korrekturen.

Wer das ignoriert und nach einem einzigen Fehlschlag urteilt, verpasst genau den Teil, der den eigentlichen Unterschied macht: die Iteration.

Gleichzeitig verändert sich dadurch der Kern beider Rollen, Entwicklung und Produktmanagement. Weniger reines Ausführen, mehr Orchestrieren, Bewerten und Entscheiden.

Wer das früh ernst nimmt, statt es nach einem schlechten ersten Eindruck abzuhaken, verschafft sich gerade einen erheblichen Vorsprung.

Bonus-Frage zum Mitnehmen: 👉 Wann hast du zuletzt ein aktuelles Modell wirklich hartnäckig getestet, statt dich auf deinen letzten Eindruck zu verlassen?

KI kann coden: Warum viele Entwickler trotzdem zu früh aufgeben