Wie „AI-Native Engineering“ die Anforderungen von Tech Buyern an ihre Software Engineering Partner verändert.

AI-native Engineering verändert mehr als nur die Produktivität einzelner Entwickler.

Indem Unternehmen KI-Agenten, interne Plattformen, automatisierte Tests, Architekturregeln, Sicherheitskontrollen und unternehmensspezifische Rahmenbedingungen in ihre Entwicklungsumgebungen integrieren, können sie die Softwareentwicklung zunehmend selbst steuern.

Das verändert die Sourcing-Frage.

Für Tech Buyers könnte es bei der Software Engineering Partner Selection zunehmend weniger darum gehen, zusätzliche Kapazitäten für die Umsetzung zu finden, sondern vielmehr darum, zu entscheiden, welche Capabilities, welches Fachwissen, welche zusätzliche Absicherung und welche Verantwortung weiterhin von ausserhalb des Unternehmens kommen müssen.

Es ist unwahrscheinlich, dass dies lediglich zu einem Rückgang bei externen Softwaredienstleistungen führen wird. Eine plausiblere Entwicklung wäre vielmehr eine Veränderung hinsichtlich des Volumens, der Zusammensetzung und des Wertversprechens der externen Nachfrage.

Was verstehen wir unter „AI-native Engineering“?

In diesem Insight bezeichnet der Begriff „AI-native Engineering“ eine Entwicklungsumgebung, in der KI-Agenten und Automatisierung in den Prozess der Konzeption, Entwicklung, Testing, Review und Betrieb von Software integriert sind.

Dazu können gehören:

• Agenten für Programmierung und Softwareentwicklung,
• interne Entwicklerplattformen,
• unternehmensspezifischer Repository- und Dokumentationskontext,
• Architektur- und Programmierregeln,
• automatisierte Tests und Qualitätskontrollen,
• Sicherheitsrichtlinien,
• CI/CD-Workflows,
• Mechanismen zur Überprüfung und Genehmigung durch Menschen.

Dies unterscheidet sich davon, einzelnen Entwicklern lediglich einen KI-Programmierassistenten zur Verfügung zu stellen.

Die DORA-Studie aus dem Jahr 2025 beschreibt KI als Verstärker des zugrunde liegenden technischen Systems: Organisationen mit soliden Plattformen, Prozessen und Rückkopplungsschleifen sind besser in der Lage, den Einsatz von KI in nützliche Ergebnisse umzusetzen, während sich bei schwachen Systemen deren Probleme ebenfalls verstärken können.

GitHub schlägt auf Produktebene einen ähnlichen Weg ein und positioniert Agenten als Teil einer koordinierten Entwicklungsumgebung mit Code-Review, Unternehmenskontrollen und Governance und nicht als isolierte Entwicklertools.

Für einen Tech Buyer ist dies von Bedeutung, da das Unternehmen selbst zunehmend einen grösseren Teil des Engineering-Systems selbst betreiben kann.

Die Sourcing-Grenze beginnt sich zu verschieben

Traditionell könnte ein externer Software Engineering Partner ein relativ umfassendes Delivery Setup mitbringen:

• Menschen,
• Entwicklungsprozess,
• Werkzeuge,
• Projektmanagement,
• Architekturpraktiken,
• Qualitätssicherung,
• Delivery Governance.

Der Tech Buyer konnte die Anforderungen definieren und sich anschliessend bei der Organisation der Umsetzung weitgehend auf den Software Engineering Partner verlassen.

In einer KI-nativen Umgebung kann ein grösserer Teil dieser Koordination innerhalb der Organisation des Einkäufers verbleiben.

Interne Teams können KI nutzen, um ein breiteres Spektrum an Entwicklungsaufgaben durchzuführen oder zu koordinieren. Der Einsatz von KI breitet sich zudem über Berufsgruppen hinaus, die über die Softwareentwicklung hinausgehen, auch wenn die Akzeptanz nach wie vor sehr uneinheitlich ist. Die Untersuchungen des Economic Index von Anthropic zeigen sowohl den besonders starken Einsatz von KI bei der Softwareentwicklung als auch eine erhebliche Nutzung in Bereichen wie Wirtschaft, Verwaltung, Bildung und Medien.

Das bedeutet jedoch nicht, dass Geschäftsanwender plötzlich die professionelle Softwareentwicklung ersetzen.

