Madalin
Development enhanced by AI

KI hat nichts ersetzt. Sie hat alles neu bepreist.

Wo KI unterstützt, wo sie mitarbeitet — und warum sich die Grenze zwischen Eigenbau und Zukauf in einem Software-Unternehmen mit 10–50 Mitarbeitenden viel weiter verschoben hat, als es die Tabellenkalkulation irgendjemandes zeigt.

Industrial Revolution repeats today in digital technology

Das Argument drehte sich um die falsche Frage

Seit drei Jahren dreht sich die öffentliche Diskussion über KI um Ersetzung. Das eine Lager sagte, es passiere nichts — Autovervollständigung mit guter PR. Das andere sagte, alles ende — Berufe, Unternehmen, der Arbeitsmarkt selbst. Beide waren laut, beide waren sich sicher, und beide machten denselben Fehler: Sie behandelten eine Kurve wie ein Ereignis.

Roy Amaras alte Beobachtung gilt noch immer. Wir überschätzen die Wirkung einer Technologie kurzfristig und unterschätzen sie langfristig. Die kurze Frist brachte viel Drama und sehr wenig Veränderung. Die lange Frist bricht jetzt an, und sie ist deutlich weniger dramatisch und deutlich folgenreicher, als beide Lager erwartet hatten.

Nichts wurde ersetzt. Sehr viel hat seinen Preis geändert. Und Preise sind der Stoff, aus dem Strategie gemacht ist.

Für eine Führungskraft, die ein Unternehmen leitet, das Software sowohl herstellt als auch nutzt, um sich selbst zu betreiben, zählt genau eine Preisänderung mehr als alle anderen: die Kosten dafür, ein Werkzeug zu bauen, das exakt zum eigenen Geschäft passt, statt eines zu mieten, das es nicht tut.

Zwei Präzedenzfälle, die mehr wert sind als zehn Kommentatoren

Fabriken wurden nicht schneller, als sie Strom bekamen. Sie erhielten Elektrizität in den 1890er-Jahren. Die Produktivität in der Fertigung bewegte sich bis in die 1920er-Jahre nicht nennenswert. Der Grund ist gut dokumentiert: Die erste Generation elektrifizierter Fabriken riss die Dampfmaschine heraus, schraubte einen einzigen riesigen Elektromotor an — und ließ alles andere exakt so, wie es war: die Transmissionswellen unter der Decke, die Lederriemen, die Maschinen, die sich um die Antriebswelle drängten, weil dort die Kraft ankam.

Man hatte die Energiequelle ausgetauscht und die Architektur beibehalten. Der Gewinn lag nahe null.

Der Produktivitätsschub kam, als jemand erkannte, dass Elektrizität es erlaubte, einen kleinen Motor an jede einzelne Maschine zu setzen. Sobald jede Maschine ihre eigene Kraftquelle trug, wurde die Antriebswelle überflüssig, und sobald die Antriebswelle verschwand, konnte man die Fabrikhalle nach dem tatsächlichen Arbeitsfluss anordnen. Das war die Veränderung. Der Motor war nur der Auslöser.

Container waren eine Stahlkiste. Als Malcolm McLean 1956 das erste Containerschiff aus Newark auslaufen ließ, war die Innovation fast beschämend einfach. Die Gewinne brauchten rund zwanzig Jahre, um sich zu materialisieren, weil dafür Häfen, Schiffe, Kräne, Lkw, Schiene, Zollverfahren und Tarifverträge umgebaut werden mussten. Und die Verteilung der Gewinner verlief brutal und geografisch: Newark stieg auf, während die Kais von Manhattan starben; Felixstowe stieg auf, während die Londoner Docks starben. Die Technologie stand allen offen. Die Neuordnung nicht.

Beide Präzedenzfälle lehren dieselbe Lektion — und es ist die Lektion, an der die meiste KI-Einführung derzeit scheitert:

