AI vs. klassische Softwareentwicklung: Wann welcher Ansatz der richtige ist

„Sollten wir das mit AI bauen oder einfach klassische Software schreiben?“ taucht inzwischen in fast jedem Scoping-Call auf, meist weil AI zur naheliegenden ersten Idee geworden ist und nicht nur noch eine Option unter mehreren. Das ist in beide Richtungen ein Fehler: Klassische Software wird für Probleme vorschnell als altmodisch abgetan, die sie eigentlich besser löst, und AI wird für Probleme eingesetzt, bei denen ein deterministisches System günstiger, besser planbar und leichter zu warten wäre. Die richtige Antwort hängt vollständig von der Struktur des Problems ab, nicht davon, welcher Ansatz spannender zu bauen ist. Die Entscheidung zwischen AI und klassischer Softwareentwicklung gleich zu Beginn richtig zu treffen, spart später Budget und Nacharbeit.

Die Frage hinter der Frage

Wenn man die Formulierung wegnimmt, lautet die eigentliche Frage immer: Hat dieses Problem eine bekannte, regelbasierte Antwort, oder muss man unklare, mehrdeutige oder stark variierende Eingaben interpretieren, um zu einer brauchbaren Lösung zu kommen? Die Berechnung der Versandkosten anhand von Gewicht, Entfernung und einer Preistabelle hat eine bekannte Antwort — es gibt genau ein richtiges Ergebnis, und es ändert sich nicht je nachdem, wie die Eingabe formuliert ist. Die Einordnung einer offenen Kundenbeschwerde in die richtige Kategorie oder das Herausziehen der zentralen Vertragsbedingungen aus einem Dokument ohne feste Vorlage hat keinen einzigen deterministischen Weg von der Eingabe zur Ausgabe — dafür braucht es Beurteilung bei unklaren Fällen, genau die Art von Aufgabe, bei der klassische Software an ihre Grenzen stößt und AI-basierte Ansätze ihre Stärken haben.

Wann klassische Software eindeutig die richtige Wahl ist

Wenn sich die Logik im Voraus vollständig beschreiben lässt — wenn also ein Mensch jede Regel und jeden Zweig aufschreiben könnte, ohne irgendwo „nach Ermessen“ sagen zu müssen — ist klassische Software fast immer die bessere Wahl. Sie ist deterministisch, sodass dieselbe Eingabe immer dieselbe Ausgabe erzeugt, was bei allem, was mit Geld, Compliance oder später prüfbaren Berechnungen zu tun hat, enorm wichtig ist. Sie ist im Betrieb günstiger, weil keine Inference-Kosten pro Aufruf anfallen. Und sie ist leichter zu debuggen, weil sich eine falsche Ausgabe auf eine konkrete Logikstelle zurückführen lässt und nicht auf das interne Denken eines Modells. Pricing-Engines, Lagerberechnungen, Workflow-Routing auf Basis klarer Business-Regeln und die meisten operativen CRUD-Systeme fallen eindeutig in diese Kategorie, und eine AI-Schicht darüber zu legen erhöht in der Regel nur Kosten, Latenz und die Zahl möglicher Fehlerquellen, ohne echte zusätzliche Fähigkeiten zu schaffen.

Wann AI-basierte Ansätze ihre Komplexität verdienen

AI ist dann die richtige Wahl, wenn die Eingaben wirklich unstrukturiert sind oder die Aufgabe Generalisierung jenseits von Regeln verlangt, die sich im Voraus vollständig auflisten lassen. Informationen aus Dokumenten zu extrahieren, die keinem einheitlichen Format folgen, die Absicht hinter einer Kundenmeldung zu verstehen, die auf ein Dutzend verschiedene Arten formuliert sein kann, oder Muster in Daten zu erkennen, die zu komplex sind, um sie auf eine Regeltabelle zu reduzieren — all das sind Aufgaben, bei denen ein deterministisches System eine unpraktisch große Zahl von Sonderfällen bräuchte, um annähernd das zu leisten, was ein Modell von Haus aus kann. Der Kompromiss ist jedoch real: probabilistische Ausgaben, der Bedarf an Schwellenwerten für Sicherheit und menschlicher Eskalation bei unsicheren Fällen, laufendes Monitoring auf Drift und eine Kostenstruktur, die sich am Nutzungsvolumen statt an einer festen Wartungspauschale orientiert. AI ist hier das richtige Werkzeug, bringt aber operative Verpflichtungen mit, die klassische Software nicht hat.

Die hybride Realität: Die meisten realen Systeme sind beides

In der Praxis sind nur sehr wenige Produktionssysteme ausschließlich das eine oder das andere. Ein System zur Dokumentenerfassung nutzt typischerweise AI, um unstrukturierte Informationen aus einer eingehenden Datei zu extrahieren und zu interpretieren, und übergibt die extrahierten Daten dann an klassische, deterministische Logik, um sie zu validieren, weiterzuleiten und Datensätze zu aktualisieren — denn Validierung und Routing folgen meist klaren Regeln, auch wenn der Extraktionsschritt das nicht tut. Wenn man das als Architekturentscheidung versteht, die pro Feature einmal getroffen wird, statt als Alles-oder-nichts-Entscheidung für ein gesamtes System, entsteht in der Regel etwas, das sowohl zuverlässiger als auch günstiger im Betrieb ist, als wenn man standardmäßig beide Komponenten auf AI oder auf manuell programmierte Logik setzt.

