Coding oder Software Engineering? Wo KI die Grenze verschiebt — und wo sie stehen bleibt

Die Unterscheidung zwischen Coding und Software Engineering war lange eine akademische Randnotiz. Mit KI in der Entwicklung wird sie zur betriebswirtschaftlichen Frage — und zur Trennlinie zwischen Teams, die schneller werden, und Teams, die schneller Technical Debt aufbauen.

Coding vs. Software Engineering — kurz und ohne Nostalgie

Coding ist das Schreiben von Programmcode. Software Engineering ist der disziplinierte Prozess, aus einer Idee ein System zu machen, das man in fünf Jahren noch warten, erweitern und auditieren kann. Requirements Engineering. Architektur. Test-Strategie. Deployment- und Rollback-Konzepte. Beobachtbarkeit. Übergabe an den Betrieb.

Coding ist ein Teil davon. Nicht das Ganze.

Diese Unterscheidung ist mit KI nicht schwächer geworden, sondern klarer sichtbar. Weil KI genau den Coding-Teil massiv beschleunigen kann — und der Reflex „dann brauchen wir das Engineering ja nicht mehr" empirisch überprüfbar falsch ist.

Was KI heute übernehmen kann — und was nicht

Produktiv delegierbar sind heute mehrere Prozess-Schritte:

• Code-Generierung aus Spezifikation oder aus einem gut definierten User-Story-Kontext
• Test-Fälle aus Anforderungen ableiten, Coverage-Lücken schließen
• Refactoring-Vorschläge in großen Codebases, konsistente Umbenennungen, Muster-Aktualisierungen
• Architektur-Skizzen und Trade-off-Diskussionen — als Sparringspartner, nicht als Entscheider
• Dokumentation, Onboarding-Material, API-Beschreibungen

Nicht delegierbar — jedenfalls nicht ohne menschliche Verantwortung im Kern:

• Requirements-Priorisierung mit Blick auf Business-Case und Regulierung
• Fach-Entscheidungen unter Ambiguität, insbesondere in domänenspezifischen Prozessen
• Verantwortung für regulierte Prozesse (KRITIS, NIS-2, EU-AI-Act)
• Governance-Entscheidungen — wer darf was, welche Datenklasse in welche Umgebung, was wird protokolliert

Die zweite Liste bleibt bei den Menschen. Die erste kann — und soll — an KI übergeben werden. Alles andere ist Ressourcen-Verschwendung.

Der Fehler: Vibe Coding statt Engineering

Der Begriff „Vibe Coding" — populär gemacht Anfang 2025 durch Andrej Karpathy — beschreibt einen Modus, in dem Entwickler den generierten Code nicht mehr wirklich lesen. Man gibt der KI eine Prompt, akzeptiert das Ergebnis, testet oberflächlich, deployed. Für ein Wochenend-Projekt ist das legitim. Für eine Software, die morgen zur kritischen Infrastruktur einer Energieversorgung wird, ist es fahrlässig.

Was passiert, wenn Engineering übersprungen wird:

• Sicherheit: SQL-Injection, unsichere Defaults, hard-coded Secrets — die KI weiß nicht, was Ihre Datenklasse ist und welche Angriffs-Fläche relevant ist
• Skalierbarkeit: Muster, die im Prototyp funktionieren, brechen bei realer Last und realem Datenvolumen
• Wartbarkeit: Sechs Monate später versteht niemand mehr, warum es tut, was es tut — und ob es das noch tun sollte
• Compliance: DSGVO, NIS-2, EU-AI-Act — Nachweispflichten kann kein „Vibe" erfüllen; ein nicht dokumentierter Entscheidungspfad ist ein Auditfund

Der Punkt ist nicht, dass KI-generierter Code per se schlechter wäre als handgeschriebener. Der Punkt ist, dass der Engineering-Prozess bewusste Prüfstellen kennt, an denen Qualität, Sicherheit und Compliance überprüft werden. Diese Prüfstellen sind der Wert des Engineerings — nicht das Tippen selbst.

Das Drei-Schritt-Rahmenwerk

