Zuerst nutzten sie ChatGPT, um Kosten zu sparen. Dann haben sie uns beauftragt, die technischen Schulden von AI zu beseitigen.

Philip Tihonovich

Mai 29, 2025 10 Minuten Lesezeit

Sie wären überrascht, wie viele Unternehmen dies inzwischen tun.

Wie aus Berichten aus der Branche hervorgeht, gibt es jetzt einen wachsenden spezialisierten Sektor für Ingenieure, die sich auf die Korrektur von AI-generierten Code-Fehlern konzentrieren.

Das Muster ist bemerkenswert einheitlich geworden. Unternehmen wenden sich an ChatGPT, um Migrationsskripte, Integrationen oder ganze Funktionen zu erstellen, in der Hoffnung, Zeit zu sparen und Kosten zu senken. Immerhin scheint die Technologie schnell und zugänglich zu sein.

Dann versagen die Systeme.

Und sie rufen uns an.

In letzter Zeit erhalten wir immer mehr dieser Anfragen. Dabei geht es nicht um die Auslieferung eines neuen Produkts, sondern darum, das Chaos zu beseitigen, das entstanden ist, nachdem jemand einem Sprachmodell mit seinem Produktionscode vertraut hat.

Inzwischen sieht es so aus, als ob es sich um eine eigene Nischenindustrie handelt. Die Behebung von durch AI verursachten Fehlern ist jetzt eine kostenpflichtige Dienstleistung. Und in manchen Fällen ist sie sehr teuer.

Der GitClear-Bericht 2024 bestätigt, was wir bei unseren Kunden festgestellt haben: AI-Codierungstools beschleunigen die Bereitstellung, führen aber auch zu Doppelarbeit, verringern die Wiederverwendung und erhöhen die langfristigen Wartungskosten.

In einem Fall kam ein Kunde zu uns, nachdem bei einer mit AI durchgeführten Migration wichtige Kundendaten verloren gegangen waren. Wir verbrachten 30 Stunden, um die verlorenen Daten wiederherzustellen, die Logik von Grund auf neu zu schreiben und die Pipeline zu bereinigen. Das Ironische daran ist, dass es billiger gewesen wäre, wenn ein erfahrener Entwickler es auf die altmodische Weise geschrieben hätte.

Wir wollen jedoch klarstellen, dass wir nicht "gegen AI" sind. Wir verwenden sie auch. Und sie ist im richtigen Kontext und mit den richtigen Leitplanken hilfreich. Was mich jedoch an der übermäßigen Verwendung von AI und ihren weit verbreiteten Auswirkungen frustriert - und wahrscheinlich auch Sie - ist das magische Denken. Die Vorstellung, dass ein Sprachmodell echte technische Arbeit ersetzen kann.

Das kann es nicht. Und wie das Sprichwort sagt: "Der Beweis liegt in der Suppe". Wenn Unternehmen so tun, als ob es nicht so wäre, bezahlen sie am Ende jemanden wie uns, um es zu bereinigen.

Wie sieht also eine dieser Säuberungsaktionen aus? Hier ist, was die AI-afficionados Ihnen nicht sagen, wenn es um verlorene Zeit und verschwendetes Geld geht.

So sieht eine typische Anfrage aus

Die Nachricht lautet in der Regel wie folgt:

"Hey, kannst du dir einen Microservice ansehen, den wir gebaut haben? Wir haben ChatGPT verwendet, um die erste Version zu erstellen. Wir haben sie ins Staging gepusht, und jetzt ist unsere RabbitMQ-Warteschlange komplett überflutet."

Es fängt immer klein an. Eine Aufgabe, die zu langweilig oder zeitaufwändig erschien. Etwas wie das Parsen einer CSV-Datei, das Umschreiben eines Cron-Jobs oder das Einrichten eines einfachen Webhooks. Also übergibt man die Aufgabe an ein Sprachmodell und hofft das Beste.

