MCSQ TECH
← Alle Insights

Für Hersteller und Entwickler

Der KI-Prototyp funktioniert. Wozu noch Ingenieure?

Ein Kunde kommt mit einem KI-Prototyp. Wofür bezahlt er dann noch ein Engineering-Unternehmen? Der Wert wandert von der ersten Version zur Verantwortung.

Alex Varabyou

Zuerst veröffentlicht auf LinkedIn am
überarbeitet am

Diesen Artikel auf Englisch lesen

KIEngineeringPrototypHardwareSoftware

Ein Mann stützt das Kinn in die Hand, während ein kleiner Roboter auf einem Werkstatttisch einen Laptop mit einem Prototyp vorführt
Die KI brachte den Prototyp. Ich brachte die Frage, die sie nicht beantworten konnte: Wer verantwortet ihn nach der Demo?

Im nächsten Jahr schickt ein Kunde vielleicht einen Roboter in den Termin, statt selbst zu kommen. Er rollt in den Raum, stellt einen Laptop auf den Tisch und zeigt mir einen funktionierenden Prototyp, der übers Wochenende mit KI-Agenten gebaut wurde.

„Hier ist er. Er funktioniert. Wozu brauchen wir Ihre Ingenieure?“, fragt der Roboter im Auftrag des Kunden.

Vielleicht ist der Roboter ein wenig zu früh dran. Die Frage kommt genau zur rechten Zeit.

Die Szene ist spekulativ. Die Verschiebung beim Einkauf ist schon sichtbar. In McKinseys globaler Umfrage 2026 gaben 32 % der Befragten an, ihre Organisationen hätten sich gegen den Kauf mindestens eines Softwareprodukts oder einer Funktion entschieden, weil sie glaubten, es mit agentischem Coding selbst bauen zu können. Das ist ein Umfrageergebnis, keine Prognose für den Anteil am gesamten Softwaremarkt. Es deutet dennoch auf eine veränderte Ausgangslage hin: Manche Kunden erwarten bereits, die erste Version selbst zu bauen.

Wenn die KI den Prototyp erstellt, wofür bezahlt ein Kunde dann ein Engineering-Unternehmen?

Mein Weg zu dieser Frage ist praktisch. Ich komme aus den Geisteswissenschaften und der Unternehmensführung. Seit mehr als einem Jahr nutze ich KI-Agenten, um aus Ideen funktionierende Anwendungen zu machen. Ich habe gesehen, wie schnell eine erste Version entstehen kann und wie viel Arbeit danach bleibt.

Der aufschlussreiche Moment kommt oft bei der zweiten ernsthaften Änderung. Das Modell austauschen. Ein Unternehmenssystem anbinden. Die Datenstruktur ändern. Zugriffskontrollen ergänzen. Das Projekt an einen anderen Ingenieur übergeben und dabei kritische Funktionen zuverlässig halten.

Dann zeigt sich, ob der Prototyp eine Architektur hat, die Menschen verstehen und weiterentwickeln können.

Auch die Dokumentation zählt hier. Ein neuer Ingenieur muss wissen, warum es bestimmte Komponenten gibt, wie Entscheidungen getroffen wurden und was weiter funktionieren muss. KI kann neben dem Code Architekturentscheidungen, Komponentenübersichten, Tests, Release Notes und Übergabeanleitungen erstellen.

Das eröffnet die Möglichkeit besser dokumentierter Projekte. Sie hängt davon ab, dass diese Unterlagen mit dem tatsächlichen System, seinen Entscheidungen und den Abnahmekriterien verbunden bleiben und bei der Übergabe geprüft werden. Sonst kann KI veraltete Dokumente schneller erzeugen.

Schnellere Generierung bedeutet nicht schnellere Produktentwicklung

KI beschleunigt bereits Teile der Softwarearbeit. Die Belege zeigen nicht, dass dadurch automatisch der gesamte Weg von der Idee zum verlässlichen Produkt schneller wird.