Die Technologie ist nicht die Veränderung. Die Neuordnung ist die Veränderung.

Ein KI-Werkzeug, das in einen unveränderten Arbeitsablauf fällt, ist ein großer Elektromotor, angeschraubt an eine Antriebswelle. Es funktioniert. Es liefert eine Demo. Es liefert fast keinen kumulativen Vorteil. Der Vorteil gehört demjenigen, der bemerkt, welche Beschränkung weggefallen ist, und die Halle neu ordnet.

Die weggefallene Beschränkung sind die Kosten, passende Software zu schreiben.


Teil 1: Der Sockel — wo KI unterstützt und nicht ersetzen wird

Jedes Softwareunternehmen ruht auf einem Infrastruktursockel: Hypervisoren, Netzwerk, Speicher, Identität, die Datenebene der Firewall. In den meisten Unternehmen ist dieser Sockel heute eine Mischung aus Open Source und kommerziellen Komponenten, und die ehrliche Haltung ist: Nichts davon sollte man selbst bauen.

Das liegt nicht daran, dass es “zu schwierig” wäre. Es gibt fünf strukturelle Gründe, die KI nicht berührt:

Physik erscheint nicht im Kontextfenster. Eine SFP28-Verbindung, die wegen eines FEC-Fehlabgleichs nicht hochkommt. Eine Festplatte, die bei einem abgeschnittenen IDENTIFY mit ILLEGAL REQUEST antwortet. Eine Lüfterkurve, ein Backplane, ein grenzwertiges Kabel. Die Diagnose realer Infrastruktur hängt regelmäßig von einem Zustand ab, der nicht Text ist und nicht über einen Prompt erreichbar ist.

Asymmetrie der Konsequenzen. Ein falscher Commit kostet ein Zurücksetzen. Eine falsche Firewall-Regel kostet einen Ausfall oder eine Sicherheitsverletzung. Ein falscher Storage-Befehl kostet Daten, die nicht zurückkommen. Die tolerierbare Fehlerrate unterscheidet sich um Größenordnungen — und genau bei der Fehlerrate bleiben heutige Systeme unzuverlässig.

Verantwortung lässt sich nicht delegieren. Unter PCI DSS, SOC 2, ISO 27001, NIS2 ist eine namentlich benannte Person für eine Kontrolle verantwortlich. Man kann Arbeit an ein Modell delegieren. Man kann Verantwortung nicht an eines delegieren, und kein Auditor wird diesen Versuch akzeptieren.

Laufende Systeme sind keine Codebasen. Ein drei Jahre alter Cluster hat Geschichte, Drift, undokumentierte Entscheidungen und einen Zustand, den niemand vollständig überblickt. Code ist lesbar. Infrastruktur ist archäologisch.

Die Ökonomie der Gemeingüter. Es gibt vielleicht vier Hypervisoren, die es wert sind, betrieben zu werden, und jeder repräsentiert Tausende von Personenjahren. Den fünften zu bauen war 2015 eine schlechte Idee und ist es heute noch. Billigerer Code macht es nicht gut.

Der Sockel bleibt also gekauft oder übernommen. Aber man beachte, was KI hier tatsächlich leistet, denn das ist nicht wenig:

  • Sie verkürzt die Recherchezeit über riesige Dokumentationsflächen hinweg drastisch. Der Großteil erfahrener Fehlersuche ist nicht Denken, sondern Nachschlagen.
  • Sie liest vierzigtausend Zeilen Logs und schlägt drei nach Plausibilität geordnete Hypothesen vor.
  • Sie schreibt die Ansible-Rolle, das Runbook, den Post-Incident-Report — jene Dokumentationsschuld, die jedes Infrastrukturteam mit sich trägt und nie abbaut.
  • Sie erklärt einem müden Techniker um 03:00 Uhr ein unbekanntes Subsystem, für das er nicht zuständig ist.