Aber die Sache ist die: Die Symptome treten viel später auf. Manchmal erst nach Tagen. Und wenn sie es tun, ist es selten offensichtlich, dass die Ursache ein von AI generierter Code war. Es sieht einfach so aus, als ob... etwas nicht stimmt.

"Man kann das architektonische Denken nicht an ein Sprachmodell auslagern. AI kann die Dinge beschleunigen, aber es braucht immer noch Ingenieure, um Systeme zu bauen, die unter Druck nicht zusammenbrechen."

Dmitry Nazarevich

Technischer Leiter

Nach einem Dutzend dieser Fälle zeichnen sich erste Muster ab:

Keine Tests. Überhaupt nicht. Nicht einmal eine Hallo-Welt-Behauptung. Nur roher, spekulativer Code, der nie richtig geübt wurde.
Kein Bewusstsein für Systemgrenzen. Wir haben ChatGPT-Skripte gesehen, die drei Microservices synchron abfragen, Timeouts ignorieren und die gesamte Aufrufkette beim ersten Fehler sprengen.
Missbräuchliche Verwendung von Transaktionen. Ein Kunde verwendete AI-generiertes SQL mit verschachtelten Transaktionen innerhalb eines Node.js-Dienstes mit Knex. Es funktionierte, bis es nicht mehr funktionierte, und die Hälfte der Schreibvorgänge schlug lautlos fehl.
Subtile Rennbedingungen. Besonders in Multithreading- oder Async-lastigen Codebasen. Die Art von Fehlern, die in der Entwicklung nicht auftauchen, aber die Produktion im großen Maßstab ruinieren.

Und wenn alles zusammenbricht, hinterlässt das AI natürlich keinen Kommentar, in dem es heißt: "Übrigens, ich habe hier geraten."

Das ist deine Sache.

Fall 1: Das Migrationsskript, das unbemerkt Kundendaten gelöscht hat

Dieser kam von einem schnell wachsenden Fintech-Unternehmen.

Sie waren dabei, eine neue Version ihres Kundendatenmodells einzuführen, wobei ein großes JSONB-Feld in Postgres in mehrere normalisierte Tabellen aufgeteilt wurde. Ziemlich normales Zeug. Aber angesichts der knappen Fristen und des Mangels an Mitarbeitern beschloss einer der Entwickler, die Dinge zu "beschleunigen", indem er ChatGPT bat, ein Migrationsskript zu erstellen.

Oberflächlich betrachtet sah es gut aus. Das Skript analysierte das JSON, extrahierte die Kontaktinformationen und fügte sie in eine neue user_contacts Tisch.

Also haben sie es durchgeführt.

Kein Probelauf. Kein Backup. Direkt ins Staging, das, wie sich herausstellte, die Daten über eine Replik mit der Produktion teilte.

Ein paar Stunden später erhielt der Kundendienst E-Mails. Die Nutzer erhielten keine Zahlungsbenachrichtigungen. Bei anderen fehlten Telefonnummern in ihren Profilen. Daraufhin riefen sie uns an.

Was schief gelaufen ist

Wir haben das Problem auf das Skript zurückgeführt. Es führte die grundlegende Extraktion durch, machte aber drei fatale Annahmen:

Es hat nicht gehandelt NULL Werte oder fehlende Schlüssel innerhalb der JSON-Struktur.
Es wurden partielle Datensätze ohne Überprüfung eingefügt.
Es verwendet ON CONFLICT DO NOTHING, so dass alle fehlgeschlagenen Einfügungen stillschweigend ignoriert wurden.

Ergebnis: über 18% der Kontaktdaten entweder verloren gegangen oder beschädigt worden ist. Keine Protokolle. Keine Fehlermeldungen. Nur stiller Datenverlust.

Was es brauchte, um die

Wir haben ein kleines Team damit beauftragt, das Durcheinander zu entwirren. Das haben wir getan:

Diagnose und Replikation (4 Stunden) Wir erstellten das Skript in einer Sandbox-Umgebung neu und führten es mit einem Snapshot der Datenbank aus. Auf diese Weise konnten wir das Problem bestätigen und genau zuordnen, was fehlte.
Forensische Datenprüfung (8 Stunden) Wir verglichen den defekten Zustand mit Backups, identifizierten alle Datensätze mit fehlenden oder unvollständigen Daten und glichen sie mit Ereignisprotokollen ab, um festzustellen, welche Einfügungen fehlgeschlagen sind und warum.
Neuschreiben der Migrationslogik (12 Stunden) Wir schrieben das gesamte Skript in Python neu, fügten eine vollständige Validierungslogik hinzu, bauten einen Rollback-Mechanismus und integrierten es in die CI-Pipeline des Kunden. Diesmal mit Tests und Unterstützung für Trockenübungen.
Manuelle Datenwiederherstellung (6 Stunden) Einige Datensätze konnten aus den Backups nicht wiederhergestellt werden. Wir zogen fehlende Felder aus externen Systemen (CRM- und E-Mail-Anbieter-APIs) und stellten den Rest manuell wieder her.

Gesamtzeit: 30 Ingenieurstunden

Zwei Ingenieure, drei Tage. Kosten für den Kunden: etwa $4,500 in service fees.

But the bigger hit came from customer fallout. Failed notifications led to missed payments and churn. The client told us they spent at least $10,000 on support tickets, SLA compensation, and goodwill credits over that one botched script.

The ironic thing is that a senior developer could’ve written the correct migration in maybe four hours. But the promise of AI speed ended up costing them two weeks of cleanup and reputation damage.

Wir reparieren, was ChatGPT kaputt gemacht hat - und bauen, was es nicht konnte.

Fall 2: Der API-Client, der Ratenbeschränkungen ignorierte und die Produktion beeinträchtigte

Dieser Fall stammt von einem Startup-Unternehmen, das eine Dokumentenmanagement-Plattform für Anwaltskanzleien entwickelt. Eine ihrer Hauptfunktionen war die Integration mit einem elektronischen Benachrichtigungsdienst der Regierung - eine REST-API eines Drittanbieters mit OAuth 2.0 und strenger Ratenbegrenzung: 50 Anfragen pro Minute, keine Ausnahmen.

Anstatt einen erfahrenen Backend-Entwickler mit der Integration zu beauftragen, beschloss jemand aus dem Team, einen "Prototyp" mit ChatGPT zu erstellen. Sie gaben die OpenAPI-Spezifikation ein, baten um einen Python-Client und erhielten ein sauber aussehendes Skript mit requests, wiederholungslogik mit tenacity, und Token-Aktualisierung.

Auf dem Papier sah es solide aus. Also haben sie es verschickt.

Was schief gelaufen ist

Zunächst schien alles in Ordnung zu sein. Der Client verarbeitete einzelne Anfragen korrekt, bestand die Authentifizierung und versuchte es sogar bei Fehlern erneut. Aber im realen Einsatz, insbesondere unter Last, begann die Plattform, sich unvorhersehbar zu verhalten.

Folgendes ist tatsächlich passiert:

Keine Beachtung der Tarifgrenzen. Der generierte Code las oder interpretierte nicht X-RateLimit-Remaining oder Retry-After Kopfzeilen. Es hat einfach weiter blind Anfragen gesendet.
Wiederholungen verschlimmerten die Situation. Als 429 Fehler zurückkamen, versuchte der Tenacity Decorator sie automatisch erneut. Kein Jitter. Keine Warteschlangen. Nur eine Flut von Folgeanfragen.
Der API-Anbieter hat ihre IP-Adresse vorübergehend gesperrt. 3 Stunden lang konnte niemand auf der Plattform Dokumente synchronisieren. Keine Protokolle, keine Warnungen. Einfach nur stiller Ausfall.