In einer McKinsey-Umfrage unter 334 Befragten aus Produkt und Engineering berichteten 25 % der Befragten auf Director-Ebene und darüber (n=173) von spürbarer KI-Beschleunigung, während 30 % sagten, die Produktivität ihrer Teams sei gesunken. Die Umfrage zeigt unterschiedliche Ergebnisse in verschiedenen Teams.

Die qualitative Analyse von 1.110 offenen Antworten von Google-Ingenieuren durch DORA beschreibt eine ähnliche Spannung: KI kann die erste Ausgabe beschleunigen und zugleich den Aufwand erhöhen, sie zu prüfen, und sie kann Schwächen eines Engineering-Systems verstärken. Das ist eine qualitative Studie, kein allgemeingültiges Maß für jedes Team.

METR warnt ebenfalls davor, Ergebnisse von Agenten bei gut spezifizierten, automatisch bewerteten Aufgaben in Vorhersagen für ganze Berufe zu übertragen. Echte Projekte bringen Mehrdeutigkeit, Altsysteme, physische Randbedingungen, Verhandlungen und Folgen mit, die kein einzelner automatischer Test erfasst. METR trennt das ausdrücklich.

Eine Demo zeigt, dass eine Idee funktionieren kann. Engineering muss zeigen, dass das Produkt in der realen Welt bestehen kann. Die Realität bringt alte Datenbanken, Lieferzeiten für Bauteile, Auditoren, Sicherheitsanforderungen und Nutzer, die doppelt klicken.

Drei Karten, Demo, reale Welt und Lebenszyklus, durch Pfeile verbunden
Die KI brachte uns bis zur Demo. Dann saßen echte Daten und Berechtigungen mit am Tisch.

Kunden werden fünf verschiedene Dinge kaufen

Diskussionen über die Zukunft des Engineerings vermischen oft mehrere Geschäftsmodelle. KI wird jedes davon anders treffen.

Software-Engineering-Dienstleistungen

Am stärksten unter Preisdruck gerät Arbeit, die vor allem an Codezeilen oder geschlossenen Tickets gemessen wird. Boilerplate-Code, einfache CRUD-Anwendungen, Standard-Dashboards und erste Entwürfe von Tests oder Dokumentation werden billiger in der Herstellung.

Kunden werden weiterhin individuelles Engineering brauchen. Sie werden für Architektur, Integration in echte Systeme, Fachlogik, Sicherheit, Verifikation, Change Management und Support zahlen.

Die Grenze zwischen probabilistischer und deterministischer Logik wird wichtiger. Ein Modell kann eine Klassifikation, einen Text oder eine mögliche Aktion vorschlagen. Wenn eine Aktion Geld, Sicherheit, Produktion oder Compliance betrifft, muss jemand die genauen Regeln festlegen, die zulässigen Fehlerarten und wie das Ergebnis geprüft wird.

Code wird billiger. Das Urteil darüber, wo ein System nicht versagen darf, wird es nicht.

SaaS

Kunden werden einzelne SaaS-Funktionen schneller nachbauen können. Eine einfache Oberfläche über einem Modell, ein weiteres Dashboard oder eine schmale Automatisierung lässt sich leichter reproduzieren als früher.

Der Wert von SaaS liegt in einem verlässlichen Betriebsprozess: Verfügbarkeit, Sicherheit, Updates, Zugriffskontrolle, Integrationen, Datenintegrität, vorhersehbare Qualität und Support.

Am stärksten gefährdet sind dünne Wrapper ohne tiefen Workflow, ohne wertvolles Betriebswissen, ohne echte Integrationen und ohne Verantwortung für ein Ergebnis. Starkes SaaS verkauft Arbeit, die verlässlich erledigt wird.

Hardware-Entwicklung

Die physische Welt setzt der Geschwindigkeit von Software eigene Grenzen.

