Ich kann coden — warum KI-Coding keine Softwareentwicklung ist

Neulich schrieb jemand auf LinkedIn: „Ich kann jetzt coden.“ Darunter ein Screenshot von ChatGPT, das ein Python-Skript ausgespuckt hatte. Zwanzig Zeilen, die irgendwas mit einer API machen. Der Beitrag hatte hunderte Likes. Und ich dachte: Nein. Kannst du nicht.

Das klingt arrogant. Ich weiß. Aber es geht mir nicht um Gatekeeping. Es geht mir darum, dass wir gerade kollektiv vergessen, was Softwareentwicklung eigentlich ist — und was nicht.

Die Hausbau-Analogie, aber richtig

Ich benutze gern das Bild vom Hausbau, weil es jedem sofort einleuchtet. Stell dir vor, jemand generiert per KI einen Grundriss. Vier Wände, ein Dach, Fenster, Tür. Sieht gut aus auf dem Bildschirm. Und dann sagt diese Person: „Ich bin jetzt Architekt.“

Jeder würde lachen. Weil jedem klar ist, dass ein Grundriss kein Haus ist. Ein Haus ist Statik. Ein Haus ist Entwässerung, Elektrik, Brandschutz. Ein Haus ist die Entscheidung, ob die tragende Wand 24 oder 36 Zentimeter dick sein muss, weil obendrauf noch ein Stockwerk kommt, das der Kunde im zweiten Gespräch plötzlich doch haben will.

Ein Haus ist auch: Baugrund begutachten. Genehmigungen einholen. Gewerke koordinieren. Bauschäden erkennen, bevor sie zu Bauschäden werden. Und nach zehn Jahren nochmal vorbeikommen und schauen, ob die Abdichtung noch hält.

Software ist exakt dasselbe. Der Code, den die KI ausspuckt, ist der Grundriss. Mehr nicht.

Was Softwareentwicklung tatsächlich bedeutet

Ich mache das seit über 25 Jahren. Der Teil, der „Code schreiben“ heißt, ist vielleicht 20 Prozent meines Tages. An guten Tagen. Der Rest sieht so aus:

Architektur. Welche Komponenten brauche ich? Wie kommunizieren sie miteinander? Was passiert, wenn Komponente A ausfällt — bricht dann alles zusammen oder fängt Komponente B das ab? Diese Entscheidungen treffe ich, bevor eine einzige Zeile Code existiert. Und sie sind die Entscheidungen, die sich in zwei Jahren als brillant oder katastrophal herausstellen.

Debugging. Der Code funktioniert nicht. Oder schlimmer: Er funktioniert, aber falsch. Das Formular speichert Daten, aber bei Umlauten im Nachnamen fehlt das letzte Zeichen. Nicht immer — nur bei bestimmten MySQL-Versionen in Kombination mit einem bestimmten Zeichensatz. Diesen Bug findest du nicht mit einem Prompt. Den findest du, indem du drei Stunden lang Hex-Dumps vergleichst und am Ende fluchend die Collation der Datenbank änderst.

Edge Cases. Der Happy Path funktioniert immer. Das ist trivial. Aber was passiert, wenn jemand das Bestellformular abschickt, dann den Zurück-Button drückt und es nochmal abschickt? Was passiert, wenn die Kreditkartenzahlung beim Provider durchgeht, aber die Bestätigung wegen eines Netzwerk-Timeouts nie bei uns ankommt? Was passiert, wenn ein Nutzer sein Passwort auf einem Gerät ändert, während er auf einem anderen noch eingeloggt ist?

Wartung. Der unspektakulärste Teil. Ein Shopware-Plugin, das ich vor drei Jahren geschrieben habe, läuft noch immer. Aber die PHP-Version hat sich geändert, Shopware hat eine Major-Version veröffentlicht, und eine Library, die ich nutze, hat ihre API umgestellt. Das Plugin muss angepasst werden. Kein neues Feature, nichts Sichtbares. Aber ohne diese Arbeit ist der Shop in sechs Monaten nicht mehr funktionsfähig.

Sicherheit. Der generierte Code nimmt Benutzereingaben entgegen und schreibt sie in die Datenbank. Funktioniert. Aber er escaped nicht. Keine Validierung, keine Parametrisierung. Das ist kein funktionierender Code — das ist eine offene Tür.

Vibe Coding vs. Senior Developer