Das war keine Einzeleinrichtung. Es war ein Missverständnis darüber, wie sich Produktionssysteme verhalten. Und es ist ein großartiges Beispiel dafür, was LLMs nicht wissen; nicht weil sie kaputt sind, sondern weil sie kein Laufzeitbewusstsein haben.

Hören Sie auf, AI-generierten Code in prod zu patchen - bringen Sie uns ein, bevor er kaputt geht.

Wie wir das Problem behoben haben

Rückverfolgung und Isolierung des Fehlers (6 Stunden) Wir fügten Middleware hinzu, um den ausgehenden Datenverkehr zu prüfen, und bestätigten die Flut von Anfragen während der Spitzenlast. Außerdem haben wir den Fehler in Staging nachgestellt, um das auslösende Muster vollständig zu verstehen.
Neuaufbau des API-Clients (10 Stunden) Wir haben den Client neu geschrieben, indem wir httpx.AsyncClient, eine Semaphor-basierte Drosselung implementiert, ein exponentielles Backoff mit Jitter hinzugefügt und die Retry-After und Ratenbegrenzungs-Header.
Stresstest und Validierung (6 Stunden) Wir haben die reale Nutzung mit Tausenden von gleichzeitigen Anfragen mit Locust simuliert, die Raten-Drosselung in verschiedenen Burst-Szenarien getestet und null 429s bei anhaltender Last bestätigt.
Überwachung und Alarmierung hinzufügen (4 Stunden) Wir richteten benutzerdefinierte Prometheus-Metriken ein, um die API-Nutzung pro Minute zu verfolgen, und fügten Warnmeldungen hinzu, um das Team zu benachrichtigen, wenn es sich einem Schwellenwert näherte.

Gesamtzeit: 26 Stunden

Zwei Ingenieure, verteilt auf zweieinhalb Tage. Kosten für den Kunden: etwa $3,900.

Das größere Problem ist, dass ihr größter Kunde - eine Anwaltskanzlei mit zeitkritischen Anträgen - aufgrund des Ausfalls zwei Zeitfenster für die Einreichung von Gerichtsanträgen verpasst hat. Der Kunde musste Schadensbegrenzung betreiben und einen Rabatt anbieten, um den Kunden zu halten.

Alles nur, weil ein Sprachmodell den Unterschied zwischen "funktionierendem Code" und "produktionsreifem Code" nicht verstanden hat. Und einfach so wurde eine weitere Schicht von AI technischer Schuld still und leise zum Stapel hinzugefügt.

Warum das immer wieder passiert

The scary part isn’t that these things go wrong. It’s how predictable it’s all becoming.

Every one of these incidents follows the same pattern. A developer asks ChatGPT for a code snippet. It returns something that works just well enough not to throw errors. They wire it into the system, maybe clean it up a little, and ship it, assuming that if it compiles and runs, it must be safe.

But here’s the catch: Large language models don’t know your system.
They don’t know how your services interact.
They don’t know your latency budget, your deployment pipeline, your observability setup, or your production traffic patterns.

They generate the most likely-looking code based on patterns in their training data. That’s all. There’s no awareness. No guarantees. No intuition for system design.

And the output often reflects that:

Code, der einmal funktioniert, aber unter Last versagt
Keine defensive Programmierung, keine Ausfallsicherheiten
Unzureichendes Verständnis für reale Beschränkungen wie Ratenbegrenzungen, Zeitüberschreitungen oder eventuelle Konsistenz
Absolut kein Sinn für architektonische Absichten

Noch schlimmer ist, dass der Code korrekt aussieht. Er ist syntaktisch sauber. Er besteht Linters. Er könnte sogar von einem einfachen Test abgedeckt werden. Aber es fehlt das Einzige, was wirklich wichtig ist: der Kontext.