KI kann helfen, eine Spezifikation zu entwerfen, eine Architektur vorzuschlagen oder einen ersten Schaltplan oder Embedded-Code zu erzeugen. Das Produkt muss trotzdem die Anforderungen an elektromagnetische Verträglichkeit, Thermik und Signalintegrität erfüllen, die FPGA-Randbedingungen einhalten, mit der Verfügbarkeit von Bauteilen zurechtkommen, im Labor getestet, zertifiziert und für die Produktion vorbereitet werden.

In meiner eigenen Arbeit mit Hardware kam es an einem Punkt auf spezialisierte FPGA-Expertise an, an dem ein weiterer generierter Entwurf sie nicht ersetzen konnte.

Kunden werden für Hardware-Software-Co-Design, physische Verifikation, Bring-up, Laborarbeit, das Management von Bauteilrisiken, Produktionsvorbereitung und Support über den Lebenszyklus zahlen. KI kann einen Designentwurf beschleunigen. Das Gerät muss trotzdem in der physischen Welt funktionieren.

Hardware-as-a-Service

Bei Hardware-as-a-Service zahlt der Kunde für die Verfügbarkeit von Geräten oder für das Ergebnis, das sie über die Zeit liefern. Der Anbieter übernimmt unter Umständen die Verantwortung für Telemetrie, Wartung, Austausch, Upgrades, Ersatzteile, Finanzierung und Restrisiko.

Das passt zu einer breiteren Bewegung der Industrieservices hin zu laufenden Ergebnissen und Servicemodellen. Die Studie von IFS und Accenture aus dem Jahr 2025 untersucht diesen Trend bei Führungskräften in der Fertigung.

Der Wert entsteht daraus, ein physisches System über die Zeit nützlich zu halten. Das verlangt neben dem ursprünglichen Design auch Betrieb, Support im Feld und Entscheidungen über den Lebenszyklus.

KI-as-a-Service

Eine Modell-API ist nur eine Komponente von KI-as-a-Service. Der Kunde zahlt für eine verwaltete Fähigkeit, die nützliche Arbeit mit definierten Daten und Berechtigungen leistet, mit Qualitätsprüfungen, Kostenkontrolle, Protokollierung, Sicherheit und menschlicher Eskalation.

NIST unterscheidet Agentenwerkzeuge nach Zugriffsstufen, von nur lesend über eingeschränkt schreibend bis zu vollem Schreibzugriff. Wichtig ist auch, ob ein Agent in einer vertrauenswürdigen oder in einer nicht vertrauenswürdigen Umgebung arbeitet. NISTs Taxonomie der Werkzeugnutzung hilft zu erklären, warum diese Details darüber entscheiden, ob ein Agent in einem realen Geschäftsprozess eingesetzt werden kann.

Ein starker KI-Service sollte seinen Wert behalten, wenn sich das zugrunde liegende Modell ändert. Sein Wert kommt aus dem Fachworkflow, der Integration, den Kontrollen und der nachgewiesenen Qualität.

Fünf Karten: Software Engineering, Software as a Service, Hardware Engineering, Hardware as a Service und KI as a Service
Fünf Wege, Engineering-Wert einzukaufen. Ich bat die KI um die risikofreie Option; sie schloss die Speisekarte stillschweigend.

Was billiger wird und was wertvoller

Zu der Arbeit, die am ehesten unter Preisdruck gerät, gehören:

  • Boilerplate-Code und einfache Oberflächen
  • Erste Entwürfe von Anforderungen, Tests und Dokumentation
  • Manuelle Übergaben zwischen unverbundenen Rollen
  • Staff Augmentation, die hauptsächlich nach Stunden verkauft wird
  • Produkte, deren Vorteil eine leicht reproduzierbare Funktion ist

Zu der Arbeit, die voraussichtlich an Wert gewinnt, gehören:

  • Architektur und Änderbarkeit
  • Tiefes Fachwissen
  • Integration in Alt- und kritische Systeme
  • Deterministische Geschäftslogik
  • Sicherheit, Verifikation und Nachweise
  • Hardware-Software-Co-Design
  • Physisches Prototyping und Produktionsvorbereitung
  • Lebenszyklusmanagement und verantwortlicher Support