Ein durchgerechnetes Beispiel der Aufteilung

Nimm einen Workflow für den Dokumenteneingang als Beispiel — er ist eine der klarsten Veranschaulichungen dafür, wo die Grenze meist verläuft. Das eingehende Dokument — ein Formular, ein Vertrag, ein eingescanter Antrag — kommt in genau dem Format an, das der Absender gewählt hat; und genau das ist die Art unstrukturierter Eingabe, die klassische Software nur schwer zuverlässig auslesen kann. Dieser Teil eignet sich hervorragend für einen KI-basierten Extraktionsschritt: das Dokument lesen, die relevanten Felder identifizieren und aus unstrukturierter Eingabe strukturierte Daten erzeugen. Doch sobald diese strukturierten Daten vorliegen, ist die Frage, was als Nächstes passiert — ist dieser Antrag vollständig, wird er an Team A oder Team B weitergeleitet, löst ein fehlendes Feld ein bestimmtes Follow-up aus — fast immer als klarer Regelkatalog ausdrückbar. Diesen Teil mit deterministischer Logik zu bauen, macht das System vorhersehbarer, leichter prüfbar und günstiger im Betrieb, als die KI-Komponente auch noch über die Weiterleitungsentscheidung entscheiden zu lassen. Die KI übernimmt den Teil, der das Interpretieren unordentlicher Eingaben erfordert; die klassische Software übernimmt den Teil, der eine bekannte, überprüfbare Antwort hat. Diese Trennung in die falsche Richtung zu ziehen — Regeln von Hand zu codieren, um unstrukturierte Dokumente zu parsen, oder ein Modell Deterministische Weiterleitungsentscheidungen treffen zu lassen, bei denen es keinen besonderen Vorteil hat — ist der Punkt, an dem viele dieser Projekte Zeit und Budget verlieren, ohne dass jemand genau merkt, warum.

Kosten- und Wartungsunterschiede, die im Pitch nicht sichtbar sind

Klassische Software hat einen einmaligen Entwicklungskostenblock und danach vergleichsweise konstante, gut planbare Wartungskosten — sie tut dasselbe, bis jemand sie bewusst verändert. KI-basierte Komponenten verursachen echte laufende Kosten, die mit der Nutzung steigen, müssen auf Fälle überwacht werden, in denen sich das Modellverhalten verschiebt oder verschlechtert, und brauchen jemanden mit Verantwortung, der Ausnahmen prüft und Schwellenwerte im Laufe der Zeit nachjustiert. Keines von beiden ist grundsätzlich teurer; die Kosten fallen nur auf unterschiedliche Weise und in unterschiedlichen Zeiträumen an. Eine Entscheidung, die die Wartungsseite ignoriert — nicht nur die Entwicklungsseite — wirkt deshalb oft ungefähr ein Jahr später falsch, ganz gleich, in welche Richtung sie ausfiel.

Ein einfacher Weg zur Entscheidung: KI vs klassische Softwareentwicklung

Ein nützlicher erster Test: Versuche, die tatsächlichen Regeln für die Aufgabe einmal auf Papier aufzuschreiben. Wenn das gelingt, ohne auf „und dann hier mit gesundem Menschenverstand entscheiden“ ausweichen zu müssen, wird klassische Software dir sehr wahrscheinlich besser dienen — sie ist vorhersehbarer, günstiger im Betrieb und später für andere leichter zu warten. Wenn du hängenbleibst, weil die Eingaben tatsächlich zu variabel sind oder weil das nötige Urteilsvermögen den eigentlichen Großteil der Arbeit ausmacht, dann ist das das Signal, dass ein KI-basierter Ansatz das richtige Problem löst. Die Anschlussfrage lautet dann, wie eng du den Bereich eingrenzen kannst, in dem die KI arbeitet, gegenüber dem Teil, in dem die deterministische Logik wieder übernimmt.

Es lohnt sich, diesen Test auf einzelne Schritte eines Workflows anzuwenden, nicht nur auf den Workflow als Ganzes, denn die meisten echten Projekte entpuppen sich bei genauerem Hinsehen als Mischung. Eine einzelne Anforderung, die sich wie eine Entscheidung anhört — „soll das KI oder klassische Software sein“ — besteht meist aus mehreren kleineren Entscheidungen, die zusammengefasst wurden. Wenn man von Anfang an so damit umgeht, vermeidet man sowohl Overengineering bei den deterministischen Teilen als auch Unterengineering bei den Teilen, die wirklich das Urteil eines Modells brauchen.

Wir bauen beides, und genau deshalb ist das eine Frage der Eingrenzung statt ein Verkaufsgespräch für nur einen Ansatz — unsere custom software development work und unsere AI development work (einschließlich agentic systems für Aufgaben, die handeln müssen und nicht nur interpretieren) liegen unter demselben Team, und die meisten echten Projekte greifen auf beides zurück. Wenn du dir nicht sicher bist, auf welcher Seite dieser Grenze dein Projekt liegt, ist der ASTACKRA Project Planner ein schneller Weg zu einer eingegrenzten Einschätzung, oder du kannst das Team direkt kontaktieren, um das konkrete Problem zu besprechen.