Ersetzt KI den Entwickler? Was stimmt und was nicht

Auf LinkedIn kehrt jede Woche eine Debatte zurück. Auf der einen Seite: „Keine KI wird einen Entwickler schlagen, der das Geschäft versteht, eine unnötige Funktion ablehnt und seine Entscheidungen im Produktivbetrieb verantwortet. Code lässt sich generieren, die Entscheidung, ihn zu schreiben, nicht.“ Auf der anderen ein spöttischer Kommentar: Niemand liest mehr Assembler, man vertraut dem Compiler; und ein Direktor liest den Code seiner Teams nicht, er beurteilt, was hineingeht und was herauskommt. Also, Menschen oder KI, wo ist der Unterschied?

Beide haben in einem Punkt recht. Und beide übersehen denselben.

Kurz gesagt

• Wahr: Die Entscheidung, Code zu schreiben, die Ablehnung einer unnötigen Funktion und die Verantwortung im Produktivbetrieb bleiben menschlich.
• Falsch: Die KI ist kein Compiler. Sie ist nicht deterministisch, und ihr Code kann falsch sein und trotzdem richtig aussehen.
• Teuer ist nicht mehr das Schreiben des Codes, sondern seine Prüfung, und nicht überall gleich intensiv.
• Den Gewinn wählt man: mit demselben Budget weiter gehen oder schneller und günstiger starten.

Was stimmt

Die Entscheidung bleibt menschlich. Eine KI produziert fünfhundert Zeilen in dreißig Sekunden. Sie fragt sich nicht, ob diese Zeilen existieren sollen, ob die Funktion dem Geschäft wirklich dient oder was ihre Wartung kosten wird. Bezahlt wird dieses Urteil, nicht das Tippen.

Steuerung über Ergebnisse gab es schon. Der technische Leiter eines großen Teams liest nicht jede Zeile. Er beurteilt Lieferungen, Störungen, Termine. So gesehen ändert es weniger, als man sagt, ob ein Team aus Entwicklern oder aus KI-Agenten besteht: Gesteuert werden Eingang, Ausgang und Fehler.

Der Wettbewerb entscheidet. Wer sein Budget kürzt, weil „die KI programmiert“, tritt auf der Stelle, während sein Wettbewerber seines behält und viel weiter kommt.

Was falsch ist, oder nur halb wahr

„Wie beim Assembler werden wir am Ende vertrauen.“ Der Vergleich ist verlockend, aber er hält nicht. Ein Compiler ist deterministisch: Dieselbe Eingabe ergibt immer dieselbe Ausgabe, und Jahrzehnte von Tests haben ihn zuverlässig gemacht. Eine KI liefert für dieselbe Anfrage zwei verschiedene Codes und manchmal einen falschen Code, der richtig aussieht. Vertrauen entsteht nicht aus Gewohnheit, sondern aus automatischen Tests, Kontrollen und gezielten Prüfungen.

„Das Team ist bereits eine Blackbox.“ Wahr für die Steuerung, falsch für die Verantwortung. Hinter einem menschlichen Team steht jemand für einen Ausfall ein und weiß, warum eine Entscheidung getroffen wurde. Hinter einem Agenten fällt die Verantwortung auf die zurück, die ihn angeschlossen haben, und die Erklärung der Entscheidung existiert oft nirgends.

„Man muss nur alles anschließen, die KI programmiert für dich.“ Die Messungen sagen etwas anderes. Im Juli 2025 hat eine kontrollierte Studie des Labors METR erfahrene Entwickler bei ihren eigenen Projekten begleitet: Mit KI brauchten sie etwa 19 % länger, obwohl sie glaubten, 20 % gewonnen zu haben. Die Werkzeuge haben sich seitdem verbessert, und die Studie umfasste nur sechzehn Personen, aber sie erinnert an eines: Das Gefühl von Geschwindigkeit ist keine Geschwindigkeit.

Unsere Position: dort prüfen, wo es zählt

Muss man jede von einer KI erzeugte Zeile prüfen? Nein. Damit verlöre man den größten Teil des Gewinns. Muss man gar keine prüfen? Auch nicht. Die richtige Antwort hängt von der Angriffsfläche ab.

Eine statische oder Headless-Unternehmenswebsite ist keine Genetik. Sie hat weder eine offene Datenbank noch einen Anwendungsserver, den man hacken könnte. Dort liefern wir wenig geprüften Code aus, generiert und dann getestet, und das geht in der Regel gut: Wir tun das jeden Tag.

Das menschliche Auge bleibt dagegen überall Pflicht, wo ein Fehler teuer wird:

• Authentifizierung und Rechte: wer sich anmelden kann, wer was sieht;
• Verbindungen zu anderen Werkzeugen: APIs, Webhooks, Zugriffstoken;
• Geheimnisse: Ein Schlüssel, der in den an den Browser gesendeten Code gerutscht ist, ist öffentlich;
• Formulare: Feldvalidierung, Spamschutz, personenbezogene Daten und DSGVO;
• Zahlung: Beträge, Erstattungen, Webhooks des Zahlungsanbieters;
• Abhängigkeiten: Eine von der KI hinzugefügte Bibliothek, manchmal unbekannt oder aufgegeben, ist fremder Code, der in Ihr Produkt gelangt.

Die Kontrollen im Einzelnen stehen in unserem Artikel über die Sicherheit einer Anwendung, und warum eine statische Website so wenig preisgibt, in dem über die PHP-Sicherheitslücke vom Oktober 2026.

Günstiger oder weiter?

Wir sind nicht mehr im Jahr 2025: Die menschlichen Eingriffe in ein Webprojekt sind tatsächlich zurückgegangen. Was man mit diesem Gewinn macht, muss man wählen, und die Antwort hängt von der Lage des Unternehmens ab.

1. Mit demselben Budget weiter gehen: mehr Funktionen, mehr Tests, mehr Märkte. Das ist der Weg dessen, der in einem umkämpften Markt steht.
2. Schneller und günstiger starten: ein erstes Produkt in wenigen Wochen online, um eine Idee zu prüfen, bevor man mehr investiert.

Wir bieten unseren Kunden beide Wege an. Was wir nicht anbieten, ist der dritte, den man zu oft hört: das Budget kürzen und darauf setzen, dass die KI dieselbe Arbeit macht, ohne dass jemand sie lenkt. Unser Artikel über Vibe Coding erzählt, wie diese Projekte enden.

Unsere Meinung

Die „Dino-Coder“ irren, wenn sie glauben, dass das Prüfen jeder Zeile ihren Beruf schützt. Die Begeisterten irren, wenn sie glauben, man könne alles anschließen und nichts mehr ansehen. Der Beruf verschiebt sich: weniger Schreiben, mehr Entscheidungen, Architektur und Prüfung. Und was den Preis eines guten Entwicklers rechtfertigt, ist nicht die Zahl der Zeilen, die er tippt. Es ist seine Fähigkeit zu sagen: „Diese hier dürfen nicht existieren“, und zu wissen, welche er prüfen muss. Unser Artikel über die Rolle des Menschen gegenüber der KI geht weiter auf dieses Urteil ein.

Quellen

1. Eine kontrollierte Studie des Labors METR (neuer Tab)metr.org