Anfang Mai 2026 wurde öffentlich, wie ein KI-Coding-Agent in neun Sekunden die gesamte Produktivdatenbank eines US-amerikanischen SaaS-Anbieters samt aller Sicherungskopien gelöscht hat. Die meisten Berichte über den Vorfall fokussieren auf das Verhalten des Agenten und die Frage, ob KI-Werkzeuge in Produktion verlässlich genug sind. Bei näherer Betrachtung steht im Mittelpunkt etwas anderes: ein Versagen auf drei voneinander unabhängigen Architektur-Ebenen, das durch die Geschwindigkeit des Agenten lediglich sichtbar wurde. Die Lehren daraus betreffen jeden, der KI-Werkzeuge mit Schreibrechten an produktive Systeme anbindet, unabhängig vom konkreten Anbieter.

Kaum ein Thema polarisiert im Mittelstand aktuell so wie KI-Coding. Die Claims der Anbieter sind groß: Vollautonomes Programmieren, Entwicklerteams werden obsolet, ein einzelner Product Owner baut Software, für die früher zehn Entwickler nötig waren. Die Gegenpositionen sind ebenso laut: Halluzinationen, Sicherheitsrisiken, technische Schulden im industriellen Maßstab. Zwischen beiden Lagern sitzen Geschäftsführer und IT-Leitungen mit der nüchternen Frage: Was stimmt jetzt eigentlich — und was muss ich als Entscheider daraus ziehen?

Am 22. April 2026 habe ich in einem Webinar versucht, diese Frage empirisch zu beantworten. Grundlage war ein über fünf Wochen durchgeführtes Experiment: Ein vollständiges ERP/CRM-System — 220.000 Code-Zeilen, 17 Module, 2.517 Tests — zum allergrößten Teil durch einen KI-Coding-Agenten (Claude Code) geschrieben. Dieser Artikel fasst die Kernbefunde zusammen. Er richtet sich an Entscheider und Projektleiter im Mittelstand, die KI nicht aus der Vogelperspektive betrachten wollen, sondern wissen müssen, was in der Realität passiert, wenn man es wirklich einsetzt.

Ein Lagebericht aus der Projektpraxis. Für Entscheider im DACH-Mittelstand, die KI einsetzen wollen, aber nicht riskieren möchten, in zwei Jahren die nächste Schrems-Debatte auf dem Schreibtisch zu haben.

3 €/Min für die 0900-Hotline. 17 €/Min für dein Meeting mit 10 Entwicklern.

Und das ist nur die halbe Rechnung.

In den letzten Jahren habe ich in unzähligen Unternehmen erlebt: Meetings kosten doppelt. Einmal das Gehalt aller im Raum. Und einmal die Arbeit, die in der Zeit nicht passiert.

Kostenloses Webinar auf Deutsch | 22. April 2026 | 10:00 Uhr | Online

Das Webinar richtet sich an CTOs, CIOs und Geschäftsführer im DACH-Raum und wird ausschließlich auf Deutsch gehalten.

Nicht weil dein Team zu langsam ist. Sondern weil deine QA am selben Ort sitzt wie deine Entwickler.

Jeder Scrum Master kennt das Muster: Die letzten zwei Tage eines Sprints gehören der QA. Die Entwickler drehen Däumchen oder fangen neue Stories an, die dann garantiert nicht mehr fertig werden. Das Ergebnis: Carry-over. Sprint für Sprint.

Die übliche Antwort darauf? Ein separates QA-Team bilden, das „vertikal" über mehrere Scrum-Teams arbeitet. Das löst ein Problem – und schafft drei neue.

In den letzten Jahren habe ich in meinen Projekten immer wieder dasselbe Muster beobachtet. Besonders deutlich wurde es bei der Steuerung multinationaler Teams für eine konzernweite Datenplattform in der Fahrzeugentwicklung – dort zeigte sich das Problem mit vertikalen QA-Strukturen in voller Schärfe: Der QA-Engpass am Sprint-Ende ist kein Kapazitätsproblem. Es ist ein Zeitzonenproblem.

Festpreis oder Time & Material? In den letzten Jahren habe ich dutzende IT-Projekte begleitet, bei denen diese Frage zum Streitpunkt wurde – oft bevor überhaupt eine Zeile Code geschrieben war. Einkaufsabteilungen bestehen auf Festpreisen, weil Budgetsicherheit nun mal nicht verhandelbar ist. Projektleiter wissen gleichzeitig, dass sich Anforderungen in komplexen Software-Projekten zwangsläufig ändern werden. Das Ergebnis: Verträge, die formal "erfolgreich" erfüllt werden, aber am tatsächlichen Bedarf vorbeigeliefert haben.

Wenn 25 Minuten Ausfall siebenstellige Umsatzverluste bedeuten können

Freitagmorgen, 5. Dezember 2025. Wieder einmal zeigen tausende Websites weltweit nur noch "500 Internal Server Error". Wieder einmal ist Cloudflare der Grund. Und wieder einmal – wie bereits am 18. November – trifft es Unternehmen völlig unvorbereitet.

Der jüngste Ausfall dauerte offiziell etwa 25 Minuten, betraf aber rund 28% des gesamten HTTP-Traffics, den Cloudflare verarbeitet. Der Ausfall im November war deutlich schwerwiegender: Über vier Stunden waren Dienste wie ChatGPT, X (ehemals Twitter), Discord, PayPal und unzählige weitere Plattformen nicht erreichbar. Cloudflare selbst nannte es den schlimmsten Ausfall seit 2019.

Das Gebot der Stunde ist klar: „Wir brauchen ein neues ERP-System." Vielleicht läuft der Support für dein aktuelles System aus. Vielleicht sind die Prozesse so verbogen, dass niemand mehr durchblickt. Oder du startest als wachsendes Unternehmen zum ersten Mal mit einem richtigen ERP. Das Ziel ist klar – aber wie kommst du von einem weißen Blatt zu einer Ausschreibung, die dir am Ende auch wirklich das liefert, was du brauchst?

Das Problem mit OKR-Tools in der Praxis

In den letzten Jahren habe ich mehrere OKR-Einführungen begleitet – von Handelskonzernen bis zu mittelständischen Unternehmen. Dabei zeigte sich immer wieder ein wiederkehrendes Muster: Die Begeisterung für OKRs war da, die Methodik überzeugte, aber an einem unerwarteten Punkt stockte die Einführung – bei der Tool-Auswahl.