Dies deutet darauf hin, dass einige kleinere Automatisierungen, interne Tools, Analyseaufgaben, Prototypen und Verbesserungen der Arbeitsabläufe näher an die Personen herangeführt werden können, die das geschäftliche Problem verstehen.

Die Frage nach der Beschaffung rückt somit eine Ebene höher:

Was sollten wir selbst entwickeln und koordinieren, und wo benötigen wir noch externe Unterstützung?

Generische Umsetzungskapazität kann als eigenständiges Wertversprechen an Bedeutung verlieren

Zusätzliche technische Kapazitäten werden nicht wegfallen.

Komplexe Produkte erfordern nach wie vor den Einsatz von Menschen. Grosse Transformationen erfordern weiterhin erhebliche Umsetzungskapazität. Interne Teams werden auch weiterhin mit Kapazitätsengpässen konfrontiert sein.

Wenn KI es jedoch einem bestehenden Entwicklerteam ermöglicht, mehr zu leisten, kann die Fähigkeit, zusätzliche Entwickler bereitzustellen, als eigenständiges Unterscheidungsmerkmal an Bedeutung verlieren.

Der Produktivitätseffekt sollte nicht überbewertet werden. Forschungsergebnisse zeigen nach wie vor erhebliche Unterschiede je nach Kontext. Eine kontrollierte Studie von METR aus dem Frühjahr 2025 ergab, dass erfahrene Open-Source-Entwickler, die an ihren eigenen Repositories arbeiteten, bei der Verwendung der damals verfügbaren KI-Tools länger brauchten, um Aufgaben zu erledigen. METR warnte ausdrücklich davor, dieses Ergebnis auf die Softwareentwicklung insgesamt zu verallgemeinern. In einer Folgestudie aus dem Jahr 2026 erklärte METR, es sei wahrscheinlich, dass Entwickler durch neuere KI-Tools eine grössere Beschleunigung erzielten, wies jedoch gleichzeitig darauf hin, dass eine breitere Einführung von KI und Veränderungen im Verhalten der Entwickler es zunehmend erschwert hätten, den Produktivitätseffekt zuverlässig zu messen.

Für Tech Buyers ergibt sich daraus daher nicht folgende Schlussfolgerung:

Durch KI werden externe Entwickler überflüssig.

Es lautet:

Wenn unser eigenes Entwicklungssystem bereits effizienter arbeiten kann, welchen Mehrwert muss dann ein externer Software Engineering Partner noch bieten?

Dieser Beitrag muss möglicherweise zunehmend über die reine Kapazität hinausgehen.

Die externe Nachfrage kann sich hin zu schwerer reproduzierbaren Capabilities verschieben

Da zunehmend mehr Aufgaben intern abgewickelt werden können, könnten Fähigkeiten, die sich nur schwer automatisieren, schnell erwerben oder von Grund auf entwickeln lassen, relativ gesehen an Wert gewinnen.

Beispiele hierfür sind:

• fundierte Fachkenntnisse,
• komplexe Software- und Plattformarchitektur,
• Fachwissen in den Bereichen Sicherheit und Regulierung,
• aufwändige Integrationsarbeit,
• Kenntnisse über Altsysteme,
• spezifisches technisches Fachwissen,
• unabhängige technische Überprüfung,
• Qualitäts- und Risikosicherung,
• die Übernahme klar definierter Lieferverantwortung.

Das bedeutet nicht, dass KI in diesen Bereichen keine Unterstützung leisten kann. Es bedeutet vielmehr, dass der Tech Buyer möglicherweise weiterhin Urteilsvermögen, Erfahrung, Verantwortungsbewusstsein und kontextbezogene Fachkenntnisse benötigt, die sich nicht einfach durch die Einbindung eines weiteren AI Agents in die interne Toolchain schaffen lassen.

Dies hat Auswirkungen darauf, wie die Capability Fit bewertet werden sollte.

Die Frage lautet nicht mehr nur:

Ist dieser Software Engineering Partner in der Lage, die Arbeit auszuführen?

Es wird zunehmend:

Was bietet dieser Software Engineering Partner zusätzlich, was unser eigenes Entwicklungssystem nicht zuverlässig leisten kann?

Neben einem geringeren Kapazitätsbedarf könnten sich neue Formen der externen Unterstützung entwickeln

Eine Abkehr von der generischen Kapazität bedeutet nicht zwangsläufig eine Abkehr von externer Unterstützung. Dies kann zu neuen Arten von Sourcing Needs führen.

