Harro KrogIch verkaufe keinen Code. Code ist billig geworden. Ich verkaufe die Entscheidung, welcher Code gebaut wird.
Das klingt nach einem unangenehmen Satz für jemanden, der Softwareentwicklung als Dienstleistung anbietet. Er ist trotzdem der ehrlichste Satz, den ich über meine Arbeit sagen kann, und er erklärt, warum ich mir Projekte inzwischen anders aussuche.
Code war nie ein Moat, die Kosten waren einer
Ein Moat ist etwas, das einen Wettbewerber daran hindert, dasselbe zu tun. Ein Netzwerkeffekt, exklusive Daten, eine Lizenz, ein Vertriebskanal, den man nicht kaufen kann.
Funktionierende Software war nie eines davon. Sie war nur teuer. Ein Produkt, für das ein Wettbewerber achtzehn Monate und vier Entwickler gebraucht hätte, war praktisch geschützt, ohne dass es einen strukturellen Vorteil besaß. Die Barriere lag in den Entwicklungskosten und hat sich wie ein Moat angefühlt.
Diese Barriere ist gefallen. Was sich verändert hat, ist nicht das Produkt, sondern der Preis des Nachbaus. Der Schein-Moat ist verschwunden, und übrig bleiben die echten. Im deutschsprachigen Raum läuft die Diskussion auf denselben Punkt hinaus: Daten und Distribution gelten inzwischen als die verbleibenden Verteidigungslinien für Startups (IT BOLTWISE).
Was genau billig geworden ist
„KI macht Entwicklung billiger" ist zu vage, um daraus etwas abzuleiten. Konkret sind es fünf Entwicklungen, die einzeln als Detail gelesen wurden und zusammen die Kostenbarriere abgeräumt haben.
Ende 2024 wurden erzwungene Ausgabeformate über JSON-Schemata zum Standard. Damit wurde aus einem Modellaufruf eine typisierte Funktion mit garantierter Ausgabeform, also etwas, das man in Software verlässlich einbauen kann, statt Freitext zu parsen.
Etwa zur selben Zeit setzte sich MCP als Protokoll durch. Seitdem kann grundsätzlich jedes Werkzeug an jeden Agenten angebunden werden, ohne dass jemand die Einzelintegration schreibt. Der Integrationsaufwand, der früher einen großen Teil jedes Projekts ausgemacht hat, ist damit ein deutlich kleinerer Posten.
Anfang 2025 kamen offene Modellgewichte in einer Preisklasse an, in der Massenverarbeitung Centbeträge kostet statt dreistelliger Summen. Parallel wurden lange Kontexte und Caching für wiederholte Eingaben normal, womit derselbe Kontext nicht bei jedem Aufruf neu bezahlt wird.
Und schließlich sitzt seit 2025 eine bezahlte, laufende Ausführungsumgebung auf Millionen von Entwicklerrechnern. Claude Code, Codex, Cursor. Das ist der Punkt, den die meisten noch nicht als Teil derselben Sache lesen.
Zusammengefasst: Intelligenz ist ein billiger, typisierter, wiederholbarer Funktionsaufruf geworden, und die Umgebung, die ihn aufruft, läuft schon beim Kunden und wird von ihm bezahlt.
Zwei Verschiebungen, die getrennt gedacht werden müssen
Diese beiden Sachen passieren gerade gleichzeitig und werden ständig vermischt.
Intelligenz ist zu einem Kostenposten geworden, nicht zu einem Produkt. Ein Modellaufruf ist heute eine typisierte Funktion mit garantierter Ausgabeform, billig genug, dass Klassifikation, Extraktion und Bewertung für einen kompletten Kunden in der Marge eines gewöhnlichen Monatsabos verschwinden. Wer eine Preisseite mit Credits und Verbrauchsanzeigen betreibt, hat damit eine Schwachstelle in der Preisseite selbst. Ein Wettbewerber mit Flatrate greift nicht das Produkt an, sondern die Abrechnung, und das ist der billigere Angriff. Der Kunde hasst nicht den Betrag, er hasst die zweite Rechnung und das Nachdenken darüber, ob eine Aktion sich lohnt.
Die Laufzeitumgebung läuft schon beim Kunden. Wer ein technisches Produkt verkauft, verkauft es zunehmend an jemanden, der bereits einen Agenten offen hat, bereits dafür bezahlt und dessen Kontext dieser Agent besser kennt als jeder eingebettete Assistent. Die naive Antwort darauf ist, einen Chat in das eigene Produkt zu bauen. Das ist ein schwächeres Modell in einem schlechteren Kontextfenster, das gegen das gewinnen soll, was der Nutzer sowieso geöffnet hat.
Die unbequeme Konsequenz
Wenn der Agent die Oberfläche ist, dann war ein Teil dessen, wofür Software bisher Geld genommen hat, die Oberfläche.
Für jedes Produkt, das im Kern eine dünne Schicht über einem Datenmodell ist, gilt damit: Ein Wettbewerber ohne Oberfläche, nur Schnittstelle und ein paar Skills, ist billiger zu bauen, schneller zu installieren und besser in dem Werkzeug, in dem der Nutzer ohnehin sitzt. Der Vertriebskanal ist bei so etwas ein Repository. Klonen, Schlüssel eintragen, fertig.
Was übrig bleibt, ist der Teil außerhalb der Software
Verteidigbar bleibt, was sich nicht nachbauen lässt, weil es nicht aus Code besteht.
Vertrieb und Zugang. Wer die Kunden erreicht, bevor der Wettbewerber überhaupt weiß, dass es sie gibt, gewinnt mit dem schlechteren Produkt. Daten, die im Betrieb entstehen und die man nicht kaufen kann. Regulierung und Zulassungen, die Zeit kosten statt Geld. Physische Abläufe, also alles, wo jemand tatsächlich etwas anfassen, ausliefern oder vor Ort tun muss. Und Beziehungen, die über Jahre entstanden sind.
Der gemeinsame Nenner: Die Nachbauzeit dieser Dinge ist nicht gefallen. Eine Oberfläche baut man in Tagen nach. Einen Vertriebskanal, dem eine Branche vertraut, baut man in Jahren nach, und Geld beschleunigt das nur begrenzt.
Deswegen ist die interessante Frage bei einem Produkt inzwischen nicht mehr, wie gut die Software ist, sondern welcher Teil des Geschäfts überhaupt aus Software besteht. Ist es der größte Teil, ist das Geschäft ungeschützt.
Was gerade laut ist und trotzdem nicht trägt
Wenn ich das so schreibe, klingt es nach einer Einladung, jetzt schnell etwas mit Agenten zu bauen. Genau da liegt der Denkfehler, und dieselben Kanäle, die die Verschiebung beschreiben, schreien gerade auch das Falsche.
Dünne Wrapper ohne eigenes Datenmodell fallen am schärfsten Filter, den es gibt: Zahlt heute jemand einen Menschen für genau diese Aufgabe? Bei den meisten dieser Werkzeuge lautet die Antwort nein, und dann ersetzen sie auch keine Kosten.
Agenten, die eine ganze Rolle ersetzen sollen, konkurrieren direkt mit dem Agenten, den der Nutzer bereits hat, und verlieren am Kontext. Ein Assistent, der nachträglich in ein bestehendes Produkt eingebaut wird, verliert an derselben Stelle. Und wer Modellkosten mit Aufschlag weiterverkauft, sieht seine Marge von unten wegschmelzen, weil genau diese Kosten fallen.
Das Muster ist dasselbe wie im Winter 2022. Die lauteste Antwort auf eine neue Fähigkeit ist fast nie die, die den Filter übersteht.
Warum ich das nicht nur behaupte
Ich habe über Monate ein technisch aufwendiges Produkt gebaut und dabei die Software nie als Engpass erlebt. Am Ende gab es keinen Markt dafür, und zwar nicht wegen der Qualität des Baus, sondern weil die Zielgruppe ihr Problem nicht benennen konnte. Den kompletten Post-mortem dazu habe ich aufgeschrieben, inklusive der Zahlen aus dem Vertrieb.
Die Lehre daraus ist nicht, dass ich schlecht gebaut habe. Die Lehre ist, dass die Qualität des Baus die Frage gar nicht berührt hat. Ich hatte die einzige Variable optimiert, bei der ich sicher gewinnen konnte, und genau diese Variable entschied nichts.
Was das für meine Projektauswahl heißt
Ich schaue mir inzwischen zuerst an, wo der schwere Teil liegt.
Liegt er im Code, ist das Projekt zu einfach. Nicht im Sinne von langweilig, sondern im Sinne von ungeschützt. Wer nur Software zwischen sich und den Wettbewerb stellt, stellt eine Sache dazwischen, deren Preis gerade fällt.
Liegt der schwere Teil außerhalb, in Vertrieb, in Zugang zu Daten, in Regulierung, in physischen Abläufen oder in Beziehungen, dann ist Software der einfachste Teil der Aufgabe. Das ist die Konstellation, die ich suche. Ich bin gut in dem Teil, der billig geworden ist, also will ich in Projekten sein, in denen dieser Teil zuverlässig gelöst ist und die Entscheidung woanders fällt.
Für Kunden bedeutet dasselbe etwas Praktisches. Wenn das Bauen schneller wird, wird die Entscheidung teurer, was gebaut wird. Ein falsches Feature war früher durch die Bauzeit gebremst. Heute ist es in einer Woche fertig, und man vervielfacht den Fehler schneller, als man ihn bemerkt. Wer sich einen Entwickler holt, kauft nicht mehr in erster Linie Umsetzungsgeschwindigkeit ein. Die ist Grundausstattung geworden.
Was diese These noch nicht belegt
Ich halte das für richtig, und ich kann es nicht in dem Maß beweisen, in dem ich es gerne würde. Der ehrliche Stand:
Die Verschiebung ist beobachtet, aber nicht sauber datiert. Was fehlt, sind Preiskurven der Modelle als Zeitreihe statt aus der Erinnerung, belastbare Zahlen dazu, wie viele Entwickler tatsächlich eine bezahlte Agenten-Umgebung laufen haben, und der Gegentest: Welches abrechnungsbasierte Produkt hat in den letzten zwölf Monaten auf Flatrate umgestellt, und mit welcher Begründung?
Solange das fehlt, ist das hier eine begründete Position und keine Messung. Wer sie mir widerlegen kann, tut mir einen Gefallen.
Baust du gerade an etwas, bei dem der schwere Teil außerhalb des Codes liegt? 30 Minuten, unverbindlich: Termin buchen