Whitepaper · 14 Seiten · von Bo Wesdorp
Wie KI das Engineering verändert hat
Seit 2022 haben Engineering-Teams KI-Tools in sechs Wellen eingeführt, von der Autovervollständigung im Editor bis zu Agenten, die eigenständig laufen. Diese Seite zeichnet den Weg nach: welche Tools wann kamen, wie jedes die tägliche Arbeit verändert hat und was Teams, die den größten Nutzen daraus zogen, anders gemacht haben.
Seit 2022 habe ich die Arbeitsweise unserer Engineers viermal neu aufgebaut. Jedes Mal kam etwas auf den Markt, das eine Einschränkung beseitigte. Nach wenigen Monaten war klar: Die Arbeit war weiterhin da, nur an anderer Stelle.
Die meisten Teams, mit denen ich spreche, haben die Tools in genau dieser Reihenfolge gekauft und sonst nichts verändert. Sie haben Copilot-Lizenzen von 2023 und Agent-Budgets von diesem Jahr. Beides läuft gegen einen Review-Prozess, eine Definition of Done und eine Personalplanung, die aus der Zeit stammen, als das Schreiben von Code der teure Teil war.
Bei unseren eigenen Builds stammen heute 80 bis 90 Prozent des Produktionscodes aus einem Modell. Das allein hat uns nicht schneller gemacht. Erst der Umbau von allem drumherum hat aus zehn Engineers vier gemacht.
Vier Jahre KI-Tools in der Softwareentwicklung
Die meisten Teams haben diese Tools in dieser Reihenfolge gekauft und nichts drumherum verändert. Wählen Sie eine Welle, um zu sehen, was Teams eingeführt haben, wie sich die Arbeit verändert hat und was davon für die nächste Welle übrig blieb. Der Stack baut sich dabei Schritt für Schritt auf.
2022 bis 2023 · Welle 1
Completion
- Was Teams eingeführt haben
- Teams kauften GitHub-Copilot-Lizenzen. Die Completion lief im Editor und verlangte von niemandem, die Arbeitsweise zu ändern. Deshalb verbreitete sie sich so schnell.
- Wie sich die Arbeit verändert hat
- Entwickler hörten auf, Boilerplate von Hand zu tippen, und übernahmen Vorschläge per Tab-Taste.
- Offen für die nächste Welle
- Entscheiden, was getippt wird
2023 bis 2024 · Welle 2
Chat
- Was Teams eingeführt haben
- Entwickler ließen ChatGPT oder Claude neben dem Editor offen und kopierten Code hin und her. GitHub Copilot Chat holte das in die IDE, und Cursor beendete diese Phase, indem das Modell das gesamte Repository lesen konnte.
- Wie sich die Arbeit verändert hat
- Die Arbeit begann damit, das Problem in Worten zu beschreiben, statt den Code zu schreiben.
- Offen für die nächste Welle
- Dem Modell Ihr System verständlich machen
2024 bis 2025 · Welle 3
Context
- Was Teams eingeführt haben
- Ende 2024 erschien das Model Context Protocol. Teams legten CLAUDE.md-, AGENTS.md- und .cursorrules-Dateien in ihren Repositories ab, und Aider, Cline und Windsurf brachten agentisches Bearbeiten in den Editor.
- Wie sich die Arbeit verändert hat
- Entwickler begannen, für das Modell zu schreiben: Kontextdateien im Repository und Live-Anbindungen an Tickets, Schemas und Fehlerlogs.
- Offen für die nächste Welle
- Festlegen, was das Modell tun darf
Anfang 2026 · Welle 4
Harness
- Was Teams eingeführt haben
- Claude Code mit Hooks, Skills und Subagents, OpenAI Codex und LangChain Deep Agents machten aus dem Modell einen Agenten. Langfuse und Braintrust zeigten, was der Agent tatsächlich getan hat.
- Wie sich die Arbeit verändert hat
- Der Agent führte die Tests aus, las den Fehler, behob ihn und öffnete den Pull Request. Die Engineers legten fest, worauf er zugreifen durfte.
- Offen für die nächste Welle
- Das Prompten in jedem einzelnen Schritt, und das Urteilsvermögen in der Konfiguration
Mitte 2026 · Welle 5
Loop
- Was Teams eingeführt haben
- Claude Code führte im März 2026 /loop ein, Codex ergänzte Goals, und der GitHub Copilot Coding Agent und OpenClaw übernahmen Aufgaben aus Tickets. Die vorhandene CI wurde zum Auslöser und meist auch zur Prüfinstanz.
- Wie sich die Arbeit verändert hat
- Agents laufen nach Zeitplan oder bei einem Ereignis, ohne dass jemand jeden Schritt freigibt. Die Engineers entwerfen die Prüfung, die den Agents sagt, wann sie aufhören sollen.
- Offen für die nächste Welle
- Prüfen, was zurückkommt
Jetzt · Welle 6
Verifikation
- Was Teams eingeführt haben
- Teams setzen KI-Review ein (CodeRabbit, Greptile, Qodo, Graphite), scannen, worauf der Agent zugegriffen hat (Semgrep, Snyk, Socket), und nutzen Tools, die die Review-Warteschlange sichtbar machen (Faros, LinearB). Die Teams, die am schnellsten vorankommen, ändern auch die Reihenfolge der Arbeit.
- Wie sich die Arbeit verändert hat
- Spezifikation und Abnahmetests werden geschrieben, bevor der Agent startet. So werden die meisten Änderungen automatisch geprüft, und Menschen lesen nur die riskanten.
- Offen für die nächste Welle
- Die Spezifikation und die Tests einmal schreiben, bevor der Agent läuft
2022 bis 2023 · Completion
Welle 1 von 6Completion nahm das Tippen ab
Was Teams eingeführt haben
Teams kauften GitHub-Copilot-Lizenzen. Die Completion lief im Editor und verlangte von niemandem, die Arbeitsweise zu ändern. Deshalb verbreitete sie sich so schnell.
Wie sich die Arbeit verändert hat
Entwickler hörten auf, Boilerplate von Hand zu tippen, und übernahmen Vorschläge per Tab-Taste.
GitHub Copilot brachte ein Modell in den Editor und vervollständigte die Zeile, die Sie gerade tippten. Es nahm Boilerplate ab, und diese Arbeit vermisst niemand.
Es machte aber auch den falschen Ansatz genauso schnell schreibbar wie den richtigen. Der Engpass verlagerte sich von der Tippgeschwindigkeit zu der Frage, ob jemand wusste, was getippt werden muss.
Wo der Fokus liegt
Den richtigen Ansatz kennen, bevor der Vorschlag erscheint. Eine schnelle falsche Antwort bleibt eine falsche Antwort.
- Gelöst
- Boilerplate und die nächste Codezeile
- Offen für die nächste Welle
- Entscheiden, was getippt wird
Die Tools dieser Welle
Testen wir das?
TeilweiseWir testen, was Completion Ihnen nicht abnimmt
Niemand wird nach Tippgeschwindigkeit oder nach dem Umgang mit Autocomplete bewertet. Das Fundamentals-Assessment läuft bei ausgeschalteten KI-Tools, denn ein Engineer, der ohne Vorschläge nicht über ein System nachdenken kann, erkennt nicht, wann ein Vorschlag falsch ist.
2023 bis 2024 · Chat
Welle 2 von 6Chat machte aus einer Beschreibung einen Codeblock
Was Teams eingeführt haben
Entwickler ließen ChatGPT oder Claude neben dem Editor offen und kopierten Code hin und her. GitHub Copilot Chat holte das in die IDE, und Cursor beendete diese Phase, indem das Modell das gesamte Repository lesen konnte.
Wie sich die Arbeit verändert hat
Die Arbeit begann damit, das Problem in Worten zu beschreiben, statt den Code zu schreiben.
ChatGPT und Claude machten aus einer Problembeschreibung einen Codeblock. Für Engineers auf mittlerem Level war das der größte einzelne Sprung der gesamten Timeline.
Keines von beiden kannte Ihr System. Es folgte ein Jahr Prompt Engineering, eine echte Fähigkeit, die auf der falschen Ebene angewendet wurde. Chat brachte auch denen etwas bei, die die Erklärung lasen, und machte diejenigen schneller, die sie nicht lasen.
Wo der Fokus liegt
Die Erklärung mitlesen und nicht nur den Code, und merken, wenn die Antwort für ein System geschrieben wurde, das nicht Ihres ist.
- Gelöst
- Aus einer beschriebenen Aufgabe lauffähigen Code machen
- Offen für die nächste Welle
- Dem Modell Ihr System verständlich machen
Die Tools dieser Welle
Testen wir das?
JaWir prüfen, ob sie eine Änderung erklären können, die sie nicht selbst getippt haben
In der AI-native-Bewertung arbeitet der Engineer mit den eigenen Tools, und wir fragen, warum der Agent seinen Ansatz gewählt hat. „Der Agent hat das gemacht“ gilt bei uns nicht als Erklärung. Wer dieselbe vage Anfrage immer wieder neu stellt, statt die Eingabe zu korrigieren, erhält eine niedrige Bewertung.
2024 bis 2025 · Kontext
Welle 3 von 6Kontext machte aus den Eingaben für das Modell das Produkt
Was Teams eingeführt haben
Ende 2024 erschien das Model Context Protocol. Teams legten CLAUDE.md-, AGENTS.md- und .cursorrules-Dateien in ihren Repositories ab, und Aider, Cline und Windsurf brachten agentisches Bearbeiten in den Editor.
Wie sich die Arbeit verändert hat
Entwickler begannen, für das Modell zu schreiben: Kontextdateien im Repository und Live-Anbindungen an Tickets, Schemas und Fehlerlogs.
Hier hörte die Branche auf, das Modell als das Produkt zu sehen, und begann, die Eingaben als das Produkt zu behandeln. Auf dieser Ebene stehen die meisten Teams bis heute, unabhängig davon, wie sie sich selbst einschätzen.
Vor dem Verfall warnt niemand. Die Datei, die im März stimmte, beschreibt ein System, das seit September nicht mehr existiert. Eine veraltete Kontextdatei ist schlechter als keine: Der Agent liegt dann selbstsicher falsch, und das besteht das Review. Das Aktualisieren gehört bei uns zur Definition of Done.
CLAUDE.md, AGENTS.md und .cursorrules enthalten, was ein neuer Engineer wissen müsste, aufgeschrieben an der Stelle, die das Tool bei jedem Lauf liest.
Ende 2024 von Anthropic veröffentlicht: ein einheitlicher Standard, der einem Modell Zugriff auf Dinge gibt, die keine Dateien sind, etwa den Ticket-Tracker, das Schema und das Error-Log.
Wo der Fokus liegt
Kontextdateien aktuell halten. Eine veraltete CLAUDE.md liefert selbstsichere Arbeit, die das Review besteht.
- Gelöst
- Das Modell kann Ihr Repository, Ihre Tickets und Ihr Schema lesen
- Offen für die nächste Welle
- Festlegen, was das Modell tun darf
Die Tools dieser Welle
Testen wir das?
JaWir bewerten den Kontext, den sie aufsetzen, und was sie hinterlassen
Prompt- und Context-Engineering ist eines von sechs AI-native-Kriterien: Liefert das Setup in ein bis zwei Durchgängen brauchbare Ergebnisse? Wir achten außerdem darauf, ob der Engineer die nächste Aufgabe leichter macht, etwa mit einer präziseren CLAUDE.md oder einem wiederverwendbaren Befehl.
Anfang 2026 · Harness
Welle 4 von 6Das Harness: Ein Agent ist ein Modell plus alles drumherum
Was Teams eingeführt haben
Claude Code mit Hooks, Skills und Subagents, OpenAI Codex und LangChain Deep Agents machten aus dem Modell einen Agenten. Langfuse und Braintrust zeigten, was der Agent tatsächlich getan hat.
Wie sich die Arbeit verändert hat
Der Agent führte die Tests aus, las den Fehler, behob ihn und öffnete den Pull Request. Die Engineers legten fest, worauf er zugreifen durfte.
Das Vokabular kam im Februar 2026. Mitchell Hashimoto prägte den Begriff harness engineering, und innerhalb weniger Wochen war daraus eine Disziplin mit einem Leitsatz geworden: Ein Agent ist ein Modell plus ein Harness.
Das Modell ist der Teil, den Sie nicht kontrollieren und den Sie austauschen können. Das Harness ist alles andere: die Schleife, die es ausführt, die Tools, die es aufrufen kann, die Kompaktierung seines Kontexts, wenn eine Aufgabe lange läuft, die Sandbox, in der es arbeitet, die Berechtigungsgrenzen, die Hooks, die vor und nach einer Aktion greifen, die Subagents, die es starten kann, und die Observability, die Ihnen hinterher zeigt, was es getan hat. Das erklärt, warum zwei Unternehmen mit demselben Modell und derselben Lizenz völlig unterschiedliche Ergebnisse bekommen.
Sicherheit sieht hier anders aus. Ein Harness ist ein System mit Zugangsdaten und Tool-Zugriff, in dem ein Modell entscheidet, was aufgerufen wird. Geprüft wird deshalb nicht mehr nur der Code. Dazu gehört auch, worauf der Agent zugreifen durfte.
Wo der Fokus liegt
Die Entscheidungen im Setup. Welche Tools der Agent aufrufen darf, wo die Sandbox-Grenze verläuft und was ein Hook blockiert, gilt jetzt für alles, was das Team ausliefert.
- Gelöst
- Ein Agent, der etwas zu Ende bringt: die Tests ausführen, den Fehler lesen, ihn beheben und den Pull Request öffnen
- Offen für die nächste Welle
- Das Prompten in jedem einzelnen Schritt, und das Urteilsvermögen in der Konfiguration
Die Tools dieser Welle
Testen wir das?
TeilweiseWir testen Orchestrierung, nicht den Bau eines vollständigen Harness
Tool-Orchestrierung wird im AI-native Assessment bewertet: was der Engineer an den Agent abgibt, was er selbst behält und ob er Arbeit in parallelen Worktrees laufen lässt. Sandbox, Berechtigungen und Hooks eines Teams zu entwerfen, passt nicht in sechzig Minuten. Deshalb enthält das DevOps-Assessment für Plattform-Rollen eine generierte Pipeline-Änderung mit einer Berechtigung, die weiter reicht, als es aussieht.
Mitte 2026 · Loop
Welle 5 von 6Der Loop lässt Agents laufen, ohne dass jemand jeden Schritt freigibt
Was Teams eingeführt haben
Claude Code führte im März 2026 /loop ein, Codex ergänzte Goals, und der GitHub Copilot Coding Agent und OpenClaw übernahmen Aufgaben aus Tickets. Die vorhandene CI wurde zum Auslöser und meist auch zur Prüfinstanz.
Wie sich die Arbeit verändert hat
Agents laufen nach Zeitplan oder bei einem Ereignis, ohne dass jemand jeden Schritt freigibt. Die Engineers entwerfen die Prüfung, die den Agents sagt, wann sie aufhören sollen.
Wir hatten Agents, die echte Aufgaben zu Ende bringen konnten, und Senior Engineers, die danebensaßen und jeden Schritt freigaben. Ein Harness rüstet einen einzelnen Lauf aus. Ein Loop setzt viele Läufe zusammen, ausgelöst per Zeitplan oder Ereignis und begrenzt durch etwas, das eine Maschine prüfen kann.
Claude Code hat im März 2026 /loop veröffentlicht, Codex hat im April goals ergänzt. Ihre bestehende CI ist meist Auslöser und Prüfinstanz zugleich.
Wo der Fokus liegt
Der Verifier und die Abbruchbedingung. Beides wird entworfen, bevor der Loop läuft.
- Gelöst
- Ein Senior Engineer, der „ja, weiter“ in vier Fenster tippt
- Offen für die nächste Welle
- Prüfen, was zurückkommt
Ein Loop, der funktioniert
- Der Verifier wird vor dem Loop entworfen
- Die Abbruchbedingung lässt sich maschinell prüfen
- Er läuft zuerst auf einem engen, gut getesteten Bereich
- Jemand liest das Ergebnis vom Morgen
Ein Loop, der Geld verbrennt
- Der Agent hat die Tests geschrieben, an denen er gemessen wird
- Die Abbruchbedingung lautet „bis es fertig aussieht“
- Er wurde am ersten Tag auf die gesamte Codebasis angesetzt
- Niemand kann sagen, was er letzte Nacht geändert hat
Die Tools dieser Welle
Testen wir das?
NeinWir testen keine Loops. Wir testen, wovon sie abhängen.
Ein unbeaufsichtigter Loop braucht Stunden, eine echte CI und eine Codebasis, die der Engineer kennt. Ein Assessment von sechzig Minuten kann das nicht zuverlässig zeigen. Sichtbar wird aber das Fundament, das ein Loop braucht: ob der Engineer ein vages Ticket in Teile zerlegt, die eine Maschine prüfen kann, und ob er Output verifiziert, statt ihm zu vertrauen, nur weil er kompiliert.
Jetzt · Verifikation
Welle 6 von 6Verifikation ist der Engpass, und spezifikations- und testgetriebene Entwicklung löst ihn
Was Teams eingeführt haben
Teams setzen KI-Review ein (CodeRabbit, Greptile, Qodo, Graphite), scannen, worauf der Agent zugegriffen hat (Semgrep, Snyk, Socket), und nutzen Tools, die die Review-Warteschlange sichtbar machen (Faros, LinearB). Die Teams, die am schnellsten vorankommen, ändern auch die Reihenfolge der Arbeit.
Wie sich die Arbeit verändert hat
Spezifikation und Abnahmetests werden geschrieben, bevor der Agent startet. So werden die meisten Änderungen automatisch geprüft, und Menschen lesen nur die riskanten.
Fünf Engpässe hatten sich mit dem nächsten Release erledigt. Dieser nicht. Ein Harvard Working Paper kam zu dem Ergebnis: Firmen, die Coding-Agents einführten, schrieben etwa 30 Prozent mehr Code, schlossen nicht mehr Arbeit ab und brauchten 49 Prozent länger, um ihn durch das Review zu bringen. KI-Review-Tools haben diese Lücke nicht geschlossen.
Wenn jede Änderung darauf wartet, dass ein Senior sie liest, werden Ihre Seniors zur Warteschlange. Spezifikations- und testgetriebene Entwicklung nimmt sie daraus heraus: Spec und Akzeptanztests entstehen, bevor der Agent irgendetwas generiert. So wird jeder Lauf automatisch gegen etwas geprüft, das der Agent nicht kontrolliert, und Menschen lesen nur, was Tests nicht beurteilen können.
Wo der Fokus liegt
Schreiben Sie zuerst die Spec und die Akzeptanztests. Dann übernehmen die Tests den Großteil der Verifikation, und Ihre Seniors lesen nur, was sich nicht automatisch beurteilen lässt.
- Gelöst
- Spezifikations- und testgetriebene Entwicklung: Die Prüfungen existieren vor dem Code
- Offen für die nächste Welle
- Die Spezifikation und die Tests einmal schreiben, bevor der Agent läuft
Das Review ist Ihr Engpass
- Mehr Pull Requests werden ganz ohne Review gemergt
- Von Agents erstellte Pull Requests warten deutlich länger auf Bearbeitung
- Ihre Seniors sind die Warteschlange, und neue Regeln machen sie länger
- Agents lassen ihre eigenen Pull Requests liegen, wenn das Feedback kein fehlschlagender Check ist
Sie haben das hinter sich
- Spec und Tests existieren, bevor der Code generiert wird
- Der Verifizierer ist unabhängig von dem, was die Änderung geschrieben hat
- Die Review-Tiefe richtet sich danach, was eine Änderung beschädigen kann
- Die Warteschlange ist am Ende der Woche leer
Die Tools dieser Welle
Review
Was der Agent erreicht hat
Die Warteschlange sichtbar machen
Testen wir das?
JaDie Verifikation hat in unseren Assessments das größte Gewicht
Die Verifikation von KI-Output gewichten wir bei AI-native Engineers am stärksten: Sie fängt halluzinierte APIs, subtil falsche Logik und Sicherheitslücken ab, bevor sie live gehen. Spec-driven Development wird in derselben Session bewertet: Wir prüfen, ob der Engineer vor dem Start des Agents aufschreibt, was die Änderung leisten muss und wie sie geprüft wird. Außerdem achten wir auf Urteilsvermögen nach Risiko. QA Engineers verifizieren ein Feature, das sie nicht selbst entworfen haben, mit generierten Tests, die alle bestehen und das Falsche abdecken.
Sechs Praktiken der Teams, die am weitesten sind
Haken Sie an, was Ihr Team schon tut. Ab vier Haken hat Ihr Team die Arbeitsweise übernommen, über die Tools hinaus.
Haken Sie an, was Ihr Team schon tut.
Engineering Leader Benchmark Q4 2026
Sehen Sie, auf welcher Ebene Ihr Team steht
Der Benchmark fragt, wie Ihr Team mit Agents arbeitet, wie Sie verifizieren und wie Sie planen. Ihr Ergebnis sehen Sie nach acht Minuten, neben Teams Ihrer Größe, sobald genug von ihnen geantwortet haben.
Fragen zum Whitepaper
Unser anderes Whitepaper beschreibt die zwei Assessments, die jeder Engineer durchläuft.
Der nächste 10X EngineerWas ist aktuell der Engpass im KI-gestützten Software Engineering?
Die Verifikation. Coding Agents haben die Menge an Code erhöht, aber die Review-Zeit ist mitgestiegen: Ein Harvard Working Paper zu 718 Unternehmen fand 30 Prozent mehr Code, keinen signifikanten Anstieg bei fertiger Arbeit und 49 Prozent mehr Zeit vom Pull Request bis zum Merge.
In welcher Reihenfolge haben Engineering-Teams KI-Tools eingeführt?
In sechs Wellen: Code Completion wie GitHub Copilot (2022 bis 2023), Chat wie ChatGPT und Claude (2023 bis 2024), Kontext über das Model Context Protocol und Dateien wie CLAUDE.md und AGENTS.md (2024 bis 2025), Agent Harnesses wie Claude Code und OpenAI Codex (Anfang 2026), Loops, die Agents ohne Freigabe bei jedem Schritt laufen lassen (Mitte 2026), und jetzt Review, Scanning sowie Spec- und Test-driven Development, um zu verifizieren, was Agents erzeugen.
Welche KI-Tools sollte ein Engineering-Team zuerst einführen?
Die Tools zählen weniger als die Reihenfolge der Arbeit drumherum. Die meisten Teams haben Completion und Chat schon. Der nächste Schritt, der sich auszahlt, ist Kontext: eine gepflegte CLAUDE.md oder AGENTS.md und Anbindungen an Tickets und Schemas. Agents und Loops zahlen sich erst aus, wenn ein Team Spec und Tests schreibt, bevor der Agent startet.
Was ist Harness Engineering?
Harness Engineering heißt, alles um das Modell herum zu gestalten: die Schleife, die es ausführt, die Tools, die es aufrufen kann, Context Compaction, die Sandbox, Berechtigungen, Hooks, Subagents und Observability. Mitchell Hashimoto hat den Begriff im Februar 2026 geprägt, zusammengefasst als agent = model + harness.
Was ist der Unterschied zwischen Context Engineering und Harness Engineering?
Context Engineering bestimmt, was das Modell sieht, über Dateien wie CLAUDE.md und AGENTS.md und Protokolle wie MCP. Harness Engineering umfasst die gesamte Laufzeitumgebung um das Modell, einschließlich dessen, was es tun darf und wie seine Arbeit geprüft wird.
Testet Miyagami Engineers auf diese Fähigkeiten?
Auf die meisten. Verifikation, Context Engineering, Tool-Orchestrierung und das Erklären von generiertem Code werden in unserem AI-native Assessment bewertet, und das Fundamentals-Assessment läuft ohne KI-Tools. Unbeaufsichtigte Loops testen wir nicht, weil eine Session von sechzig Minuten sie nicht aussagekräftig zeigen kann.
Shortlist in drei Tagen erhalten
Sie schicken uns die Rollen und den Stack, in einem kurzen Formular oder in einem 30-minütigen Gespräch. Innerhalb von drei Werktagen erhalten Sie Senior Engineers mit Namen zur Prüfung, jeweils mit beiden Scorecards, und Sie können innerhalb von fünf Werktagen einstellen.
ISO 27001Zertifiziert