Die £35.000 Lektion: Wenn KI generierter Code auf Produktion trifft

Im letzten Monat habe ich zugesehen, wie zwei separate Projekte ins absolute Chaos abgerutscht sind, weil Drittanbieter entschieden haben, dass KI generierter Code gut genug für die Produktion ist. Das Ergebnis? Über £35.000 an direkten Kosten und es wird täglich mehr, unzählige Stunden beim Debuggen von halluzinierter Logik anderer Leute, und die Motivation, ai-code-detector zu bauen, ein Tool das in den letzten Tagen ordentlich Aufmerksamkeit bekommen hat.

Das ist kein theoretisches Geschwätz darüber, ob KI Code schreiben kann. Das ist ein echtes Post Mortem dessen, was passiert, wenn Organisationen KI generierten Code als Abkürzung statt als Ausgangspunkt behandeln. Schnall dich an, es wird nicht schön.

Zwei Projekte, gleiches Problem, verschiedene Geschmacksrichtungen des Desasters

Ich arbeite gerade an zwei großen E-Commerce Integrationen: eine für einen US amerikanischen Schmuckhändler und eine für eine britische Modeplattform. Beide haben Drittanbieter, die kritische APIs und Services bereitstellen. Beide Anbieter, wie sich herausstellt, haben entschieden, dass KI unterstützte Entwicklung bedeutet "lass die KI alles schreiben und hoff auf das Beste."

Die Symptome waren unterschiedlich. Die zugrundeliegende Krankheit war identisch.

Projekt Eins: Die US Schmuckplattform (Ja, ich rede mit dir)

Das hier ist ein Skalierungsprojekt. Wenn ich die Integration ausbaue, müssen sie mitwachsen. Sie nutzen, was sie ein "Rapid Development Framework" nennen, was, soweit ich das beurteilen kann, übersetzt bedeutet "Claude oder ChatGPT schreibt den Code und wir shippen ihn ohne hinzuschauen."

Hier ist, was ich in den letzten vier Wochen erlebt habe:

Nichts ist getestet. Buchstäblich nichts.

Ich meine nicht "die Testabdeckung ist ein bisschen niedrig." Ich meine es gibt null Tests. Nada. Niente. Die KI hat die Implementation generiert, jemand hat etwa drei Sekunden draufgeschaut, und es ging direkt in Produktion.

Als ich nach ihrer Teststrategie gefragt habe, bekam ich eine Antwort darüber, wie "KI generierter Code von Natur aus zuverlässiger ist, weil er auf Mustern aus Millionen von Codebasen basiert." Alter, so funktioniert das absolut nicht.

Die praktische Auswirkung? Jede einzelne Integration die ich baue muss berücksichtigen, dass ihre API komplett unerwartete Datenstrukturen zurückgeben könnte. Ich habe gesehen, wie Produkt Endpoints Preise als Strings, Integers, Floats und bei einer denkwürdigen Gelegenheit als verschachteltes Objekt mit dem Preis drei Ebenen tief vergraben zurückgegeben haben. Alles vom selben Endpoint. Alles in derselben verdammten Woche.

Funktionalität ändert sich zufällig

Das ist das verräterische Zeichen von KI generiertem Code, der kontinuierlich neu generiert statt ordentlich gewartet wird.

Montag: der /api/products/{id} Endpoint gibt { "name": "Diamond Ring", "price": 1299 } zurück

Mittwoch: genau derselbe Endpoint gibt { "product_name": "Diamond Ring", "price_cents": 129900 } zurück

Freitag: jetzt ist es { "title": "Diamond Ring", "pricing": { "amount": 1299, "currency": "USD" } }

Das ist keine Versionierung. Es gibt keine Deprecation Warnung. Das Schema ändert sich einfach, weil jemand die KI gebeten hat, den Endpoint zu "verbessern", und sie entschieden hat, dass das bedeutet, die Response komplett umzustrukturieren.

Mein Integrationscode muss jetzt alle drei Formate handhaben, weil ich ehrlich keine Ahnung habe, welches ich an einem bestimmten Tag bekomme. Es ist wie API Roulette, außer dass alle verlieren.

Die API ist nicht sicher (und das hält mich nachts wach)

Das Authentifizierungssystem hat alle klassischen Merkmale von KI generiertem Security Code:

API Keys werden bei manchen Endpoints client seitig und bei anderen server seitig validiert. Es gibt einen Endpoint, der einen user_id Parameter akzeptiert und die komplette Bestellhistorie dieses Nutzers zurückgibt, inklusive Zahlungsdetails, mit absolut keiner Authentifizierungsprüfung. Die "Admin" Endpoints sind geschützt, indem geprüft wird, ob der Request Header X-Admin: true enthält. Das war's. Das ist das gesamte Sicherheitsmodell.

