ERP mit KI-Coding-Agenten entwickeln: Lohnt sich Eigenentwicklung — und bleibt der Code wartbar?

Wer im deutschen Netz nach „ERP-Eigenentwicklung” sucht, bekommt überwiegend eine Antwort: Lass es. Selbst bauen lohne sich nur für Großkonzerne mit eigener IT-Abteilung, der Rest solle Standard kaufen. Diese Regel war lange richtig — sie stammt aber aus der Zeit, bevor Software mit KI-Coding-Agenten gebaut wurde. Die Kostenannahmen, auf denen sie beruht, sind nicht mehr aktuell.

Damit wird die Frage interessant statt rhetorisch: Verschieben Coding-Agenten die Rechnung so weit, dass sich maßgeschneidertes ERP auch für den Mittelstand lohnt — und bleibt der so entstandene Code wartbar, oder handelt man sich nur eine neue Art von Altlast ein? Beides ehrlich beantwortet.

Die alte Rechnung — und warum sie kippt

Der klassische Einwand gegen Eigenentwicklung hatte drei Teile: zu teuer, zu langsam, zu riskant. Alle drei drehten sich um Aufwand. Maßgeschneiderte Software bedeutete Monate bis Jahre Entwicklungszeit, ein großes Team und das Risiko, am Ende auf Code zu sitzen, den niemand mehr durchschaut.

Genau dieser Aufwand sinkt. Im DORA State of AI-assisted Software Development 2025 nutzen 90 Prozent der Entwickler KI in der täglichen Arbeit, und — anders als noch 2024 — korreliert der KI-Einsatz inzwischen positiv mit der Liefergeschwindigkeit. Das ist keine Marketingzahl, sondern die größte branchenweite Erhebung dazu.

Bei uns sieht das konkret so aus: Unsere Multi-Tenant-SaaS-Plattform heysuma — 36 fachliche Domänen, fünf nativ integrierte KI-Agenten — entstand als Greenfield bis zur Version 1.0 in drei Monaten und ist mit demselben Workflow heute in wenigen Wochen replizierbar. Auch der lead-gen-agent, eine Multi-Agent-CLI mit Google ADK, ist produktiv im Einsatz. Was früher das abschreckende Monatelang-Projekt war, ist heute ein überschaubares Vorhaben. Damit wandert die Schwelle, ab der sich Maßgeschneidertes rechnet, spürbar nach unten — in den Mittelstand hinein.

Entscheidend ist dabei ein zweiter Hebel, der oft untergeht: Wiederverwendung. Wir fangen nicht bei jedem Projekt mit einem leeren Editor an, sondern bringen einen Baukasten erprobter Standard-Komponenten mit — Mandantenfähigkeit, Rechte, Datenmodelle, Integrationen, Agenten-Bausteine. Daraus wird ein zusammenhängendes System zusammengesetzt und nur dort erweitert, wo das Unternehmen anders ist. Das ist der Grund, warum heysuma heute in Wochen statt Monaten replizierbar ist — und warum ein eigenes System kein neuer Flickenteppich wird, sondern ein kohärentes Ganzes.

Der ehrliche Haken: schnell heißt nicht wartbar

Hier müsste ein Anbieter, der von Custom-Software lebt, aufhören. Wir nicht — denn die zweite Hälfte der Forschung ist genauso wichtig wie die erste, und wer sie verschweigt, verkauft eine Illusion.

Eine kontrollierte Studie von METR (Juli 2025) ließ erfahrene Open-Source-Entwickler reale Aufgaben mit und ohne KI bearbeiten. Das Ergebnis war kontraintuitiv: An ihren eigenen, reifen Codebasen waren sie mit KI 19 Prozent langsamer — obwohl sie vorher eine Beschleunigung von 24 Prozent erwartet hatten und im Nachhinein glaubten, 20 Prozent schneller gewesen zu sein. Die Wahrnehmung lag also komplett daneben. (Fairerweise: METR hält die konkrete Zahl für aktuelle Werkzeuge inzwischen für überholt — die Tools haben sich seither verbessert. Die Lehre über die Wahrnehmungslücke bleibt.)

