KI-Risiken , die man als Entwickler und Entscheider kennen sollte / AI risks every developer and decision maker should know

In klassischen Transformer-Modellen steigt der Rechen- und Speicherbedarf (über den sogenannten Self-Attention-Mechanismus) nicht linear , sondern quadratisch mit der Länge des Kontexts.

Wenn ein Entwickler ein komplettes Softwareprojekt in den Kontext lädt und über viele Runden hinweg iteriert , wird jede einzelne nachfolgende Anfrage überproportional teurer.

Das "Lost in the Middle"-Problem bei großen Kontextfenstern

Selbst wenn das Kontextfenster moderner Modelle theoretisch groß genug ist und man die hohen Token-Kosten bezahlt , sinkt die Aufmerksamkeit der KI für Informationen in der Mitte großer Datenmengen massiv ab (bekannt als "Lost in the Middle"-Effekt).

Man kann also nicht einfach ein ganzes Softwareprojekt in den Kontext werfen und erwarten , dass die KI alles zuverlässig berücksichtigt.

Das Modell fokussiert sich primär auf den Anfang und das Ende des Prompts , übersieht dabei bestehende Hilfsklassen , Schnittstellen oder Geschäftslogik in der Mitte des Kontexts und generiert genau dadurch ungewollte Redundanzen.

Agentische Workflows und Reasoning-Modelle

Moderne KI-Systeme für komplexe Entwicklungsprojekte antworten nicht mehr nur einmalig auf einen Prompt.

Sie planen , schreiben Code , führen Tests aus , lesen Fehlermeldungen und korrigieren sich selbst in Schleifen.

Eine einzige komplexe Aufgabe eines Entwicklers kann im Hintergrund Hunderte interne Modellaufrufe und Millionen von Tokens auslösen.

⚠️Wegfall der Quersubventionierung

Bisher haben KI-Anbieter ihre Marktanteile durch Risikokapital erkauft und gehofft , dass viele Gelegenheitssurfer die wenigen Power-User quersubventionieren.

Es ist ein Paradoxon:

Diese Rechnung funktioniert durch wachsende Beliebtheit der Systeme nicht mehr , d.h. wenn ein einzelner Power-User bis zu 14.000 $ Kosten verursacht , aber maximal 500 $ pro Monat zahlt.

Selbst Hunderte 20-$-Abos bei den KI-Anbietern können einen einzigen solchen Intensivnutzer kaum ausgleichen!

Wahrscheinliche Konsequenzen für die nächsten 3 Jahre

OpenAI (ChatGPT) und Anthropic wollen beispielsweise börsennotierte Unternehmen werden - Initial public offering (IPO) incoming:

Harte Kontingente und Pay-as-you-go

Echte Flatrates für Spitzenmodelle werden verschwinden oder auf sehr kleine Kontingente gedrosselt.

Wer komplexe Projekte umsetzt, wird direkt nach Token-Verbrauch (API-Preise) oder über extrem teure Enterprise-Verträge abrechnen müssen.

Dynamisches Routing und Drosselung

Anbieter leiten Anfragen im Hintergrund bereits auf kleinere , billigere Modelle um , sobald ein Nutzer sein unsichtbares Tagesbudget überschreitet.

Dies ist schon heute teilweise Praxis , auch wenn es viele (sogar Entwickler) nicht wahrhaben wollen!

Es gibt genügend Berichte von KI-Anwendern , die das sogar verifiziert haben und teils für dieselben Aufgaben bei unterschiedlichen Ausführungstagen massiv schwankende Qualitätsergebnisse erzielten.

Überlastungen und Ausfälle

Da der Ausbau von Rechenzentren , spezialisierten Chips und vor allem der lokalen Stromnetze physischen Grenzen unterliegt , führen Lastspitzen zwangsläufig zu Rate-Limits (Fehlermeldungen wegen zu vieler Anfragen) , hoher Latenz oder zeitweisen Komplettausfällen der Dienste.

Weitere mögliche Risiken

Es wurden in der vorherigen Auflistung und Einschätzung noch nicht einmal grundlegende Risiken wie externe Schocks (Anschläge , Kriege...) berücksichtigt!

Alle diese Faktoren sind unzweifelhaft mögliche weitere Gründe , warum die KI-Funktionalität im schlimmsten Fall nicht nur eingeschränkt , sondern sogar auch einmal (vermutlich nur zeitweise) komplett ausfallen könnte.

⚠️Quellcode-Qualität