Deshalb tauchen diese Fehler auch nicht sofort auf. Sie warten auf den Einsatz am Freitagabend, auf hochfrequentierte Zeitfenster, auf seltene Sonderfälle. Das ist die Natur der technischen Schulden von AI - sie sind unsichtbar, bis sie etwas Kritisches kaputt machen.

Wenn AI tatsächlich hilft

As we mentioned earlier, we use AI too. Pretty much every engineer on our team has a Copilot-like setup running locally. It’s fast, helpful, and honestly, a great way to skip the boring parts.

But here’s the difference: nothing makes it into the main branch without going through a senior engineer, and in most cases, a CI pipeline that knows what to look for.

LLMs are great at:

Gerüstbausteine für neue Dienste oder API-Endpunkte,
Generierung der Testabdeckung für bestehende Logik,
Hilfe beim wiederholten Refactoring großer Codebasen,
die Übersetzung einfacher Shell-Skripte in Infrastruktur-als-Code-Vorlagen,
oder sogar den Vergleich von algorithmischen Ansätzen, die wir bereits kennen.

Was sie sind nicht gut im Design ist. Oder Kontext. Oder sichere Standardeinstellungen.

Deshalb haben wir unsere Arbeitsabläufe so gestaltet, dass wir LLM-Ausgaben als Vorschläge und nicht als Quelle der Wahrheit behandeln. So sieht das in der Praxis aus:

Wir markieren alle von AI erzeugten Commits, damit sie leicht zu verfolgen und zu überprüfen sind.
Unsere Editoren verfügen über Inline-Aufforderungen, aber mit erzwungenen Pre-Commit-Hooks, die alles ohne Tests oder Dokumentation blockieren.
Unsere KI enthält Regeln für die statische Analyse, die unsichere Muster erkennen lassen, die wir schon bei LLMs gesehen haben: Dinge wie ungeschützte Wiederholungsversuche, ungesicherte Timeouts, naives JSON-Parsing oder unsichere SQL-Behandlung.
Jede Pull-Anfrage mit LLM-generiertem Code durchläuft eine obligatorische menschliche Überprüfung, in der Regel durch eine erfahrene Person, die die Domänenlogik und die Risikooberfläche versteht.

Richtig eingesetzt, ist es eine Zeitersparnis. Blindlings eingesetzt, ist es eine Zeitbombe.

Was wir den CTOs empfehlen

We’re not here to tell you to ban AI tools. That ship has sailed.

But giving a language model commit access? That’s just asking for trouble.

Here’s what we recommend instead:

1. LLMs wie Werkzeuge behandeln, nicht wie Ingenieure

Lassen Sie sie bei sich wiederholendem Code helfen. Lassen Sie sie Lösungen vorschlagen. Aber ihnen keine kritischen Entscheidungen anvertrauen. Jeder von AI erzeugte Code sollte ausnahmslos von einem erfahrenen Ingenieur überprüft werden.

2. LLM-generierten Code nachvollziehbar machen

Ob es sich um Commit-Tags, Metadaten oder Kommentare im Code handelt, deutlich zu machen, welche Teile von AI stammen. Das erleichtert später die Prüfung, die Fehlersuche und das Verständnis des Risikoprofils.

3. Definieren Sie eine Erzeugungspolitik

Entscheiden Sie im Team, wo die Verwendung von LLMs akzeptabel ist und wo nicht. Boilerplate? Sicher. Autorenströme? Vielleicht. Transaktionssysteme? Auf jeden Fall nicht ohne Überprüfung. Machen Sie die Politik explizit und Teil Ihrer technischen Standards.

4. Überwachung auf DevOps-Ebene hinzufügen

Wenn Sie AI-generierten Code in die Produktion einfließen lassen, müssen Sie davon ausgehen, dass irgendwann etwas kaputtgehen wird. Fügen Sie synthetische Prüfungen hinzu. Ratenbegrenzungsüberwachungen. Verfolgung von Abhängigkeiten. Das Unsichtbare sichtbar machen, besonders wenn der ursprüngliche Autor kein Mensch ist.