Das ist enormer Wert. Es ist nur Wert auf der unterstützenden Seite der Grenze, und das ist eine strukturelle Position, keine vorübergehende. Infrastruktur ist der Bereich, in dem KI als Assistentin am nützlichsten und als autonomer Agent am wenigsten angebracht ist.


Teil 2: Wo KI mitarbeitet — und was die Grenze tatsächlich bestimmt

“Assistent versus Agent” wird meist als Frage der Modellfähigkeit diskutiert. Das ist sie nicht. Die entscheidende Variable ist, wer die Verifikationsschleife kontrolliert.

Assistenten-Modus. Der Mensch initiiert, der Mensch überprüft jede Ausgabe, der Mensch ist bei jedem Schritt im Loop. Richtig für irreversible Aktionen, Produktivsysteme und alles, bei dem die Kosten einer falschen Aktion die Kosten eines menschlichen Blicks übersteigen.

Agenten-Modus. Die KI initiiert und iteriert gegen ein automatisiertes Orakel. Der Mensch überprüft das Ergebnis und den Diff, nicht jeden Schritt. Das erfordert zwei Dinge:

  1. Ein schnelles, vertrauenswürdiges Verifikationssignal — Tests, ein Typprüfer, ein Linter, eine Staging-Umgebung, ein idempotentes Apply mit funktionierendem Dry-Run.
  2. Einen begrenzten Wirkungsradius — ein Branch, ein Container, ein Scratch-Namespace, ein Rollback, das tatsächlich geübt wurde.

Fehlt beides, hat man keine agentische KI. Man hat unbeaufsichtigte KI, und das ist etwas anderes und deutlich Schlechteres.

Die strategische Konsequenz ist der Teil, den Führungskräfte durchgängig übersehen:

Wie viel KI-Hebelwirkung sich gefahrlos gewinnen lässt, ist eine Funktion der Testabdeckung, der CI, der Rollback-Fähigkeit und der Umgebungsisolation.

Zwei Unternehmen, die identische Lizenzen kaufen, erzielen radikal unterschiedliche Ergebnisse — und der Unterschied ist nicht das Modell. Ein Team mit echter CI und wiederherstellbaren Umgebungen kann einem Agenten eine Aufgabe übergeben und einen Diff prüfen. Ein Team ohne das muss jede Zeile lesen, was den Gewinn ungefähr auf Tippgeschwindigkeit begrenzt.

Das sind gute Nachrichten für einen Betrieb mit 10–50 Personen. Technische Reife lässt sich in Monaten aufbauen, und sie ist der Multiplikator für jede weitere KI-Investition. Repariert die Verifikationsschleife, bevor ihr den Agenten-Fußabdruck erweitert. Für Infrastruktur speziell hat diese Verifikationsschleife bereits einen Namen: --check-Modus, terraform plan, unveränderliche Rebuilds und eine Observability, die gut genug ist, um innerhalb von Minuten zu erkennen, dass sich etwas verändert hat.


Teil 3: Die drei Kategorien — und die Rechnung, die man bereits zahlt

Jede Software, mit der ein Unternehmen zu tun hat, fällt in eine von drei Kategorien. Die meisten Unternehmen haben die Grenzen an der falschen Stelle gezogen — und sie wurden dorthin gesetzt aus Gründen, die zum damaligen Zeitpunkt richtig waren.

Kategorie 1: Immer mieten. Die Kosten am ersten Tag akzeptieren.

Betriebssysteme. Office-Pakete. Chat und Video. E-Mail und Kalender. Identitätsanbieter. Lohn- und Steuerabrechnung. Zahlungsabwicklung.

Diese teilen gemeinsame Eigenschaften: Commodity-Funktion, klar definierte Schnittstellen, kein Wettbewerbsvorteil und oft eine Compliance-Haftung, die man niemals freiwillig übernehmen würde. Manche sind gerade deshalb wertvoll, weil alle anderen sie auch nutzen. Hier selbst zu bauen ist keine Sparsamkeit, sondern Eitelkeit. Dafür budgetieren und die Entscheidung nicht mehr hinterfragen.