Die AI/KI-Quellcode-Qualität ist systembedingt oft "monolithisch" und in großen Projekten ist dringend zur Vorsicht zu raten - hier muss ein menschlicher Entwickler "Chef der Architektur" bleiben!

Code , den die AI/KI-Systeme standardmäßig erzeugen , ist nur dann von der Architektur modern und austauschbar , wenn man die AI/KI dazu zwingt!

Hier gibt es eindeutig massive Risiken - es wird vermehrt zu "Back to Spaghetti Code"-Szenarien kommen - vor allem durch viele "Möchtegern"-Entwickler , die nie richtig Codieren gelernt haben! Nennen wir diese einfach mal so 😁.

Es muss ein "Horror-Szenario" angesprochen werden , welches wir leider in der Praxis schon festgestellt haben:

Der "Möchtegern"-Entwickler ist irgendwann nicht mehr da und/oder hat keine Lust mehr und/oder blickt halt selber nicht mehr durch.

Eine KI auf das gesamte Projekt "loszulassen" und die schlechte Architektur zu bereinigen , ist nicht bezahlbar oder selbst die KI ist überfordert!

Konsequenz: man versucht das dann "echten" Entwicklern "aufs Auge zu drücken" - mit dem "lockeren" Hinweis:

Muss in drei Stunden fertig sein - Du kannst ja KI nutzen!

Das ist dann natürlich der Gipfel der "Pervertierung" des Nutzens der AI/KI-Folgen und der eigentlichen Grundidee der aktuellen KI-Systeme!

Warum "KI repariert KI-Spaghetti-Code" auch technisch scheitert

Ein sauberes Refactoring erfordert zwingend das Verstehen der impliziten Geschäftslogik.

Wenn aber schon der ursprüngliche Code ohne saubere Architektur "zusammenkopiert" wurde , fehlt im Projekt jede verlässliche Struktur (Single Source of Truth).

Versucht eine KI nun , dieses gewachsene Konstrukt im Nachhinein aufzuräumen , kann sie nicht zwischen gewollter Fachlogik (wichtigen Edge Cases) und bloßen Programmierfehlern des "Möchtegern"-Entwicklers unterscheiden.

Da in solchen Projekten fast immer auch sinnvolle Unit-Tests als Sicherheitsnetz fehlen , halluziniert die KI beim Refactoring neue Zusammenhänge , löscht vermeintlich überflüssige Sonderfälle oder bricht sogar unbemerkt bestehende Funktionalitäten.

Hauptgründe , warum die AI/KI-Systeme so vorgehen

1. Token-Limits und RLHF (Reinforcement Learning from Human Feedback)

Sprachmodelle werden im Training oft darauf optimiert , präzise, direkte und sofort lauffähige Antworten zu geben.

Da jedes generierte Token Rechenleistung (und damit Geld sowie Zeit) kostet , haben Modelle eine Art eingebauten Drang zur Kompaktheit.

Wenn eine KI für eine einfache Frage unaufgefordert drei Interfaces , zwei Implementierungen, eine Factory und den Code für den Dependency-Injection-Container generiert , "explodiert" die Token-Anzahl.

Zudem "beschweren" sich viele Durchschnittsnutzer (erneut , nennen wir diese mal "Möchtegern"-Entwickler 😁) im Feedback-Prozess , wenn sie statt einer schnellen Lösung plötzlich fünf verschiedene Klassen-Fragmente erhalten , die sie erst mühsam zusammenkopieren müssen.

2. Das "Copy-and-Paste"-Paradigma (Time-to-Run)

Eine KI geht standardmäßig davon aus, dass der Nutzer den generierten Code direkt in eine einzelne Datei oder ein Test-Skript kopieren und sofort ausführen möchte.

Monolithischer Code hat den Vorteil , dass er in sich geschlossen (self-contained) ist.

Sobald Abstraktionsebenen wie Interfaces und Dependency Injection hinzukommen , verteilt sich die Logik im echten Leben auf mehrere Dateien und erfordert oft zusätzliche Konfigurationen in der Startdatei der Anwendung.

Ohne das genaue Projekt-Setup des Nutzers zu kennen , wählt die KI den Weg des geringsten Widerstands.

3. Beschränkung durch die Trainingsdaten - das übersehen fast alle , die AI/KI-Systeme bewerten!

Ein gigantischer Teil der Trainingsdaten von Sprachmodellen stammt von Plattformen wie Stack Overflow , aus Tutorials , Blogs oder aus kleineren GitHub-Skripten.

In solchen Quellen wird fast immer das konkrete Problem isoliert und so kurz wie möglich dargestellt (Minimal Reproducible Example).