Ich habe diese Probleme mehrfach gemeldet. Die Antwort? "Wir lassen die KI die Security Implementation überprüfen." Dieselbe KI, die den unsicheren Code überhaupt erst geschrieben hat. Brilliant.

Endpoints ändern sich ohne jede Vorwarnung

Letzten Dienstag ist die Hälfte meiner Integration kaputtgegangen, weil /api/v2/inventory zu /api/inventory/v2 wurde. Kein Redirect. Keine Deprecation Periode. Keine Benachrichtigung. Einfach kaputt.

Als ich fragte warum, wurde mir gesagt, sie hätten "das Routing für bessere Organisation refactored." Die KI hat es vorgeschlagen, anscheinend. Danke dafür.

Ich habe jetzt Monitoring, das alle fünf Minuten die Endpoint Verfügbarkeit prüft, weil ich ehrlich nicht darauf vertrauen kann, dass die URLs die ich heute aufrufe morgen noch existieren.

Projekt Zwei: Die UK Modeplattform

Das hier ist anders. Skalierung ist nicht das unmittelbare Problem. Das Problem ist, dass ich mich auf keinen Input oder Output verlassen kann, weil die zugrundeliegende Logik sich zufällig ändert.

Selbe Krankheit, andere Symptome:

Logik die sich zwischen Deploys ändert

Der Rabattberechnungs Endpoint ist mein absolutes Lieblingsbeispiel. Über drei Wochen habe ich sieben verschiedene Rabattberechnungsmethoden dokumentiert:

Woche 1: Prozent vom Listenpreis

Woche 1 (später in derselben Woche): Prozent nach MwSt

Woche 2: Fester Betrag ab, abgerundet

Woche 2 (später): Fester Betrag ab, auf nächsten Penny gerundet

Woche 3: Prozent ab, aber gedeckelt bei £50

Woche 3 (später): Prozent ab, aber Mindestrabatt von £5

Woche 3 (noch später): Zurück zu Prozent vom Listenpreis, aber jetzt wird MwSt anders berechnet

Jede Änderung kam ohne Dokumentation, ohne Changelog, ohne Benachrichtigung. Der Code hat sich einfach geändert. Weil jemand die KI gebeten hat, "die Rabattberechnung zu fixen", und sie das als "von Grund auf neu schreiben basierend auf dem, was heute vernünftig erscheint" interpretiert hat.

Inkonsistente Datenvalidierung

Derselbe Input, der gestern funktioniert hat, wirft heute einen 400 Fehler. Derselbe fehlerhafte Input, der einen Fehler werfen sollte, wird akzeptiert und korrumpiert die Datenbank.

Ich habe gesehen:

E-Mail Validierung, die not-an-email am Montag akzeptiert, aber [email protected] am Dienstag ablehnt, weil jemand eine Regex hinzugefügt hat, die eine zweibuchstabige TLD erfordert

Preisfelder, die negative Zahlen akzeptieren, was zu Bestellungen führt, bei denen der Kunde buchstäblich dafür bezahlt wird, Produkte zu kaufen

Datum Parsing, das 01/02/2025 manchmal als 2. Januar und manchmal als 1. Februar interpretiert, abhängig davon, welche KI generierte Parsing Funktion gerade an dem Tag deployed ist

Die klassischen KI Code Gerüche

Beide Codebasen zeigen die Muster, die mich motiviert haben, ai-code-detector zu bauen:

Übermäßig ausführliche Kommentare, die das absolut Offensichtliche wiederholen:

# This function calculates the total price by adding up all the item prices
def calculate_total_price(items):
    # Initialize the total to zero
    total = 0
    # Loop through each item in the items list
    for item in items:
        # Add the item's price to the total
        total += item.price
    # Return the calculated total
    return total

Danke dafür. Ich hätte nie herausgefunden, was calculate_total_price macht ohne diese Kommentare.

Jede Funktion hat einen perfekten Docstring, selbst triviale:

def add(a, b):
    """
    Adds two numbers together.
    
    Args:
        a: The first number to add.
        b: The second number to add.
    
    Returns:
        The sum of a and b.
    
    Raises:
        TypeError: If a or b are not numeric types.
    """
    return a + b

Echte Entwickler schreiben keine Dokumentation wie diese für eine Zwei Zeilen Funktion. Tun sie einfach nicht.

Überdefensive Fehlerbehandlung, die alles fängt und nichts behandelt:

try:
    result = process_order(order)
except ValueError:
    pass  # Handle value error appropriately
except TypeError:
    pass  # Handle type error appropriately  
except Exception:
    pass  # Handle any other errors appropriately

Ah ja, das klassische "handle appropriately indem wir absolut nichts tun" Pattern.

Das TODO über funktionierendem Code:

# TODO: Implement order processing
def process_order(order):
    # Full implementation follows
    validate_order(order)
    calculate_totals(order)
    process_payment(order)
    send_confirmation(order)
    return order

Das TODO sagt implementier es. Der Code darunter implementiert es. Erklär mir das mal.

Die echten Kosten: £35.000 und steigend

Lass mich aufschlüsseln, was das meine Kunden im letzten Monat tatsächlich gekostet hat:

Direkte Entwicklungszeit: £18.500

Meine Zeit für Debugging, Bauen von Workarounds, Implementieren von defensivem Code und Handhaben von Produktionsvorfällen, die durch Upstream Änderungen verursacht wurden. Bei kommerziellen Raten summiert sich das erschreckend schnell.

Produktionsvorfälle: £8.200

Drei signifikante Ausfälle, verursacht durch unerwartete API Änderungen. Jeder erforderte Notfallreaktion, Kundenkommunikation und manuelle Bestellverarbeitung, während ich mich abmühte, Integrationen zu reparieren, die durch absolut keinen eigenen Fehler kaputtgegangen sind.

Datenabgleich: £4.800

Die inkonsistenten Rabattberechnungen und Preishandhabung bedeuteten, dass Bestellsummen in meinem System nicht mit Bestellsummen in ihrem System übereinstimmten. Den Abgleich von einem Monat Transaktionen hat zwei Leute drei volle Tage gekostet.

Kundenentschädigung: £2.100

Bestellungen, die falsch bepreist waren, Lieferungen, die fehlgeschlagen sind, weil sich die Adressvalidierung mitten in der Woche geändert hat, Kunden, die falsche Produkte erhalten haben, weil sich die SKU Handhabungslogik zufällig mutiert hat.

Security Audit (laufend): £1.400 bisher

Nachdem ich die Authentifizierungsprobleme entdeckt hatte, habe ich einen Dritten beauftragt, die Exposition zu bewerten. Diese Arbeit läuft noch.

Gesamt: £35.000+ und steigt jeden einzelnen Tag

Das beinhaltet nicht die Opportunitätskosten von Features, die ich nicht bauen konnte, weil ich das KI generierte Chaos anderer Leute bekämpft habe.

Warum ich ai-code-detector gebaut habe

Nach der dritten Woche dieses absoluten Chaos brauchte ich eine Möglichkeit, schnell zu bewerten, ob neue Code Drops von diesen Anbietern wahrscheinlich KI generiert sind. Nicht weil KI generierter Code von Natur aus schlecht ist, sondern weil KI generierter Code, der nicht von einem Menschen reviewed, getestet oder verstanden wurde, eine tickende Zeitbombe ist.

ai-code-detector ist ein heuristisches Tool. Es sucht nach den Verrätern:

Kommentarstil (ausführlich, das Offensichtliche wiederholend, absichernde Sprache wie "you may want to consider")

Docstring Sättigung (jede Funktion perfekt dokumentiert, selbst triviale)

Namensmuster (KI liebt ihr userAuthenticationToken, wo ein Mensch auth_tok schreiben würde)

Fehlerbehandlung (überdefensive Muster, leere except Blöcke mit "handle appropriately" Kommentaren)

Strukturelle Uniformität (jede Funktion sieht identisch aus, weil sie alle gleich generiert wurden)

Tote Hinweise (TODO Kommentare direkt über voll funktionierenden Implementationen)

Es ist nicht perfekt. Es kann KI Code, der sorgfältig von einem Menschen bearbeitet wurde, nicht erkennen. Kurze Snippets geben ihm nicht viel zum Arbeiten. Aber es war echt nützlich, um Code zu flaggen, der zusätzliche Prüfung braucht, bevor ich ihm irgendwo in der Nähe von Produktion vertraue.

Die Resonanz war mental. In zwei Tagen hat es mehr Aufmerksamkeit bekommen, als ich je erwartet habe. Es stellt sich heraus, ich bin absolut nicht der Einzige, der mit diesem Problem kämpft.

Die Risiken, über die niemand spricht

Über die unmittelbaren Kosten hinaus gibt es systemische Risiken, die mich echt beunruhigen:

Technische Schulden Multiplikation

Jedes Mal, wenn diese Anbieter Code mit KI regenerieren, warten sie keine Codebasis. Sie generieren eine komplett neue. Es gibt kein institutionelles Wissen. Es gibt kein Verständnis dafür, warum Dinge so sind, wie sie sind. Wenn etwas kaputtgeht, ist der "Fix", neu zu generieren, was das unmittelbare Problem beheben könnte, aber neue Inkonsistenzen anderswo einführt.

Security als Nachgedanke

KI Modelle werden auf öffentlichem Code trainiert, der einen absoluten Berg von unsicherem Code beinhaltet. Wenn du eine KI bittest, "Authentifizierung hinzuzufügen", gibt sie dir vielleicht etwas, das wie Authentifizierung aussieht, aber fundamentale Mängel hat. Ohne menschliches Review von jemandem, der Security tatsächlich versteht, gehen diese Mängel direkt in Produktion.

Die Wissenslücke

Die Teams, die diese Systeme warten, verstehen sie nicht. Sie können nicht, weil sie sie nicht geschrieben haben. Wenn etwas schiefgeht, können sie es nicht debuggen. Sie können nur regenerieren und hoffen. Das schafft eine Abhängigkeit von der KI, die zunehmend gefährlich wird, wenn die Systeme komplexer werden.

Vendor Lock In ins Chaos

Sobald deine Systeme mit einem Anbieter integriert sind, der so arbeitet, bist du in ihr Chaos eingesperrt. Migrieren ist teuer. Bleiben ist teuer. Es gibt keine gute Option, nur verschiedene Grade von schlecht.

Was sich ändern muss

Ich bin nicht anti KI. Ich nutze KI Tools in meiner eigenen Entwicklung jeden einzelnen Tag. Aber es gibt einen massiven Unterschied zwischen KI als Werkzeug nutzen und KI als Ersatz für Verständnis nutzen.

Für Anbieter:

KI generierter Code ist ein erster Entwurf, kein fertiges Produkt. Er braucht Review, Testing und vor allem echtes Verständnis. Wenn die Menschen, die den Code warten, nicht erklären können, warum er funktioniert, sollte er nirgendwo in der Nähe von Produktion sein.

Für Organisationen, die mit Dritten integrieren:

Frag nach ihren Entwicklungspraktiken. Nimm Code Qualität und Stabilitätsanforderungen in Verträge auf. Bau defensive Integrationen, die Upstream Instabilität annehmen. Überwache konstant auf unerwartete Änderungen.

Für die Branche:

Wir brauchen ordentliche Standards rund um KI unterstützte Entwicklung. Keine Einschränkungen, aber Erwartungen. Code Reviews sind immer noch notwendig. Tests sind immer noch notwendig. Dokumentation, die Absicht erklärt (nicht nur was der Code macht, sondern warum er es macht), ist immer noch notwendig.

Was kommt als Nächstes

Ich plane, ai-code-detector mit einigen zusätzlichen Fähigkeiten zu erweitern:

Ein Web Interface, damit du nicht das Repo klonen und im Terminal rumfummeln musst

GitHub Integration, um ganze Repositories zu scannen

Git History Analyse, weil plötzliche Änderungen im Code Stil oder Commit Mustern selbst ein massiver Verräter sind

Pro Datei Reporting, um zu identifizieren, welche Teile einer Codebasis am verdächtigsten sind

Das Ziel ist nicht, KI aus der Entwicklung zu eliminieren. Es ist zu identifizieren, wo KI generierter Code möglicherweise zusätzliche menschliche Aufmerksamkeit braucht, bevor er die Art von Desaster verursacht, mit der ich gerade kämpfe.

In der Zwischenzeit werde ich hier sein, defensiven Code gegen zwei verschiedene APIs warten, die ihr Verhalten buchstäblich jederzeit ändern könnten, während ich zuschaue, wie die Kosten stetig nach oben ticken.

£35.000 in einem Monat. Für Code, den niemand bei diesen Organisationen tatsächlich versteht.

Willkommen in der Zukunft der Softwareentwicklung. Sie ist teuer.

Die beschriebenen Projekte sind echt. Identifizierende Details wurden geändert oder weggelassen. Die Kosten sind zum Zeitpunkt des Schreibens akkurat und akkumulieren weiter.

Wenn du mit ähnlichen Problemen kämpfst, schau dir ai-code-detector an. Und wenn du ein Anbieter bist, der das liest: ja, ich rede mit dir. Bitte, um aller Willen, lass einen Menschen deinen Code reviewen, bevor du ihn shippst.