Kategorie 2: Bauen auf gekauften Grundbausteinen.

Die Kategorie, die niemand benennt — und in der der Großteil der eigentlichen Arbeit steckt. Man baut keine Datenbank; man baut seine Anwendung auf Postgres. Man baut keinen Identitätsanbieter; man baut den eigenen Zugriffs-Workflow darauf auf. Man baut keinen Message Bus, keinen Objektspeicher, keinen TLS-Stack.

Man baut die Schicht, die die eigene Logik auf Grundbausteinen abbildet, die man nicht selbst geschrieben hat. Hier ist die Wirkung von KI am größten, weil Zusammenfügen, Integration und Verbindungscode genau die Arbeit ist, die sie am besten beherrscht.

Kategorie 3: Die Werkzeuge, bei denen Mieten aktiv schadet.

Hier liegt der Kern. Wenn man Software mietet, die einen Prozess abbildet, kauft man keine Fähigkeit. Man kauft die Meinung von jemand anderem darüber, wie die eigene Arbeit ablaufen sollte — und organisiert dann das eigene Unternehmen um, damit es dazu passt.

Dieser Tausch war dreißig Jahre lang vernünftig. Entwicklung war langsam und Personal teuer, also war es korrekte Rechenarbeit, mit Prozessverzerrung zu bezahlen, um Ingenieurskosten zu vermeiden. 2010 war das richtig. Jetzt wird es neu bepreist.

Und die Rechnung, die man zahlt, ist nicht die Rechnung selbst. Man achte auf diese vier Posten, von denen keiner im SaaS-Ausgabenbericht auftaucht:

Prozessverzerrung. Man frage jedes Team: Was machen wir umständlich, nur weil das Werkzeug es verlangt? Jede Umgehungslösung, jede parallele Tabelle, jedes “dieses Feld nutzen wir einfach nicht” ist eine Zahlung. Die besten Leute absorbieren täglich Reibung, damit das Datenmodell eines Anbieters intakt bleibt.

Änderungslatenz. Wie lange dauerte es beim letzten Mal, als das Unternehmen eine echte Änderung an einem gemieteten Werkzeug brauchte? Lautet die Antwort “wir haben es angefragt, und es steht auf der Roadmap”, dann ist die Fähigkeit, die eigene Arbeitsweise zu ändern, gedeckelt durch ein Unternehmen, dessen Prioritäten vom Median-Kunden bestimmt werden — nicht von einem selbst. In einem Markt, der sich bewegt, ist Änderungslatenz Wettbewerbsposition.

Ausstiegskosten, die sich aufsummieren. Datengravitation, Integrationen, antrainierte Gewohnheiten, historische Aufzeichnungen. Jedes Jahr, das man bleibt, kostet der Ausstieg mehr. Das ist kein Zufall; es ist das Geschäftsmodell.

Eigentümerschaft an Daten und Bedeutung. Nicht nur, wo die Datensätze liegen, sondern wer definiert, was ein Datensatz bedeutet — und wer diese Definition am Dienstag ändern darf.

Diesen vier Punkten stand bisher ein achtzehnmonatiger Eigenbau als Gegengewicht gegenüber. Heute kann ein kompetentes kleines Team mit KI-Unterstützung für ein gut abgegrenztes internes Werkzeug in Wochen eine v1 am Laufen haben. Das macht die Entscheidung nicht automatisch. Es macht sie zum ersten Mal seit einem Jahrzehnt wieder zu einer Entscheidung — eine, die man aktiv neu prüfen sollte, statt sie einfach zu übernehmen.

