Kürzlich sehe ich auf meiner Timeline immer wieder den Satz „Contract Development ist tot". Meistens wird das im Zusammenhang damit diskutiert, dass KI Software schneller und günstiger macht, und das traditionelle Modell „genau das bauen und liefern, was der Kunde verlangt" rapide an Wert verliert.
Ehrlich gesagt dachte ich zuerst: „Ist das nicht wieder so ein ‚X ist tot'-Hype?"
Denn seit Jahrzehnten wird gesagt, dass „Contract Development stirbt", schon lange vor KI. Inhouse-Entwicklung, die Cloud, mehrstufige Subunternehmer, Offshoring – jedes Mal hieß es „dieses Mal stirbt es wirklich", und doch überlebt Contract Development wie ein Zombie.
Eigentlich habe ich lange für Produktunternehmen gearbeitet und diese Themen daher eher aus der Ferne beobachtet. Ich erinnere mich, dass ich dachte, Contract Development sehe schwierig aus und sei nichts, dem ich mich nähern möchte.
Dann, vor drei Jahren, bin ich zu Hololab Inc. gekommen und bin jetzt mitten in der Kundenarbeit, inklusive Contract Development. Um ehrlich zu sein, hat mir der Begriff „Contract Development" beim Eintritt etwas zu denken gegeben. Trotzdem haben die Herausforderung der Transformation durch neue Technologien und die Anziehungskraft des Unternehmens selbst überwogen. Ich dachte mir, es wäre uncool, über „Contract Development" zu jammern, ohne es ausprobiert zu haben.
Seitdem sind drei Jahre vergangen. Ich bin in die Geschäftsleitung eingetreten und habe mich direkt mit Contract Development auseinandergesetzt. Deshalb möchte ich dieses Mal dem Satz „Contract Development ist tot" ohne Wegzulaufen ins Gesicht sehen.
Stimmt es, dass „Contract Development tot ist"?
Ja, das stimmt.
Schon vor KI gab es im Kontext der digitalen Transformation Bewegungen hin zu No-Code und einen Trend zur Inhouse-Entwicklung. Dann kam die Welle der KI (insbesondere KI-Agenten) und hat diesen Trend sofort verstärkt. Selbst Nicht-Entwickler können jetzt Software erstellen.
Wenn dieses Thema aufkommt, neigen Ingenieure, die davon leben, dazu, ein großes Geschrei um „Qualität" oder „Sicherheit" zu machen und zu argumentieren, dass „Softwareentwicklung nicht so einfach ist".
Allerdings hängt die erforderliche Qualität von Software vom Zweck und Anwendungsfall ab. Software für Kunden oder Produktionsumgebungen benötigt ein bestimmtes Serviceniveau. Auf der anderen Seite ist das Niveau, das für interne Tools oder Proof-of-Concepts (PoCs) erforderlich ist, oft relativ niedrig. Und genau dieser Bereich wird leicht durch KI-Agenten ersetzt – oder besser gesagt, die Ablösung hat bereits begonnen.
Was Sicherheit und Qualität angeht, habe ich das Gefühl, dass die Lücke jedes Jahr kleiner wird, da sich die Modelle weiterentwickeln und das menschliche Wissen über den KI-Einsatz wächst. Noch vor zwei oder drei Jahren war die vorherrschende Meinung: „KI kann unterstützen, aber es ist zu früh, sie Code schreiben zu lassen." Heute schreibt KI die meiste Zeit Code. Angesichts dieser Veränderungsgeschwindigkeit könnte selbst in Bereichen, in denen eine vollständige Übergabe derzeit noch schwierig ist, in naher Zukunft leicht eine Situation eintreten, in der „KI zuverlässiger ist als Menschen".
Um ehrlich zu sein, als Ingenieur möchte ich selbst nicht glauben, dass die Arbeit, die ich geleistet habe, so einfach ersetzt werden kann. Aber ich kann deutlich sehen, was direkt vor meinen Augen stirbt. Das ist kein Hype oder Standpunkt-Denken, sondern eine Veränderung, die tatsächlich stattfindet.
Das bedeutet jedoch nicht, dass „Contract Development als Ganzes stirbt". Was stirbt, ist nicht das Contract Development, sondern die Softwareentwicklung, die „nur baut". Ich erkläre, warum ich das denke.
1. Man kann nicht jedes „Contract Development" über einen Kamm scheren
Auch wenn man „Contract Development" sagt, variiert der Inhalt von Unternehmen, die nur Personentage verkaufen, über SIer, Berater, Produktpartner, PMOs bis hin zu DX-Unterstützung. Die Frage ist also nicht: „Ist Contract Development tot?" sondern: „Was genau stirbt eigentlich?"
Wenn man es aufschlüsselt, geschieht der Wertverlust durch KI nicht auf einmal, sondern schrittweise. Die erste Welle trifft den Wert des Aktes des „Codeschreibens". Tatsächlich steigt die Entwicklungsproduktivität und die Gewinnstruktur von Projekten beginnt sich zu verändern.
Und diese Welle wird nicht beim Codeschreiben haltmachen. Sie wird sich allmählich auf das Design, die Anforderungsdefinition und die Konzeptionsphase davor ausweiten. Deshalb möchte ich unterscheiden, welche Werte zuerst fallen und welche bleiben.
Was also stirbt, ist der Job des „einfach nur Codeschreibens, wie gesagt". Ob es sich um Contract Development handelt oder nicht, spielt keine Rolle. Und dieser Bereich schrumpft bereits.
Allerdings ist das Schrumpfen nicht einheitlich. Kleine bis mittlere Auftragsentwickler und kleine Inhouse-Entwicklungen spüren die volle Wucht der Inhouse- und generativen KI-Welle, und Projekte beginnen zu verschwinden. Auf der anderen Seite höre ich oft, dass komplexe Systeme für große Unternehmen noch nicht so sehr in Schwierigkeiten sind, weil sie nicht allein von Inhouse-Teams bewältigt werden können. Die Auswirkungen variieren stark je nach Größe und Kundenstamm, daher verschwimmt die Diskussion, wenn man alles vermischt.
2. Kunden kaufen nicht in erster Linie „Code"
Wenn man darüber nachdenkt, ob Kunden Aufträge vergeben, weil sie Code geschrieben haben wollen, lautet die Antwort nein.
Was Kunden erwarten, ist Problemlösung: Sie wollen Geschäftsstrategien organisieren, gemeinsam Anforderungen durchdenken, Hilfe bei Entscheidungen bekommen, Unterstützung bei der internen Koordination und Risikominimierung. Code ist nur ein Mittel zum Zweck.
So gesehen ist die Logik „Code wurde billig = Contract Development ist tot" ziemlich kurzsichtig. Die Mittel sind billiger geworden, aber die erwartete Substanz ist keineswegs verschwunden.
Das deckt sich mit meiner eigenen Erfahrung, sowohl in Produktunternehmen als auch im Contract Development gearbeitet zu haben. Es gibt Auftragsentwicklungen, die tief in das Geschäft eintauchen, und es gibt Inhouse-Entwicklungsteams, die wie interne Auftragnehmer agieren und einfach das bauen, was die Fachabteilung sagt. Eine Grenze zwischen „Produktunternehmen vs. Contract Development" zu ziehen, bildet die Realität nicht mehr ab.
Außerdem betrifft das nicht nur das Contract Development. Die Grenze zwischen Entwicklung und Beratung verschmilzt ebenfalls. Beratungsfirmen bauen zunehmend Entwicklungsteams auf, und SIer beginnen mit der Geschäftsunterstützung. „SaaS ist tot" folgt derselben Struktur: Unternehmen, die nur Software verkaufen, sind erledigt, während Unternehmen, die in BPO, Betrieb, Partnerschaft und Leistungsgarantien eintauchen, wachsen. Beratung, SIer, SaaS und Produktunternehmen überschneiden sich immer mehr. Das Ziel ist der „Wert" für den Kunden.
3. „Denken" und „Bauen" rücken näher zusammen
Lange Zeit waren die Kosten für die Entwicklung von Software viel zu hoch. Daher waren „Denken" und „Bauen" zwangsläufig getrennt. Rollen waren geteilt, Jobtitel waren geteilt, Organisationen waren geteilt, und sogar Unternehmen tendierten dazu, geteilt zu sein.
KI hat die Kosten für das „Bauen" gesenkt. Infolgedessen beginnen „Denken" und „Bauen" natürlich zusammenzuwachsen. Rollen, Jobtitel, Organisationen und Unternehmen rücken alle näher zusammen. Das ist die Veränderung, die jetzt stattfindet.
Und genau das wollte die agile Entwicklung erreichen: „Denken" und „Bauen" näher zusammenbringen. Wir nähern uns endlich dem Ideal, das damals nicht vollständig verwirklicht werden konnte, weil die Kosten für das Bauen zu hoch waren.
Tatsächlich nehmen in unserer eigenen Kundenarbeit die Fälle zu, die nicht nur mit der Entwicklung enden. Was als normale Entwicklung beginnt, wird oft zu „wir möchten beraten, wie das Geschäft vorangebracht werden kann" und erweitert sich auf PMO, Geschäftsmodell-Design, Projektförderung und Entscheidungsunterstützung. Heutzutage gibt es Einsatzorte, an denen wir mehr Zeit damit verbringen, „das Geschäft aufzubauen" als „das System zu bauen". Ich habe mich anfangs gefragt, ob das noch Contract Development ist, aber mir sind die Grenzen inzwischen egal.
Ich höre in letzter Zeit oft den Begriff FDE (Forward Deployment Engineer), und das ist wahrscheinlich Teil desselben Trends. Vor Ort beim Kunden sein, gemeinsam über Probleme nachdenken und bei Bedarf Code schreiben. Kein „Denker" und „Bauer", sondern eine „Person, die baut, während sie denkt". Ein häufiges Missverständnis hierbei ist, dass es um die räumliche Nähe zum Kunden geht. Das ist nicht der Fall. Es geht um die Nähe zur Problemlösung.
Allerdings ist diese Veränderung ein zweischneidiges Schwert. Ich habe kürzlich diese Geschichte in einem großen Unternehmen gehört: Es begann mit einer Geschäftsstrategie. Die Systementwicklung begann. Auf halbem Weg wurde das Bauen zum einzigen Ziel. Die Strategie verschwand. Und eine massive Menge ungenutzter Systeme blieb übrig. Diese Realität gab es schon lange vor KI. Aber da KI die Kosten für das Bauen senkt, wird sich diese Tragödie leichter und in größerem Umfang ereignen. Je einfacher das Bauen wird, desto schwerer wiegt die Frage „was gebaut werden soll".
Daher ist KI für Contract Development, das in die Problemlösung eintaucht, ein Rückenwind, kein Gegenwind. Es ist weit davon entfernt, „tot" zu sein. Aber in dem Moment, in dem man sich von der Problemlösung entfernt, wird dieser Rückenwind zu einer „Massenproduktionsmaschine für nutzlose Dinge".
4. Letztlich ist die Quelle des Werts der „Mensch"
Wenn man so weit kommt, scheint die Quelle des Werts für Contract Development, Beratung und SaaS dieselbe zu sein. Es ist nicht die Software selbst. Es sind die Menschen.
Arbeit, die jedes Unternehmen lösen kann, wird ersetzt. Arbeit, die KI lösen kann, wird ebenfalls ersetzt. Aber „es müssen diese Leute sein, die es lösen" bleibt. „Ich möchte mit diesen Leuten zusammenarbeiten" bleibt auch.
Das Ziel ist also nicht, ein Produkt zu liefern, sondern ein Partner für den Kunden zu sein, um einen Wert zu erreichen. Lass sie den Wert in den Menschen spüren, nicht im Objekt.
Das Paradebeispiel ist die Entscheidungsfindung. KI kann beliebig viele Kandidaten generieren. Aber derjenige, der entscheidet, ist ein Mensch. Und man wird nur besser in der Entscheidungsfindung, indem man Entscheidungen trifft.
Wie wir Menschen ausbilden, verändert sich ebenfalls. In meiner Abteilung verlagern wir uns in Richtung „Denken + Bauen", und natürlich gibt es Kämpfe. Aber das lernt man nicht in Schulungen. Das wächst nur in der Arbeit.
Ich möchte kurz auf die Einstellung eingehen. In letzter Zeit stellen mehr Unternehmen aufgrund von KI weniger Junioren ein. Die Logik ist: „Wenn KI Code schreibt, brauchen wir keine Junioren." Aber ich glaube das Gegenteil. KI-native Junioren haben, weil sie keine festgefahrenen Ideen haben, das Potenzial, Nutzungsweisen zu entwickeln, auf die wir nie kommen würden. Auch wenn die Einstellung kurzfristig zurückgehalten wird, wenn man kein Umfeld schaffen kann, in dem Menschen wachsen, wird diese Branche nur schrumpfen. Das ist nicht die Schuld der KI; es ist einfach ein Versagen, sich an die Veränderungen anzupassen, die KI gebracht hat.
Der Beruf des Ingenieurs verschwindet nicht. Der Job des Ingenieurs, der „nur baut", verschwindet.
Die gesamte Softwareentwicklung nähert sich dem „Wert"
„Contract Development ist tot" ist wahr. Allerdings stirbt nicht das Contract Development, sondern die Softwareentwicklung, die „nur baut". Es ist nicht so, dass der Beruf des Ingenieurs verschwindet, sondern der Job des Ingenieurs, der „nur baut". Und es hat bereits begonnen. Contract Development ist nur zufällig an vorderster Front.
Wenn man einen Schritt zurücktritt und diese Veränderungen betrachtet, wird ein größeres Bild sichtbar. Contract Development, das ins Geschäft eintaucht. Beratungsfirmen mit Entwicklungsteams. SaaS, das Leistungsgarantien übernimmt. FDEs, die zu Kunden gehen. Die Positionen und Formate sind alle unterschiedlich, aber die Richtung ist gleich. Die gesamte Softwareentwicklung nähert sich auf ihre eigene Weise dem „Wert".
Außerdem ist das kein neuer Trend. Ingenieure wissen seit langem, dass „nur bauen nicht reicht", und haben versucht, näher an Kunden, Benutzer und Wert heranzukommen. Das repräsentative Beispiel ist die agile Entwicklung. Es ist 25 Jahre her, seit Agile geboren wurde. Dieses Ideal, „Denken" und „Bauen" näher zusammenzubringen, wird in diesen wenigen Jahren durch KI auf einmal beschleunigt. So sehe ich das.
Also sollten wir nicht mehr auf die „Form" der Softwareentwicklung fixiert sein. Contract Development oder Produktunternehmen? SIer oder Berater? Anstatt dort Energie zu verschwenden, lautet die Frage: „Wie tief kannst du in den Wert eintauchen?"
Am 24.07. werde ich eine Live-Diskussion zum Thema „Contract Development ist tot" bis zum Morgen führen
Am 24.07. werde ich auf einer Veranstaltung von Creationline zum Thema „Die Zukunft des Contract Development im KI-Zeitalter – Jenseits von ‚Contract Development ist tot'" sprechen.
https://creationline.connpass.com/event/398146/
Freitag, 24. Juli 2026, 19:00–20:30 Uhr, via Zoom, kostenlose Teilnahme.
Ich werde mit @samuraiRed und @sasakendayo eine gründliche, ehrliche Diskussion zum Thema „Contract Development ist tot" führen.
Da wir drei sind, die vielleicht Dinge sagen, die wir nicht sagen sollten, habe ich den Organisatoren während des Vorbereitungstreffens gesagt: „Bitte stoppt uns, wenn es außer Kontrolle gerät." Es wird sicherlich eine Präsenz geben, die man nur live erleben kann.
Worüber werden wir reden?
Die Antwort ist... Tranquilo! Keine Eile!
Ich warte auf euch am Tag.
Blog hier:
