Es ist unwahrscheinlich, dass dies lediglich zu einem R\u00fcckgang bei externen Softwaredienstleistungen f\u00fchren wird. Eine plausiblere Entwicklung w\u00e4re vielmehr eine Ver\u00e4nderung hinsichtlich des Volumens, der Zusammensetzung und des Wertversprechens der externen Nachfrage<\/strong>.<\/p>\n\n\n\n In diesem Insight bezeichnet der Begriff \u201eAI-native Engineering\u201c<\/strong> eine Entwicklungsumgebung, in der KI-Agenten und Automatisierung in den Prozess der Konzeption, Entwicklung, Testing, Review und Betrieb von Software integriert sind.<\/p>\n\n\n\n Dazu k\u00f6nnen geh\u00f6ren:<\/p>\n\n\n\n Dies unterscheidet sich davon, einzelnen Entwicklern lediglich einen KI-Programmierassistenten zur Verf\u00fcgung zu stellen.<\/p>\n\n\n\n Die DORA-Studie aus dem Jahr 2025<\/a> beschreibt KI als Verst\u00e4rker des zugrunde liegenden technischen Systems<\/strong>: Organisationen mit soliden Plattformen, Prozessen und R\u00fcckkopplungsschleifen sind besser in der Lage, den Einsatz von KI in n\u00fctzliche Ergebnisse umzusetzen, w\u00e4hrend sich bei schwachen Systemen deren Probleme ebenfalls verst\u00e4rken k\u00f6nnen.<\/p>\n\n\n\n GitHub schl\u00e4gt auf Produktebene einen \u00e4hnlichen Weg ein und positioniert Agenten als Teil einer koordinierten Entwicklungsumgebung mit Code-Review, Unternehmenskontrollen und Governance und nicht als isolierte Entwicklertools.<\/p>\n\n\n\n F\u00fcr einen Tech Buyer ist dies von Bedeutung, da das Unternehmen selbst zunehmend einen gr\u00f6sseren Teil des Engineering-Systems selbst betreiben kann.<\/p>\n\n\n\n Traditionell k\u00f6nnte ein externer Software Engineering Partner ein relativ umfassendes Delivery Setup mitbringen:<\/p>\n\n\n\n Der Tech Buyer konnte die Anforderungen definieren und sich anschliessend bei der Organisation der Umsetzung weitgehend auf den Software Engineering Partner verlassen.<\/p>\n\n\n\n In einer KI-nativen Umgebung kann ein gr\u00f6sserer Teil dieser Koordination innerhalb der Organisation des Eink\u00e4ufers verbleiben.<\/p>\n\n\n\n Interne Teams k\u00f6nnen KI nutzen, um ein breiteres Spektrum an Entwicklungsaufgaben durchzuf\u00fchren oder zu koordinieren. Der Einsatz von KI breitet sich zudem \u00fcber Berufsgruppen hinaus, die \u00fcber die Softwareentwicklung hinausgehen, auch wenn die Akzeptanz nach wie vor sehr uneinheitlich ist. Die Untersuchungen des Economic Index von Anthropic<\/a> zeigen sowohl den besonders starken Einsatz von KI bei der Softwareentwicklung als auch eine erhebliche Nutzung in Bereichen wie Wirtschaft, Verwaltung, Bildung und Medien. <\/p>\n\n\n\n Das bedeutet jedoch nicht<\/strong>, dass Gesch\u00e4ftsanwender pl\u00f6tzlich die professionelle Softwareentwicklung ersetzen.<\/p>\n\n\n\n Dies deutet darauf hin, dass einige kleinere Automatisierungen, interne Tools, Analyseaufgaben, Prototypen und Verbesserungen der Arbeitsabl\u00e4ufe n\u00e4her an die Personen herangef\u00fchrt werden k\u00f6nnen, die das gesch\u00e4ftliche Problem verstehen.<\/p>\n\n\n\n Die Frage nach der Beschaffung r\u00fcckt somit eine Ebene h\u00f6her:<\/p>\n\n\n\n Was sollten wir selbst entwickeln und koordinieren, und wo ben\u00f6tigen wir noch externe Unterst\u00fctzung?<\/strong><\/p>\n<\/blockquote>\n\n\n\n Zus\u00e4tzliche technische Kapazit\u00e4ten werden nicht wegfallen.<\/p>\n\n\n\n Komplexe Produkte erfordern nach wie vor den Einsatz von Menschen. Grosse Transformationen erfordern weiterhin erhebliche Umsetzungskapazit\u00e4t. Interne Teams werden auch weiterhin mit Kapazit\u00e4tsengp\u00e4ssen konfrontiert sein.<\/p>\n\n\n\n Wenn KI es jedoch einem bestehenden Entwicklerteam erm\u00f6glicht, mehr zu leisten, kann die F\u00e4higkeit, zus\u00e4tzliche Entwickler bereitzustellen, als eigenst\u00e4ndiges Unterscheidungsmerkmal an Bedeutung verlieren<\/strong>.<\/p>\n\n\n\n Der Produktivit\u00e4tseffekt sollte nicht \u00fcberbewertet werden. Forschungsergebnisse zeigen nach wie vor erhebliche Unterschiede je nach Kontext. Eine kontrollierte Studie von METR aus dem Fr\u00fchjahr 2025<\/a> ergab, dass erfahrene Open-Source-Entwickler, die an ihren eigenen Repositories arbeiteten, bei der Verwendung der damals verf\u00fcgbaren KI-Tools l\u00e4nger brauchten, um Aufgaben zu erledigen. METR warnte ausdr\u00fccklich davor, dieses Ergebnis auf die Softwareentwicklung insgesamt zu verallgemeinern. In einer Folgestudie aus dem Jahr 2026<\/a> erkl\u00e4rte METR, es sei wahrscheinlich, dass Entwickler durch neuere KI-Tools eine gr\u00f6ssere Beschleunigung erzielten, wies jedoch gleichzeitig darauf hin, dass eine breitere Einf\u00fchrung von KI und Ver\u00e4nderungen im Verhalten der Entwickler es zunehmend erschwert h\u00e4tten, den Produktivit\u00e4tseffekt zuverl\u00e4ssig zu messen.<\/p>\n\n\n\n F\u00fcr Tech Buyers ergibt sich daraus daher nicht folgende Schlussfolgerung:<\/p>\n\n\n\n Durch KI werden externe Entwickler \u00fcberfl\u00fcssig.<\/p>\n<\/blockquote>\n\n\n\n Es lautet:<\/p>\n\n\n\n Wenn unser eigenes Entwicklungssystem bereits effizienter arbeiten kann, welchen Mehrwert muss dann ein externer Software Engineering Partner noch bieten?<\/strong><\/p>\n<\/blockquote>\n\n\n\n Dieser Beitrag muss m\u00f6glicherweise zunehmend \u00fcber die reine Kapazit\u00e4t hinausgehen.<\/p>\n\n\n\n Da zunehmend mehr Aufgaben intern abgewickelt werden k\u00f6nnen, k\u00f6nnten F\u00e4higkeiten, die sich nur schwer automatisieren, schnell erwerben oder von Grund auf entwickeln lassen, relativ gesehen an Wert gewinnen.<\/p>\n\n\n\n Beispiele hierf\u00fcr sind:<\/p>\n\n\n\n Das bedeutet nicht, dass KI in diesen Bereichen keine Unterst\u00fctzung leisten kann. Es bedeutet vielmehr, dass der Tech Buyer m\u00f6glicherweise weiterhin Urteilsverm\u00f6gen, Erfahrung, Verantwortungsbewusstsein und kontextbezogene Fachkenntnisse<\/strong> ben\u00f6tigt, die sich nicht einfach durch die Einbindung eines weiteren AI Agents in die interne Toolchain schaffen lassen.<\/p>\n\n\n\n Dies hat Auswirkungen darauf, wie die Capability Fit bewertet werden sollte.<\/p>\n\n\n\n Die Frage lautet nicht mehr nur:<\/p>\n\n\n\n Ist dieser Software Engineering Partner in der Lage, die Arbeit auszuf\u00fchren?<\/p>\n<\/blockquote>\n\n\n\n Es wird zunehmend:<\/p>\n\n\n\n Was bietet dieser Software Engineering Partner zus\u00e4tzlich, was unser eigenes Entwicklungssystem nicht zuverl\u00e4ssig leisten kann?<\/strong><\/p>\n<\/blockquote>\n\n\n\n Eine Abkehr von der generischen Kapazit\u00e4t bedeutet nicht zwangsl\u00e4ufig eine Abkehr von externer Unterst\u00fctzung. Dies kann zu neuen Arten von Sourcing Needs f\u00fchren.<\/p>\n\n\n\n\n\n\n\n Ein aktuelles Beispiel hierf\u00fcr ist der \u201eForward Deployed Engineer\u201c<\/a><\/strong>: 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.<\/p>\n\n\n\n Anthropic und DXC entwickeln zudem gezielt ein \u201eForward Deployed Engineer\u201c-Modell f\u00fcr die Einf\u00fchrung von KI in Unternehmen, bei dem Ingenieure direkt in die Kundenorganisationen eingebunden werden.<\/p>\n\n\n\n F\u00fcr Tech Buyers ist das Gesamtbild wichtiger als die Berufsbezeichnung.<\/p>\n\n\n\n Anstatt ein grosses externes Team zu beauftragen, kann es vorkommen, dass ein Unternehmen Folgendes ben\u00f6tigt:<\/p>\n\n\n\n Diese Funktionen k\u00f6nnen ein internes Engineering-System erg\u00e4nzen, anstatt es zu ersetzen.<\/p>\n\n\n\n Sie verdienen eine gesonderte Betrachtung, da sich ihre Auswahlkriterien, ihr Verantwortungsbereich und ihr Gesch\u00e4ftsmodell erheblich von denen einer klassischen Team Extension unterscheiden.<\/p>\n\n\n\n Ein weiteres m\u00f6gliches Beschaffungsmodell ist ein externes \u201eAI Automation Center of Excellence\u201c<\/strong> oder eine \u00e4hnliche Managed Capability.<\/p>\n\n\n\n Die Logik unterscheidet sich von der Auslagerung einer einzigen grossen Anwendung.<\/p>\n\n\n\n Ein spezialisierter Software Engineering Partner k\u00f6nnte ein Portfolio kleinerer KI- und Automatisierungsinitiativen im gesamten Unternehmen unterst\u00fctzen, indem er Folgendes bereitstellt:<\/p>\n\n\n\n Dieses Modell befindet sich noch in der Entwicklungsphase und sollte daher nicht als etablierte Marktkategorie betrachtet werden.<\/p>\n\n\n\n Die zugrunde liegende Nachfrage ist jedoch erkennbar: Dienstleistungsunternehmen und KI-Anbieter bauen bereits spezielle Verfahren zur KI-Einf\u00fchrung, \u201eForward Deployed Engineering\u201c-Teams<\/a> und Kompetenzzentren auf, die darauf abzielen, KI in Unternehmen von der Experimentierphase in den produktiven Einsatz zu \u00fcberf\u00fchren. Anthropic und Accenture haben beispielsweise neben Kapazit\u00e4ten f\u00fcr den Einsatz vor Ort ein spezielles \u201eClaude Center of Excellence\u201c angek\u00fcndigt. <\/p>\n\n\n\n Insbesondere f\u00fcr kleinere und mittelst\u00e4ndische Unternehmen kann es ineffizient sein, jede spezialisierte KI-F\u00e4higkeit dauerhaft im eigenen Haus aufzubauen.<\/p>\n\n\n\n Dies f\u00fchrt zu einer anderen Beschaffungsentscheidung:<\/p>\n\n\n\n Welche KI-Funktionen sollten in unser festes Entwicklungssystem integriert werden, und welche sollten besser als extern bereitgestellte Managed Capability genutzt werden?<\/strong><\/p>\n<\/blockquote>\n\n\n\n Wenn der Tech Buyer einen gr\u00f6sseren Teil seines Engineering-Systems selbst kontrolliert, muss die Partnerauswahl die Integration anders bewerten.<\/p>\n\n\n\n Es reicht nicht mehr aus, zu fragen, ob der Software Engineering Partner \u00fcber einen eigenen, gut funktionierenden Entwicklungsprozess verf\u00fcgt.<\/p>\n\n\n\n Tech Buyers sollten sich m\u00f6glicherweise folgende Fragen stellen:<\/p>\n\n\n\n Dies macht Engineering-System Fit<\/strong> zu einem wichtigen Aspekt bei der Software Engineering Partner Selection.<\/p>\n\n\n\n Dadurch gewinnt auch Governance an Bedeutung.<\/p>\n\n\n\n Die aktuellen agentic security principles von GitHub<\/a> legen den Schwerpunkt auf Berechtigungen, Kontextgrenzen und die Verantwortung des Menschen, je mehr die Autonomie der Systeme zunimmt. Auch in den Leitlinien zur Code-\u00dcberpr\u00fcfung bleibt die endg\u00fcltige Entscheidung \u00fcber die Zusammenf\u00fchrung weiterhin in menschlicher Hand, selbst wenn die KI einen immer gr\u00f6sseren Teil der \u00dcberpr\u00fcfungsarbeit \u00fcbernimmt.<\/p>\n\n\n\n Der K\u00e4ufer 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\u00fcgt<\/strong>.<\/p>\n\n\n\n K\u00fcnstliche Intelligenz kann die Codegenerierung und die Ausf\u00fchrung von \u00c4nderungen beschleunigen. Das bedeutet jedoch nicht automatisch, dass die daraus resultierende Software besser ist. <\/p>\n\n\n\n Die Forschungsergebnisse von DORA unterstreichen, wie wichtig Tests, R\u00fcckkopplungsschleifen, Governance und solide Umsetzungspraktiken sind, w\u00e4hrend die Einf\u00fchrung von KI zunimmt.<\/p>\n\n\n\n Dies f\u00fchrt zu einer weiteren m\u00f6glichen Ver\u00e4nderung des Wertes externer Partner.<\/p>\n\n\n\n Ein Software Engineering Partner kann zunehmend nicht nur durch die Entwicklung von Software, sondern auch durch folgende Massnahmen einen Mehrwert schaffen:<\/p>\n\n\n\n F\u00fcr den Tech Buyer stellt sich nun folgende Frage bei der Auswahl:<\/p>\n\n\n\n Kann dieser Software Engineering Partner sowohl unser Vertrauen als auch unsere Leistungsf\u00e4higkeit steigern?<\/strong><\/p>\n<\/blockquote>\n\n\n\n Dies stellt ein anderes Wertversprechen dar als die blosse Erweiterung der Kapazit\u00e4ten.<\/p>\n\n\n\n Die KI stellt zudem die Art und Weise in Frage, wie Software Engineering Partner eingekauft werden.<\/p>\n\n\n\n Das \u201eTime-and-Materials\u201c-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\u00e4ten w\u00fcnscht. <\/p>\n\n\n\n Wenn KI jedoch den f\u00fcr bestimmte Arten von Arbeit erforderlichen Aufwand erheblich reduziert, verliert der Aufwand als verl\u00e4sslicher Indikator f\u00fcr den Wert an Bedeutung<\/strong>.<\/p>\n\n\n\n Tech Buyers k\u00f6nnten zunehmend kommerzielle Modelle in Betracht ziehen, die auf folgenden Faktoren basieren:<\/p>\n\n\n\n Festpreis- und ergebnisorientierte Modelle sind nicht dasselbe. Ein Festpreis kann nach wie vor lediglich den gesch\u00e4tzten Aufwand abbilden. Ein ergebnisorientiertes Modell geht von dem Beitrag oder Ergebnis aus, den bzw. das der K\u00e4ufer tats\u00e4chlich erwirbt. <\/p>\n\n\n\n Diese Unterscheidung d\u00fcrfte zunehmend an Bedeutung gewinnen, wenn Software Engineering Partner KI einsetzen, um den Aufwand f\u00fcr die Ausf\u00fchrung zu reduzieren.<\/p>\n\n\n\n Dies verdient einen eigenen, ausf\u00fchrlicheren \u201eValueLeap Insight\u201c.<\/p>\n\n\n\n Dieser Effekt beschr\u00e4nkt sich nicht auf Neuentwicklung.<\/p>\n\n\n\n Die Modernisierung von Anwendungen ist ein gutes Beispiel daf\u00fcr.<\/p>\n\n\n\n In der Vergangenheit entfiel ein erheblicher Teil der Modernisierungskosten auf die Analyse grosser Legacy-Systemlandschaften, die Dokumentation des Verhaltens, die Ermittlung von Abh\u00e4ngigkeiten, die Neuprogrammierung des Codes sowie die \u00dcberpr\u00fcfung, ob das umgestaltete System weiterhin ordnungsgem\u00e4ss funktionierte.<\/p>\n\n\n\n KI-gest\u00fctzte Tools zielen zunehmend genau auf diese Aufgaben ab. AWS bietet beispielsweise mittlerweile agentenbasierte Tools f\u00fcr wiederholbare Code- und Anwendungstransformationen<\/a> an, w\u00e4hrend Google Cloud generative KI f\u00fcr die Bewertung, Transformation und das Testen von Mainframe-Systemen einsetzt. <\/p>\n\n\n\n Das macht Application Modernization jedoch nicht trivial.<\/p>\n\n\n\n Dies kann jedoch die wirtschaftlichen Rahmenbedingungen so stark ver\u00e4ndern, dass Tech Buyers Projekte erneut pr\u00fcfen sollten, die zuvor als zu teuer, zu langsam oder zu schwierig angesehen wurden.<\/p>\n\n\n\n Dadurch \u00e4ndern sich auch die Anforderungen an die Beschaffung.<\/p>\n\n\n\n Der wertvollste Software Engineering Partner ist m\u00f6glicherweise nicht mehr das Unternehmen, das das gr\u00f6sste Migrationsteam stellen kann. Es k\u00f6nnte vielmehr der Partner sein, der folgende Eigenschaften vereint:<\/p>\n\n\n\n Auch hier verlagert sich der Schwerpunkt von der Kapazit\u00e4t hin zum Beitrag<\/strong>.<\/p>\n\n\n\n F\u00fcr einen AI-nativen Tech Buyer ist eine traditionelle Bewertung der F\u00e4higkeiten und der Leistungserbringung nach wie vor von Bedeutung.<\/p>\n\n\n\n Doch das reicht m\u00f6glicherweise nicht mehr aus.<\/p>\n\n\n\n Sieben weitere Fragen erweisen sich zunehmend als n\u00fctzlich:<\/p>\n\n\n\n Ist es schwierig, diesen Beitrag intern nachzuvollziehen, oder erwerben wir in erster Linie zus\u00e4tzliche Ausf\u00fchrungskapazit\u00e4ten?<\/p>\n\n\n\n Kann der Software Engineering Partner innerhalb unserer Repositories, Plattformen, AI-Workflows, Standards und Kontrollmechanismen arbeiten?<\/p>\n\n\n\n Bringt er Dom\u00e4nenwissen, Architekturerfahrung, spezialisierte Technologiekenntnisse oder Erkenntnisse aus vergleichbaren Situationen mit?<\/p>\n\n\n\n Kann dies dazu beitragen, KI-gest\u00fctzte Arbeitsabl\u00e4ufe zu validieren, anstatt lediglich den Arbeitsertrag zu steigern?<\/p>\n\n\n\n Stellt der Partner Personal, Fachkompetenz, ein definiertes Ergebnis oder die Verantwortung f\u00fcr ein Ergebnis bereit?<\/p>\n\n\n\n Sind Sicherheit, Berechtigungen, Kontextgrenzen, die \u00dcberpr\u00fcfung durch Menschen und die Rechenschaftspflicht klar geregelt?<\/p>\n\n\n\n Bezahlen wir f\u00fcr den Aufwand, weil wir diesen Aufwand tats\u00e4chlich ben\u00f6tigen, oder weil Software-Dienstleistungen traditionell auf diese Weise erworben werden?<\/p>\n\n\n\n![\"\"](\"https:\/\/valueleap.io\/wp-content\/uploads\/2026\/08\/d783b305-3740-434a-9dcc-ad65746c5a7c-1024x683.png\")
<\/figure>\n\n\n\nWas verstehen wir unter \u201eAI-native Engineering\u201c?<\/h2>\n\n\n\n
\n
Die Sourcing-Grenze beginnt sich zu verschieben<\/h2>\n\n\n\n
\n
\n
Generische Umsetzungskapazit\u00e4t kann als eigenst\u00e4ndiges Wertversprechen an Bedeutung verlieren<\/h2>\n\n\n\n
\n
\n
Die externe Nachfrage kann sich hin zu schwerer reproduzierbaren Capabilities verschieben<\/h2>\n\n\n\n
\n
\n
\n
Neben einem geringeren Kapazit\u00e4tsbedarf k\u00f6nnten sich neue Formen der externen Unterst\u00fctzung entwickeln<\/h2>\n\n\n\n
\n
Manche K\u00e4ufer lagern m\u00f6glicherweise eine KI-Automatisierungsl\u00f6sung anstelle einzelner Projekte aus.<\/h2>\n\n\n\n
\n
\n
Der Software Engineering Partner muss zunehmend in das Engineering-System des Tech Buyers passen<\/h2>\n\n\n\n
\n
Ein h\u00f6herer Durchsatz erh\u00f6ht die Bedeutung der Verifizierung<\/h2>\n\n\n\n
\n
\n
Das Commercial Model k\u00f6nnte sich mit der ver\u00e4nderten Wertsch\u00f6pfung ver\u00e4ndern<\/h2>\n\n\n\n
\n
KI kann zudem beeinflussen, welche Projekte wirtschaftlich rentabel sind<\/h2>\n\n\n\n
\n
Was \u00e4ndert sich bei der Software Engineering Partner Selection?<\/h2>\n\n\n\n
1. Welche entscheidende Kompetenz bringt der Software Engineering Partner mit?<\/h3>\n\n\n\n
2. Inwieweit passt der Software Engineering Partner zu unserem Entwicklungssystem?<\/h3>\n\n\n\n
3. Welchen zus\u00e4tzlichen Kontext bringt der Software Engineering Partner ein?<\/h3>\n\n\n\n
4. Inwiefern tr\u00e4gt dies zur Verbesserung der \u00dcberpr\u00fcfung und des Vertrauens bei?<\/h3>\n\n\n\n
5. Welche Verantwortung kann der Software Engineering Partner tats\u00e4chlich \u00fcbernehmen?<\/h3>\n\n\n\n
6. Wie l\u00e4sst sich die AI-enabled Delivery weiterhin kontrollieren?<\/h3>\n\n\n\n
7. Spiegelt das Gesch\u00e4ftsmodell den Beitrag wider?<\/h3>\n\n\n\n