Der Beweis durch Schatten-IT. Man weiß bereits, dass dieses Argument stimmt, denn jedes Unternehmen hat geschäftskritische Tabellen und halb verlassene Access-Datenbanken, die Prozesse zusammenhalten. Die existieren, weil das offizielle Werkzeug nicht passte und jemand das fehlende Stück im einzig verfügbaren Medium gebaut hat. Unternehmen wollten schon immer passende Werkzeuge. Sie konnten es sich nur nie leisten, sie richtig zu bauen. Jetzt können sie es — und die Alternative zum richtigen Bauen ist nicht “nichts”, sondern die Tabelle, die bereits existiert und die niemand gesichert hat.


Das ehrliche Gegenargument

Jede Führungskraft, die das oben Gesagte liest und zur Budgetzeile greift, sollte zunächst Folgendes verinnerlichen, denn hier werden die Fehlschläge herkommen:

KI hat die Kosten der ersten 80 % zum Einsturz gebracht. Sie hat die Kosten der letzten 20 % und der folgenden zehn Jahre kaum berührt.

Die Lebenszeitkosten eines internen Werkzeugs bestehen nicht im Schreiben. Sie bestehen aus:

  • Bereitschaftsdienst dafür
  • Patchen und dem endlosen Nachjagen von Abhängigkeits-Updates
  • einem Backup- und Wiederherstellungspfad, der tatsächlich getestet wurde
  • dem Bus-Faktor, wenn die eine Person kündigt, die es verstanden hat
  • Dokumentation, Einarbeitung und Zugriffskontrolle
  • zehn Jahren kleiner Änderungen, jede für sich trivial

KI senkt die Schreibkosten um etwa das Fünf- bis Zehnfache. Sie senkt die Wartungskosten deutlich weniger — auch wenn sie dabei wirklich hilft, insbesondere beim Lesen unbekannten Codes, beim Erstellen von Tests und beim Durcharbeiten von Upgrades. Die Grenze zwischen Eigenbau und Zukauf verschiebt sich also, aber sie verschiebt sich weniger weit, als die Demo suggeriert.

Der absehbare Fehler der nächsten zwei Jahre ist die Führungskraft, die den Eigenbau anhand der 80-%-Zahl kalkuliert, in einem Quartal vier interne Werkzeuge ausliefert und im zweiten Jahr feststellt, dass sie vier ungewartete Produkte und keinen Verantwortlichen für keines davon erworben hat. Dieser Fehler wird der KI angelastet werden. Er wird nicht die Schuld der KI sein.

Die Disziplin, die das verhindert, ist unspektakulär: weniger Dinge bauen, sie richtig besitzen und jedes interne Werkzeug als Produkt behandeln — mit benanntem Verantwortlichem, einer Testsuite und einem dokumentierten Weg zur Außerbetriebnahme.

Es gibt auch einen Präzedenzfall für Überversprechen, an den man sich erinnern sollte. Die späten 1980er verkauften CASE-Tools und 4GLs als das Ende der Programmierung. Das waren sie nicht. Aber FORTRAN ist die bessere Analogie: Backus’ Team wusste, dass der einzige Weg, handgeschriebenen Assembler zu verdrängen, darin bestand, zu beweisen, dass der generierte Code konkurrenzfähig war. Zunächst war er es nicht. Dann war er es. Dann schrieb fast niemand mehr Assembler — und diejenigen, die die Fähigkeit behielten, waren jene, die den Compiler debuggen konnten. Das ist ungefähr die Position, in der sich erfahrene Ingenieurinnen und Ingenieure heute befinden, und es ist eine starke Position, keine bedrohte.