Ein aktuelles Beispiel hierfür ist der „Forward Deployed Engineer“: eine seniorige technische Rolle, die eng beim Kunden eingebettet ist und die Bereiche Anforderungsermittlung, Architektur, Implementierung und Produktionsbereitstellung vereint. OpenAI beschreibt die FDE-Rolle derzeit als eine Aufgabe, die von der technischen Anforderungsermittlung und dem Systemdesign bis hin zur Entwicklung und Produktionsbereitstellung reicht und dabei eng mit den technischen und Fachteams des Kunden zusammenarbeitet.

Anthropic und DXC entwickeln zudem gezielt ein „Forward Deployed Engineer“-Modell für die Einführung von KI in Unternehmen, bei dem Ingenieure direkt in die Kundenorganisationen eingebunden werden.

Für Tech Buyers ist das Gesamtbild wichtiger als die Berufsbezeichnung.

Anstatt ein grosses externes Team zu beauftragen, kann es vorkommen, dass ein Unternehmen Folgendes benötigt:

• ein oder mehrere hochspezialisierte Embedded-Ingenieure,
• Fractional Technical Leadership,
• Fractional Architecture Leadership,
• Fachwissen im Bereich der KI-Transformation,
• temporäre Technical Governance,
• fachliche Unterstützung während einer Übergangsphase.

Diese Funktionen können ein internes Engineering-System ergänzen, anstatt es zu ersetzen.

Sie verdienen eine gesonderte Betrachtung, da sich ihre Auswahlkriterien, ihr Verantwortungsbereich und ihr Geschäftsmodell erheblich von denen einer klassischen Team Extension unterscheiden.

Manche Käufer lagern möglicherweise eine KI-Automatisierungslösung anstelle einzelner Projekte aus.

Ein weiteres mögliches Beschaffungsmodell ist ein externes „AI Automation Center of Excellence“ oder eine ähnliche Managed Capability.

Die Logik unterscheidet sich von der Auslagerung einer einzigen grossen Anwendung.

Ein spezialisierter Software Engineering Partner könnte ein Portfolio kleinerer KI- und Automatisierungsinitiativen im gesamten Unternehmen unterstützen, indem er Folgendes bereitstellt:

• wiederverwendbare Architekturen und Muster,
• Fachwissen in den Bereichen KI und Agenten,
• Sicherheits- und Governance-Rahmenwerke,
• Umsetzungskapazität,
• Bewertungsverfahren,
• Befähigung und Schulung,
• Empfehlungen dazu, welche Anwendungsfälle es wert sind, weiterverfolgt zu werden.

Dieses Modell befindet sich noch in der Entwicklungsphase und sollte daher nicht als etablierte Marktkategorie betrachtet werden.

Die zugrunde liegende Nachfrage ist jedoch erkennbar: Dienstleistungsunternehmen und KI-Anbieter bauen bereits spezielle Verfahren zur KI-Einführung, „Forward Deployed Engineering“-Teams und Kompetenzzentren auf, die darauf abzielen, KI in Unternehmen von der Experimentierphase in den produktiven Einsatz zu überführen. Anthropic und Accenture haben beispielsweise neben Kapazitäten für den Einsatz vor Ort ein spezielles „Claude Center of Excellence“ angekündigt.

Insbesondere für kleinere und mittelständische Unternehmen kann es ineffizient sein, jede spezialisierte KI-Fähigkeit dauerhaft im eigenen Haus aufzubauen.

Dies führt zu einer anderen Beschaffungsentscheidung:

Welche KI-Funktionen sollten in unser festes Entwicklungssystem integriert werden, und welche sollten besser als extern bereitgestellte Managed Capability genutzt werden?

Der Software Engineering Partner muss zunehmend in das Engineering-System des Tech Buyers passen

Wenn der Tech Buyer einen grösseren Teil seines Engineering-Systems selbst kontrolliert, muss die Partnerauswahl die Integration anders bewerten.

Es reicht nicht mehr aus, zu fragen, ob der Software Engineering Partner über einen eigenen, gut funktionierenden Entwicklungsprozess verfügt.

Tech Buyers sollten sich möglicherweise folgende Fragen stellen:

• Kann der Software Engineering Partner im Rahmen unserer Repositorys und technischen Standards arbeiten?
• Kann der Software Engineering Partner unsere AI-Tools und Agent-Workflows nutzen?
• Kann der Software Engineering Partner innerhalb unserer Architekturregeln und Quality Gates arbeiten?
• Wie funktioniert das mit unseren internen Plattformen und CI/CD?
• Welchen Unternehmenskontext benötigt der Software Engineering Partner?
• Auf welche Daten, welchen Code und welches geistige Eigentum hätten die KI-Tools des Unternehmens Zugriff?
• Wie werden von KI generierte Änderungen überprüft?
• Welche Entscheidungen liegen weiterhin in der Hand des Menschen?
• Kann der Software Engineering Partner wiederverwendbares Wissen in unser Entwicklungssystem einbringen?

Dies macht Engineering-System Fit zu einem wichtigen Aspekt bei der Software Engineering Partner Selection.

Dadurch gewinnt auch Governance an Bedeutung.

Die aktuellen agentic security principles von GitHub legen den Schwerpunkt auf Berechtigungen, Kontextgrenzen und die Verantwortung des Menschen, je mehr die Autonomie der Systeme zunimmt. Auch in den Leitlinien zur Code-Überprüfung bleibt die endgültige Entscheidung über die Zusammenführung weiterhin in menschlicher Hand, selbst wenn die KI einen immer grösseren Teil der Überprüfungsarbeit übernimmt.

Der Käufer muss daher nicht nur beurteilen, in welchem Umfang ein Software Engineering Partner Prozesse automatisieren kann, sondern auch, wie sicher und transparent sich diese Automatisierung in die Kontrollmechanismen des Unternehmens einfügt.

Ein höherer Durchsatz erhöht die Bedeutung der Verifizierung

Künstliche Intelligenz kann die Codegenerierung und die Ausführung von Änderungen beschleunigen. Das bedeutet jedoch nicht automatisch, dass die daraus resultierende Software besser ist.

Die Forschungsergebnisse von DORA unterstreichen, wie wichtig Tests, Rückkopplungsschleifen, Governance und solide Umsetzungspraktiken sind, während die Einführung von KI zunimmt.

Dies führt zu einer weiteren möglichen Veränderung des Wertes externer Partner.

Ein Software Engineering Partner kann zunehmend nicht nur durch die Entwicklung von Software, sondern auch durch folgende Massnahmen einen Mehrwert schaffen:

• Architektur validieren,
• Überprüfung der von der KI generierten Änderungen,
• das Testen komplexer Systeme,
• Risiken identifizieren,
• interne Annahmen hinterfragen,
• spezialisierte Security Reviews durchführen,
• eine unabhängige technische Perspektive zu vermitteln.

Für den Tech Buyer stellt sich nun folgende Frage bei der Auswahl:

Kann dieser Software Engineering Partner sowohl unser Vertrauen als auch unsere Leistungsfähigkeit steigern?

Dies stellt ein anderes Wertversprechen dar als die blosse Erweiterung der Kapazitäten.

Das Commercial Model könnte sich mit der veränderten Wertschöpfung verändern

Die KI stellt zudem die Art und Weise in Frage, wie Software Engineering Partner eingekauft werden.

Das „Time-and-Materials“-Modell wird nicht verschwinden. Es ist nach wie vor geeignet, wenn der Umfang ungewiss ist, eine kontinuierliche Zusammenarbeit stattfindet oder der Auftraggeber bewusst flexiblen Zugang zu Kapazitäten wünscht.

Wenn KI jedoch den für bestimmte Arten von Arbeit erforderlichen Aufwand erheblich reduziert, verliert der Aufwand als verlässlicher Indikator für den Wert an Bedeutung.

Tech Buyers könnten zunehmend kommerzielle Modelle in Betracht ziehen, die auf folgenden Faktoren basieren:

• eine klar definierte Leistung,
• eine definierte Transformation,
• ein klar abgegrenzter Verantwortungsbereich,
• eine auf den Käufer zugeschnittene, wiederverwendbare Lösung,
• messbare operative Ergebnisse,
• spezielle Kompetenz, die für einen bestimmten Zweck bereitgestellt wird.

Festpreis- und ergebnisorientierte Modelle sind nicht dasselbe. Ein Festpreis kann nach wie vor lediglich den geschätzten Aufwand abbilden. Ein ergebnisorientiertes Modell geht von dem Beitrag oder Ergebnis aus, den bzw. das der Käufer tatsächlich erwirbt.