Dazu kommt die Code-Qualität. GitClear analysierte über 211 Millionen Codezeilen und fand, dass im KI-Zeitalter messbar weniger sauber refaktoriert (verschobene Zeilen 25 Prozent → unter 10 Prozent) und deutlich mehr kopiert wird (geklonte Blöcke rund achtmal häufiger; Churn, also binnen zwei Wochen wieder revidierter Code, von 3,1 auf 5,7 Prozent). Das ist Korrelation, nicht Kausalität — aber ein klares Warnsignal. Und DORA bringt es 2025 auf den Punkt: KI ist ein Verstärker, kein Selbstläufer. Höhere KI-Adoption korreliert weiterhin mit Instabilität, und rund 30 Prozent der Entwickler vertrauen dem von KI erzeugten Code wenig.

Die nüchterne Zusammenfassung: Roher KI-Output ist schnell, aber nicht automatisch wartbar. Wer einen Coding-Agenten „mach mal ein ERP” sagen lässt und das Ergebnis ungeprüft in den Betrieb nimmt, baut sich genau die Altlast, vor der die alte Regel warnte — nur schneller.

Wie wartbarer Custom-ERP-Code wirklich entsteht

Der Unterschied zwischen „schnell gebaut” und „schnell und wartbar gebaut” ist kein Modell, sondern Methode. Es sind dieselben Engineering-Prinzipien, die wir im KI-Agenten-Bau anwenden — und die erklären, warum laut Gartner über 40 Prozent der Agenten-Projekte scheitern, fast nie am Modell, sondern am fehlenden Handwerk drumherum (die ehrliche Einordnung dazu):

• Senior-Architektur zuerst. Der Zuschnitt des Systems — Domänen, Grenzen, Datenflüsse — entsteht durch menschliche Architekten, nicht durch Zuruf an ein Modell. Die Coding-Agenten beschleunigen die Umsetzung innerhalb dieses Rahmens.
• Wiederverwendung statt Blankobau. Wir setzen erprobte Standard-Komponenten ein, statt jedes Mal neu zu bauen. Produktiv gehärteter Code ist nicht nur schneller verfügbar, sondern auch wartbarer als frisch generierter — und hält das Ergebnis als ein System zusammen, statt es zu zerstückeln.
• Typisierte Verträge statt Fließtext. Komponenten reichen sich Daten als typisierte Schemata weiter — jede Schnittstelle ist ein Vertrag mit definierten Feldern. Das macht Fehler isolierbar und einzeln testbar, statt sie im System verschwinden zu lassen.
• Deterministische Prüfung, wo es harte Regeln gibt. Eine Mengen-mal-Preis-Rechnung prüft Code, nicht ein Sprachmodell. Das Modell schlägt vor; die Regeln entscheiden.
• Tests, Review, Mensch in der Schleife. Generierter Code wird gelesen und getestet, nicht geglaubt. Unsichere Fälle werden eskaliert, nicht geraten.

Das ist der Grund, warum die METR-Wahrnehmungslücke uns nicht trifft: Wir verlassen uns nicht auf das Gefühl, schneller zu sein, sondern auf Tests und Review, die zeigen, ob der Code trägt. Coding-Agenten sind das Werkzeug, das die Umsetzung beschleunigt — der Architekt, der für Wartbarkeit sorgt, ist ein Mensch. Genau diese Arbeitsteilung macht den Unterschied zwischen einem beeindruckenden Prototyp und einem System, dem der Betrieb über Jahre traut.

Was das für die Make-or-Buy-Entscheidung heißt