Komplexe Enterprise-Architekturen , bei denen konsequent nach SOLID-Prinzipien , mit sauberer Dependency Injection und strikter Trennung von Verantwortlichkeiten (Separation of Concerns) gearbeitet wird , sind in kurzen Frage-Antwort-Foren stark unterrepräsentiert.

Die KI reproduziert also den typischen "Tutorial-Stil".

4. Fehlender Kontext über die Gesamtarchitektur

Um sinnvolle Interfaces und Abhängigkeiten zu entwerfen , muss man wissen, welche Teile der Software sich in Zukunft wahrscheinlich ändern werden , wie der Lebenszyklus der Objekte aussieht (Singleton, Transient, Scoped) und welche Komponenten für Unit-Tests gemockt werden müssen.

Da der KI bei einem einzelnen Prompt dieser architektonische Gesamtkontext fehlt , vermeidet sie spekulative Abstraktionen (ganz im Sinne des YAGNI-Prinzips: "You Ain't Gonna Need It") und liefert lieber die direkte Implementierung.

Fazit / Ausblick in die Zukunft

In kleineren Projekten und für einzelne Problemstellungen KI einzusetzen , ist nicht nur okay , sondern wettbewerbstechnisch unbedingt nötig.

In speziellen Feldern , wie beispielsweise unserer ERP-Praxis wird aber dann (Kunde kommt vom "Hölzchen aufs Stöckchen") ganz schnell über die Zeit ein undurchsichtiges "Gewusel" an Code daraus , wenn keine "echten" Entwickler am Werk sind , die kein gutes Architektur-Muster beherrschen.

Es entsteht Code mit Redundanzen bei teilweise denselben Parametern etc.

Berücksichtigt man die kommenden massiven Preiserhöhungen bei KI-Systemen (es wird kommen!) , die möglichen Qualitätsschwankungen und - im schlimmsten Falle - Ausfälle von zahlreichen KI-Systemen , dann ergeben massive Probleme.

Diese Probleme kann man durch einen intelligenten Einsatz von KI im Vorfeld massiv minimieren!

English

AI Risks Every Developer and Decision Maker Should Know , especially in the ERP market

Quadratic computational complexity with growing context

In classic Transformer models , the computational and memory requirements (via the so-called self-attention mechanism) do not increase linearly , but quadratically with the length of the context.

When a developer loads an entire software project into the context and iterates over many rounds , each subsequent request becomes disproportionately more expensive.

The "Lost in the Middle" problem with large context windows

Even if the context window of modern models is theoretically large enough and one pays the high token costs , the AI's attention to information in the middle of large amounts of data drops massively (known as the "Lost in the Middle" effect).

Therefore , one cannot simply throw an entire software project into the context and expect the AI to reliably take everything into account.

The model focuses primarily on the beginning and the end of the prompt , overlooking existing helper classes , interfaces , or business logic in the middle of the context , and thereby generates unwanted redundancies.

Agentic workflows and reasoning models

Modern AI systems for complex development projects no longer respond just once to a prompt.

They plan , write code , execute tests , read error messages , and correct themselves in loops.

A single complex task from a developer can trigger hundreds of internal model calls and millions of tokens in the background.

⚠️Elimination of cross-subsidisation

Previously , AI providers bought their market shares through venture capital and hoped that many casual users would cross-subsidise the few power users.

It is a paradox:

Due to the growing popularity of the systems, this calculation no longer works, i.e. when a single power user causes up to $14,000 in cost s, but pays a maximum of $500 per month.

Even hundreds of $20 subscriptions with the AI providers can hardly compensate for a single such intensive user!

Probable consequences for the next 3 years

OpenAI (ChatGPT) and Anthropic , for example , want to become publicly listed companies - Initial Public Offering (IPO) incoming:

Hard quotas and pay-as-you-go

True flat rates for top models will disappear or be throttled to very small quotas.

Anyone implementing complex projects will have to bill directly according to token consumption (API prices) or via extremely expensive enterprise contracts.

Dynamic routing and throttling

Providers are already redirecting requests in the background to smaller, cheaper models as soon as a user exceeds their invisible daily budget.

This is already partially practised today , even if many (including developers) do not want to admit it!

There are plenty of reports from AI users who have even verified this and sometimes achieved massively fluctuating quality results for the exact same tasks on different execution days.

Overloads and outages

Since the expansion of data centres , specialised chips , and above all local power grids is subject to physical limits , peak loads inevitably lead to rate limits (error messages due to too many requests) , high latency , or temporary complete outages of the services.