Das ist eine Hypothese darüber, wohin sich der Wert verschiebt: vom Herstellen eines Artefakts hin zum Umgang mit seinen Folgen.

Zwei Spalten: Arbeit unter wachsendem Preisdruck links, Arbeit mit steigendem Wert rechts
Der erste Entwurf wurde billiger. Die Verantwortung hat dieses Update offenbar nicht bekommen.

Der Verkauf beginnt nach der Demo

Ein Kunde, der mit einem Prototyp kommt, ist nicht zwangsläufig ein verlorener Kunde. Das Gespräch kann auf einer höheren Ebene beginnen.

Statt zu fragen „Was sollen wir für Sie bauen?“, kann ein Engineering-Unternehmen fragen:

  • Was darf in diesem System nie passieren?
  • Welche Entscheidungen müssen deterministisch bleiben?
  • Auf welche Daten und Aktionen darf der Agent zugreifen?
  • Welche Nachweise braucht es vor dem Start?
  • Mit welchen realen Systemen muss das Produkt verbunden sein?
  • Wie wird jede wesentliche Änderung geprüft?
  • Wer ist verantwortlich für die Reaktion, wenn etwas ausfällt?
  • Wer betreut das System über die Zeit?
Drei Karten zu Grenzen, Nachweisen und Verantwortung, jeweils mit den Fragen, die nach einer Demo zu stellen sind
Die Demo steht. Ich fragte, wer Rufbereitschaft hat, wenn sie ausfällt; die KI fragte, ob das im Prompt stehe.

Der Verkauf verschiebt sich dahin, Risiko und Verantwortung gemeinsam zu definieren.

Ein Engineering-Unternehmen kann einen begleiteten Übergang vom Prototyp zur Produktion anbieten: Architekturbewertung, Härtung, Integration, Sicherheitsprüfung, physische Validierung, Wiederherstellung der Dokumentation und Lebenszyklusplanung.

Der Kunde bringt den Ausgangspunkt mit. Das Engineering-Unternehmen hilft dabei, den Weg zu einem verlässlichen Produkt verständlich und beherrschbar zu machen.

Wo ich die Chance sehe

Meine persönliche Hypothese, keine offizielle Unternehmensstrategie, lautet: Engineering-Unternehmen werden näher an die anspruchsvollsten Übergänge rücken:

  • Vom Prototyp zum Produkt
  • Von der Software zu einem physischen Gerät
  • Von einer entdeckten Schwachstelle zu einer verifizierten Behebung
  • Von der ersten Lieferung zu einem betreuten Lebenszyklus

In meiner eigenen Arbeit haben sich das Finden einer Schwachstelle und die Wahl einer sicheren, verifizierten Behebung als verschiedene Aufgaben erwiesen. Das Finden lässt sich automatisieren. Eine Behebung verlangt weiterhin Produktkontext, Abhängigkeitsanalyse, Risikoentscheidungen, regulatorisches Verständnis, Tests und eine Person, die die Entscheidung verantwortet.

KI verkürzt den Weg zur ersten Version. Der Weg von dieser Version zu einem verlässlichen Ergebnis bleibt eine Engineering-Aufgabe.

Der Roboter liefert den Prototyp vielleicht schon nächstes Jahr. Der Kunde wird trotzdem fragen, wer ihn versteht, wer ihn ändern kann und wer das Ergebnis verantwortet, wenn die Demo auf die reale Welt trifft.

Das ist die Frage, die Engineering-Unternehmen jetzt beantworten müssen: Wenn die KI Ihres Kunden die erste Version gebaut hat, welche Verantwortung kauft er dann als Nächstes bei Ihnen ein?

Weitere Insights

Sie haben eine ähnliche Aufgabe?

Gespräch anfragen