Die Schwelle ist gesunken, nicht verschwunden. Für Commodity — Buchhaltung, Lohn, alles Standardisierte — bleibt Kaufen richtig; niemand sollte ein Hauptbuch neu erfinden. Für den Differenzierer — den Prozess, der euch vom Wettbewerb unterscheidet und den die Stange nicht abbildet — ist Eigenentwicklung heute eine realistische Option, wo sie es vor drei Jahren noch nicht war. Den vollständigen Entscheidungsrahmen dazu liefert unser Leitfaden zu individueller ERP-Software und das Make-or-Buy-Framework.

Der entscheidende Zusatz, den die meisten „lohnt sich nicht”-Artikel auslassen: Mit dem richtigen Engineering bekommt ihr nicht nur ein günstigeres, schnelleres System, sondern eines, das genau auf euren Betrieb zugeschnitten ist — on-premise möglich, ohne Abo und ohne Lizenz pro Nutzer. Und ihr seid nicht das Wartungsteam: Das ist unsere Aufgabe, nicht eure.

Häufige Fragen

Kann man ein ERP wirklich „mit KI” entwickeln lassen? Nicht im Sinne von „eine KI baut das ERP allein” — das wäre genau die Altlast-Falle. Sondern so, dass Senior-Architekten das System entwerfen und Coding-Agenten die Umsetzung beschleunigen. Das verkürzt die Entwicklungszeit von Monaten auf Wochen, ohne die Verantwortung an ein Modell abzugeben.

Wird KI-generierter Code nicht zur Wartungshölle? Roher Output kann das werden — Studien zeigen mehr Duplikate und weniger Refactoring im KI-Zeitalter (GitClear, 2025). Wartbarkeit entsteht durch typisierte Schnittstellen, Tests, Review und saubere Architektur. Der Code ist nur so wartbar wie die Disziplin, mit der er entsteht — und genau die ist unsere Aufgabe.

Macht KI Entwickler nicht ohnehin viel schneller? Im Schnitt ja, aber nicht überall: Eine METR-Studie (2025) fand erfahrene Entwickler an ihren eigenen Codebasen mit KI sogar 19 Prozent langsamer — und sie merkten es nicht. Die Lehre ist nicht „KI hilft nicht”, sondern: Auf das Bauchgefühl ist kein Verlass, auf Tests und Messung schon.

Lohnt sich Eigenentwicklung jetzt für jeden Mittelständler? Nein. Für Commodity bleibt Standard die richtige Wahl. Aber die Schwelle, ab der sich Maßgeschneidertes rechnet, ist durch KI-native Entwicklung deutlich gesunken — gerade für Prozesse, die einen Wettbewerbsvorteil tragen.

Fazit

Die Regel „Eigenentwicklung lohnt sich nicht” gehört aktualisiert, nicht abgeschafft. Coding-Agenten haben den Aufwand so weit gesenkt, dass maßgeschneidertes ERP für den Mittelstand erschwinglich und schnell geworden ist. Was sie nicht geändert haben, ist die Notwendigkeit echten Engineerings: Wartbarkeit kommt aus Architektur, Verträgen, Tests und Review — nicht aus dem Modell. Wer beides zusammenbringt, bekommt das Beste aus der neuen Welt: die Geschwindigkeit der Coding-Agenten und die Verlässlichkeit klassischer Software-Disziplin. Wer nur das erste nimmt, baut sich die alte Altlast in neu.

---

kitun ist eine AI-native Software-Manufaktur für den Mittelstand: Zwei Senior-Architekten und Coding-Agents bauen Custom Business-Software und ERP-Module — on-premise oder EU-gehostet, ohne Abo und ohne Lizenz pro Nutzer. Im 20-minütigen Erstgespräch klären wir ehrlich, ob und wie sich euer Fall lohnt.

→ Die Lösung im Überblick: Custom ERP mit kitun

→ Wie wir Verlässlichkeit bauen: Die Zukunft der AI Agents · Case: heysuma in 3 Monaten