Was in den nächsten neunzig Tagen zu tun ist

  1. SaaS-Bestand nach Prozessverzerrung inventarisieren, nicht nach Kosten. Für jedes Werkzeug zwei Fragen: Was machen wir deswegen umständlich? und Wie lange hat die letzte notwendige Änderung gedauert? Danach ranken, nicht nach Rechnungsbetrag. Die Spitze dieser Liste ist die Kandidatenmenge — und das meiste davon bleibt zu Recht gemietet. Man sucht die zwei oder drei Fälle, die tatsächlich mehr kosten, als sie in Rechnung stellen.
  2. Genau ein Ding bauen und die wahren Kosten erfassen. Internen Verbindungscode wählen, kein Produktfeature. Ausliefern. Dann sechs Monate lang alles messen — Vorfälle, Stunden, Änderungen, Beschwerden. Damit hat man einen echten Koeffizienten für das eigene Unternehmen, statt den eines Anbieters oder Kommentators.
  3. In die Verifikationsschleife investieren, bevor der Agenten-Fußabdruck wächst. CI, Tests, Staging, Dry-Run, geübtes Rollback, Observability. Das ist der Multiplikator für jeden KI-Euro, der in den nächsten fünf Jahren ausgegeben wird — und es lohnt sich, selbst wenn die KI-Entwicklung vollständig stagniert.
  4. Die Assistent/Agent-Grenze als Richtlinie schriftlich festhalten. Welche Systeme einen Menschen bei jedem Schritt im Loop verlangen, welche einen Agenten mit Diff-Prüfung erlauben. Benennen. In einer regulierten Umgebung ist das nicht optional, und es schriftlich festzuhalten ist auch der schnellste Weg herauszufinden, dass die Hälfte des Teams längst improvisiert hat.
  5. Die vorhandenen Leute weiterbilden. Eine erfahrene Ingenieurin mit KI ist ein weit größerer Sprung als ein Berufseinsteiger mit KI, weil sich der Engpass vom Produzieren zum Prüfen verschiebt — und Prüfen ist eine Urteilsfähigkeit, die Jahre braucht. KI erhöht den Wert der erfahrenen Leute. Entsprechend budgetieren und jedem Plan skeptisch begegnen, der lautet: “mehr Junior-Leute einstellen, KI wird die Lücke füllen.”

Der Sockel bleibt der Sockel

Nichts davon ist ein Argument dafür, den eigenen Hypervisor, die eigene Firewall oder den eigenen Storage-Stack zu bauen. Dieser Sockel bleibt, wo er ist, und die Rolle der KI dort besteht darin, ein kleines Team dramatisch effektiver darin zu machen, die exzellente Software eines anderen zu betreiben — schnellere Konfiguration, schnellere Diagnose, bessere Dokumentation, kürzere Vorfälle. Unterstützung, keine Ersetzung, und das strukturell.

Der Fall dreht sich um die Schicht darüber: die Werkzeuge, die abbilden, wie das eigene Unternehmen tatsächlich arbeitet. Diese Schicht wurde dreißig Jahre lang aus einem Grund gemietet, der wahr war und mit jedem Quartal weniger wahr wird.

Die Fabriken, die 1900 elektrifizierten und die Antriebswelle behielten, gewannen dabei nichts. Diejenigen, die bemerkten, dass die Beschränkung weggefallen war, die Deckenwellen herausrissen und die Halle um die Arbeit herum neu aufbauten — die rannten dem Jahrhundert davon.

Die Frage, die es diesem Quartal an die Führungsebene zu richten lohnt, lautet nicht wie führen wir KI ein. Sie lautet:

Was machen wir derzeit umständlich, nur weil es bisher zu teuer war, das passende Werkzeug zu bauen?

Alles Strategische folgt aus der Antwort.

Madalin

Madalin

AI integrator

🚀 Senior Architect | SRE & Database Expert | AI Orchestrator 👋 Building the future at the speed of thought. ⚡️ I don't just write code; I architect high-performance, bulletproof ecosystems. With a foundation in Systems Engineering and a mastery of Go and TypeScript, I bridge the gap between heavy-duty backend reliability and seamless, high-conversion frontends.

Continue the conversation

If this article reflects the challenges your organisation is navigating, explore more practical guidance across Madalin.