Abschnitt: Technologie & KI Autor: IN Leselänge: ~27 Min Quellen und weiterführende Literatur: 22 Artikel Themen: KI, Programmierung, Copilot, Cursor, Produktivität, Tests, Betrieb, Verantwortlichkeit SEO / Arbeitstitel: Kann KI Programmierer ersetzen?
Kann KI Programmierer ersetzen? Die Frage klingt einfach, bis wir bemerken, dass wir nicht einen Job vergleichen. Die Reduzierung der Zeit auf dem HTTP-Server im Labor ist im Team keine Woche. Das gelöste GitHub-Problem ist nicht auf Abruf. Das 50 %-Zeithorizontmodell ist keine Halbzeit. Und der Benchmark-Score ist kein Zeichen für den Vorfall. Daher wird in dem Artikel nicht nach einem Datum gesucht, an dem der Programmierer verschwinden wird. Es wird gesucht, welche Aufgabe der Assistent beschleunigt, wohin sich die Arbeit während der Überprüfung bewegt und wer während der Ausfallzeit bleibt.
1. Zwölf grüne Tests auf dem HTTP-Server sind kein nächtlicher Rückfall in der Produktion
Die Demo vom Freitag sieht überzeugend aus. Junior wird einen kleinen HTTP-Server in JavaScript demonstrieren. Tests sind grün. Er erklärt, dass er die Lösung mit Copilot viel schneller geschrieben hat, als er erwartet hatte. Der technische Leiter sitzt neben ihm und sagt, dass der Agent ihm in einem großen internen Repository oft Arbeit hinzufügt, weil er Zweige überprüft, die er selbst nicht geschrieben hätte. Der Produktmanager zeigt eine Grafik der geschlossenen Tickets. Der Direktor fragt, ob er im nächsten Quartal weniger Leute einstellen soll. Bereitschaftsingenieur legtKürzere Frage: Wer wird es nachts zurücksetzen, wenn die grünen Tests nicht ausreichen?
Auf den ersten Blick ist es umstritten, ob KI Programmierer ersetzen wird oder nicht. In Wirklichkeit misst jeder ein anderes Objekt. Junior-Laboraufgabe mit klarer Aufgabenstellung. Technisch führendes, ausgereiftes System, das Bescheid weiß. Anzahl der abgeschlossenen Arbeitseinheiten des Produktmanagers. Der Direktor möchte die Aufgabe in den Rekrutierungsplan übertragen. Die Bereitschaftsperson misst die Verkehrsverantwortung.
In einer Studie mit GitHub Copilot haben Peng, Kalliamvakou, Cihon und Demirer vom 15. Mai bis 20. Juni 2022 eine Programmieraufgabe gemessen: die Implementierung eines HTTP-Servers in JavaScript, der zwölf Tests bestehen musste. An der Studie nahmen 95 Upwork-Freiberufler teil, und 35 Personen in jeder Branche erledigten die Aufgabe. Die Autoren berichten von einer Zeitverkürzung um 55,8 % bei einem 95 %-Konfidenzintervall von 21 bis 89 [1]. Das ist eine starke Zahl. Es misst jedoch nicht die Produktionscodebasis, die Überprüfung, den Vorfall, die Eigentümerschaft des Dienstes oder die nächtliche Entscheidung, ob ein Rollback den Kunden mehr schadet als ein Fehler.
Ein schnellerer HTTP-Server ist nicht dasselbe wie die Verantwortung für ein Produktionssystem.
– Anderer Kontext
2. Die Programmierarbeit besteht aus mindestens sechs Ebenen
Wenn das Diff auf dem Bildschirm erscheint, erweckt es den Eindruck, dass „der Code von KI geschrieben wurde“. Doch das Ergebnis entsteht in mehreren Schichten. Jeder kann anders gemessen werden und jeder kann zu einer anderen Schlussfolgerung führen.
- Codegenerierung: Auffüllung, Boilerplate, Tests, Skripte und kleinere Transformationen.
- Ein bekanntes System ändern: Arbeiten in einem Depot, dessen Abkürzungen, Schulden und ungeschriebene Regeln man kennt.
- Agenten-Benchmark: Ausgabe, Patch, Testlauf und Ergebnis auf dem öffentlichen Set.
- Aufgabenlänge: der Horizont, an dem das Modell immer längere Arbeiten mit einigem Erfolg abschließt.
- Messungen im Team: Tickets, Durchlaufzeit, Überprüfung, Mängel, Arbeitsunterbrechung und Prozessänderung.
- Verantwortung: Zusammenführung, Vorfall, Sicherheitsauswirkung, Audit, Kunde und Rollback.
Diese Schichten sind keine subtilen Nuancen. Es handelt sich um unterschiedliche Messobjekte. Peng misst die Zeit, die zum Bestehen der Tests für eine klar definierte Aufgabe benötigt wird [1]. Cui und Co-Autoren messen die Aufgabenerledigung in Organisationen in Feldexperimenten [2]. METR im Jahr 2025 misst erfahrene Open-Source-Entwickler zu echten Problemen in Repositories, die sie gut kennen [4][5]. SWE-Bench misst das Patchen von GitHub-Problemen im Harness [9]. Der Zeithorizont misst, wie lange Softwareaufgaben die Modelle mit einer bestimmten Erfolgsquote bewältigen [6].
In der Arbeitsmarktskizze wird gefragt, was mit dem Beruf passiert. Hier ist die Frage enger. Welche Softwareschicht wird derzeit gemessen? Wenn wir es nicht benennen, landen wir bei einem Satz, der aus einem grünen Test eine Personalpolitik und aus einer Entschleunigung ein Werkzeugverbot macht.
3. Der beste Assistent ist derjenige, dessen Fehler durch Test, Überprüfung und Rollback erkannt wird
Es ist verlockend, die Tippgeschwindigkeit anhand von Code zu messen. Aber Software ist kein Textabsatz. Ein Fehler kann offensichtlich, billig und reversibel sein. Oder es besteht die Tests reibungslos und taucht nur in den Daten des Kunden auf. Daher ist nicht nur derjenige ein guter Assistent, der die meisten Zeilen entwirft. Es handelt sich um ein Werkzeug, dessen Ausfall erkannt wird, bevor er zu einem Betriebsproblem wird.
| Eine Art Misserfolg | Wie sieht er aus? | So testen Sie | Was wird den Schaden begrenzen? |
|---|---|---|---|
| Code-Konfabulation | Diff sieht fertig aus, ändert aber die Autorisierung oder den Edge-Status | Review, CI, proprietärer Test und Rollback | Die Person wird zusammengeführt, der Agent hat eingeschränkte Berechtigungen |
| Schlechtes Messdesign | Berufungsurteil eines RCT | Separate Aufgabe, Ticket, bekanntes Repo und Betrieb | Übertragen Sie die Nummer nicht auf einen Nebenjob |
| Zur Rezension wechseln | Das Festschreiben ist schneller, das Zusammenführen ist langsamer | Messeingang, Kontrolle und akzeptabler Status | Werten Sie die gesamte Zeichenfolge aus |
| Benchmark als Statement | SWE-Bank punktet als Ersatz für Teamarbeit | Listen Sie auf, was das Kit nicht misst | Interne Aufgaben vor der öffentlichen Bildunterschrift |
| Vorfall ohne Eigentümer | „KI hat es geschrieben“ statt verantwortungsvolle Zusammenführung | Wer retourniert, wer berichtet, wer erklärt | Runbook pro Person und Organisation |
Damit verändert sich auch die Kauffrage. Wir fragen nicht nur, wie viel Zeit der Assistent beim Tippen spart. Wir fragen, ob wir über Tests, Überprüfungen, Beobachtbarkeit, Berechtigungen und Rollbacks verfügen, die seinen Fehler behandeln. Wo Fehler billig sind und die Kontrolle klar ist, kann sich der Erfolg großartig auszahlen. Wenn ein Fehler in die Produktion gelangt, kann eine schnellere Generierung das Problem möglicherweise nur an einen teureren Ort verlagern.
4. Drei Designs, drei Richtungen. Nicht drei Berufungsurteile
Die öffentliche Debatte mag ein Diagramm. Untersuchungen zur Produktivität von KI-Programmierern bieten eher drei verschiedene Designs.
Peng und Co-Autoren haben eine Laboraufgabe mit einem klaren Ergebnis gemessen: ein HTTP-Server in JavaScript, zwölf Tests, Upwork-Freelancer und Zeit bis zur Fertigstellung [1]. Cui, Demirer, Jaffe, Musolff, Peng und Salz arbeiten (Stand Februar 2025) mit 4 867 Entwicklern bei Microsoft, Accenture und einem Fortune-100-Unternehmen. Ihre instrumentelle Schätzung der Copilot-Nutzung pro erledigter Aufgabe beträgt +26,08 % pro Woche mit einem Standardfehler von 10,3 [2][3]. METR und Becker et al. Im Jahr 2025 verfolgten sie 16 erfahrene Entwickler, 246 echte Probleme, eine durchschnittliche menschliche Zeit von 2,0 Stunden und Repositories mit etwa 23 tisíc hvězdami. Mit Cursor Pro und Claude 3.5/3.7 wurde eine Zeitsteigerung von 19 % gemessen [4][5].
Das sind nicht drei Urteile. Es gibt drei Fenster. In einem gibt es ein klares Grundgerüst und Tests. Im zweiten Teil geht es um allgemeine Unternehmensaufgaben und die Einführung von Tools. Im dritten Fall sind es Leute, die ihren Code kennen und Entwürfe anhand des Kontexts überprüfen müssen, den sie in ihren Köpfen haben. Keine dieser Messungen allein sagt aus, ob der Arbeitsvertrag endet. Und keine davon kann ehrlich verwendet werden, ohne die Bevölkerung, den Zeitraum, die Metrik und das, was nicht zählte, zu beschreiben.
5. Das Beschleunigen eines Skeletts ist nicht die Aufgabe eines Juniors
Das Ergebnis von Pengs Studie ist gerade deshalb wichtig, weil es eng ist. Es zeigt, dass der Assistent bei einer genau definierten Aufgabe mit einer testbaren Ausgabe die Zeit erheblich reduzieren kann. Vor allem dort, wo es viele Boilerplates gibt und Tests schnell zeigen, ob die Lösung funktioniert. Dies ist genau die Art von Arbeit, die viele weniger erfahrene Menschen lernen.
Daraus folgt nicht, dass der Junior vom Budget abgezogen werden kann. Die Studie hatte eine bestimmte Aufgabe, einen bestimmten Zeitraum und eine vollständige Stichprobe von 35 Personen in jeder Branche [1]. Es wurden weder das Onboarding noch die Kenntnis der Unternehmensdomäne, die Kommunikation mit dem Produkt, das Debuggen von Anforderungen, die Überprüfung von Fremdcode oder die Aufrechterhaltung des Betriebs des Dienstes gemessen. Sie hat nicht einmal gemessen, ob das Team die fehlende Ausbildung neuer Leute in einem halben Jahr bezahlen würde.
Daher lautet der korrekte Führungssatz nicht: „KI wird Nachwuchsarbeit leisten.“ Darin heißt es: „Für Aufgaben wie diese kann der Schreibaufwand erheblich verkürzt werden, wenn wir klare Tests und eine kostengünstige Kontrolle haben.“ Dies ist weniger effektiv. Es ist jedoch benutzerfreundlicher.
Es ist ein anderer Test für das Team. Nehmen Sie Ihre eigene kleine Aufgabe, die einem Grundgerüst ähnelt: bekannte Aufgabenstellung, klares Ergebnis, automatische Tests. Lassen Sie es mit und ohne Assistent erledigen. Um nicht nur die Schreibzeit zu messen, sondern auch die Zeit, in der der Senior das Diff liest. Wenn die Speicherung bei der Überprüfung verloren geht, wurde das Werk nicht entfernt. Sie war bewegt.
Dennoch könnte dieser Schritt eine gute Nachricht sein. Ein Junior, der mit einem Assistenten schneller einen ersten Entwurf erstellt, stößt möglicherweise früher auf Fragen zur Architektur, zum Testen und zur Verantwortlichkeit. Dies gilt jedoch nur, wenn das Team nicht zulässt, dass das Modell das Lernen ersetzt. Wenn Sie nicht wissen, warum der Code den Test bestanden hat, können Sie ihn nicht pflegen. Wenn er seinen eigenen Unterschied nicht erklären kann, ist er nicht bereit, die Änderung auf ein gemeinsames System zu übertragen. Der Beitrag des Assistenten muss daher zusammen mit dem Lernen gemessen werden: Er beschleunigte den Weg zuverstanden oder einfach nur mehr Text produziert, damit jemand anderes ihn entwirren kann?
6. Mehr abgeschlossene Tickets bedeuten nicht mehr Qualität im Verkehr
Cui und Co-Autoren verlagern die Debatte vom Labor in die Unternehmenswelt. Das ist eine große Veränderung. Viertausendachthundertsiebenundsechzig Entwickler, drei Organisationen und die Messung erledigter Aufgaben pro Woche entsprechen eher dem, was Managern am Herzen liegt [2]. Die Schätzung von +26,08 % erledigter Aufgaben pro Woche ist geringer als der Laboreffekt für Pengs Aufgabe, den die Autoren selbst auf den Unterschied zwischen reiner Aufgabe und Routinearbeit zurückführen [2].
Aber auch das Ticket ist nur eine Einheit des Prozesses. Eine erledigte Aufgabe ist nicht automatisch eine Qualitätsänderung in der Produktion. Es hängt davon ab, was die Organisation als vollständig erachtet, wie aussagekräftig die Überprüfung ist, ob Mängel, Vorfälle, Kundenauswirkungen und die Zeit anderer Personen gemessen werden. Das Team kann mit dem Assistenten kleinere Aufgaben abschließen und gleichzeitig die Überprüfung belasten. Oder es kann tatsächlich den Durchsatz erhöhen, ohne dass die Qualität darunter leidet. Daten zu abgeschlossenen Aufgaben sind der Anfang, nicht die Endabrechnung.
Hier scheitert die Ersatzdebatte oft. Wenn ein Unternehmen nur die Anzahl der Tickets erfasst, besteht die Versuchung, den Prozentsatz in Personen umzurechnen. Wenn er außerdem Mängel, Überprüfungen und betriebliche Änderungen verfolgt, entdeckt er möglicherweise noch etwas anderes: Der Assistent erhöht das Arbeitsvolumen, erfordert jedoch eine andere Art der Kontrolle und eine andere Verteilung der Verantwortlichkeiten.
Bei Feldmessungen kommt es auch darauf an, wer das Werkzeug tatsächlich für welche Aufgaben nutzt. Adoption wird nicht wahllos verteilt wie Farbe an einer Wand. Manche greifen für einfache Reparaturen zum Assistenten, manche für Bibliotheksrecherchen, manche für Tests und wieder andere kaum. Wenn dann die Anzahl der erledigten Aufgaben verfolgt wird, kann das Ergebnis eine Mischung aus der Leistungsfähigkeit des Tools, der Bereitschaft der Leute, es zu nutzen, der Art der zugewiesenen Tickets und den Teamregeln sein. Cui und Co-Autoren erforschen esbeabsichtigt; Der Leser sollte hieraus vor allem Vorsicht walten lassen, wenn er in sein eigenes Unternehmen übersetzt [2].
Daher muss der Firmenpilot nicht einfach nach einem Monat das Tool einschalten und die geschlossenen Posten zählen. Sie müssen zwischen Aufgabentypen, der Erfahrung der Personen, der Diff-Größe, der Überprüfungszeit und der Anzahl der rückgängig gemachten Änderungen unterscheiden. Andernfalls könnte ein guter Passbericht einen neuen Engpass für diejenigen verschleiern, die die Änderungen kontrollieren.
Es lässt sich noch genauer nachverfolgen, wer für die Beschleunigung bezahlt. Wenn der Assistent dem Autor der Aufgabe hilft, der Prüfer aber mehr Zeit mit der Überprüfung verbringt, hat sich die Ersparnis zwischen den Personen verlagert. Wenn die Anzahl der Tickets zunimmt, aber auch die Anzahl der Rücksendungen aus der Qualitätssicherung zunimmt, wurde die Einsparung in eine andere Warteschlange verschoben. Wenn die gesamte Kette von der Eingabe bis zur sicher akzeptierten Änderung beschleunigt wird, verfügt das Team über Beweise, die mehr wert sind als eine allgemeine Schlagzeile über KI.
7. Eine Verlangsamung ist für Personen, die mit dem Repo vertraut sind, kein Beweis dafür, dass der Assistent nicht funktioniert
METR im Jahr 2025 lieferte ein unbequemes Ergebnis. Erfahrene Open-Source-Entwickler arbeiteten an Problemen in Repositories, die sie gut kannten. Die durchschnittliche Erfahrung mit einem bestimmten Repository betrug mehrere Jahre, die Aufgaben erforderten eine durchschnittliche menschliche Zeit von 2,0 Stunden und die Studie fand von Februar bis Juni 2025 statt. Als sie KI-Tools verwenden durften, erhöhte sich die Zeit im Durchschnitt um 19 % [4][5].
Noch interessanter ist die Vorfreude. Die Entwickler erwarteten im Vorfeld eine Beschleunigung um 24 %. Nach der Studie schätzten sie immer noch, dass sie mit KI 20 % schneller waren, auch wenn das gemessene Ergebnis in die entgegengesetzte Richtung ging [5]. Das ist kein Beweis dafür, dass die Entwickler nicht wissen, was sie tun. Es ist eine Warnung, dass das subjektive Gefühl einer reibungslosen Arbeit selbst erfahrene Menschen täuschen kann.
Dies bedeutet nicht, dass der Assistent nicht funktioniert. Dies ergibt sich aus der Tatsache, dass in einem bekannten System eine Person einen Kontext im Kopf hat, den das Modell nicht hat. Er weiß, welche scheinbar einfache Lösung die alte Integration zerstören wird. Er weiß, warum der besondere Helfer absichtlich etwas Besonderes ist. Es weiß, dass der Test nur in Kombination mit Daten fehlschlägt, die sich nicht im Repository befinden. KI kann Vorschläge, aber auch Sackgassen hinzufügen, die überprüft werden müssen.
Drei Produktivitätstests
Planen Sie die grünen Tests für das neue Skelett? Messen Sie die Anzahl der erledigten Aufgaben im Team? Oder messen Sie die Zeit pro Problem in Ihrem eigenen ausgereiften Repository? Drei positive Antworten passen nicht zusammen. Jeder gehört zu einer anderen Entscheidung.
8. Ein Zeithorizont von 50 % entspricht nicht 50 % der Vollzeitvergütung
METR in der Studie von Kwa et al. misst die Fähigkeit von Modellen, immer längere Softwareaufgaben zu erledigen. Es funktioniert mit einem Satz von 170 Aufgaben, darunter HCAST, RE-Bench und 66 SWAA, sowie zwölf Grenzmodellen. Für das o3-Modell werden etwa 110 Minuten menschlicher Zeit als 50 %-Zeithorizont angegeben [6]. Die Studie schätzt außerdem, dass sich dieser Horizont seit 2019 etwa alle sieben Monate verdoppelt hat, nämlich 207 Tage mit einem 95-Prozent-Intervall von 166 bis 240 Tagen [6][7].
Dies ist wichtig für die Richtung der Entwicklung. Es ist jedoch kein Satz, dass das Modell die Hälfte des Programmierers ersetzt. Ein Horizont von 50 % bedeutet, dass das Modell bei einem bestimmten Satz für eine Aufgabe, die einer bestimmten menschlichen Zeit entspricht, etwa die Hälfte der Erfolgsquote aufweist. METR gibt außerdem an, dass der 80-Prozent-Horizont etwa vier- bis sechsmal kürzer ist [6][7]. Die Produktion will normalerweise keine halbe Chance. Er will Zuverlässigkeit, Wiederholbarkeit und Verantwortung.
Darüber hinaus wird in der METR-Notiz vom 20. März 2026 darauf hingewiesen, dass die Ergebnisse des Zeithorizonts empfindlich auf Modellannahmen, Regularisierung und Schätzung menschlicher Zeiten reagieren [8]. Dies bricht den Trend nicht. Es verhindert lediglich die Übersetzung in einen einfachen Satz über monatelange Arbeit in einem Unternehmen.
Der Zeithorizont von 50 % gibt an, wie lange das Modell manchmal für die Erledigung einer Aufgabe benötigt. Es wird nicht gesagt, wer den Ausfall in der Nacht rückgängig machen wird.
– Anderer Kontext
9. SWE-Bench behebt Probleme mit Tests. Er entwirft keine Architektur und trägt keinen Pager
SWE-Bench ist ein nützlicher Benchmark, da er versucht, echte GitHub-Probleme zu lösen. Die Originalarbeit von Jimenez und Co-Autoren arbeitete mit 2.294 Ausgaben aus zwölf Python-Repositories. In der Arbeit erreichte Claude 2 mit der BM25-Suche 1,96 % gelöste Probleme; GPT-4 wurde aus Budgetgründen mit einer Teilmenge von 25 % bewertet [9]. Der spätere SWE-Bench Verified von OpenAI führte eine von Menschen verifizierte Stichprobe von 500 Elementen ein und meldet GPT-4o mit einer Punktzahl von 33,2 %. [10]. Epoch AI beschreibt das verifizierte Set auch als Variante mit 500 oder 484 nutzbaren Samples je nach Einstellung [11].
Dies ist ein Fortschritt in der Agentenmessung. Es ist nicht die Aufgabe eines Programmierers. Der Benchmark umfasst keine Produktberatung, Architekturentscheidungen, das Lesen interner Vorfälle, Migration ohne Ausfallzeiten, Sicherheitsüberprüfung oder Bereitschaftsdienst. Enthält Problem, Repository, Tests und Bewertungsmethode.
Die richtige Frage ist also nicht, ob die SWE-Bench die Zukunft des Programmierens zeigt. Es zeigt eine wichtige Ebene: die Fähigkeit der Modelle, einige Fehler in den getesteten offenen Repositories zu finden und zu beheben. Es ist ein Signal zur Instrumentenauswahl. Für eine Produktionshaftpflichtversicherung ist das zu wenig.
10. Die Standardbeschleunigung bei den weniger Erfahrenen bedeutet nicht den Untergang der Älteren
Ergebnisse zu Codierungsassistenten zeigen häufig einen größeren Nutzen für weniger erfahrene Personen oder Personen in einem weniger vertrauten Teil des Jobs. Das macht Sinn. Wenn man nach Syntax, Boilerplate, einem gemeinsamen Muster oder einem ersten Entwurf eines Tests sucht, kann das Modell schnell Material zur Bearbeitung liefern. Wenn der Senior die Geschichte des Systems im Kopf behält, können Vorschläge für zusätzlichen Lärm sorgen.
Dies hat nicht den Untergang des Senioren zur Folge. Auch der umgekehrte bequeme Satz, dass der Senior außerhalb der Reichweite von Veränderungen sei, trifft nicht zu. Vielmehr verändert sich die Zusammensetzung der Arbeit. Eine weniger erfahrene Person kann schneller zur ersten Lösung gelangen, muss aber lernen, den Unterschied zu lesen, die Tests zu verstehen und zu erkennen, wenn das Modell gerade souverän das falsche Muster kopiert hat. Ein Senior kann weniger Routinecode und mehr Designgrenzen schreiben, die Sicherheit überprüfen und entscheiden, ob er Änderungen akzeptiert.
Ein Team, bei dem es nur darum geht, Menschen zu retten, riskiert zwei Dinge. Sie werden die Lehrstelle verlieren, in der künftige Senioren aufwachsen. Und es überträgt die Kontrolle auf eine kleinere Anzahl von Personen, die dann eine größere Bewertungswarteschlange haben. Ein Team, das einen Assistenten wegen einer Verlangsamung sperrt, kann bei gut prüfbaren Aufgaben billige Gewinne hinterlassen.
11. Die Verwendung des Tools führt dazu, dass der Ausgabe nicht vertraut wird
Die Stack Overflow-Entwicklerumfrage 2025 zeigt eine hohe Akzeptanz von KI-Tools. Dem Bericht zufolge nutzen 84 % der Befragten KI-Tools oder planen deren Einsatz, gegenüber 76 % im Jahr 2024. Unter den Fachleuten geben 51 % an, KI täglich zu nutzen. Gleichzeitig vertrauen 46 % der Befragten eher nicht auf die Genauigkeit der Ergebnisse als auf sie, während 33 % ihr Vertrauen zum Ausdruck bringen [12][13].
Dies ist keine repräsentative Stichprobe aller Programmierer in der Wirtschaft. Es handelt sich um eine Selbstauswahl der Stack Overflow-Befragten. Dennoch ist das Signal nützlich: Nutzung und Vertrauen sind nicht dasselbe. Man kann das Tool jeden Tag verwenden, da es Zeit beim Suchen, Entwerfen eines Tests oder Erklären eines Fehlers spart. Gleichzeitig müssen sie nicht glauben, dass Output ohne Kontrolle zur Produktion gehört.
Es ist dieser Unterschied, der für Software gesund ist. Ein Programmierer muss kein Gegner der KI sein, um den autonomen Einsatz abzulehnen. Er muss kein Geek sein, um die Code-Vervollständigung zu nutzen. Vertrauen ist kein Aufkleber auf einem Werkzeug. Es hängt mit einer bestimmten Aufgabe, Tests, Berechtigungen und den Auswirkungen des Fehlers zusammen.
12. Inspektionen können Stromeinsparungen verschlingen
Der Assistent beschleunigt oft den ersten Entwurf. Das lässt sich auch ohne Studie erkennen. Weniger sichtbar ist das zweite Konto: Kontrolle. Man muss den Unterschied lesen, verstehen, warum die Änderung funktioniert, die Tests ausführen, den fehlenden Test schreiben, die Sicherheit überprüfen, die Auswirkungen auf die Migrationen ermitteln und entscheiden, ob das Ergebnis akzeptiert werden kann.
Bei einer einfachen Aufgabe kann eine Inspektion kostengünstig sein. Die Tests sagen ja oder nein, und der Fehler hat keine großen Auswirkungen. In einem ausgereiften System ist Kontrolle die Arbeit selbst. Das Modell generiert möglicherweise eine Lösung, die lokal funktioniert, aber nicht der Dienstarchitektur entspricht. Möglicherweise werden mehr Dateien als nötig bearbeitet. Es kann den scheinbar unnötigen Schutz entfernen, der das historische Randgehäuse schützte. All diese Dinge verlängern die Zeit des Seniors.
Auch die Inspektion hat je nach Umgebung unterschiedliche Preise. In einer Bibliothek ohne Daten kann ein Test und eine kurze Rezension genügen. In einem Zahlungsverkehr, im Gesundheitswesen oder in einer internen Verwaltung mit personenbezogenen Daten ist der gleiche Unterschied teurer, da die Auswirkungen des Fehlers teurer sind. Es ist keine Frage der Angst vor KI. Es ist die gleiche Logik, die Teams für menschliche Veränderungen verwenden: Riskante Veränderungen erfordern mehr Augen, bessere Beobachtbarkeit und einen Rollback-Plan.
So testen Sie, wohin ein Job verschoben wurde
Wählen Sie Ihr eigenes Übungs-Repository oder Ihre interne Sandbox. Verwenden Sie keine Produktionssysteme von Drittanbietern und überschreiten Sie nicht die Berechtigungen. Messen Sie für die gleiche Art von Aufgabe dreimal: Geben Sie ein, überprüfen Sie es und bringen Sie es in den Zustand, in dem Sie den Vorfall abzeichnen würden. Wenn das Tippen kürzer geworden ist, das Überprüfen aber länger geworden ist, haben Sie keinen Ersatzprogrammierer. Sie haben einen Jobtransfer.
13. Der Arbeitsmarkt ist ein anderes Thema als der Übergang in die Produktion
In der Debatte über Programmierer wird leicht die umfassendere Frage des Arbeitsmarktes aufgeworfen. Wie viele IKT-Fachkräfte gibt es, wie steigen die Löhne, wie viele Schüler kommen zur Schule, was sagen die OECD, die ILO oder Eloundou über die Belastung durch Aufgaben? Das sind legitime Themen. Aber es gehört zu einem anderen Thema als die Frage, ob ein bestimmter Assistent Änderungen im Repository sicher beschleunigt.
Beispielsweise beschreibt die CZSO IKT-Spezialisten in der Tschechischen Republik und ihre Gehälter [14][15][16]. Eloundou, die ILO und die OECD beschreiben die Belastung von Aufgaben und Veränderungen für die Arbeit in der Gesamtwirtschaft [17][18][21]. Diese Quellen sagen nicht, ob Ihr Agent die Autorisierung korrekt ändern wird, ob die Überprüfung den Fehler erkennt oder wer nachts den Rollback auslöst. Daher erstellen wir in diesem Artikel kein Ranking der Berufe und übertragen keine Prozentsätze vom Arbeitsmarkt auf den Softwareprozess.
Die richtige Linie lautet: Der Arbeitsmarkt kann erkennen, warum die Frage wichtig ist. Es reagiert nicht auf die Zusammenführung. Wenn der Assistent einem bestimmten Team hilft, muss er seine eigene Aufgabe, seine eigene Prüfung, seine eigene Überprüfung und seine eigene operative Verantwortung nachweisen. Ohne dies ist die Debatte über den Austausch von Programmierern zu weit gefasst, als dass sie zu einer sicheren Entscheidung führen könnte.
Aus diesem Grund verwenden wir hier auch nicht die Prozentangaben aus dem Berufe-Artikel als Abkürzung. Die Gefährdung von Aufgaben in der Wirtschaft kann je nach Methodik hoch oder niedrig sein, aber über die Zusammenführungsanfrage in einem bestimmten Repository wird anhand anderer Beweise entschieden. Gibt es einen Diff-Test? Versteht ihn der Rezensent? Hat er den Service verbessert? Hat er nicht eine stille Sicherheitsschuld hinzugefügt? Fehlen diese Antworten, hilft der Arbeitsmarkt nicht weiter. Wenn sie klar sind, kann das Team das Tool nutzen, ohne große Erklärungen über den Untergang des Berufsstandes abzugeben.
14. Benchmark-Ergebnisse bedeuten keinen Vorfall
Wenn ein Agent einen Benchmark löst, signiert er die Punktzahl. Wenn eine Änderung die Produktion beeinträchtigt, wird sie von der Organisation genehmigt. Dieser Unterschied ist grundlegend. Das Model ist kein Mitarbeiter in einem Vertragsverhältnis, kein Pager-Inhaber und nicht die Person, die dem Kunden erklären muss, warum die Daten fehlerhaft verarbeitet wurden. Das Tool kann einen Unterschied vorschlagen. Die Verantwortung für die Akzeptanz bleibt dabei bestehen.
Das KI-Gesetz stuft bestimmte Beschäftigungs- und Workforce-Management-Systeme aufgrund ihres Einsatzes, beispielsweise bei der Rekrutierung oder Bewertung von Personen, als risikoreich ein [20]. Dies ist hier kein Argument dafür, dass Copilot verboten ist oder dass Programmierer verschwinden werden. Es ist eine Erinnerung daran, dass der Einsatz von KI bei menschlichen oder beruflichen Entscheidungen andere Anforderungen stellt als die Erstellung eines Sandbox-Tests.
Vor der Eingliederung in die Produktion
Wird das Ergebnis durch Tests abgedeckt, die das tatsächliche Risiko und nicht nur das Glück messen? Wer ist der Eigentümer des Dienstes und wer hat das Recht, die Änderung zu akzeptieren? Gibt es einen Rollback-, Observability- und Kommunikationsplan? Sind die Geheimnisse von dem Werkzeug getrennt, das sie nicht sehen soll? Wenn das Team diese Fragen nicht beantworten kann, hilft ihm der Benchmark-Score nicht weiter.
15. Ein Agent mit dem Recht, Dateien zu ändern, ist ein anderer Fehler als ein halluzinatorischer Schnipsel
Die ältere Debatte über KI in der Programmierung verlief oft so: Das Modell schlägt einen Ausschnitt vor und der Mensch kopiert ihn. Heute liest der Agent das Repository, bearbeitet Dateien, führt Tests durch, installiert Abhängigkeiten und bereitet manchmal einen Commit vor. Das ist eine andere Risikoklasse. Der falsche Ausschnitt ist Text. Ein falscher Agentenschritt kann den Status des Projekts ändern.
Dabei kommt es nicht nur auf die Qualität des Modells an. Es geht um Berechtigungen. Kann ein Agent Produktionsgeheimnisse lesen? Kann es über den Arbeitsbereich hinaus verlängert werden? Können sie Befehle ausführen, die die Datenbank ändern? Kann er pushen? Darf er den Konflikt lösen, indem er die Arbeit eines anderen entfernt? Jedes „Darf“ verändert die Fehlerkosten.
Daher beginnt gute Praxis nicht mit dem Satz, dass das Modell intelligent ist. Es beginnt mit Sandboxing, der Vorschau von Änderungen, der Trennung von Geheimnissen, der Einschränkung von Schreibvorgängen und der menschlichen Genehmigung, wenn das Ergebnis den gemeinsamen Status ändert. Ein Agent kann in einem sicher definierten Bereich ein hervorragender Helfer sein. Derselbe Agent kann mit einem zu weit gefassten Ansatz schneller Schaden anrichten als die Person, die er beschleunigen sollte.
Besonders wichtig ist die Unterscheidung zwischen Vorschlag und Aktion. Der Vorschlag kann falsch sein und es wird nichts passieren, wenn man ihn ablehnt. Eine Aktion ändert eine Datei, Konfiguration, einen Zweig, ein Paket oder eine Umgebung. Sobald ein Agent handelt, benötigt er die gleiche Logik wie andere Automatisierungen: die geringsten erforderlichen Berechtigungen, Aufzeichnung der Schritte, Vorschauoption und Rollback-Option. Die Intelligenz des Modells setzt diese Logik nicht außer Kraft. Es erweitert lediglich den Umfang dessen, was die Automatisierung gestalten kann.
Im normalen Entwicklungsprozess bedeutet dies eine einfache Bremse. Der Agent kann die Vorbereitung der Änderung zwar beschleunigen, aber die Akzeptanz der Änderung muss dennoch an einem Ort erfolgen, an dem klar ist, wer die Entscheidung getroffen hat. Ein Commit ohne Besitzer, ein Test ohne Bedeutung und ein grüner Lauf ohne Rollback sind keine Anzeichen einer ausgereiften KI. Es sind die Schwächen des Prozesses, die die KI nur beschleunigt hat.
16. Die Helferabhängigkeit ist ein anderes Konto als die Commit-Geschwindigkeit
Ein Team kann mit einem Assistenten beschleunigen und trotzdem neue Schulden machen. Nicht im Code, sondern im Workflow. Wenn Menschen die Veränderungen, die sie akzeptieren, nicht mehr verstehen, wächst die Sucht. Wenn das Wissen über das System vom Teamleiter auf die Eingabeaufforderungen und das Tool verlagert wird, erhöht sich das Risiko im Falle eines Serviceausfalls, einer Preisänderung oder eines Modellwechsels.
Sucht muss nicht schlimm sein. Jedes Team ist auf den Editor, das CI, die Cloud und die Paketregistrierung angewiesen. Der Unterschied besteht darin, ob sie die Sucht sehen. Wenn ein Assistent die Routine beschleunigt und das Team trotzdem ohne ihn Unterschiede lesen, Tests durchführen und einen Vorfall lösen kann, handelt es sich um ein Werkzeug. Wenn sie ihre eigenen Veränderungen ohne sie nicht verstehen können, handelt es sich um eine betriebliche Schwäche.
Dieses Konto wird normalerweise nicht im Benchmark angezeigt. Ein Benchmark misst eine Aufgabe. Die Abhängigkeit misst den Tag, an dem ein Dienst ausfällt, sich ein Modell ändert, Kontoregeln verschärft werden oder ein neues Teammitglied einen alten Commit erklären muss. Wer nur Wert auf die Geschwindigkeit des Commits legt, übersieht möglicherweise die Kosten, die durch den Verlust des Verständnisses entstehen.
17. Dreimal sagt mehr als eine Ersatzüberschrift
Ein Übungstest für ein Team muss nicht groß sein. Muss genau sein. Wählen Sie einige Aufgaben aus, die Sie sicher messen können. Ein einfaches mit guten Tests. Einer in einem bekannten Teil des Systems. Eines, bei dem Überprüfung oder Sicherheitsspielraum wichtig sind. Führen Sie jeweils eine Variante ohne Assistent und mit Assistent durch, sofern dies organisatorisch möglich ist. Suchen Sie nicht nach den Schwachstellen anderer Personen, arbeiten Sie nicht ohne Genehmigung und geben Sie einem Agenten keine Geheimnisse, die er nicht benötigt.
Dreimal messen. Erstens: Eingabe und Erstellung eines Designs. Die zweite: Kontrolle, also Unterschiede, Tests, Überprüfung und Korrekturen. Drittens: Den Diensteigentümer in einen Zustand versetzen, in dem er den Vorfall unterzeichnen würde. Es ist das dritte Mal, dass sich die Demo von der Produktion unterscheidet. Code, der einen lokalen Test besteht, entspricht möglicherweise nicht dem Status, den das Team akzeptiert.
Was muss getestet werden
Schreiben Sie für jede Aufgabe im Voraus auf, was sie zu erledigen bedeutet. Nicht „das Model hat geantwortet“. Fertig bedeutet: Die Tests sind bestanden, die Prüfung macht Sinn, das Risiko ist benannt, das Rollback existiert und der Service Owner würde die Änderung in seinen Prozess übernehmen. Wenn die Steuerung die Ersparnis verschluckt, gilt der Satz „Das Schreiben hat sich verkürzt, die Verantwortung nicht“. Wenn die gesamte Kette verkürzt wird, haben Sie einen echten Vorteil.
18. Die Frage ist nicht, ob KI Programmierer ersetzen wird. Es hört sich danach an, wer die Folgen tragen wird
Ein schnellerer HTTP-Server könnte wahr sein. Weitere geschlossene Aufgaben können wahr sein. Es kann auch wahr sein, erfahrene Leute in einem bekannten Repository auszubremsen. Diese Sätze schließen sich nicht gegenseitig aus, da sie nicht dasselbe messen. Man spricht von Skelett und Tests. Der zweite über den Aufgabenablauf im Unternehmen. Der dritte über den Kontext, den das Modell nicht hat. Der vierte, der operative, fragt, wer die Konsequenzen tragen wird.
Daraus folgt nicht, dass die Frage der Programmierer ruhig ist. Daraus folgt, dass es fehl am Platz ist, wenn es nur heißt „wird ersetzen oder nicht ersetzen“. Die Software besteht aus Aufgaben, Tests, Überprüfung, Betrieb und Verantwortung. Einige Teile werden schneller. Einige werden umziehen. Einige sind möglicherweise billiger. Einige werden teurer, weil das Überprüfen wichtiger sein wird als das Schreiben.
Die richtige Frage ist also nicht, ob KI Programmierer ersetzen wird. Darin heißt es: Bei welcher Aufgabe verkürzt der Assistent die Schrift, bei welcher verlängert sich die Prüfung im bekannten System und wer unterschreibt den Ausfall, wenn die Grüntests in der Nacht nicht ausreichen. Solange die Reaktion beim Benchmark endet, fehlt es an Produktion. Und solange es am Ende zur Produktion kommt, ohne die Aufgabe zu messen, fehlt der Beweis.
Verwandte Texte in dieser Reihe
- Welche Berufe wird KI ersetzen? — Arbeitsmarkt; Dieser Text ist eine Aufgabe, ein Test und ein Bereitschaftsdienst.
- ChatGPT vs. Gemini vs. Claude vs. Grok… — Die SWE-Benchmark ist ein Urteil, kein Berufungsurteil.
- Wem erlauben Sie, Fehler zu machen?