In der Praxis lässt sich der Umgang mit KI in der Softwareentwicklung auf drei Schritte verdichten. Nicht als Rezept, sondern als Ordnungsrahmen, der entscheidet, wo KI wo greift.

1. Prozess einhalten. Der Software-Engineering-Prozess von Requirements bis Betrieb bleibt der Ordnungsrahmen. Nicht als Ritual, sondern als Struktur, die entscheidet, welche Ergebnisse überhaupt zwischen den Schritten übergeben werden dürfen — mit oder ohne KI-Beteiligung.
2. Aufgaben an KI delegieren — bewusst. Code-Generierung, Test-Coverage, Architektur-Vorschläge, Refactoring, Dokumentation. Diese Schritte lassen sich heute produktiv mit KI-Assistenten ausführen, mit einem Faktor 2× bis 10× Geschwindigkeit gegenüber Handarbeit. Voraussetzung: klare Inputs (Requirements, Kontext, Konventionen) und klar definierte Erwartungen an den Output.
3. Quality- und Security-Gates nach jedem Schritt. Was KI produziert, kommt nicht ungeprüft in den nächsten Prozess-Schritt. Die Gates können selbst wieder aus KI (LLM-basierte Reviews), klassischer Werkzeug-Kette (Linters, SAST, DAST, SBOM) und menschlicher Prüfung bestehen — die Mischung hängt vom Risiko-Profil ab. Je höher die kritische Infrastruktur-Relevanz, desto mehr Gewicht auf klassische Werkzeuge und Mensch.

Das Ergebnis ist nicht „weniger Engineering". Es ist Engineering mit anderer Zeitverteilung: weniger Tipp-Zeit, mehr Prüf-Zeit; weniger Boilerplate, mehr Design; weniger Copy-Paste-Wiederholung, mehr bewusste Konvention.

Der eigentliche Hebel — und wo er nicht liegt

Der oft gehörte Satz „mit KI schreiben wir 10-mal schneller Code" ist als Business-Case nicht besonders stark. Der interessantere Satz ist:

Mit KI durchlaufen wir den gesamten Prozess-Zyklus — Requirements, Architektur, Code, Tests, Gates, Deployment, Betrieb — bei mindestens gleicher Qualität in einem Drittel der Zeit.

Der Unterschied ist substanziell. Wer nur schneller codet und dieselbe Zeit im Review, im Bug-Fixing und in der Compliance-Nachbereitung verliert, hat nichts gewonnen — außer mehr Code, den irgendjemand pflegen muss. Wer den Zyklus verkürzt, kann in derselben Zeit mehr Features liefern, mehr Feedback ziehen, mehr Iterationen fahren — bei gleichbleibender oder besserer Qualität.

Das ist die eigentliche Aufgabe eines Software Engineers heute (noch): den Prozess so zu automatisieren, dass Geschwindigkeit und Qualität gleichzeitig gewinnen — nicht das eine gegen das andere.

Fazit

Die Rolle „Software Engineer" wird nicht kleiner. Was sich ändert, ist der Anteil der Zeit, der im Editor verbracht wird — und der Anteil, der in Design, Review, Governance und Prozess-Automatisierung fließt.

Wer diese Verschiebung strukturiert nachzieht, wird schneller und besser. Wer sie ignoriert oder falsch macht (Vibe Coding statt Engineering), wird schneller und schlechter — was in kritischen Prozessen keine Kategorie ist, sondern ein Risiko.

Die Unterscheidung zwischen Coding und Software Engineering war lange akademisch. Mit KI wird sie zur wirtschaftlichen Frage. Und zur Frage, ob eine Organisation die Zeit, die sie im Editor spart, in Qualität investiert — oder ob sie sie in mehr Code verpulvert, den morgen jemand aufräumen muss.

Offene Frage

Wo stehen Sie in dieser Verschiebung? Welche Schritte in Ihrem Software-Delivery-Prozess laufen bei Ihnen heute bereits produktiv mit KI-Unterstützung — und wo halten Sie die Gates bewusst noch bei Mensch oder klassischem Werkzeug? Ich freue mich über Ihre Erfahrung.