5. Aufbau für Wiederherstellbarkeit

Die größten AI-bedingten Ausfälle, die wir erlebt haben, waren nicht auf "schlechten" Code zurückzuführen. Sie kamen von stillen Fehlern - fehlende Daten, unterbrochene Warteschlangen, Wiederholungsstürme - die stundenlang unentdeckt blieben. Investieren Sie in Beobachtbarkeit, Fallback-Logik und Rollbacks. Vor allem, wenn Sie ChatGPT die Migrationen schreiben lassen.

Kurz gesagt: AI kann Ihrem Team Zeit sparen, aber es kann keine Verantwortung übernehmen.

Das ist immer noch eine menschliche Aufgabe.

Abschließende Gedanken: AI ≠ Software-Ingenieure

AI can help you move faster. But it can’t think for you.

It doesn’t understand your architecture. It doesn’t know what “done” means in your context. And it definitely doesn’t care if your data pipeline silently breaks on a Friday night.

That’s why, as CTOs, we need to stay focused on system resilience, not just speed.

It’s tempting to let AI handle the boring parts. And sometimes that’s fine. But every shortcut comes with a tradeoff. When AI-generated code slips through unchecked, it often becomes AI technical debt. The kind you don’t see until your ops team is firefighting in production.

If you’ve already run into that wall, you’re not alone. We’ve helped teams recover from everything from broken migrations to API disasters. We don’t just refactor code. We help refactor the thinking behind it.

Because in the end, that’s what actually makes systems reliable.

Philip Tikhanovich

Leiter der Abteilung Python, Big Data, ML/DS/AI

Philip bringt einen scharfen Blick für alles, was mit Daten und AI zu tun hat. Er ist derjenige, der frühzeitig die richtigen Fragen stellt, eine starke technische Vision entwickelt und dafür sorgt, dass wir nicht nur intelligente Systeme bauen, sondern die richtigen, die einen echten geschäftlichen Nutzen bringen.

Mehr erfahren

Inhaltsübersicht

Kontakt

Buchen Sie einen Anruf oder füllen Sie das untenstehende Formular aus und wir werden uns mit Ihnen in Verbindung setzen, sobald wir Ihre Anfrage bearbeitet haben.

Name

Unternehmen

E-Mail

Telefon

Nachricht

Senden Sie uns eine Sprachnachricht

Fügen Sie die Dokumente bei

Datei hochladen

Sie können 1 Datei mit bis zu 2 MB anhängen. Gültige Dateiformate: pdf, jpg, jpeg, png.

Durch Klicken auf Senden erklären Sie sich damit einverstanden, dass Innowise Ihre personenbezogenen Daten gemäß unserer Datenschutzrichtlinie verarbeitet, um Ihnen relevante Informationen zukommen zu lassen. Mit der Angabe Ihrer Telefonnummer erklären Sie sich damit einverstanden, dass wir Sie per Sprachanruf, SMS und Messaging-Apps kontaktieren. Es können Gebühren für Anrufe, Nachrichten und Datenübertragung anfallen.

Sie können uns auch kontaktieren
über contact@innowise.com

Wie geht es weiter?

Sobald wir Ihre Anfrage erhalten und bearbeitet haben, werden wir uns mit Ihnen in Verbindung setzen, um Ihre und unterzeichnen ein NDA, um die Vertraulichkeit zu gewährleisten.

Nachdem wir Ihre Wünsche, Bedürfnisse und Erwartungen geprüft haben, erstellt unser Team ein Projekt Projektvorschlag mit Arbeitsumfang, Teamgröße, Zeit- und Kostenvoranschlägen.

Wir vereinbaren einen Termin mit Ihnen, um das Angebot zu besprechen und die Details festzulegen.

Abschließend unterzeichnen wir einen Vertrag und beginnen sofort mit der Arbeit an Ihrem Projekt.