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

5. August 2025 10 Minuten Lesezeit

Artikel mit AI zusammenfassen

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 an Dienstleistungsgebühren.

Der größere Schaden entstand jedoch durch die Kundenabwanderung. Fehlgeschlagene Benachrichtigungen führten zu verpassten Zahlungen und Abwanderung. Der Kunde sagte uns, er habe mindestens $10,000 für Support-Tickets, SLA-Entschädigungen und Goodwill-Gutschriften wegen dieses einen verpfuschten Skripts.

Das Ironische daran ist, dass ein erfahrener Entwickler die korrekte Migration in vielleicht vier Stunden hätte schreiben können. Aber das Versprechen von AI-Geschwindigkeit kostete sie am Ende zwei Wochen Aufräumarbeiten und Rufschädigung.

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

Das Beängstigende daran ist nicht, dass diese Dinge schief gehen. Es geht darum, wie vorhersehbar das alles wird.

Jeder dieser Vorfälle folgt dem gleichen Muster. Ein Entwickler fragt ChatGPT nach einem Codeschnipsel. Er bekommt etwas zurück, das gerade gut genug funktioniert, um keine Fehler zu verursachen. Sie binden es in das System ein, bereinigen es vielleicht ein wenig und versenden es in der Annahme, dass es sicher sein muss, wenn es kompiliert wird und läuft.

Aber hier ist der Haken an der Sache: Große Sprachmodelle kennen Ihr System nicht.
Sie wissen nicht, wie Ihre Dienste zusammenwirken.
Sie kennen weder Ihr Latenzbudget, noch Ihre Bereitstellungspipeline, Ihre Beobachtungseinstellungen oder Ihre Verkehrsmuster in der Produktion.

Sie erzeugen den am wahrscheinlichsten aussehenden Code auf der Grundlage von Mustern in ihren Trainingsdaten. Das ist alles. Es gibt kein Bewusstsein. Keine Garantien. Keine Intuition für den Systementwurf.

Und das spiegelt sich oft im Ergebnis wider:

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

Wie wir bereits erwähnt haben, verwenden wir auch AI. So gut wie jeder Ingenieur in unserem Team hat eine Copilot-ähnliche Einrichtung lokal laufen. Es ist schnell, hilfreich und ehrlich gesagt eine tolle Möglichkeit, die langweiligen Teile zu überspringen.

Der Unterschied ist jedoch, dass nichts in die Hauptniederlassung gelangt, ohne einen leitenden Ingenieur und in den meisten Fällen eine CI-Pipeline zu durchlaufen, die weiß, wonach sie suchen muss.

LLMs sind großartig darin:

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

Wir sind nicht hier, um Ihnen zu raten, AI-Werkzeuge zu verbieten. Der Zug ist abgefahren.

Aber einem Sprachmodell Commit-Zugriff geben? Das kann nur Ärger geben.

Wir empfehlen stattdessen Folgendes:

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 kann Ihnen helfen, schneller voranzukommen. Aber er kann nicht für Sie denken.

Es versteht Ihre Architektur nicht. Er weiß nicht, was "erledigt" in Ihrem Kontext bedeutet. Und es ist ihm definitiv egal, wenn Ihre Datenpipeline an einem Freitagabend stillschweigend zusammenbricht.

Deshalb müssen wir uns als CTOs auf die Ausfallsicherheit des Systems konzentrieren, nicht nur auf die Geschwindigkeit.

Es ist verlockend, AI die langweiligen Teile zu überlassen. Und manchmal ist das auch gut so. Aber jede Abkürzung ist mit einem Kompromiss verbunden. Wenn AI-generierter Code unkontrolliert durchrutscht, wird er oft zu AI technical debt. Die Art von Schulden, die Sie erst sehen, wenn Ihr Ops-Team in der Produktion nachbessert.

Wenn Sie bereits gegen diese Wand gelaufen sind, sind Sie nicht allein. Wir haben Teams bei der Wiederherstellung von Migrationen bis hin zu API-Katastrophen geholfen. Wir refaktorisieren nicht nur den Code. Wir helfen bei der Refaktorierung des dahinter stehenden Denkens.

Denn das ist es, was die Systeme letztlich zuverlässig macht.

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 aufnehmen

Anruf buchen 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.