Warum Coding-KI die wichtigste Technologieentscheidung bei neuer Unternehmenssoftware verändert
Wer heute eine neue Unternehmenssoftware plant, landet erstaunlich schnell bei einer technischen Grundsatzfrage:
Welches Framework oder welche Entwicklungsplattform sollen wir einsetzen?
React oder Angular? Next.js oder eine klassische Serveranwendung? ASP.NET Core, Spring Boot, Laravel oder Django? Microsoft Power Apps, Mendix, OutSystems oder eine andere Low-Code-Plattform?
Die Frage wirkt vernünftig. Schließlich soll die Entscheidung langfristig tragen. Die Software muss wartbar sein, mit dem Unternehmen wachsen und später von anderen Entwicklern übernommen werden können. Niemand möchte nach zwei Jahren feststellen, dass er auf die falsche Technologie gesetzt hat.
Deshalb werden Kriterienkataloge geschrieben, Anbieter verglichen und technische Workshops abgehalten. Man diskutiert Komponenten, Versionen, Lizenzmodelle, verfügbare Spezialisten und vermeintliche Zukunftssicherheit.
Ich glaube inzwischen: In vielen Projekten kommt diese Frage zu früh.
Die erste Frage sollte nicht mehr lauten:
Welches große Framework brauchen wir?
Sondern:
Brauchen wir für diese Anwendung überhaupt noch ein großes Framework?
Das ist keine Wortspielerei. Coding-KI verändert gerade die wirtschaftliche und technische Ausgangslage, auf der die klassische Frameworkentscheidung beruhte.
Eine Entwicklung, die ich seit 30 Jahren beobachte
Ich entwickle seit rund 30 Jahren Software für betriebliche Abläufe. In dieser Zeit ging es im Kern immer um dieselbe Frage: Wie lässt sich individuelle Software schneller und wirtschaftlicher herstellen, ohne ihre Passgenauigkeit zu verlieren?
Microsoft Access war darauf schon früh eine bemerkenswert produktive Antwort. Tabellen, Abfragen, Formulare, Berichte und Geschäftslogik konnten in einer gemeinsamen Entwicklungsumgebung verbunden werden. Zusammen mit SQL Server entstanden daraus leistungsfähige Mehrbenutzeranwendungen, die sehr genau auf einen Betrieb zugeschnitten waren.
Der entscheidende Vorteil lag nicht in einer einzelnen technischen Funktion. Access ersparte einen großen Teil der wiederkehrenden Handarbeit und ließ mehr Zeit für den eigentlichen Geschäftsprozess.
Mit dem Web kamen neue Anforderungen: Browser, mobile Geräte, externe Benutzer, Portale, Schnittstellen und Cloud-Dienste. Frameworks und später Low-Code-Plattformen versprachen erneut, die Entwicklung zu beschleunigen. Sie lösten damit dasselbe Grundproblem auf eine andere Weise – durch vorbereitete Strukturen und immer umfangreichere Abstraktionsschichten.
Coding-KI ist für mich die nächste Stufe dieser Entwicklung. Sie beschleunigt nicht durch einen starren Baukasten. Sie kann die konkrete Anwendung, ihre Daten und ihre Regeln analysieren und den passenden Quellcode erzeugen.
Das ist mehr als eine weitere Evolution der Werkzeuge – es ist eine Revolution. Sie verändert die Grundlage, auf der Unternehmen ihre Softwarearchitektur auswählen.
Frameworks waren eine vernünftige Antwort auf ein reales Problem
Frameworks sind nicht ohne Grund entstanden. Sie haben über Jahrzehnte ein zentrales Problem der Softwareentwicklung gelöst: Menschen können nur eine begrenzte Menge Code in einer begrenzten Zeit schreiben, prüfen und pflegen.
Ein Entwickler sollte nicht bei jedem Projekt Navigation, Formulare, Validierungen, Datenzugriff, Benutzerverwaltung, Sicherheitsmechanismen und Deployment vollständig neu erfinden. Frameworks lieferten dafür vorbereitete Strukturen, Komponenten und Konventionen.
Das brachte enorme Vorteile:
- Projekte konnten schneller beginnen.
- Entwickler fanden sich in einer bekannten Struktur zurecht.
- Teams mussten viele Grundsatzentscheidungen nicht bei jedem Projekt neu treffen.
- Wiederkehrende technische Aufgaben wurden vereinheitlicht.
- Für verbreitete Frameworks entstand ein Markt spezialisierter Entwickler und Komponenten.
Die Logik war überzeugend: Wenn menschliche Entwickler nicht alles selbst programmieren können, muss ein vorbereitetes Gerüst einen Teil der Arbeit übernehmen.
Frameworks waren damit nicht nur eine technische Mode. Sie waren ein Produktivitätsinstrument.
Der Preis der Beschleunigung
Diese Beschleunigung war jedoch nie kostenlos.
Ein Framework nimmt Entscheidungen ab – und gibt damit gleichzeitig vor, wie die Anwendung aufgebaut werden soll. Das Entwicklungsteam muss deshalb nicht nur das Unternehmen und seine Anforderungen verstehen. Es muss zusätzlich die Denkweise des Frameworks beherrschen.
Zu den fachlichen Fragen kommen technische Fragen:
- Wie baut das Framework Komponenten auf?
- Wie werden Zustände verwaltet?
- Wie läuft der Lebenszyklus einer Maske oder Seite?
- Wie werden Daten über das vorgesehene Modell gelesen und geschrieben?
- Welche Erweiterungen passen zu welcher Version?
- Wie werden Updates und Versionswechsel behandelt?
- Welche Abhängigkeiten sind miteinander kompatibel?
Solange eine Anwendung weitgehend dem vorgesehenen Standard entspricht, funktioniert das ausgezeichnet.
Individualsoftware entsteht jedoch häufig gerade dort, wo der Standard nicht reicht.
Ein spezialisierter Betrieb besitzt vielleicht eine ungewöhnliche Auftragslogik. Ein Prüfschritt hängt von mehreren fachlichen Ausnahmen ab. Eine Kalkulation folgt keinem üblichen Schema. Eine Tabelle muss sich anders bedienen lassen als vom Komponentenmodell vorgesehen. Ein Start-up entwickelt einen Prozess, den es in dieser Form bisher noch nicht gab.
Dann beginnt der bekannte Kampf gegen das Werkzeug:
- Ein Formular kann fast alles – nur nicht genau das Benötigte.
- Ein Prozess passt nicht sauber in das Workflowmodell.
- Eine Abfrage lässt sich nur mit Umwegen über die vorgesehene Datenzugriffsschicht ausdrücken.
- Eine kleine fachliche Änderung zieht Anpassungen durch mehrere technische Schichten nach sich.
- Für eine Besonderheit wird ein zusätzliches Paket eingebunden, das weitere Abhängigkeiten erzeugt.
Das Framework beschleunigt oft die ersten 80 Prozent. Die letzten 20 Prozent enthalten jedoch die eigentliche Individualität – und können unverhältnismäßig teuer werden.
Die Frameworkentscheidung ist auch eine Geschäftsentscheidung
Für die Geschäftsführung geht es deshalb um mehr als um Programmiersprachen.
Mit der Frameworkentscheidung werden häufig langfristige Bindungen festgelegt:
- an einen Versions- und Updatepfad,
- an bestimmte Komponenten und deren Hersteller,
- an einen Markt spezialisierter Entwickler,
- an technische Konventionen, die mit dem Geschäftsprozess nichts zu tun haben,
- an einen Teil des Budgets, der dauerhaft in die Pflege des Entwicklungsgerüsts fließt.
Diese Kosten stehen selten vollständig im ersten Angebot. Sie zeigen sich später: bei Updates, Sicherheitsanpassungen, Erweiterungen, Entwicklerwechseln und beim Austausch nicht mehr gepflegter Komponenten.
Das bedeutet nicht, dass Frameworks grundsätzlich unwirtschaftlich sind. Es bedeutet nur: Ihr Nutzen muss die zusätzliche Bindung rechtfertigen.
Genau diese Rechnung verändert sich durch Coding-KI.
Low-Code verschiebt das Problem
Low-Code- und No-Code-Plattformen treiben die ursprüngliche Frameworkidee noch weiter.
Sie liefern grafische Editoren, Datenmodelle, Benutzerverwaltung, Konnektoren, Oberflächenkomponenten und oft auch den Betrieb aus einer Hand. Für einfache, standardisierte Anwendungen innerhalb eines vorhandenen Ökosystems kann das sehr sinnvoll sein.
Aber auch hier gilt eine einfache Regel:
Je mehr die Plattform übernimmt, desto stärker wird die Anwendung von der Plattform abhängig.
Mögliche Folgen sind nutzerbezogene Lizenzkosten, steigende Kosten bei wachsender Nutzung, Einschränkungen bei ungewöhnlichen Prozessen, proprietäre Komponentenmodelle und eine schwierige spätere Migration.
Für eine standardisierte interne App kann dieser Preis angemessen sein. Für eine individuelle Kernanwendung, in der das besondere Wissen und Geschäftsmodell eines Unternehmens steckt, kann die Plattform selbst zum begrenzenden Faktor werden.
Low-Code beseitigt die Grundfrage daher nicht. Es tauscht Entwicklungsaufwand gegen Plattformbindung.
Coding-KI verändert die Ausgangslage
Leistungsfähige Coding-KI übernimmt heute einen großen Teil der wiederkehrenden Arbeit, für die Frameworks, Generatoren und Low-Code-Systeme geschaffen wurden.
Sie kann unter anderem:
- Projektstrukturen anlegen,
- Datenbanktabellen und Abfragen entwickeln,
- Eingabe-, Such- und Listenmasken erstellen,
- Validierungen und Berechtigungen umsetzen,
- Backend-Routen und Schnittstellen ergänzen,
- vorhandene Module als Muster verwenden,
- Änderungen projektweit durchführen,
- automatisierte Tests erzeugen,
- Fehler und Seiteneffekte suchen,
- technische Dokumentation aktualisieren.
Der entscheidende Unterschied ist nicht nur die Geschwindigkeit.
Ein Framework beschleunigt die Anwendung nach den Regeln des Frameworks. Eine gut geführte Coding-KI kann die Anwendung nach den Regeln des Unternehmens entwickeln.
Sie kann vorhandenen Quellcode, Projektregeln, Datenstrukturen und fachliche Zusammenhänge gemeinsam berücksichtigen. Sie ist damit kein starrer Generator, sondern ein flexibles Entwicklungswerkzeug, das sich an die konkrete Anwendung anpassen kann.
Früher war das Framework der Generator. Heute kann es die KI sein.
Damit verliert das große Anwendungsframework nicht automatisch jede Berechtigung. Aber seine historische Hauptaufgabe – die Beschleunigung menschlicher Entwickler – ist nicht mehr alternativlos.
Was KI-native Entwicklung tatsächlich bedeutet
„KI-nativ“ bedeutet für mich nicht, dass jemand eine Aufgabenbeschreibung in ein Chatfenster schreibt und anschließend ungeprüften Code veröffentlicht.
KI-native Entwicklung ist ein geführter, strukturierter Entwicklungsprozess:
- Geschäftsprozess verstehen
Ziele, Beteiligte, Entscheidungen, Ausnahmen und Ergebnisse werden fachlich geklärt. - Daten modellieren
Informationen, Beziehungen, Zustände, Historie und Rechte werden belastbar strukturiert. - Projektregeln definieren
Architektur, Sicherheit, Namenskonventionen, Fehlerbehandlung, Tests und Dokumentation werden verbindlich vorgegeben. - Coding-KI führen
Die KI erzeugt und verändert den produktiven Quellcode innerhalb dieser Regeln und im Kontext der vorhandenen Anwendung. - Ergebnis prüfen
Funktionen, Sicherheit, Datenintegrität, Bedienung und fachliche Richtigkeit werden kontrolliert und getestet.
Der Quellcode bleibt normaler, vollständig verfügbarer Quellcode. Er liegt im eigenen Repository, wird versioniert und kann von anderen KI-Modellen oder menschlichen Entwicklern übernommen werden.
Die KI wird für die Entwicklung eingesetzt. Die fertige Anwendung muss für ihren laufenden Betrieb nicht von diesem KI-Modell abhängig sein.
Das ist ein wesentlicher Unterschied zu einer proprietären Entwicklungsplattform.
Ein direkter technischer Aufbau kann genügen
Am Ende versteht ein Browser drei grundlegende Technologien: HTML für die Struktur, CSS für die Darstellung und JavaScript für das Verhalten.
Mit Node.js kann JavaScript auch auf dem Server eingesetzt werden. Eine relationale Datenbank wie Microsoft SQL Server oder PostgreSQL übernimmt die strukturierten Unternehmensdaten.
Ein direkter Aufbau kann deshalb beispielsweise so aussehen:
- Browser: HTML, CSS und JavaScript
- Server: Node.js und JavaScript
- Datenbank: Microsoft SQL Server oder PostgreSQL
Dieser Aufbau ist nicht für jedes denkbare Projekt die beste Wahl. Für viele datenbankorientierte Unternehmensanwendungen ist er jedoch überraschend leistungsfähig.
Typische Anforderungen sind dort:
- Eingabe- und Suchmasken,
- Tabellen und Auswertungen,
- klar definierte Rollen und Rechte,
- fachliche Prüfungen und Freigaben,
- Dokumenten- und Datenprozesse,
- Schnittstellen zu ausgewählten Systemen.
Für solche Anwendungen kann ein direkter Stack vollkommen ausreichen. Die Software bleibt nahe an den tatsächlich ausgeführten Technologien. Es gibt weniger Übersetzungsschichten, weniger Frameworkkonventionen und weniger technischen Ballast.
Vor allem kann die Coding-KI das gesamte System leichter überblicken und verändern.
Weniger Framework bedeutet nicht weniger Architektur
Der Verzicht auf ein großes Anwendungsframework darf nicht mit strukturloser Entwicklung verwechselt werden.
Professionelle Unternehmenssoftware benötigt weiterhin:
- eine klare Modulstruktur,
- zentrale Authentifizierung,
- serverseitige Rechteprüfung,
- parametrisierte Datenbankzugriffe,
- Eingabevalidierung,
- einheitliche Fehlerbehandlung,
- Protokollierung und Datensicherung,
- Versionsverwaltung,
- automatische Tests,
- dokumentierte Installations- und Betriebsabläufe,
- verbindliche Projekt- und Architekturregeln.
Diese Anforderungen verschwinden durch KI nicht. Im Gegenteil: Je schneller Code erzeugt werden kann, desto wichtiger werden klare Regeln und konsequente Kontrolle.
Der Unterschied liegt im Umfang. Ein großes Framework bringt Lösungen für sehr viele mögliche Szenarien mit. Eine individuelle Anwendung benötigt vielleicht nur einen Teil davon. Bei direkter KI-gestützter Entwicklung können genau die Bausteine entstehen, die das konkrete System braucht.
Nicht weniger professionell – sondern gezielter.
Warum das für KMU wirtschaftlich interessant ist
Kleine und mittlere Unternehmen sind selten Durchschnitt.
Viele sind hoch spezialisiert und unterscheiden sich gerade durch ihre besonderen Abläufe vom Wettbewerb. Standardsoftware passt dann oft nur ungefähr. Doch ungefähr reicht bei einem Kernprozess nicht.
Die Alternative war bisher häufig unattraktiv:
- Standardsoftware einführen und den Betrieb an die Software anpassen,
- manuelle Lücken mit Excel, E-Mail und Mehrfacheingaben überbrücken,
- oder ein großes, entsprechend teures Individualsoftwareprojekt starten.
Coding-KI verschiebt diese Grenze.
Wenn wiederkehrende Entwicklungsarbeit schneller entsteht, kann ein größerer Anteil des Budgets in das fließen, was tatsächlich Wettbewerbsvorteile schafft:
- den richtigen Workflow,
- eine passende Bedienung,
- ein belastbares Datenmodell,
- klare Prüfungen und Berechtigungen,
- die besonderen Regeln des Unternehmens,
- sinnvolle Schnittstellen zu vorhandener Standardsoftware.
Ein Unternehmen benötigt dabei nicht zwingend sofort ein umfassendes neues System. Oft genügt zunächst ein klar abgegrenztes Modul: eine besondere Kalkulation, ein Prüf- oder Freigabeprozess, ein Kundenportal, ein Dokumentenworkflow oder eine Schnittstelle zwischen vorhandenen Inselsystemen.
Standardsoftware bleibt dort im Einsatz, wo sie gut passt. Individualsoftware ergänzt genau den Teil, der das Unternehmen besonders macht.
Der Maßanzug kann dadurch wirtschaftlich näher an die Konfektionsware rücken.
Die neue Rolle des Entwicklers
Wenn Coding-KI mehr Quellcode erzeugt, wird der Entwickler nicht überflüssig. Seine wertvollste Leistung verschiebt sich.
Der Engpass ist nicht mehr das Tippen möglichst vieler Codezeilen. Der Engpass ist die Fähigkeit, die richtige Anwendung zu entwerfen.
Der Entwickler wird stärker zum:
- Prozessanalysten,
- Datenmodellierer,
- Softwarearchitekten,
- Übersetzer zwischen Fachbereich und Technik,
- Verantwortlichen für Sicherheit und Qualität,
- professionellen Führer der Coding-KI.
Er muss Geschäftsprozesse und Ausnahmen verstehen, stabile Datenstrukturen entwerfen, technische Regeln setzen und das Ergebnis fachlich wie technisch beurteilen können.
Fundierte Kenntnisse in Webentwicklung, Datenbanken, Sicherheit und Softwarearchitektur bleiben unverzichtbar. Nicht mehr zwingend ist dagegen die Spezialisierung auf ein bestimmtes großes Anwendungsframework.
Die neue Form der Herstellerabhängigkeit
Natürlich erzeugt KI-native Entwicklung neue Fragen.
Was passiert, wenn das eingesetzte KI-Modell nicht mehr angeboten wird? Kann die Anwendung später von einem anderen Entwickler übernommen werden? Wird man von einem KI-Anbieter abhängig?
Diese Risiken müssen von Anfang an berücksichtigt werden.
Deshalb sollte KI-native Entwicklung modellunabhängig organisiert sein:
- vollständiger Quellcode im eigenen Repository,
- Git-Versionierung und nachvollziehbare Änderungen,
- klare Projekt- und Architekturregeln,
- dokumentierte Datenstrukturen,
- automatisierte Tests,
- dokumentierte Installation und Betrieb,
- möglichst wenig proprietäre Entwicklungsabhängigkeiten.
Das Ziel darf nicht lauten:
Diese Anwendung kann nur mit genau diesem KI-Modell weiterentwickelt werden.
Sondern:
Diese Anwendung ist so strukturiert und dokumentiert, dass andere KI-Systeme und bei Bedarf auch menschliche Entwickler sie übernehmen können.
KI-Modelle und Anbieter werden sich ändern. Der Quellcode und das Wissen über die Anwendung müssen deshalb beim Projekt bleiben.
Wann ein Framework weiterhin sinnvoll ist
Der Verzicht auf ein Framework ist keine Religion.
Ein großes Framework kann weiterhin die richtige Wahl sein, wenn:
- ein großes menschliches Entwicklerteam gemeinsam an der Anwendung arbeitet,
- der Auftraggeber einen bestimmten Technologiestandard verbindlich vorgibt,
- eine vorhandene IT-Abteilung genau dieses Framework betreibt und übernehmen soll,
- sehr viele externe Entwickler kurzfristig verfügbar sein müssen,
- eine riesige öffentliche Plattform mit hochkomplexer Oberfläche entsteht,
- vorhandene Komponenten einen wesentlichen Teil der Anforderungen bereits exakt erfüllen.
Auch eine Low-Code-Plattform kann richtig sein, wenn eine kleine, standardisierte Anwendung vollständig im jeweiligen Ökosystem bleiben soll und die langfristigen Lizenz- und Plattformkosten bewusst akzeptiert werden.
Entscheidend ist nicht, Frameworks grundsätzlich abzulehnen.
Entscheidend ist, sie nicht mehr automatisch zum Fundament jeder Neuentwicklung zu machen.
Sieben Fragen vor der Technologieentscheidung
Wer eine neue Unternehmenssoftware plant, sollte vor der Auswahl eines Frameworks oder einer Plattform sieben Fragen beantworten:
- Was ist an unserem Geschäftsprozess wirklich individuell?
- Welche vorhandene Standardsoftware soll bestehen bleiben und über Schnittstellen ergänzt werden?
- Wie viele Benutzer, Rollen und Integrationen benötigen wir tatsächlich?
- Welchen konkreten Nutzen liefert ein großes Framework für genau diese Anwendung?
- Welche Versions-, Lizenz- und Spezialistenabhängigkeiten entstehen dadurch?
- Kann ein direkter, KI-nativ entwickelter Aufbau denselben Bedarf einfacher abdecken?
- Wie stellen wir sicher, dass Quellcode, Tests, Dokumentation und Betriebswissen dauerhaft übertragbar bleiben?
Erst danach sollte die Technologieentscheidung fallen.
Manchmal lautet die Antwort weiterhin React, Angular, ASP.NET Core, Spring Boot oder eine Low-Code-Plattform.
Aber immer häufiger könnte die richtige Antwort lauten:
Keines davon muss das Fundament sein.
Fazit: Die Frameworkfrage neu stellen
Frameworks waren eine Antwort auf die begrenzte Geschwindigkeit menschlicher Softwareentwicklung.
Coding-KI verändert diese Voraussetzung.
Sie kann wiederkehrende Entwicklungsarbeit übernehmen, normalen Quellcode erzeugen und sich an die Regeln einer konkreten Anwendung anpassen. Dadurch wird eine neue Form der Individualentwicklung möglich: schneller als klassische manuelle Entwicklung, freier als ein starres Framework und unabhängiger als eine proprietäre Low-Code-Plattform.
Für spezialisierte KMU und Start-ups kann das wirtschaftlich entscheidend sein. Sie müssen sich nicht mehr automatisch zwischen ungefähr passender Standardsoftware und einem großen, teuren Individualprojekt entscheiden.
Die neue Software kann beim Geschäft beginnen – nicht beim Technologie-Stack.
Deshalb ist meine provokante These ernst gemeint:
Vergessen Sie zunächst die Frameworks. Modellieren Sie zuerst den Workflow, die Daten und die tatsächlichen Anforderungen. Prüfen Sie anschließend, ob Sie überhaupt noch ein großes Framework brauchen.
Wenn Sie gerade eine neue Anwendung planen, beschreiben Sie zunächst die erwarteten Benutzer, den wichtigsten Workflow und die vorhandenen Systeme. Genau daraus sollte die Architektur entstehen.
Weitere Informationen zur KI-nativen Entwicklung: https://enercape.com
Jörg Hartgen entwickelt seit rund 30 Jahren Software für reale Geschäftsprozesse. Er ist Geschäftsführer der ENERCAPE UG (haftungsbeschränkt) und führt Coding-KI in komplexen Softwareprojekten von der Prozess- und Datenmodellierung bis zur technischen Umsetzung.