Nehmen wir ein konkretes Beispiel. Die Aufgabe: „Baue eine REST-API, die Produkte aus einer Datenbank liefert.“

Der Vibe Coder tippt den Prompt, bekommt 40 Zeilen Python, startet den Server, ruft die URL auf, sieht JSON. Fertig. „Ich kann coden.“

Der Senior Developer stellt erst mal Fragen. Wie viele Produkte? Hundert oder zwei Millionen? Wie oft ändern sich die Daten? Wer konsumiert die API — ein Frontend, eine Mobile App, ein Drittanbieter? Brauche ich Pagination? Caching? Rate Limiting? Authentifizierung? Was ist das Ausfallszenario? Gibt es eine SLA? Wie sieht die Datenmigration aus, wenn sich das Schema ändert?

Dann schreibt der Senior Developer Code. Wahrscheinlich weniger elegant als das, was die KI ausspuckt. Aber dieser Code hat Error Handling, Logging, Input Validation, Pagination, vernünftige HTTP-Statuscodes und eine Datenbankabfrage, die auch bei zwei Millionen Datensätzen nicht den Server killt.

Der Unterschied zwischen beiden ist nicht der Code. Der Code sieht manchmal sogar ähnlich aus. Der Unterschied ist alles, was um den Code herum passiert: Die Fragen, die gestellt werden. Die Fälle, an die gedacht wird. Die Erfahrung, die sagt: „Das wird uns in drei Monaten auf die Füße fallen.“

Ein Werkzeug, kein Ersatz

Ich nutze KI-Tools jeden Tag. Claude, Copilot, ChatGPT. Sie machen mich schneller. Boilerplate, Regex-Patterns, Unit-Test-Grundgerüste — dafür sind sie großartig. Aber sie machen mich nicht zu einem besseren Entwickler. Sie machen einen guten Entwickler produktiver. Das ist ein fundamentaler Unterschied.

Wenn ich Claude bitte, mir eine Symfony-Command-Klasse zu generieren, spare ich fünf Minuten Tipparbeit. Aber ich weiß, dass ich die Dependency Injection überprüfen muss. Ich weiß, dass der Exit-Code stimmen muss. Ich weiß, dass ich ein Signal-Handling brauche, wenn der Command lange läuft. Das Wissen kommt nicht aus dem Prompt — es kommt aus zwanzig Jahren, in denen ich Commands geschrieben habe, die in Produktion liefen.

Eine Motorsäge macht einen Förster produktiver. Aber sie macht nicht jeden, der sie einschalten kann, zum Förster. Der Förster weiß, welchen Baum er fällen muss, in welche Richtung der Baum fallen wird, und was der Eingriff für den Wald in zwanzig Jahren bedeutet. Der Typ mit der Motorsäge fällt einen Baum. Hoffentlich den richtigen.

Die unbequeme Wahrheit

Softwareentwicklung ist nicht die Fähigkeit, Code zu erzeugen. Softwareentwicklung ist die Fähigkeit, ein Problem so tief zu durchdringen, dass die richtige Lösung daraus entsteht — und die Erfahrung, die falsche zu erkennen, auch wenn sie auf den ersten Blick funktioniert.

Es ist die Fähigkeit, um drei Uhr nachts einen Stack Trace zu lesen und zu wissen, dass das Problem nicht in Zeile 47 liegt, wo der Fehler auftritt, sondern in Zeile 12, wo ein Null-Wert durchgereicht wird, den drei Methoden vorher niemand geprüft hat. Es ist die Erfahrung, die sagt: „Der Code ist zu einfach für dieses Problem“ — weil einfach manchmal bedeutet, dass jemand die Komplexität ignoriert hat, statt sie zu lösen.

Wer Software nur mit KI erzeugt, ohne sie zu verstehen, baut auf Sand. Das funktioniert — solange es nicht regnet. Und in der Softwareentwicklung regnet es immer. Irgendwann.

Code erzeugen lassen kann jeder. Software entwickeln erfordert Erfahrung, Urteilsvermögen und die Bereitschaft, Verantwortung für das zu übernehmen, was man ausliefert.

Der Typ auf LinkedIn kann prompten. Und das ist eine nützliche Fähigkeit. Aber coden kann er nicht. Und der Unterschied zwischen beidem ist der Unterschied zwischen einem Grundriss und einem Haus, in dem Menschen leben.