Rubrik: Technologie & KI Autor: V Leselänge: ~27 Min Quellen und weiterführende Literatur: 22 Einträge Themen: KI, Programmierung, Copilot, Cursor, Produktivität, Tests, Betrieb, Verantwortung SEO / Arbeitstitel: Kann KI Programmierer ersetzen?
Kann KI Programmierer ersetzen? Die Frage klingt nur so lange einfach, bis wir merken, dass wir nicht eine Arbeit vergleichen. Kürzere Zeit an einem HTTP-Server im Labor ist keine Woche im Team. Ein gelöstes GitHub-Issue ist kein On-Call. Der 50% time horizon eines Modells ist keine halbe Stelle. Und ein Benchmark-Wert unterschreibt keinen Incident. Der Artikel sucht deshalb kein Datum, an dem der Programmierer verschwindet. Er sucht, welche Aufgabe der Assistent beschleunigt, wohin die Arbeit bei der Prüfung wandert und wer beim Ausfall bleibt.
1. Zwölf grüne Tests an einem HTTP-Server sind kein nächtlicher Revert in der Produktion
Die Freitagsdemo wirkt überzeugend. Ein Junior zeigt einen kleinen HTTP-Server in JavaScript. Die Tests leuchten grün. Er erklärt, dass er die Lösung mit Copilot viel schneller geschrieben hat, als er erwartet hatte. Der Tech Lead sitzt neben ihm und sagt, dass ihm der Agent in einem großen internen Repository oft Arbeit hinzufügt, weil er Umwege prüfen muss, die er selbst nie geschrieben hätte. Der Product Manager zeigt eine Grafik geschlossener Tickets. Der Direktor fragt, ob er im nächsten Quartal weniger Leute einstellen soll. Der On-Call-Ingenieur stellt eine kürzere Frage: Wer macht nachts den Revert, wenn die grünen Tests nicht reichen.
Auf den ersten Blick ist das ein Streit, ob KI Programmierer ersetzen wird oder nicht. Tatsächlich misst jeder ein anderes Objekt. Der Junior eine Laboraufgabe mit klarem Auftrag. Der Tech Lead ein reifes System, das er kennt. Der Product Manager die Zahl abgeschlossener Arbeitseinheiten. Der Direktor möchte die Aufgabe gern in einen Einstellungsplan übersetzen. Der Mensch im On-Call misst die Verantwortung für den Betrieb.
Peng, Kalliamvakou, Cihon und Demirer haben in einer Studie mit GitHub Copilot vom 15. Mai bis 20. Juni 2022 eine Programmieraufgabe gemessen: die Implementierung eines HTTP-Servers in JavaScript, der zwölf Tests bestehen musste. In der Studie waren 95 Freelancer von Upwork, und 35 Personen in jedem Versuchsarm haben die Aufgabe abgeschlossen. Die Autoren berichten eine Zeitverkürzung um 55,8 % mit einem 95%-Konfidenzintervall von 21 bis 89 [1]. Das ist eine starke Zahl. Sie misst jedoch keine Produktions-Codebase, kein Review, keinen Incident, kein Eigentum an einem Dienst und nicht die nächtliche Entscheidung, ob ein Rollback die Kunden mehr schädigt als der Fehler.
Ein schnellerer HTTP-Server ist nicht dasselbe wie die Verantwortung für ein Produktionssystem.
— Jiný Kontext
2. Programmierarbeit hat mindestens sechs Schichten
Wenn auf dem Bildschirm ein Diff erscheint, entsteht der Eindruck, „den Code hat die KI geschrieben“. Das Ergebnis entsteht aber in mehreren Schichten. Jede lässt sich anders messen, und jede kann zu einem anderen Schluss führen.
- Codeerzeugung: Autovervollständigung, Boilerplate, Tests, Skripte und kleine Transformationen.
- Änderung eines bekannten Systems: Arbeit in einem Repository, dessen Abkürzungen, Schulden und ungeschriebenen Regeln ein Mensch kennt.
- Agent-Benchmark: Issue, Patch, Ausführen der Tests und ein Wert auf einem öffentlichen Satz.
- Länge der Aufgabe: der Horizont, auf dem das Modell immer längere Arbeit mit einer bestimmten Erfolgsquote abschließt.
- Messung im Team: Tickets, Lead Time, Review, Defekte, Unterbrechungen der Arbeit und eine Änderung des Prozesses.
- Verantwortung: Merge, Incident, Sicherheitswirkung, Audit, Kunde und Rollback.
Diese Schichten sind keine feinen Nuancen. Es sind verschiedene Gegenstände der Messung. Peng misst die Zeit bis zum Bestehen der Tests bei einer klar begrenzten Aufgabe [1]. Cui und Mitautoren messen in Feldexperimenten abgeschlossene Aufgaben in Organisationen [2]. METR misst 2025 erfahrene Open-Source-Entwickler an realen Issues in Repositories, die sie gut kennen [4][5]. SWE-bench misst die Reparatur von GitHub-Issues in einem Harness [9]. Time horizon misst, wie lange die Softwareaufgaben sind, die Modelle mit einer gegebenen Erfolgsquote bewältigen [6].
Die Skizze des Arbeitsmarkts fragt, was mit dem Beruf geschieht. Hier ist die Frage enger. Welche Schicht der Software wird gerade gemessen? Wenn wir sie nicht benennen, landen wir bei einem Satz, der aus einem grünen Test Personalpolitik macht und aus einer Verlangsamung ein Verbot des Werkzeugs.
3. Der beste Assistent ist der, dessen Fehler Test, Review und Rollback auffangen
Beim Code ist es verlockend, die Schreibgeschwindigkeit zu messen. Software ist aber kein Textabsatz. Ein Fehler kann offensichtlich, billig und umkehrbar sein. Oder er geht glatt durch die Tests und erscheint erst in den Daten des Kunden. Deshalb ist ein guter Assistent nicht nur der, der die meisten Zeilen entwirft. Es ist ein Werkzeug, dessen Scheitern sichtbar ist, bevor es zum Betriebsproblem wird.
| Art des Scheiterns | Wie es aussieht | Wie testen | Was den Schaden begrenzt |
|---|---|---|---|
| Konfabulation von Code | Das Diff wirkt fertig, ändert aber die Autorisierung oder einen Randfall | Review, CI, Eigentümertest und Rollback | Ein Mensch mergt, der Agent hat begrenzte Rechte |
| Schlechtes Messdesign | Verdikt über einen Beruf aus einem RCT | Aufgabe, Ticket, bekanntes Repo und Betrieb trennen | Die Zahl nicht auf eine Stelle umlegen |
| Verschiebung ins Review | Der Commit ist schneller, der Merge langsamer | Auftrag, Prüfung und akzeptablen Zustand messen | Die ganze Kette bewerten |
| Benchmark als Aussage | Ein SWE-bench-Wert als Ersatz für die Arbeit eines Teams | Aufzählen, was der Satz nicht misst | Interne Aufgaben vor der öffentlichen Überschrift |
| Incident ohne Eigentümer | „Das hat die KI geschrieben“ statt eines verantwortlichen Merge | Wer revertet, wer meldet, wer erklärt | Runbook auf einen Menschen und eine Organisation |
Damit ändert sich auch die Kauffrage. Wir fragen nicht nur, wie viel Zeit der Assistent beim Schreiben spart. Wir fragen, ob wir Tests, Review, Observability, Rechte und Rollback haben, die seinen Fehler tragen. Dort, wo der Fehler billig und die Prüfung klar ist, kann der Nutzen groß sein. Dort, wo der Fehler in die Produktion entkommt, kann schnelleres Erzeugen das Problem nur an eine teurere Stelle verschieben.
4. Drei Designs, drei Richtungen. Nicht drei Verdikte über einen Beruf
Die öffentliche Debatte mag eine Grafik. Die Forschung zur Produktivität von Programmierern mit KI bietet eher drei verschiedene Designs.
Peng und Mitautoren haben eine Laboraufgabe mit klarem Ergebnis gemessen: HTTP-Server in JavaScript, zwölf Tests, Freelancer von Upwork und Zeit bis zum Abschluss [1]. Cui, Demirer, Jaffe, Musolff, Peng und Salz arbeiten in der Fassung vom Februar 2025 mit 4 867 Entwicklern bei Microsoft, Accenture und einem Fortune-100-Unternehmen. Ihr instrumenteller Schätzer der Copilot-Nutzung auf die Zahl abgeschlossener Aufgaben beträgt +26,08 % je Woche bei einem Standardfehler von 10,3 [2][3]. METR und Becker et al. haben im Jahr 2025 insgesamt 16 erfahrene Entwickler, 246 reale Issues, eine durchschnittliche menschliche Zeit von 2,0 Stunden und Repositories mit etwa 23 Tausend Sternen verfolgt. Mit Cursor Pro und Claude 3.5/3.7 haben sie eine Verlängerung der Zeit um 19 % gemessen [4][5].
Das sind keine drei Verdikte. Es sind drei Fenster. Im einen gibt es ein klares Skeleton und Tests. Im zweiten gewöhnliche Firmenaufgaben und die Übernahme eines Werkzeugs. Im dritten Menschen, die ihren Code kennen und Vorschläge gegen einen Kontext prüfen müssen, den sie im Kopf haben. Keine dieser Messungen sagt für sich, ob ein Arbeitsvertrag endet. Und keine lässt sich ehrlich verwenden ohne die Beschreibung der Population, des Zeitraums, der Metrik und dessen, was nicht gezählt wurde.
5. Eine Beschleunigung am Skeleton ist keine Juniorstelle
Das Ergebnis der Studie von Peng ist gerade deshalb wichtig, weil es eng ist. Es zeigt, dass ein Assistent bei einer gut begrenzten Aufgabe mit prüfbarem Ergebnis die Zeit deutlich verkürzen kann. Besonders dort, wo viel Boilerplate ist und wo Tests schnell sagen, ob die Lösung funktioniert. Das ist genau die Art von Arbeit, an der viele weniger erfahrene Menschen lernen.
Daraus folgt nicht, dass sich ein Junior vom Budget abziehen lässt. Die Studie hatte eine bestimmte Aufgabe, einen bestimmten Zeitraum und eine abgeschlossene Stichprobe von 35 Personen in jedem Versuchsarm [1]. Sie hat weder Onboarding gemessen noch Kenntnis der Firmendomäne, Kommunikation mit dem Produkt, das Schärfen von Anforderungen, das Review fremden Codes oder das Halten eines Dienstes im Betrieb. Sie hat auch nicht gemessen, ob das Team in einem halben Jahr die fehlende Ausbildung neuer Leute bezahlt.
Der richtige Satz der Leitung lautet also nicht: „KI erledigt die Juniorarbeit.“ Er lautet: „Bei Aufgaben wie dieser kann sich das Schreiben deutlich verkürzen, wenn wir klare Tests und eine billige Prüfung haben.“ Das ist weniger effektvoll. Es ist aber brauchbarer.
Für ein Team folgt daraus ein anderer Test. Nehmen Sie eine eigene kleine Aufgabe, die einem Skeleton ähnelt: bekannter Auftrag, klares Ergebnis, automatische Tests. Lassen Sie sie mit Assistent und ohne ihn erledigen. Messen Sie nicht nur die Schreibzeit, sondern auch die Zeit, in der ein Senior das Diff liest. Wenn die Ersparnis im Review verloren geht, wurde Arbeit nicht entfernt. Sie wurde verschoben.
Diese Verschiebung kann trotzdem eine gute Nachricht sein. Ein Junior, der mit dem Assistenten schneller einen ersten Entwurf herstellt, kann früher auf Fragen der Architektur, des Testens und der Verantwortung stoßen. Das gilt aber nur, wenn das Team das Modell nicht das Lernen ersetzen lässt. Wenn ein Mensch nicht weiß, warum der Code den Test bestanden hat, kann er ihn nicht halten. Wenn er das eigene Diff nicht erklären kann, ist er nicht bereit, eine Änderung in ein geteiltes System zu tragen. Der Nutzen des Assistenten muss deshalb zusammen mit dem Lernen gemessen werden: Hat er den Weg zum Verstehen beschleunigt, oder hat er nur mehr Text erzeugt, den jemand anderes entwirren muss?
6. Mehr abgeschlossene Tickets sind nicht mehr Qualität im Betrieb
Cui und Mitautoren verschieben die Debatte aus dem Labor in die Firmen. Das ist eine große Änderung. Viertausendachthundertsiebenundsechzig Entwickler, drei Organisationen und die Messung abgeschlossener Aufgaben je Woche liegen näher an dem, was Leitung interessiert [2]. Der Schätzer von +26,08 % abgeschlossener Aufgaben je Woche liegt dabei unter dem Laboreffekt bei Pengs Aufgabe, was die Autoren selbst mit dem Unterschied zwischen einer reinen Aufgabe und der gewöhnlichen Arbeit verbinden [2].
Aber auch ein Ticket ist nur eine Einheit des Prozesses. Eine abgeschlossene Aufgabe ist nicht automatisch eine qualitativ gute Änderung in der Produktion. Es kommt darauf an, was die Organisation als fertig zählt, wie stark das Review ist und ob Defekte, Incidents, Kundenwirkungen und die Zeit anderer Menschen gemessen werden. Ein Team kann mit dem Assistenten mehr kleine Aufgaben schließen und zugleich das Review belasten. Oder es kann den Durchsatz wirklich erhöhen, ohne dass die Qualität sinkt. Daten zu abgeschlossenen Aufgaben sind ein Anfang, keine Endabrechnung.
Hier bricht die Debatte über den Ersatz oft. Wenn eine Firma nur die Zahl der Tickets verfolgt, wird sie in Versuchung geraten, ein Prozent in Menschen umzurechnen. Wenn sie auch Defekte, Review und betriebliche Änderungen verfolgt, kann sie etwas anderes finden: Der Assistent erhöht das Arbeitsvolumen, verlangt aber eine andere Art der Prüfung und eine andere Verteilung der Verantwortung.
Bei Feldmessungen ist außerdem wichtig, wer das Werkzeug wirklich benutzt und bei welchen Aufgaben. Die Übernahme ist meist nicht zufällig verteilt wie Farbe an einer Wand. Jemand greift beim Assistenten zu einfachen Korrekturen, jemand zur Recherche von Bibliotheken, jemand zu Tests und jemand fast nie. Wenn dann die Zahl abgeschlossener Aufgaben verfolgt wird, kann das Ergebnis die Fähigkeit des Werkzeugs, die Bereitschaft der Leute, es zu nutzen, die Art der zugeteilten Tickets und die Regeln des Teams vermischen. Cui und Mitautoren gehen darauf im Forschungsdesign ein; der Leser sollte daraus vor allem Vorsicht mitnehmen, wenn er es in die eigene Firma übersetzt [2].
Ein Firmenpilot darf deshalb nicht nur das Werkzeug einschalten und nach einem Monat die geschlossenen Posten zählen. Er muss Aufgabentypen, Erfahrung der Leute, Größe des Diffs, Reviewzeit und die Zahl zurückgewiesener Änderungen unterscheiden. Sonst kann eine gute Nachricht über den Durchsatz einen neuen Engpass bei denen verdecken, die die Änderungen prüfen.
Noch genauer ist zu verfolgen, wer die Beschleunigung bezahlt. Wenn der Assistent dem Autor der Aufgabe hilft, der Reviewer aber mehr Zeit mit der Prüfung verbringt, hat sich die Ersparnis zwischen Menschen verschoben. Wenn die Zahl der Tickets steigt, aber auch die Zahl der Rückläufer aus der QA, hat sich die Ersparnis in eine andere Warteschlange verschoben. Wenn sich die ganze Kette vom Auftrag bis zur sicher angenommenen Änderung verkürzt, hat das Team einen Beleg, der mehr wert ist als eine allgemeine Überschrift über KI.
7. Eine Verlangsamung bei Leuten, die das Repo kennen, ist kein Beweis, dass der Assistent nicht funktioniert
METR hat 2025 ein unbequemes Ergebnis gebracht. Erfahrene Open-Source-Entwickler haben an Issues in Repositories gearbeitet, die sie gut kannten. Die durchschnittliche Erfahrung mit dem jeweiligen Repository betrug mehrere Jahre, die Aufgaben hatten eine durchschnittliche menschliche Zeit von 2,0 Stunden, und die Studie lief von Februar bis Juni 2025. Als ihnen der Einsatz von KI-Werkzeugen erlaubt war, hat sich die Zeit im Mittel um 19 % verlängert [4][5].
Noch interessanter ist die Erwartung. Die Entwickler erwarteten im Voraus eine Beschleunigung um 24 %. Nach der Studie schätzten sie weiterhin, mit KI um 20 % schneller gewesen zu sein, obwohl das gemessene Ergebnis in die Gegenrichtung ging [5]. Das ist kein Beweis, dass die Entwickler nicht wissen, was sie tun. Es ist eine Warnung, dass das subjektive Gefühl flüssiger Arbeit auch erfahrene Menschen täuschen kann.
Daraus folgt nicht, dass der Assistent nicht funktioniert. Daraus folgt, dass ein Mensch in einem bekannten System Kontext im Kopf hat, den das Modell nicht hat. Er weiß, welche scheinbar einfache Lösung eine alte Integration zerbricht. Er weiß, warum ein seltsamer Helper absichtlich seltsam ist. Er weiß, dass ein Test nur in Verbindung mit Daten fehlschlägt, die nicht im Repository liegen. KI kann Vorschläge hinzufügen, aber auch Sackgassen, die geprüft werden müssen.
Drei Tests der Produktivität
Messen Sie die Zeit bis zu grünen Tests an einem neuen Skeleton? Messen Sie die Zahl abgeschlossener Aufgaben im Team? Oder messen Sie die Zeit an einem Issue in Ihrem eigenen reifen Repository? Drei Ja-Antworten addieren sich nicht. Jede gehört zu einer anderen Entscheidung.
8. Ein 50% time horizon ist kein Ersatz von 50 % einer Stelle
METR misst in der Studie von Kwa et al. die Fähigkeit von Modellen, immer längere Softwareaufgaben abzuschließen. Gearbeitet wird mit einem Satz von 170 Aufgaben, unter anderem HCAST, RE-Bench und 66 SWAA, und mit zwölf Frontier-Modellen. Beim Modell o3 gibt sie etwa 110 Minuten menschlicher Zeit als 50% time horizon an [6]. Die Studie schätzt zugleich, dass sich dieser Horizont seit 2019 etwa alle sieben Monate verdoppelt hat, genauer 207 Tage mit einem 95%-Intervall von 166 bis 240 Tagen [6][7].
Das ist wichtig für die Richtung der Entwicklung. Es ist aber kein Satz, dass das Modell die Hälfte eines Programmierers ersetzt. Ein 50%-Horizont bedeutet, dass das Modell auf dem gegebenen Satz ungefähr eine halbe Erfolgsquote bei einer Aufgabe hat, die einer bestimmten menschlichen Zeit entspricht. METR gibt außerdem an, dass der 80%-Horizont etwa vier- bis sechsmal kürzer ist [6][7]. Die Produktion will meist keine halbe Chance. Sie will Zuverlässigkeit, Wiederholbarkeit und Verantwortung.
Eine Notiz von METR vom 20. März 2026 warnt zudem, dass die Ergebnisse zum time horizon empfindlich gegenüber Modellannahmen, Regularisierung und der Schätzung menschlicher Zeiten sind [8]. Das hebt den Trend nicht auf. Es verhindert nur die Übersetzung in einen einfachen Satz über Monate Arbeit in einer beliebigen Firma.
Ein 50% time horizon sagt, wie lang eine Aufgabe ist, die das Modell gelegentlich abschließt. Er sagt nicht, wer nachts den Ausfall revertet.
— Jiný Kontext
9. SWE-bench repariert ein Issue mit Tests. Es entwirft keine Architektur und trägt keinen Pager
SWE-bench ist ein nützlicher Benchmark, weil er von realen GitHub-Issues auszugehen versucht. Die ursprüngliche Arbeit von Jimenez und Mitautoren arbeitete mit 2 294 Issues aus zwölf Python-Repositories. Im Paper erreichte Claude 2 mit BM25-Suche 1,96 % gelöste Issues; GPT-4 wurde wegen des Budgets auf einer 25%-Teilmenge bewertet [9]. Das spätere SWE-bench Verified von OpenAI hat eine von Menschen geprüfte Stichprobe von 500 Einträgen eingeführt und nennt GPT-4o mit einem Wert von 33,2 % [10]. Epoch AI beschreibt den geprüften Satz auch als Variante mit 500 bzw. 484 nutzbaren Samples je nach Einstellung [11].
Das ist ein Fortschritt in der Messung von Agenten. Es ist nicht die Arbeit eines Programmierers. Der Benchmark enthält keine Absprache mit dem Produkt, keine Entscheidung über die Architektur, kein Lesen interner Incidents, keine Migration ohne Ausfall, kein Security-Review und keinen On-Call. Er enthält ein Issue, ein Repository, Tests und eine Art der Bewertung.
Die richtige Frage lautet also nicht, ob SWE-bench die Zukunft des Programmierens zeigt. Er zeigt eine wichtige Schicht: die Fähigkeit von Modellen, einige Fehler in offenen Repositories unter einem Test zu finden und zu beheben. Für die Wahl eines Werkzeugs ist das ein Signal. Für einen Plan der Verantwortung in der Produktion ist das zu wenig.
10. Schnelleres Boilerplate bei weniger Erfahrenen ist nicht das Ende des Seniors
Ergebnisse zu Coding-Assistenten zeigen oft einen größeren Nutzen bei weniger erfahrenen Menschen oder bei Menschen in einem weniger bekannten Teil der Arbeit. Das ergibt Sinn. Dort, wo ein Mensch Syntax, Boilerplate, ein übliches Muster oder einen ersten Entwurf eines Tests sucht, kann ein Modell schnell Material zur Bearbeitung liefern. Dort, wo ein Senior die Geschichte des Systems im Kopf hält, können Vorschläge Rauschen hinzufügen.
Daraus folgt nicht das Ende des Seniors. Es gilt auch nicht der umgekehrte bequeme Satz, der Senior liege außerhalb der Reichweite der Änderung. Eher ändert sich die Zusammensetzung der Arbeit. Ein weniger erfahrener Mensch kann schneller zu einer ersten Lösung kommen, muss aber lernen, ein Diff zu lesen, Tests zu verstehen und zu erkennen, wann das Modell nur selbstbewusst ein falsches Muster abgeschrieben hat. Ein Senior kann weniger Routinecode schreiben, dafür aber mehr Grenzen setzen, Sicherheit prüfen und über die Annahme einer Änderung entscheiden.
Ein Team, das daraus nur eine Ersparnis an Leuten macht, riskiert zwei Dinge. Es verliert die Lehrarbeit, an der künftige Seniors wachsen. Und es verschiebt die Prüfung auf eine kleinere Zahl von Menschen, die dann eine größere Review-Warteschlange tragen. Ein Team, das den Assistenten wegen einer Verlangsamung verbietet, kann wiederum billige Gewinne bei gut testbaren Aufgaben liegen lassen.
11. Die Nutzung des Werkzeugs ist kein Vertrauen in die Ausgabe
Der Stack Overflow Developer Survey 2025 zeigt eine hohe Übernahme von KI-Werkzeugen. Nach dem Überblick nutzen oder planen 84 % der Befragten KI-Werkzeuge, gegenüber 76 % im Jahr 2024. Bei den Profis wird angegeben, dass 51 % KI täglich nutzen. Zugleich misstrauen 46 % der Befragten der Genauigkeit der Ausgabe eher, als dass sie ihr vertrauen, während 33 % Vertrauen äußern [12][13].
Das ist keine repräsentative Auswahl aller Programmierer in der Wirtschaft. Es ist eine Selbstauswahl der Befragten von Stack Overflow. Trotzdem ist das Signal nützlich: Nutzung und Vertrauen sind nicht dasselbe. Ein Mensch kann das Werkzeug jeden Tag nutzen, weil es Zeit beim Suchen, beim Entwurf eines Tests oder bei der Erklärung eines Fehlers spart. Zugleich muss er nicht glauben, dass eine Ausgabe ohne Prüfung in die Produktion gehört.
Gerade dieser Unterschied ist für Software gesund. Ein Programmierer muss kein Gegner der KI sein, um ein autonomes Deployment abzulehnen. Er muss kein Enthusiast sein, um Codevervollständigung zu nutzen. Vertrauen ist kein Aufkleber auf einem Werkzeug. Es ist ein Verhältnis zu einer bestimmten Aufgabe, zu Tests, Rechten und der Wirkung eines Fehlers.
12. Die Prüfung kann die Ersparnis aus dem Erzeugen auffressen
Ein Assistent beschleunigt oft den ersten Entwurf. Das sieht man auch ohne Studie. Weniger sichtbar ist die zweite Rechnung: die Prüfung. Ein Mensch muss das Diff lesen, verstehen, warum die Änderung funktioniert, Tests ausführen, einen fehlenden Test nachziehen, die Sicherheit prüfen, die Wirkung auf Migrationen finden und entscheiden, ob sich das Ergebnis annehmen lässt.
Bei einer einfachen Aufgabe kann die Prüfung billig sein. Tests sagen ja oder nein, und der Fehler hat wenig Wirkung. Bei einem reifen System ist die Prüfung selbst die Arbeit. Ein Modell kann eine Lösung erzeugen, die lokal besteht, aber nicht zur Architektur des Dienstes passt. Es kann mehr Dateien ändern, als nötig war. Es kann eine scheinbar überflüssige Guard entfernen, die einen historischen Randfall geschützt hat. Jede solche Sache fügt einem Senior Zeit hinzu.
Die Prüfung hat auch verschiedene Preise je nach Umgebung. In einer Bibliothek ohne Daten können ein Test und ein kurzes Review genügen. In einem Zahlungsfluss, einem Gesundheitssystem oder einer internen Verwaltung mit personenbezogenen Daten ist dasselbe Diff teurer, weil die Wirkung des Fehlers teurer ist. Das ist keine Frage der Angst vor KI. Es ist dieselbe Logik, die Teams bei menschlichen Änderungen nutzen: Eine riskante Änderung braucht mehr Augen, bessere Observability und einen Plan zur Rückkehr.
Wie testen, wohin die Arbeit gewandert ist
Wählen Sie ein eigenes Übungs-Repository oder eine interne Sandbox. Nutzen Sie keine fremden Produktionssysteme und überschreiten Sie keine Rechte. Bei demselben Aufgabentyp messen Sie drei Zeiten: Auftrag, Prüfung und das Bringen in einen Zustand, für den Sie einen Incident unterschreiben würden. Wenn das Schreiben kürzer geworden ist, die Prüfung aber stärker gewachsen ist, haben Sie keinen Ersatz für einen Programmierer. Sie haben eine Verschiebung der Arbeit.
13. Der Arbeitsmarkt ist eine andere Frage als ein Merge in die Produktion
In der Debatte über Programmierer öffnet sich leicht die weitere Frage des Arbeitsmarkts. Wie viele IKT-Fachkräfte es gibt, wie die Löhne steigen, wie viele Studierende an die Schulen kommen, was OECD, ILO oder Eloundou zur Exposition von Aufgaben sagen. Das sind legitime Themen. Sie gehören aber auf eine andere Karte als die Frage, ob ein bestimmter Assistent eine Änderung im Repository sicher beschleunigt.
Das ČSÚ beschreibt zum Beispiel IKT-Fachkräfte in Tschechien und ihre Löhne [14][15][16]. Eloundou, ILO und OECD beschreiben die Exposition von Aufgaben und Änderungen der Arbeit in der weiteren Wirtschaft [17][18][21]. Diese Quellen sagen nicht, ob Ihr Agent die Autorisierung richtig ändert, ob das Review den Fehler auffängt oder wer nachts den Rollback ausführt. Deshalb bauen wir in diesem Artikel keine Rangfolge der Berufe und übertragen keine Prozente vom Arbeitsmarkt in den Softwareprozess.
Die richtige Grenze lautet: Der Arbeitsmarkt kann sagen, warum die Frage wichtig ist. Er antwortet nicht für den Merge. Soll ein Assistent einem bestimmten Team helfen, muss er die eigene Aufgabe, den eigenen Test, das eigene Review und die eigene betriebliche Verantwortung zeigen. Ohne das ist die Debatte über den Ersatz von Programmierern zu weit, um zu einer sicheren Entscheidung zu führen.
Das ist auch der Grund, warum wir hier keine Prozente aus dem Artikel über Berufe als Abkürzung verwenden. Die Exposition von Aufgaben in der Wirtschaft kann je nach Methode hoch oder niedrig sein, aber ein Merge Request in einem bestimmten Repository entscheidet sich nach anderen Belegen. Hat das Diff einen Test? Versteht es der Reviewer? Hat es den Dienst verbessert? Hat es eine stille Sicherheitsschuld hinzugefügt? Fehlen diese Antworten, hilft der Arbeitsmarkt nicht. Sind sie klar, kann das Team das Werkzeug nutzen, ohne große Erklärungen über das Ende des Berufs.
14. Ein Benchmark-Wert unterschreibt keinen Incident
Wenn ein Agent einen Benchmark löst, unterschreibt das ein Wert. Wenn eine Änderung die Produktion umlegt, unterschreibt das eine Organisation. Dieser Unterschied ist grundlegend. Ein Modell ist kein Beschäftigter in einem Vertragsverhältnis, kein Inhaber eines Pagers und keine Person, die dem Kunden erklärt, warum Daten falsch verarbeitet wurden. Ein Werkzeug kann ein Diff vorschlagen. Die Verantwortung für dessen Annahme bleibt im Prozess.
Der AI Act ordnet einige Systeme in Beschäftigung und Führung von Arbeitnehmern je nach Verwendung als hochriskant ein, etwa bei Einstellung oder Bewertung von Personen [20]. Das ist hier kein Argument, dass Copilot verboten sei, und auch keines, dass Programmierer verschwinden. Es ist eine Erinnerung, dass die Verwendung von KI in einer Entscheidung über einen Menschen oder über Arbeit andere Anforderungen hat als das Erzeugen eines Tests in einer Sandbox.
Vor dem Merge in die Produktion
Ist das Ergebnis durch Tests gedeckt, die das wirkliche Risiko messen, nicht nur den glücklichen Pfad? Wer ist Eigentümer des Dienstes, und wer hat das Recht, die Änderung anzunehmen? Gibt es Rollback, Observability und einen Kommunikationsplan? Sind Geheimnisse von einem Werkzeug getrennt, das sie nicht sehen darf? Wenn das Team diese Fragen nicht beantworten kann, hilft ihm ein Benchmark-Wert nicht.
15. Ein Agent mit dem Recht, Dateien zu ändern, ist ein anderer Fehler als ein halluziniertes Snippet
Die ältere Debatte über KI im Programmieren sah oft so aus: Das Modell schlägt ein Snippet vor, und ein Mensch kopiert es. Heute liest ein Agent das Repository, ändert Dateien, führt Tests aus, installiert Abhängigkeiten und bereitet manchmal einen Commit vor. Das ist eine andere Risikoklasse. Ein falsches Snippet ist Text. Ein falscher Agentenschritt kann den Zustand eines Projekts ändern.
Es geht nicht nur um die Qualität des Modells. Es geht um Rechte. Darf der Agent Produktionsgeheimnisse lesen? Darf er außerhalb des Workspace greifen? Darf er Befehle ausführen, die eine Datenbank ändern? Darf er pushen? Darf er einen Konflikt so lösen, dass er fremde Arbeit entfernt? Jedes „darf“ ändert den Preis des Fehlers.
Gute Praxis beginnt deshalb nicht mit dem Satz, das Modell sei klug. Sie beginnt mit einer Sandbox, einer Vorschau der Änderungen, der Trennung von Geheimnissen, der Begrenzung des Schreibens und der menschlichen Freigabe dort, wo das Ergebnis einen geteilten Zustand ändert. Ein Agent kann in einem sicher begrenzten Raum ein ausgezeichneter Helfer sein. Derselbe Agent mit zu weitem Zugang kann Schaden schneller anrichten als der Mensch, den er beschleunigen sollte.
Besonders wichtig ist der Unterschied zwischen Vorschlag und Handlung. Ein Vorschlag kann falsch sein, und es geschieht nichts, wenn ein Mensch ihn ablehnt. Eine Handlung ändert eine Datei, eine Konfiguration, einen Branch, ein Paket oder eine Umgebung. Sobald ein Agent handelt, braucht er dieselbe Logik wie andere Automatisierung: die kleinsten nötigen Rechte, ein Protokoll der Schritte, die Möglichkeit der Vorschau und die Möglichkeit der Rückkehr. Die Intelligenz des Modells hebt diese Logik nicht auf. Sie vergrößert nur den Umfang dessen, was Automatisierung vorschlagen kann.
Im gewöhnlichen Entwicklungsprozess bedeutet das eine schlichte Bremse. Der Agent darf die Vorbereitung einer Änderung beschleunigen, aber die Annahme der Änderung muss weiter durch eine Stelle gehen, an der klar ist, wer entschieden hat. Ein Commit ohne Eigentümer, ein Test ohne Sinn und ein grüner Lauf ohne Möglichkeit der Rückkehr sind keine Zeichen reifer KI. Es sind Schwächen des Prozesses, die die KI nur beschleunigt hat.
16. Abhängigkeit vom Assistenten ist eine andere Rechnung als Commit-Geschwindigkeit
Ein Team kann mit dem Assistenten schneller werden und sich trotzdem eine neue Schuld schaffen. Nicht im Code, sondern im Arbeitsablauf. Wenn Menschen die Änderungen, die sie annehmen, nicht mehr verstehen, wächst die Abhängigkeit. Wenn das Wissen über das System aus dem Kopf des Teams in Prompts und ein Werkzeug wandert, wächst das Risiko bei einem Ausfall des Dienstes, einer Preisänderung oder einem Wechsel des Modells.
Abhängigkeit muss nicht schlecht sein. Jedes Team hängt vom Editor, von CI, von der Cloud und vom Paketregister ab. Der Unterschied liegt darin, ob die Abhängigkeit sichtbar ist. Wenn der Assistent Routine beschleunigt und das Team weiterhin Diffs lesen, Tests halten und einen Incident ohne ihn lösen kann, ist er ein Werkzeug. Wenn es ohne ihn die eigenen Änderungen nicht versteht, ist das eine betriebliche Schwäche.
Diese Rechnung erscheint im Benchmark gewöhnlich nicht. Der Benchmark misst eine Aufgabe. Die Abhängigkeit misst den Tag, an dem der Dienst nicht geht, sich das Modell ändert, die Regeln des Kontos strenger werden oder ein neues Mitglied des Teams einen alten Commit erklären muss. Wer nur die Commit-Geschwindigkeit bewertet, kann den Preis des verlorenen Verstehens übersehen.
17. Drei Zeiten sagen mehr als eine Überschrift über den Ersatz
Ein praktischer Test für ein Team muss nicht groß sein. Er muss genau sein. Wählen Sie einige Aufgaben, die Sie sicher messen dürfen. Eine einfache mit guten Tests. Eine in einem bekannten Teil des Systems. Eine, bei der Review oder ein Sicherheitsrand wichtig ist. Führen Sie bei jeder eine Variante ohne Assistent und mit Assistent, wenn das organisatorisch möglich ist. Suchen Sie nicht nach fremden Schwachstellen, arbeiten Sie nicht außerhalb der Rechte und geben Sie dem Agenten keine Geheimnisse, die er nicht braucht.
Messen Sie drei Zeiten. Erstens: Auftrag und Erstellung eines Vorschlags. Zweitens: die Prüfung, also Diff, Tests, Review und Korrekturen. Drittens: das Bringen in einen Zustand, für den der Eigentümer des Dienstes einen Incident unterschreiben würde. Gerade die dritte Zeit unterscheidet Demo und Produktion. Code, der einen lokalen Test besteht, muss kein Zustand sein, den das Team annimmt.
Was zu testen ist
Schreiben Sie bei jeder Aufgabe vorher auf, was fertig bedeutet. Nicht „das Modell hat geantwortet“. Fertig bedeutet: Tests sind bestanden, das Review ergibt Sinn, das Risiko ist benannt, ein Rollback existiert, und der Eigentümer des Dienstes würde die Änderung in seinen Prozess nehmen. Wenn die Prüfung die Ersparnis schluckt, gilt der Satz „das Schreiben hat sich verkürzt, die Verantwortung nicht“. Wenn sich die ganze Kette verkürzt, haben Sie einen wirklichen Nutzen.
18. Die Frage lautet nicht, ob KI Programmierer ersetzen wird. Sie lautet, wer den Ausfall trägt
Ein schnellerer HTTP-Server kann wahr sein. Mehr geschlossene Aufgaben können wahr sein. Eine Verlangsamung erfahrener Menschen in einem bekannten Repository kann ebenfalls wahr sein. Diese Sätze schließen einander nicht aus, weil sie nicht dasselbe messen. Der eine spricht von Skeleton und Tests. Der zweite vom Firmenfluss der Aufgaben. Der dritte vom Kontext, den das Modell nicht hat. Der vierte, der betriebliche, fragt, wer die Folge trägt.
Daraus folgt nicht, dass die Frage nach den Programmierern ruhig wäre. Daraus folgt, dass sie schlecht gestellt ist, wenn sie nur lautet „ersetzt oder ersetzt nicht“. Software besteht aus Aufgaben, Tests, Review, Betrieb und Verantwortung. Einige Teile werden schneller. Einige wandern. Einige können billiger werden. Einige werden teurer, weil die Prüfung wichtiger sein wird als das Schreiben.
Die richtige Frage lautet also nicht, ob KI Programmierer ersetzen wird. Sie lautet: Bei welcher Aufgabe verkürzt der Assistent das Schreiben, bei welcher verlängert er die Prüfung in einem bekannten System, und wer unterschreibt den Ausfall, wenn die grünen Tests in der Nacht nicht reichen. Solange die Antwort beim Benchmark endet, fehlt ihr die Produktion. Und solange sie bei der Produktion ohne Messung der Aufgabe endet, fehlt ihr der Beleg.
Verwandte Texte dieser Reihe
- Welche Berufe wird KI ersetzen… — Arbeitsmarkt; dieser Text ist Aufgabe, Test und On-Call.
- ChatGPT vs. Gemini vs. Claude vs. Grok… — SWE-bench ist ein Harness, kein Verdikt über einen Beruf.
- Wem Sie Fehler erlauben