Further potential risks

In the previous list and assessment , fundamental risks such as external shocks (attacks, wars...) were not even taken into account!

All of these factors are undoubtably potential further reasons why , in the worst-case scenario , AI functionality might not only be restricted , but could at some point even fail completely (for a certain time at least).

⚠️Quality of the source code

Source code quality is often "monolithic" and urgent caution is advised in large projects - here , a human developer must remain "head of architecture"!

Code that the AI systems generate by default is only modern and interchangeable in terms of architecture if you force the AI to make it so!

There are clearly massive risks here - "back to spaghetti code" scenarios will increasingly occur - especially due to many "wannabe" developers who never learned to code properly! Let's call them "wannabe" developers - for the sake of the argument 😁.

Let's address a "Horror scenario" , which we unfortunately already encountered in your line of work:

The above-mentioned "wannabe" developer is eventually no longer there and/or no longer feels like it and/or simply loses track themselves.

"Unleashing" an AI on the entire project to clean up the poor architecture is suddenly unaffordable.

Consequence: People then try to palm this off onto "real" developers - with the "casual" remark:

Must be finished in three hours - after all, you can use AI!

That is , of course , the pinnacle of "perverting" the benefits and the whole principle of current AI!

Why "AI repairs AI spaghetti code" also fails technically

A clean refactoring strictly requires understanding the implicit business logic.

However , if the original code was already copied together without a clean architecture , the project lacks any reliable structure (Single Source of Truth).

If an AI now tries to clean up this organically grown construct retrospectively , it cannot distinguish between intended domain logic (important edge cases) and mere programming errors made by the "wannabe" developer.

Since meaningful unit tests as a safety net are almost always missing in such projects as well , the AI hallucinates new connections during refactoring , deletes supposedly superfluous special cases , or even breaks existing functionalities unnoticed.

Main reasons why the AI systems proceed in this way

1. Token limits and RLHF (Reinforcement Learning from Human Feedback)

During training , language models are often optimised to give concise , direct , and immediately executable answers.

Because every generated token costs computing power (and thus money and time) , models have a kind of built-in urge for compactness.

If an AI generates three interfaces , two implementations , a factory , and the code for the dependency injection container unprompted for a simple question , the token count "explodes".

In addition, many average users (again , let's call those "wannabe" developers for the sake of the argument 😁) "complain" during the feedback process when , instead of a quick solution , they suddenly receive five different class fragments that they first have to laboriously copy together.

2. The "copy-and-paste" paradigm (Time-to-Run)

By default , an AI assumes that the user wants to copy the generated code directly into a single file or test script and execute it immediately.

Monolithic code has the advantage of being self-contained.

As soon as abstraction layers such as interfaces and dependency injection are added, the logic in real life is distributed across multiple files and often requires additional configuration in the application's startup file.

Without knowing the exact project setup of the user , the AI chooses the path of least resistance.

3. Limitation by training data - almost everyone evaluating AI systems overlooks this!

A gigantic proportion of the training data for language models comes from platforms like Stack Overflow , tutorials , blogs , or smaller GitHub scripts.

In such sources , the specific problem is almost always isolated and presented as briefly as possible (Minimal Reproducible Example).

Complex enterprise architectures that consistently follow SOLID principles , clean dependency injection , and strict separation of concerns are heavily underrepresented in short Q&A forums.

Thus , the AI reproduces the typical "tutorial style".

4. Lack of context regarding the overall architecture

To design meaningful interfaces and dependencies , one must know which parts of the software are likely to change in the future , what the lifecycle of the objects looks like (Singleton , Transient , Scoped) , and which components need to be mocked for unit tests.

Because the AI lacks this overall architectural context in a single prompt , it avoids speculative abstractions (very much in the spirit of the YAGNI principle: "You Ain't Gonna Need It") and prefers to deliver the direct implementation.

Conclusion / Outlook for the future

Using AI in smaller projects and for individual problems is not only okay , but absolutely necessary to remain competitive.

However , in highly specialised fields , such as our ERP practice for example (where the client constantly digresses from one minor detail to the next) , it very quickly turns into an opaque "tangle" of code over time if no "real" developers who master good architectural patterns are at work.

The result is code with redundancies, sometimes with the exact same parameters , etc.

If one takes into account the upcoming massive price increases for AI systems - mark our words - it will happen - the possible fluctuations in quality , and - in the worst case - outages of numerous AI systems , massive problems will arise.

These problems can be massively minimised in advance through the intelligent use of AI!

OFFICIUM INSERVIO IT