Foto von Karola G: https://www.pexels.com/it-it/foto/6229/
Vor ein paar Nächten habe ich einen Artikel gelesen. Er heißt The Death of Software 2.0 und nutzt eine Metapher, die mir geblieben ist: er vergleicht das Software der Zukunft mit den Speicherhierarchien der Computer. Der schnelle, flüchtige Speicher, das, was wir DRAM nennen, wäre die KI, die nicht-deterministisch verarbeitet. Der persistente Speicher, NAND, wäre das strukturierte Datum, die APIs, das, was man Single Source of Truth nennt. Die Schlussfolgerung des Autors ist brutal: die UI-orientierte Software wird obsolet. Wert haben Daten und APIs, durch die KI-Agenten auf die Systeme zugreifen.
Beim Lesen ist etwas in meinem Kopf eingerastet. Nicht, weil es eine reizvolle Theorie war. Weil es genau das beschrieb, was ich in meiner Arbeit zu tun beginne, was ich für nötig halte — auch wenn ein Teil von mir noch widersteht.
Fünfzehn Jahre habe ich Software nach einer einfachen Wertelogik gebaut: zuerst die Oberfläche, dann die API. Aus Kundensicht war die UI das Produkt, die API ein Anhängsel, eine Zugabe für Integratoren, etwas, das man dokumentiert, wenn Zeit übrig ist. Das Modell funktionierte, weil Software von Menschen genutzt werden sollte. Das stimmt nicht mehr — oder zumindest nicht mehr nur.
Agenten klicken nicht
Claude, ChatGPT, Gemini, KI-Agenten, Agentic-Tools im Allgemeinen nutzen Software nicht so, wie ein Mensch sie nutzt. Sie klicken keine Buttons. Sie folgen keinen UX-Flows. Sie verheddern sich nicht in den siebzehn Edge Cases im Checkout-Formular, an denen ich Wochen gesessen habe. Sie brauchen drei Dinge: strukturierte, über gut entworfene APIs zugängliche Daten, persistenten Kontext, den sie in einem Gespräch verstehen, deterministische, wiederholbare Aktionen, die sie fehlerfrei orchestrieren können. Wenn das Produkt, das du baust, nicht um diese drei Säulen gedacht ist, baust du es für 2015.
Hier muss ich ehrlich mit mir sein. Jahrelang habe ich Seele in Oberflächen gesteckt. Ich habe Stunden über die richtige Buttonfarbe gestritten, über die Anordnung eines Menüs, über die Mikrointeraktion, die das Erlebnis flüssiger machen würde. Verschwendete Zeit war es nicht, weit gefehlt. Aber ich frage mich, ob ich nicht Kathedralen auf Fundamenten errichtet habe, die schon zu beben begannen.
MCP als Brücke
Das Model Context Protocol ist der Standard, den Anthropic im November 2024 veröffentlicht hat. OpenAI und Google haben ihn sofort übernommen. Es ist die standardisierte Brücke zwischen einer KI und Unternehmenssystemen. Bisher war jede KI-Integration ein Custom-Projekt: rohe API-Calls in der App, brüchige RAG-Pipelines, bespoke Tool Calling, keine Wiederverwendung, keine Governance. Mit MCP kippt das Paradigma. Du belichtest dein System als MCP-Server. Die KI konsumiert es als standardisierter Client. Du authentifizierst es einmal. Du regierst es einmal. Du überwachst es einmal.
Das ist nicht wenig. Es ist das Äquivalent dessen, was HTTP in den 90ern für die Standardisierung der Web-Kommunikation war. Und wie HTTP wird es alles verändern, ohne dass die meisten es bemerken.
Der neu geschriebene Fluss
Ich versuche mir konkret vorzustellen, was das für die Kundinnen bedeuten würde, mit denen ich arbeite.
Heute ist der Fluss: die Kundin geht in die UI, klickt für acht oder zehn verschiedene Aktionen, exportiert Daten als CSV, fügt sie in eine andere App ein, bekommt das Ergebnis. Ein Prozess, der funktioniert, den wir über Jahre optimiert haben, den die Kundinnen kennen. Aber auch ein Prozess, der Zeit, Aufmerksamkeit, spezifische Kompetenz über das Funktionieren genau dieser Software verlangt.
Der zukünftige Fluss könnte sein: die Kundin spricht zu Claude/ChatGPT/Gemini/whatever und sagt „verarbeite diese Daten und gib mir den Bericht“. Claude verbindet sich direkt über MCP, liest die Daten, verarbeitet sie, schreibt das Ergebnis in die richtige Tabelle. Alles in zehn Sekunden, kein Klick. Das ist nicht KI, die Software kennt. Es ist Software, die für KI konsumierbar wird. Mit Werkzeugen, die alle bereits täglich nutzen.
Ich schreibe diese Worte und spüre inneren Widerstand. Oberflächen zu bauen war jahrelang mein Beruf. Es gibt etwas Menschliches darin, eine Erfahrung zu entwerfen, daran zu denken, wie eine Person mit etwas interagiert, das du erschaffen hast. Es gibt auch — ich gebe es zu — eine Form von Kontrolle. Wenn du eine Oberfläche entwirfst, entscheidest du den Fluss. Du führst die Nutzerin. Du wählst, was sie tun darf, in welcher Reihenfolge, mit welchen Beschränkungen. All das einer KI zu öffnen heißt, diese Kontrolle abzugeben. Es heißt, darauf zu vertrauen, dass das System das Richtige tut, auch wenn du nicht genau vorhersehen kannst, was die Nutzerin fragen wird.
Aber vielleicht ist genau das der Punkt. Vielleicht war diese Kontrolle immer eine Illusion, eine Art Komplexität zu verwalten, indem man Optionen reduziert, statt sie zu konfrontieren.
Die Governance-Lücke
Die Marktdaten sind klar. Mehr als 80 % der Entwicklungsteams folgen schon einer API-first-Methodik. Geschätzt werden 1,7 Milliarden aktive APIs bis 2030, eine Steigerung um 300 % gegenüber dem aktuellen Baseline. API-first gegenüber traditionellen Ansätzen senkt die Integrationskosten um 37 %. Aber die Zahl, die mich am stärksten getroffen hat: Gartner schätzt, dass mehr als 40 % der Projekte mit KI-Agenten bis 2027 abgebrochen werden, wenn sie keine solide Governance haben.
Hier wird es kompliziert, hier stößt die technologische Vision auf operative Realität. MCP hat heute große Lücken. Kein Authentifizierungsstandard: jede Implementierung anders. Sandboxing schwach: wenn ein Agent die Kontrolle übernimmt, wo hältst du ihn an? Risiko von Prompt Injection: wie sicherst du, dass die KI nicht manipuliert wird, unerwünschte Aktionen auszuführen? Audit-Lücken: wie verfolgst du, wer was wann getan hat?
Die EU-Kommission und die europäischen Zentralbanken treiben bereits transparente, kontrollierbare, auditierbare APIs voran. Das ist nicht nur eine technische Wahl. Es ist eine regulatorische Überlebensfrage. Und hier öffnet sich ein Terrain, das ich gut kenne: das Gleichgewicht zwischen Innovation und Compliance, zwischen dem, was du tun könntest, und dem, was du tun solltest.
Ich denke oft über dieses Gleichgewicht nach. Auf der einen Seite der Druck, schnell zu sein, neue Technologien vor den Wettbewerbern zu adoptieren, der Erste zu sein, der den Kundinnen etwas bietet, von dem sie nicht wussten, dass sie es wollten. Auf der anderen die Verantwortung gegenüber diesen Kundinnen, ihren Daten, der Langfristigkeit. Nicht immer im Konflikt — aber manchmal schon. Und dann ist die Wahl nie offensichtlich.
Ich habe Unternehmen zu schnell laufen sehen, mit unausgereiften KI-Implementierungen, die Vertrauen verbrannt haben. Ich habe Unternehmen zu langsam laufen sehen und unbedeutend werden, während sich der Markt verändert. Den perfekten Trade-off gibt es nicht. Es gibt nur die Fähigkeit, bewusst zu wählen, im Wissen, was man opfert und warum.
Wert steckt nicht in der Arbeit
Was ich konkret erkunde: eine Backend-Schicht, die die Kundendaten als MCP-Server bereitstellt. Eine Sammlung von Anweisungen und Konfigurationen für KI, die diesen Server abfragen kann. Eine Governance-Oberfläche, in der die Kundin entscheidet, was die KI lesen darf und was nicht, welche Aktion sie ausführen darf und welche nicht. Ein vollständiger Audit-Trail, der jede Interaktion, jede Entscheidung, jeden Fehler protokolliert.
Das Ergebnis, wenn es klappt: die Kundin braucht uns nicht mehr für drei Viertel der repetitiven Tasks. Sie braucht uns, um das System sauber zu halten, um neue Datenquellen anzubinden, für Governance und Compliance, für Probleme, die menschliches Urteil verlangen. Eine Veränderung der Beziehung: vom „die-Arbeit-macht“ zum „die-Arbeit-automatisierbar-macht“.
Ich schreibe diesen Satz und merke, wie radikal er ist. Ich denke an etwas, das die Arbeitsmenge reduzieren wird, die Kundinnen mir abverlangen. Aus Sicht des Sofortumsatzes Wahnsinn. Aus Sicht des langfristigen Werts der einzige sinnvolle Weg. Kunden zahlen nicht, weil sie zahlen lieben. Sie zahlen, weil du etwas hast, das sie brauchen. Wenn wir ihnen denselben Wert oder mehr mit weniger Reibung geben können, warum sollten wir es nicht tun? Tust du es nicht, tut es jemand anderes.
Ein Satz, den ich mir oft sage: der Wert liegt nicht in der Arbeit, die du tust, er liegt im Problem, das du löst. Jahrelang habe ich meinen Wert in Stunden, Deliverables, ausgelieferten Features gemessen. Heute frage ich mich, ob ich ihn nicht in eliminierten Problemen, reduzierter Reibung, an Kundinnen zurückgegebener Fähigkeit messen sollte, das zu tun, was sie am besten können.
Das Zeitfenster für diesen Wandel ist jetzt, 2026. MCP ist Standard, von den drei großen KI-Anbietern getragen. Die Sicherheitslücken werden schrittweise geschlossen. Kundinnen verstehen langsam, dass sie etwas wie „rede mit ChatGPT und fertig“ wollen. Wer sich in dieser Richtung nicht bewegt, wird abgehängt. Nicht morgen. Jetzt.
Aber „jetzt“ heißt nicht „um jeden Preis“. Heißt nicht, Datensicherheit für Implementierungstempo zu opfern. Heißt nicht, Kundinnen Funktionen zu versprechen, die noch nicht reif sind. Heißt nicht, Vorschriften zu ignorieren, weil sie unbequem sind. Heißt einen Weg zu finden, schnell in die richtige Richtung zu gehen, mit offenen Augen für das Wohin.
Verantwortung der Bauenden
Etwas kribbelt mich besonders, wenn ich daran denke. Nicht die Angst vor technischem Irrtum. Die ist da, aber handhabbar. Etwas Tieferes. Das Bewusstsein, dass die Entscheidungen, die wir heute als Software-Bauer treffen, die Beziehung definieren, die Menschen morgen zur Technik haben werden. Jede API, die wir freigeben, jedes Datum, das wir zugänglich machen, jede Aktion, die wir automatisieren, schafft einen Präzedenzfall. Sie etabliert, was normal ist, was akzeptabel ist, was erwartet wird.
Ich denke an unsere Kundinnen, Menschen, die Unternehmen führen, Mitarbeitende haben, ihrerseits Kundinnen bedienen. Wenn ich ihre Systeme der KI öffne, ändere ich, wie sie arbeiten. Ich definiere neu, welche Kompetenzen nötig sein werden, welche Rollen Sinn ergeben, wie ihr Tag strukturiert sein wird. Eine Verantwortung, die nicht leicht zu nehmen ist — und wir müssen mit deutlich mehr Widerstand rechnen, weil das, was wir anbieten, kein Software ist, sondern eine (oft tiefe) Veränderung von Rollen, Prozessen und Hierarchien.
Aber es ist auch eine außergewöhnliche Chance. Die Möglichkeit, menschliche Zeit und Energie für Tätigkeiten freizusetzen, die wirklich Intelligenz, Kreativität und Urteil verlangen. Repetitive Arbeit zu reduzieren, die Menschen aufzehrt, ohne Wert zu schaffen. Kleine Unternehmen mit großen wettbewerbsfähig zu machen, weil Zugang zur Automatisierung nicht mehr eine Budgetfrage für eigene Teams ist.
Vielleicht ist das der grundlegende Trade-off. Auf der einen Seite das Risiko, Systeme zu bauen, die der Kontrolle entgleiten, Abhängigkeiten erzeugen, Macht in falschen Händen konzentrieren. Auf der anderen die Möglichkeit, etwas zu bauen, das Menschen wirklich hilft, besser zu arbeiten, besser zu leben, ihre Zeit dem zu widmen, was zählt.
Und ich bin überzeugt, Stillstand ist keine Option, und entschlossen, in die Richtung zu gehen, die mir richtig erscheint, Schritt für Schritt, mit offenen Augen.
Und das ist es, was ich tue.
Wenn Sie diese Bahn erkennen und Lust auf einen Austausch über das Wohin haben, sprechen wir darüber.
Was du mitnimmst
Die Kontrolle, die Oberflächen gaben, war immer eine Illusion: ein Weg, Komplexität durch Reduktion der Optionen zu verwalten, statt sie anzugehen.
MCP hat ernste Lücken — Authentifizierung, Sandboxing, Audit — und Gartner schätzt, dass 40 Prozent der Agentic-Projekte bis 2027 ohne solide Governance abgebrochen werden.
Wert steckt nicht in der Arbeit, die du tust, sondern im Problem, das du löst: sich an gelösten Problemen messen, nicht an abrechenbaren Stunden.
Fragen & Antworten
Was ist der Übergang von Software 2.0 zu Software 3.0?
Software 1.0 war handgeschriebener Code. Software 2.0 (Karpathys Begriff) waren auf Daten trainierte neuronale Modelle: das implizite Programm steckt in den Gewichten, nicht in den Zeilen. Software 3.0 ist der nächste Schritt: man trainiert kein dediziertes Modell, man weist ein generelles Foundation-Modell über Prompts und Orchestrierung an. Die Logik wandert vom Code zu den Gewichten zum Kontext — mit radikalen Folgen für den Software-Lebenszyklus.
Warum „verwandelt uns“ dieser Übergang, wie der Titel sagt?
Weil er ändert, was „entwickeln“ heißt. In Software 1.0 war die Fertigkeit, Anforderungen in Algorithmen zu übersetzen. In Software 2.0, Daten zu sammeln und zu labeln. In Software 3.0 ist es, kontextbezogene Anweisungen (Prompts, Tool Definitions, Retrieval) für bereits existierende Modelle zu schreiben. Das ist nicht nur ein neues Werkzeug, es ist ein anderes Handwerk — näher am Editing/Prompting als am Coding.
Was bedeutet das für Unternehmen, die in Software 2.0 investiert haben?
Dass viele in den letzten fünf Jahren gebaute Custom-ML-Projekte mit Foundation-Model-Lösungen konkurrieren, die dasselbe mit einem Zehntel des Aufwands liefern. Das macht die Investition nicht rückwirkend ungültig, aber viele künftige Roadmaps schon. Viele ML-Engineering-Teams müssen neu bewerten, wo ihr IP verteidigbar ist: bei eigenen Daten, bei Custom-Modellen oder bei Orchestrierung?
Was muss eine Entwicklerin heute lernen, um in zwei Jahren noch relevant zu sein?
Nicht so sehr eine neue Sprache, sondern eine neue Abstraktionsebene: Kontexte, Prompts, Evaluation, Tool Use, Retrieval-augmented Reasoning. Der Integrationscode zwischen diesen Bausteinen ist oft einfach; die Herausforderung liegt im Pipeline-Design und in rigoroser Evaluation. Wer bei Software 1.0/2.0 stehen bleibt, wird Spezialistin schrumpfender Nischen. Wer Software 3.0 hinzufügt, bewegt sich dorthin, wo die Nachfrage wächst.
Der Autor