Diese Unterscheidung dürfte zunehmend an Bedeutung gewinnen, wenn Software Engineering Partner KI einsetzen, um den Aufwand für die Ausführung zu reduzieren.

Dies verdient einen eigenen, ausführlicheren „ValueLeap Insight“.

KI kann zudem beeinflussen, welche Projekte wirtschaftlich rentabel sind

Dieser Effekt beschränkt sich nicht auf Neuentwicklung.

Die Modernisierung von Anwendungen ist ein gutes Beispiel dafür.

In der Vergangenheit entfiel ein erheblicher Teil der Modernisierungskosten auf die Analyse grosser Legacy-Systemlandschaften, die Dokumentation des Verhaltens, die Ermittlung von Abhängigkeiten, die Neuprogrammierung des Codes sowie die Überprüfung, ob das umgestaltete System weiterhin ordnungsgemäss funktionierte.

KI-gestützte Tools zielen zunehmend genau auf diese Aufgaben ab. AWS bietet beispielsweise mittlerweile agentenbasierte Tools für wiederholbare Code- und Anwendungstransformationen an, während Google Cloud generative KI für die Bewertung, Transformation und das Testen von Mainframe-Systemen einsetzt.

Das macht Application Modernization jedoch nicht trivial.

Dies kann jedoch die wirtschaftlichen Rahmenbedingungen so stark verändern, dass Tech Buyers Projekte erneut prüfen sollten, die zuvor als zu teuer, zu langsam oder zu schwierig angesehen wurden.

Dadurch ändern sich auch die Anforderungen an die Beschaffung.

Der wertvollste Software Engineering Partner ist möglicherweise nicht mehr das Unternehmen, das das grösste Migrationsteam stellen kann. Es könnte vielmehr der Partner sein, der folgende Eigenschaften vereint:

• eine leistungsfähige Modernisierungsarchitektur,
• Kenntnisse über Altsysteme,
• KI-gestützte Transformationsfähigkeit,
• Prüfung und Verifizierung,
• Verantwortung für einen geordneten Übergang.

Auch hier verlagert sich der Schwerpunkt von der Kapazität hin zum Beitrag.

Was ändert sich bei der Software Engineering Partner Selection?

Für einen AI-nativen Tech Buyer ist eine traditionelle Bewertung der Fähigkeiten und der Leistungserbringung nach wie vor von Bedeutung.

Doch das reicht möglicherweise nicht mehr aus.

Sieben weitere Fragen erweisen sich zunehmend als nützlich:

1. Welche entscheidende Kompetenz bringt der Software Engineering Partner mit?

Ist es schwierig, diesen Beitrag intern nachzuvollziehen, oder erwerben wir in erster Linie zusätzliche Ausführungskapazitäten?

2. Inwieweit passt der Software Engineering Partner zu unserem Entwicklungssystem?

Kann der Software Engineering Partner innerhalb unserer Repositories, Plattformen, AI-Workflows, Standards und Kontrollmechanismen arbeiten?

3. Welchen zusätzlichen Kontext bringt der Software Engineering Partner ein?

Bringt er Domänenwissen, Architekturerfahrung, spezialisierte Technologiekenntnisse oder Erkenntnisse aus vergleichbaren Situationen mit?

4. Inwiefern trägt dies zur Verbesserung der Überprüfung und des Vertrauens bei?

Kann dies dazu beitragen, KI-gestützte Arbeitsabläufe zu validieren, anstatt lediglich den Arbeitsertrag zu steigern?

5. Welche Verantwortung kann der Software Engineering Partner tatsächlich übernehmen?

Stellt der Partner Personal, Fachkompetenz, ein definiertes Ergebnis oder die Verantwortung für ein Ergebnis bereit?

6. Wie lässt sich die AI-enabled Delivery weiterhin kontrollieren?

Sind Sicherheit, Berechtigungen, Kontextgrenzen, die Überprüfung durch Menschen und die Rechenschaftspflicht klar geregelt?

7. Spiegelt das Geschäftsmodell den Beitrag wider?

Bezahlen wir für den Aufwand, weil wir diesen Aufwand tatsächlich benötigen, oder weil Software-Dienstleistungen traditionell auf diese Weise erworben werden?

Diese Fragen ersetzen nicht die bestehende Partner Evaluation.

Sie verändern dessen Schwerpunkt.