Vordenker
Copilot hat es geschrieben, aber wem gehört es? Die Governance‑Lücke, die Engineering‑Teams übersehen könnten

Ein Ingenieur öffnet Copilot, um Code für die Website eines Kunden zu entwerfen. Innerhalb von Sekunden erhalten sie Code, der zuvor manuell deutlich länger geschrieben werden musste. Für viele Webentwickler und Unternehmen, die ihre Websites optimieren, ist es normal, sich zu fragen: Ist dieser Code zuverlässig? Ist er sicher? Sollte er vor der Implementierung überprüft werden? Diese Fragen fallen alle unter eine übergeordnete Frage: Wer wird für KI‑unterstützte Codierung zur Verantwortung gezogen? Und, am wichtigsten, wem gehört der Produktivitätszuwachs?
Wenn KI einem Engineering‑Team ermöglicht, in derselben Zeit mehr Arbeit zu erledigen, kann jeder mehr von diesem wirtschaftlichen Wert profitieren. Das könnte der Entwickler sein, der Zeit spart, der Arbeitgeber, der mehr Wert aus den eingesparten Stunden zieht, oder der Kunde, der das bezahlt bekommt und noch Zeit übrig hat. Unabhängig davon, wie der gesparte Zeitgewinn genutzt wird, steht im Vordergrund, wie die Arbeit gesteuert und bepreist wird.
KI und Codierung werden unausweichlich
KI‑Codierungswerkzeuge gewinnen schnell an Zugkraft und dringen in die Mainstream‑Entwicklung vor. Laut dem 2025 Stack Overflow Developer Survey, gaben 84 % der Befragten an, KI‑Tools in ihrem Entwicklungsprozess zu nutzen oder zu planen.
Obwohl die Integration von KI in die Arbeitsabläufe von Webentwicklern immer üblicher wird, gibt es nach wie vor Bedenken hinsichtlich ihrer Zuverlässigkeit. Dieselbe Umfrage ergab, dass 46 % kein volles Vertrauen in die Genauigkeit von KI‑Ausgaben haben und etwa 66 % KI‑Lösungen, die „fast richtig, aber nicht ganz“ seien, als Frustrationsquelle nannten.
Die sich abzeichnende Debatte über KI‑Codierung dreht sich mehr um ihre Zuverlässigkeit als darum, ob dieser Code mehr Wert schafft und wer dafür verantwortlich ist, dass dies gewährleistet wird.
KI durchbricht das Verhältnis zwischen Stunden und Output
Die Vergütung für Softwareentwicklung beruhte stets auf der Annahme, dass der Engineering‑Output eng mit dem Aufwand verbunden ist. Generative KI verkompliziert diese Gleichung nun.
Ein kontrolliertes Experiment mit 95 Entwicklern ergab, dass Teilnehmer mit Zugriff auf GitHub Copilot eine spezifische JavaScript‑HTTP‑Server‑Aufgabe 55,8 % schneller als ohne Zugriff.
Das verdeutlicht, dass KI die Entwicklung beschleunigen kann, möglicherweise ohne Qualitätsverlust. Diese Zahlen sind jedoch nur erfolgreich, weil das Experiment einer sehr spezifischen Programmieraufgabe folgte. Obwohl die Aufgabe schneller erledigt wurde, bedeutet das nicht, dass Copilot eine gesamte Engineering‑Organisation um 55,8 % produktiver macht.
Eine weitere Forschungsstudie veranschaulicht diese Idee. Ein Versuch mit 96 Vollzeit‑Softwareingenieuren von Google ergab, dass Entwickler, die KI nutzten, eine unternehmensweite Aufgabe in etwa 96 Minuten erledigten, verglichen mit 114 Minuten für diejenigen ohne KI. Die angepasste Schätzung der Forscher deutete auf etwa eine 21 % Reduzierung der Bearbeitungszeit hin. Die Studie untersuchte jedoch nicht die Qualität des KI‑Codes und behandelte keine Fragen der Gerechtigkeit im Hinblick auf die Abhängigkeit von der Technologie nicht.
Es gibt auch Hinweise darauf, dass KI die Codierungszeit verlangsamt. Eine randomisierte Studie von METR umfasste 16 erfahrene Open‑Source‑Entwickler, die an 246 realen Issues in bekannten Repositories arbeiteten. Mit den zu Beginn des Jahres 2025 verfügbaren Werkzeugen, darunter Claude Sonnet 3.5 und 3.7 sowie Cursor Pro, benötigten sie etwa 19 % länger für die Aufgaben, obwohl viele annahmen, dass diese Werkzeuge Zeit sparen würden.
Zusammen stellen diese Studien die Erwartung in Frage, dass KI Entwicklern ein schnelleres Arbeiten ermöglicht. Stattdessen wird die Zeit und der Wert von Entwicklern für Unternehmen, die Webarbeit anbieten, und für die Kunden, die sie erhalten, weniger vorhersehbar.
Das Preisproblem, über das niemand spricht
Time & Material (T&M) ist ein gängiges Modell im Webdevelopment für den Softwarekauf, da es ein wiederkehrendes Branchenproblem adressiert: ein sich entwickelndes Projekt.
Mit diesem Modell können Kunden, anstatt jede Funktion oder Aufgabe vor Beginn der Entwicklung festzulegen, für die Engineering‑Zeit zahlen, während das Projekt voranschreitet und sich ändert.
Allerdings verursacht KI Stolpersteine in diesem bewährten Modell. Da die Vergütung direkt an die Engineering‑Stunden gekoppelt ist, kann eine effizientere Entwicklungszeit zu weniger abrechenbaren Stunden für die Kunden führen. Wenn KI dieselben Ergebnisse in kürzerer Zeit liefert, schafft die Technologie Wert für die Kunden, aber die Reduzierung der abrechenbaren Stunden bedeutet weniger Einnahmen für die Anbieter.
Die Lösung besteht nicht darin, Entwickler zu verlangsamen. Das T&M‑Modell steht nun vor einem strukturellen Problem hinsichtlich der Preisgestaltung und Anreizgestaltung. Die Verwendung von Stundensätzen zur Bestimmung des Werts kann einschränkend sein. Ein Käufer kann genau wissen, was jede Engineering‑Stunde kostet, bleibt jedoch unsicher über die Gesamtinvestition, die nötig ist, um das gewünschte Ergebnis zu erzielen.
Wenn KI die Engineering‑Produktivität verändert, kann sich die Frage verschieben von:
- “Was kostet eine Entwicklerstunde?” → “Was passiert mit dem Wert, wenn weniger Entwicklerstunden benötigt werden?”
Die METR‑Ergebnisse verkomplizieren diese Frage. Wenn Entwickler glauben, Zeit zu sparen, obwohl sie in Wirklichkeit länger benötigen, reicht weder die KI‑Einführung noch die wahrgenommene Produktivität aus, um finanziellen Wert zu demonstrieren. Deshalb benötigen Organisationen Governance, die messen kann, was tatsächlich geschehen ist.
Die Governance‑Lücke hat vier Eigentümer
Die Diskussion über Governance im Zusammenhang mit KI‑unterstützter Entwicklung muss über Richtlinien hinausgehen, die festlegen, welche Werkzeuge Entwickler nutzen dürfen.
Es gibt mindestens vier Arten von Eigentum, die Engineering‑Organisationen definieren sollten.
1. Wer besitzt den Code?
KI kann eine Implementierung erzeugen, aber sie kann nicht als Ausrede für eine verantwortungsfreie Entwicklung dienen. Jemand muss weiterhin für das Überprüfen, Testen und Freigeben des Codes bis zur Produktionsphase verantwortlich sein.
2. Wer trägt das Risiko?
Schneller Code ist nur dann wertvoll, wenn er nicht an anderer Stelle Probleme verursacht. Eine empirische Studie zu KI-generiertem Code identifizierte Sicherheitslücken in 29,5 % der untersuchten Python‑Snippets und 24,2 % der JavaScript‑Snippets. Die Forschung identifizierte außerdem Schwächen in 43 Kategorien der Common Weakness Enumeration.
Die Studie zeigte jedoch, dass das Zurückspielen von statischen Analysewarnungen in Copilot Chat bis zu 55,5 % der identifizierten Sicherheitsprobleme beheben kann. Die Forschung zeigt, wie KI Coding‑Probleme erzeugen und lösen kann, aber Organisationen benötigen Prozesse, um zu bestimmen, wie deren Ausgabe validiert wird.
NIST’s SP 800-218A spiegelt dieses Prinzip wider, indem es sein Secure Software Development Framework um bewährte Verfahren erweitert, die generative KI und dual‑Use‑Foundation‑Modelle adressieren.
3. Wer besitzt den Produktivitätszuwachs?
Kommerzielle Vereinbarungen von Anfang an sind entscheidend, um zu bestimmen, wer die Effizienzgewinne erhalten soll. KI kann Kunden helfen, weniger auszugeben, Teams ermöglichen, mehr Software zu liefern, oder am Projektende keinen finanziellen Nutzen bringen.
Was unverändert bleibt, ist die Notwendigkeit transparenter Prozesse und die Lieferung von qualitativ hochwertiger, vereinbarter Arbeit.
4. Wer trägt die Priorisierung?
KI kann die Erstellung von Features günstiger und schneller machen, aber sie kann nicht entscheiden, ob diese Features erforderlich sind.
Tatsächlich kann eine steigende Entwicklungskapazität die Priorisierung noch wichtiger machen. Wenn Teams schneller bauen und experimentieren können, muss dennoch jemand bestimmen, welche Ergebnisse das verfügbare Budget rechtfertigen und welche Ideen verworfen werden sollten.
KI‑Governance wird zu einer Finanzfrage
Diese Fragen machen KI‑Governance immer relevanter. Stellen Sie sich zwei Entwicklungspartner vor, die ähnliche Stundensätze berechnen.
Einer hat KI in einen robusten Engineering‑Prozess integriert und erzielt das gewünschte Ergebnis deutlich schneller, während der andere länger braucht. Der reine Vergleich ihrer Stundensätze sagt dem Käufer wenig über die von ihnen durchgeführten Prozesse.
Käufer müssen bewerten:
- Gesamterwartete Investition
- Verantwortung für Kostenüberschreitungen
- Qualitätskontrollen für KI-generierte Arbeit
- Wie Effizienzgewinne verteilt werden
T&M kann für beide Parteien weiterhin nützlich sein, wenn sie die Unsicherheit in den Leistungen bewusst akzeptieren. Festpreisvereinbarungen können ebenfalls funktionieren, wenn Anforderungen und Lieferungen stabil sind.
Aber KI macht auch alternative Strukturen lohnenswert zu prüfen. Ein Ansatz besteht darin, eine maximale finanzielle Grenze festzulegen und gleichzeitig den Umfang flexibel zu halten. Anschließend können Features nach ihrem geschäftlichen Wert innerhalb dieses Modells priorisiert werden.
Wird das Engineering effizienter, können die Gewinne in zusätzliche Produktfunktionen statt in zusätzliche abrechenbare Zeit übersetzt werden. Kommerzielle Anreize sollten dasselbe Ergebnis wie Engineering‑Anreize fördern und möglichst effizient nützlichere Software schaffen.
Das gleiche KI‑Gespräch
Engineering‑Führungskräfte müssen verstehen, wie kommerzielle Anreize die Lieferung beeinflussen. Finanz- und Beschaffungsteams benötigen ausreichende Transparenz in die KI‑unterstützte Entwicklung, um zu beurteilen, ob die behauptete Effizienz messbaren Wert liefert.
Das bedeutet, dass eine ausgereifte KI‑Governance nicht bei genehmigten Modelllisten, Sicherheitskontrollen, Datenrichtlinien oder Code‑Review‑Anforderungen enden darf. Sie muss Verantwortung, finanzielle Risiken, Priorisierung und Eigentum an Produktivitätsgewinnen adressieren.
Aber es gibt eine zweite Eigentumsfrage, die einen viel größeren Einfluss auf Technologie‑Budgets haben könnte: Wer besitzt den Wert, der geschaffen oder verloren geht, wenn KI die Geschwindigkeit der Softwareentwicklung verändert?
Die Organisationen, die bestimmen, ob schnelleres Engineering tatsächlich bessere Produkte hervorbringt, Investitionen steuern und messbare Geschäftsergebnisse erzielen, werden die sein, die den Wettbewerbern voraus bleiben.
Wenn Ihr Entwicklungsteam morgen KI einführt, würde Ihr aktuelles Governance‑ und Geschäftsmodell Ihnen überhaupt sagen, ob die Lieferung dadurch wertvoller geworden ist?












