Die Werkzeuge der Softwareentwicklung haben sich in weniger als zwei Jahren grundlegend verändert. Wo bis 2024 ein Sprachmodell als Autovervollständigung im Editor arbeitete, sitzt es heute als autonomer Agent in der Kommandozeile. GitHub Copilot CLI, Claude Code, OpenAI Codex CLI und vergleichbare Werkzeuge planen Aufgaben, lesen Codebasen, schreiben Patches, führen Tests aus, erstellen Pull Requests, bearbeiten Tickets, deployen Container. Die Verschiebung ist nicht inkrementell. Sie betrifft das Berufsbild der Entwicklung, das Verhältnis zwischen den Rollen eines Projektteams und die Kontrollarchitektur, in der eine Organisation Software produziert.
Die Geschwindigkeit der Verschiebung lässt sich an einigen Daten ablesen. Anthropic hat Claude Code im Februar 2025 als Preview veröffentlicht, im Mai folgte die General Availability. OpenAI brachte Codex CLI im April 2025 als Open-Source-Terminal-Tool. GitHub kündigte Copilot CLI im September 2025 als Public Preview an, mit voller GitHub-Integration und Plan-Modus. Im Februar 2026 hat das Werkzeug die Anweisungsdatei AGENTS.md gleichberechtigt zu der älteren .github/copilot-instructions.md aufgenommen. Innerhalb eines Jahres ist aus einer Kategorie experimenteller Werkzeuge eine Kategorie produktiv eingesetzter Standard-Tools geworden. Mittlere und große IT-Organisationen rollen die Werkzeuge derzeit in Wellen aus, oft schneller, als die Methodik in den Teams reifen kann.
Wer in dieser Lage ein Werkzeug einkauft und es seinen Entwicklerinnen und Entwicklern in die Hand gibt, kann zusehen, wie einzelne Aufgaben schneller fertig werden und gleichzeitig die Qualität der Projektarbeit absinkt. Dass dieser Befund kein Pessimismus ist, sondern ein gemessener Effekt, hat eine Studie aus diesem Jahr nüchtern dokumentiert. Christopher Potts und Moritz Sudhof, beide Stanford University, werten in der Arbeit „A paradox of AI fluency" knapp 27.000 reale KI-Dialoge aus dem Korpus WildChat-4.8M aus, je 1.000 zufällig gezogene englische Gespräche pro Monat von Mai 2023 bis Juli 2025. Sie messen vier Achsen: KI-Kompetenz, Interaktionsstil, Aufgabenkomplexität und Fehlerindikatoren. Das auffälligste Ergebnis betrifft die Sichtbarkeit von Fehlern. In Dialogen mit hoher KI-Kompetenz tauchen 64 Prozent Fehlerindikatoren auf, in Dialogen mit geringer KI-Kompetenz nur 24 Prozent. Wer das oberflächlich liest, hält die Geübten für die schlechteren Anwender. Die zweite Zahl löst das Paradox auf. Bei den Geübten sind 59 Prozent der Fehler im Dialog selbst sichtbar. Bei den Ungeübten sind es 12 Prozent. Die übrigen 88 Prozent gehen ins Ergebnis ein, ohne dass jemand eine Korrekturschleife eingeleitet hätte.
Die Konsequenz für Entwicklerteams ist eindeutig. Wer Agentic Coding ohne aktive Steuerung einsetzt, verschiebt Fehler von „sichtbar und korrigierbar" zu „unsichtbar und im Ergebnis enthalten". Eine Schulung, die nur Bedienung zeigt, trainiert die zweite Praxis. Was Teams brauchen, ist eine Methode, die das Werkzeug in eine Kontrollarchitektur einbettet, in der Fehler früh sichtbar werden, ein Mensch jeden riskanten Schritt prüft und der Projektzustand nicht im Chatverlauf liegt, sondern in versionierten Artefakten.
Genau diese Methode habe ich in den letzten Wochen als Schulungsprogramm ausgearbeitet. Ich nenne sie „Team-Betriebssystem für Agentic CLI". Sie ist in fünf Kompetenzfelder mit aufeinander aufbauenden Lerneinheiten gegliedert und durch einen Validierungsrahmen ergänzt, der die Wiederholbarkeit für Folgekurse sicherstellen soll. Mein Anspruch ist nicht Werkzeugbedienung, sondern Methodenbildung. Was die Methode vorgibt, ist ein Vorgehen, das ein Entwicklerteam end-to-end aufsetzen muss, wenn es im Zeitalter agentischer Werkzeuge weiter bestehen will. Die folgenden Abschnitte beschreiben die Inhalte dieser Methode und ordnen sie in die Branchenlage ein.
Mentales Modell als erste Bedingung
Ich beginne meine Schulung mit einer Klärung, die in vielen Organisationen unausgesprochen bleibt. Sprachmodelle antworten in natürlicher Sprache. Sie sagen „ich denke", „ich erinnere mich", „ich verstehe deinen Code". Wer mit ihnen täglich arbeitet, beginnt sie wie Kollegen zu behandeln, mit denen man sich abstimmt, denen man vertraut und auf deren Urteil man baut. Diese Personifikation hat Folgen für die Bedienung. Anwender geben vage Hinweise, hoffen auf Mitdenken, lassen Annahmen unausgesprochen.
Die korrigierte Sicht ist technisch und entlastend zugleich. Ein Sprachmodell ist ein statistischer Apparat. Es nimmt einen Kontext entgegen, berechnet Wahrscheinlichkeiten für den nächsten Token, wählt einen aus, hängt ihn an, beginnt von vorn. Es hat kein Gedächtnis außerhalb des Kontextfensters. Es versteht nichts; es approximiert Muster, die im Training plausibel waren. Eine Rückfrage des Modells klingt nach kollegialem Nichtwissen, sie ist aber eine wahrscheinliche Fortsetzung des bisherigen Textes.
Der Konsequenz dieses Modells ist die zentrale Stellschraube der Bedienung. Qualität des Kontexts ist Qualität der Antwort. Wer das Modell als Approximator behandelt, liefert expliziten, strukturierten, vollständigen Kontext, weil er weiß, dass keine andere Stellschraube wirkt. Wer es als Kollegen behandelt, lässt Kontextlücken offen und bekommt Antworten, die diese Lücken plausibel füllen, ohne sie zu schließen.
Diese Klärung ist keine philosophische Vorrede. Sie ist die Voraussetzung dafür, dass die folgenden Methodenelemente überhaupt greifen.
Drei Säulen einer Team-Methode
Auf dieser Grundlage habe ich drei tragende Elemente formuliert. Sie heißen Artifact Contract, Review-Gates und Tool-Zonen.
Der Artifact Contract regelt, wo der Projektzustand liegt. Meine Antwort darauf ist eindeutig. Der Chat ist Transit. Der Projektzustand liegt in versionierten Artefakten, die Menschen reviewen können. Markdown-Dateien für Kontext, Entscheidungen, Pläne, Testausgaben und Runbooks. Jira für Arbeitszuschnitt, Status und Verantwortlichkeit. Confluence für freigegebene Specs und Doku. Pull Requests für Diff, Tests und Review-Entscheidung. Was während einer Agent-Sitzung erzeugt wird und nicht in eines dieser Artefakte überführt wird, gilt als nicht passiert. Diese Regel klingt restriktiv. Sie ist die Bedingung dafür, dass Begründungen, Zwischenstände und Risiken nicht im Chatfenster verloren gehen.
Die Review-Gates fügen der Pipeline sechs prüfbare Übergänge hinzu. Die Discovery endet mit der Frage, ob die Quellen tragen, ob Lücken und Widersprüche sichtbar sind. Die Spec endet mit der Frage, ob die Architektur- und Compliance-Entscheidungen tragfähig sind. Ein Ticket gilt nicht als ready, bevor jemand bestätigt hat, dass es klein und testbar ist, mit Akzeptanzkriterien und Non-Goals. Vor dem Code prüft ein Plan-Review die Reihenfolge, die Teststrategie, die Risiken und die betroffenen Dateien. Ein Pull Request darf nicht gemerged werden, solange Diff, Tests und Plan nicht zusammen verständlich sind. Eine produktionsnahe Aktion bleibt blockiert, bis Runbook, Rollback und menschliche Freigabe vorliegen. Jedes der sechs Gates trägt eine kurze, prüfbare Frage und einen klaren Verantwortlichen.
Die Tool-Zonen ordnen MCP- und CLI-Werkzeuge nach Risiko. Read-only-Werkzeuge wie Suchen, Lesen, Status- und Logabfragen sind frei nutzbar, mit der Pflicht, das Ergebnis zu belegen. Draft-Werkzeuge erlauben dem Agenten, Pläne, Tests, Code-Drafts und PR-Texte zu entwerfen, die ein Mensch vor Wirkung reviewt. Write-Werkzeuge wie das Schreiben in Jira, das Pushen eines Branches, das Erstellen eines PRs brauchen eine Freigabe. Restricted-Werkzeuge umfassen Produktions-Apply, Secrets, Datenlöschung und Berechtigungsänderungen; sie sind ausschließlich menschliche Aktionen mit eigenem Gate, auch wenn der Agent sie technisch ausführen könnte.
Die drei Säulen zusammen verschieben die Frage, die ein Team über Agentic Coding stellt. Es geht nicht darum, wie schnell der Agent ist. Es geht darum, wie sicher das Team mit ihm arbeiten kann.
Fünf Felder, eine Artefaktkette
Auf dieser Grundlage organisiere ich den Lernpfad in fünf Kompetenzfeldern. Bedienen, Belegen, Strukturieren, Umsetzen, Betreiben. Die Reihenfolge ist nicht beliebig. Jedes Feld senkt eine andere Unsicherheit, und jedes Feld schließt mit einem Artefakt, das im nächsten Feld als Input dient.
Bedienen ist die Eintrittstüre. Hier lernt das Team, eine CLI-Sitzung zu führen, Sessions zu hygienisieren, Tools freizugeben, erste Guardrails zu setzen. Das Ergebnisartefakt ist ein Operating Model in Form einer Datei, in der die Tool-Zonen für das eigene Team konkret stehen. Welche MCP-Server sind eingebunden, welche Werkzeuge laufen ohne Rückfrage, welche brauchen menschliche Freigabe.
Belegen ist die Disziplin der Projektrecherche. Aus Quellen, Glossaren, Confluence-Seiten und Codebefunden entsteht eine Wissensbasis, in der Lücken, Widersprüche und Aktualität sichtbar sind. Der Agent ist hier ein Recherchewerkzeug, kein Erzähler. Was er findet, geht durch eine Quellenprüfung. Was er nicht findet, wird als Lücke markiert. Das Artefakt ist ein dokumentiertes Quelleninventar, das die Grundlage für jede spätere Entscheidung trägt.
Strukturieren übersetzt Wissen in Entscheidungen. Aus Befund wird Architekturentscheidung, aus Vorschriften eine Compliance-Matrix, aus Anforderungen ein Epic mit Tickets, die einer Definition of Ready genügen. Der Agent darf hier viel entwerfen. Aber jede Entscheidung läuft durch ein Review-Gate, bevor sie weitergetragen wird. Das Artefakt ist eine Projektstruktur, die für die Umsetzung tragfähig ist.
Umsetzen ist die kleinste Phase und gleichzeitig die heikelste. Sie endet mit einem Pull Request, der ein einziges, kleines Ticket vollständig umsetzt. Vor dem ersten Code steht ein Plan, in dem Scope, Nicht-Ziele, betroffene Dateien, Teststrategie, Risiken und Reihenfolge stehen. Erst nach dem Plan-Review beginnt der Agent zu schreiben. Tests entstehen vor oder zusammen mit dem Code. Der PR muss ohne den Chatverlauf verständlich sein. Das Artefakt ist ein Liefernachweis, in dem Plan, Testausgabe und Review-Notiz beieinander liegen.
Betreiben behandelt das, was im Anschluss an die Lieferung beginnt. Security als Betriebsregel, Incident-Diagnose, Rollout-Entscheidungen, Apply-Gates, das Team-Playbook. Das Artefakt am Ende ist eine Datei, in der das Team seine Regeln festhält und für die nächsten Kollegen reproduzierbar macht. Wer hier Abkürzungen nimmt, verliert die Lehre der vorhergehenden Felder.
Die Folge dieser Anordnung ist eine Artefaktkette. Ohne Operating Model gibt es keine Wissensbasis. Ohne Wissensbasis keine Compliance-Matrix. Ohne Compliance-Matrix kein tragfähiges Epic. Ohne Epic kein Plan. Ohne Plan kein PR. Ohne PR kein Apply-Entscheid. Ein Team, das ein Feld überspringt, kann das nächste nicht ehrlich abschließen.
Rollen im Umbau
Ich trenne die Lerneinheiten bewusst nicht nach Rollen, sondern nach Kompetenzfeldern. Business-Architektin, UX-Designer, Entwicklerin, Tester und Infrastruktur sitzen in denselben Sessions. Sie nutzen dasselbe Werkzeug. Sie reviewen einander. Die Trennung der Verantwortung läuft über die Artefakte, nicht über die Tools.
Die Business-Architektur arbeitet vor allem an Discovery, Compliance und Epic-Schnitt. Sie sichtet Altdokumente, generiert Spec-Vorschläge, schreibt Tickets in Jira. Im klassischen Modell war diese Rolle stark dokumentlastig und in der Geschwindigkeit oft der Engpass des Projekts. Mit einem Agenten, der Confluence-Inhalte zusammenfassen und Spec-Entwürfe vorschlagen kann, verschiebt sich der Aufwand von der Texterstellung hin zur Bewertung. Die Rolle wird zu einer Lektorin der Maschine.
UX explored Konzepte, prüft Annahmen am Verhalten, dokumentiert Entscheidungen in Confluence. Hier ist die Wirkung der Werkzeuge bisher zurückhaltender. Visuelle Konzepte und Prototypen entstehen weiterhin in spezialisierten Anwendungen, aber die Begleitdokumentation und die Argumentation für eine Entscheidung lassen sich agentisch beschleunigen.
Die Entwicklung läuft durch Exploration, Plan, Implementation und PR. Ich betone die Reihenfolge ausdrücklich. Vor dem Code kommt der Plan, vor dem Plan die Frage, vor der Frage die Codebefundsichtung. Wer dem Agenten erlaubt, ohne Plan zu schreiben, riskiert PRs, die Tests nicht decken, Architekturmuster brechen oder Scope unangekündigt ausweiten. Ich habe für diese Phase eine Lesson-Vorlage entworfen, in der genau dieser Plan als reviewbares Markdown-Artefakt formalisiert ist.
Der Tester generiert Testfälle aus der Spec, lässt einen Browser-Test-Runner über das Model Context Protocol E2E-Tests im Browser ausführen, schreibt Ergebnisse zurück nach Jira. Die Rolle gewinnt an Bedeutung, weil agentisch erzeugter Code per Definition mehr Tests verlangt, nicht weniger. Der Plan, der vor dem Code steht, listet Tests, die den Plan überprüfen.
Die Infrastruktur sorgt für Pipelines, Deployments und Monitoring. Sie liefert ein Playbook, das Apply-Entscheidungen trägt, also schreibt nieder, wann eine Aktion freigegeben werden darf und unter welchen Bedingungen sie blockiert. Die Rolle nähert sich damit der eines Plattformingenieurs an, der nicht nur Werkzeuge bereitstellt, sondern Regeln, gegen die sich der Agent prüfen lässt.
In Summe verschiebt sich die Tätigkeit jeder Rolle. Was bleibt, ist die Verantwortung für die Artefakte am Ende der Phase.
Werkzeugkette und das Model Context Protocol
Im Zentrum der Werkzeugkette, die ich in der Methode beschreibe, steht das Agentic CLI mit angeschlossenen MCP-Servern. Drumherum gruppieren sich fünf Stationen: Confluence für Specs, Jira für Tickets, Bitbucket für Code und Pull Requests, Playwright für E2E-Tests, der Kunde für Feedback und Abnahme. Die Verbindung zwischen Agent und Stationen läuft über das Model Context Protocol, eine 2024 von Anthropic vorgeschlagene Spezifikation, die inzwischen mehrere Anbieter unterstützen.
Die Bedeutung dieses Bildes lässt sich vor dem Hintergrund der bisherigen Toolchain einordnen. Wer in den vergangenen zehn Jahren Continuous Integration und Continuous Delivery aufgesetzt hat, kennt die Friktion zwischen den Werkzeugen. Anforderungen lebten in einem System, Tickets in einem zweiten, Code in einem dritten, Tests in einem vierten, Deployments in einem fünften. Ein Mensch übersetzte zwischen ihnen. Die Übersetzung kostete Zeit, sie ging verloren, sie war nirgendwo zur Gänze dokumentiert.
Eine Pipeline, in der ein Agent über MCP-Server an Anforderungen, Tickets, Code, Tests und Deployment angebunden ist, schließt diese Lücke erstmals werkzeugseitig. Ein Ticket aus Jira wird zur Aufgabe für den Agenten, der Plan landet als Markdown im Repository, der Code wandert in einen PR, die Tests laufen automatisiert, das Ergebnis fließt zurück in das Ticket. Was als zerbrochene Werkzeugkette galt, kann zum durchgängigen Prozess werden. Aber nur unter Bedingungen, die ich in der Schulung explizit setze. MCP-Server sind nicht neutral. Schreibzugriffe geben dem Agenten die Möglichkeit, freigegebene Specs zu überschreiben, Tickets zu schließen, PRs zu mergen. Die Tool-Zonen-Architektur ist die Antwort darauf, dass diese Wirkungspfade nicht offen liegen dürfen.
Repo-Regeln und Sicherheit
Im fortgeschrittenen Teil der Methode behandle ich eine Frage, die größer ist, als sie wirkt. Wie hält ein Agent sich an die Regeln eines konkreten Projekts? Die Antwort ist eine Datei am Repository-Root, die je nach Werkzeug unterschiedlich heißt. AGENTS.md hat sich als kanonische Wahl etabliert. GitHub Copilot CLI liest diese Datei gleichberechtigt mit der älteren .github/copilot-instructions.md. Daneben existieren Fallbacks für CLAUDE.md, GEMINI.md, pfadspezifische Regeln in .github/instructions/ und persönliche Konfigurationen unter $HOME/.copilot/.
Das Prinzip ist eine Repo-Verfassung. Was der Agent nicht erraten darf, also Build-Kommandos, Architekturentscheidungen, lokale Abweichungen, Tool-Grenzen, gehört in die Regeldatei. Was ein Linter oder Test besser erzwingt, gehört nicht hinein. Tutorials und Marketing-Vergleiche bleiben draußen.
Eine Subtilität, die ich in der Schulung ausspreche, ist nicht in jeder Anbieterdokumentation präsent. Wenn dasselbe Repo mehrere parallele Anweisungsdateien enthält und sie sich widersprechen, ist die Auflösung nicht deterministisch. Das Werkzeug muss sich für eine entscheiden, und die Entscheidung kann zwischen zwei Sitzungen variieren. Daraus folgt eine harte Regel. Eine Wahrheit pro Regel. Die parallelen Anweisungsdateien müssen inhaltlich konsistent gehalten werden.
Das zweite kritische Thema ist Sicherheit. Im Block Betreiben behandle ich Tool-Agenten als Risiko, wenn drei Faktoren zusammenkommen. Erstens untrusted Input, also alles, was von außen in den Agenten fließt. Tickets, Logs, Webseiten, MCP-Rückgaben, Skill-Dateien. Zweitens sensible Daten, also Secrets, Kundendaten, Prod-Logs, interne Architekturdetails. Drittens wirksame Tools, also alles, was schreiben, ins Netz greifen oder produktionsnah handeln kann.
Die Regel ist eine Trennlinie. Untrusted Input ist Befund, nie Befehl. Eine Anweisung, die in einem Ticket steht, ist nicht ohne weiteres eine Aufgabe für den Agenten, sie ist Eingangsmaterial. Sensible Daten unterliegen einem Need-to-know-Prinzip, also Minimierung, Maskierung oder getrennter Verarbeitung. Wirksame Tools brauchen Allowlists, einen klaren Zweck und ein menschliches Gate. Ich formuliere das ausdrücklich als Betriebsregel, nicht als Sicherheitskapitel. Wer Sicherheit ans Ende des Lernpfads schiebt, hat sie schon verloren.
Industrielle Softwareproduktion oder schnelle Werkstatt?
In der Branche zirkuliert eine Behauptung, die ich bewusst in den Methodenteil aufgenommen habe, um sie zur Diskussion zu stellen. Mit der durchgängigen Pipeline aus Agentic CLI, MCP-Servern, Confluence, Jira, Bitbucket und Playwright, so der Satz, komme die Branche dem Traum von industrieller Softwareproduktion einen gewaltigen Schritt näher. Die Aussage verdient eine Prüfung, weil sie das Versprechen quer durch die Branche prägt.
Industrielle Produktion lebt von zwei Eigenschaften. Wiederholbarkeit unter wechselnden Eingangsbedingungen und Belegbarkeit jedes Schritts. Eine Schraube vom Band lässt sich auf Charge, Werkstoff, Maschine und Schicht zurückverfolgen. Wenn eine Charge defekt ist, kann sie zurückgerufen werden. Softwareproduktion war diesem Modell selten nahe. Sie war Handwerk, dann Workflow mit Continuous Integration und Code Review. Die Verkettung von Anforderung über Spec, Code, Test und Deploy bis zum Kundenfeedback verlief über Werkzeuge, die unterschiedliche Sprachen sprachen. Menschen übersetzten zwischen ihnen.
Die agentische Pipeline schließt diese Übersetzungslücke werkzeugseitig. Das ist eine substanzielle Veränderung. Ob sie zur industriellen Produktion führt, hängt von drei Vorbehalten ab.
Erstens, die Belegbarkeit. Wenn der Agent eine Entscheidung im Chat trifft, die nicht in ein Artefakt landet, geht die Begründung verloren. Die Pipeline ist durchgängig; das Audit ist es nur, wenn der Artifact Contract diszipliniert eingehalten wird. Zweitens, die Wiederholbarkeit. Sprachmodelle sind nicht deterministisch. Derselbe Prompt mit demselben Kontext erzeugt nicht zwingend denselben Plan. Industrielle Produktion lebt von der genauen Wiederholung; agentische Produktion lebt von der Bandbreite akzeptabler Varianten. Drittens, die Qualitätssicherung. Wo eine Maschine eine Schraube prüft, prüft hier ein Mensch einen Plan oder einen Diff. Die Prüfung verschiebt sich, sie verschwindet nicht.
Ich adressiere diese drei Vorbehalte strukturell, nicht rhetorisch. Der Artifact Contract sichert die Belegbarkeit. Die Review-Gates sichern die Wiederholbarkeit der Qualitätsschwelle, wenn auch nicht die der Outputs. Die Tool-Zonen sichern, dass die Qualitätsprüfung nicht ans Werkzeug delegiert wird. Was am Ende entsteht, ist nicht industrielle Softwareproduktion. Es ist reviewbare Softwarearbeit mit der Geschwindigkeit eines Agenten und der Auditierbarkeit eines Teams. Ich halte diese Formulierung für genauer und ehrlicher als den Werbeslogan.
Was passiert, wenn ein Team nichts ändert
Die Lage hat eine Asymmetrie. Wer Werkzeuge wie Copilot CLI oder Claude Code nicht einsetzt, verliert Geschwindigkeit gegenüber Wettbewerbern, die sie einsetzen. Wer sie einsetzt, ohne eine Methode wie die beschriebene aufzubauen, verliert Auditierbarkeit, Reviewkultur und in vielen regulierten Branchen die Compliance-Fähigkeit. Beide Wege haben Kosten.
Mein Programm zielt auf den dritten Weg. Werkzeuge einsetzen, Methode aufbauen, Artefakte einfordern, Gates durchsetzen. Ich liefere ein Vorgehen, das in einer Organisation reproduzierbar ist und das ein Team in die Lage versetzt, sein Vorgehen schriftlich weiterzugeben.
Drei Bedingungen tragen den Erfolg dieses Vorgehens. Erstens braucht es Führungskräfte, die Plan-Reviews ernst nehmen und Reviewzeit einplanen. Eine Methode, die nur in der Schulungswoche lebt, ist verschenkte Zeit. Zweitens braucht es Werkzeugkonfigurationen, die die Tool-Zonen technisch durchsetzen. Eine schreibende Verbindung zu einem Produktionssystem ohne menschliches Gate widerspricht der Methode. Drittens braucht es Iteration. Modelle ändern sich, Werkzeuge ändern sich, MCP-Server kommen hinzu. Das Team-Playbook ist kein einmaliges Dokument, sondern eine lebendige Sammlung, die mindestens vierteljährlich überarbeitet werden muss.
Ausblick
Agentic Coding wird in den kommenden zwei Jahren die Branche grundlegender prägen, als es agentische Editor-Plugins zwischen 2022 und 2024 getan haben. Anbieter wie GitHub, Anthropic, OpenAI und kleinere Spezialhäuser wetteifern um Permissionsmodelle, Hooks, Subagentensysteme und MCP-Erweiterungen. Die Frage, wer das beste Modell hat, wird zunehmend von der Frage abgelöst, wer das beste Bedienmodell um das Modell herum baut. Die Studie von Potts und Sudhof formuliert den Befund auf der Anwenderseite. Ich formuliere mit meinem Programm die Konsequenz auf der Teamseite.
Entwicklerteams, die heute aufsetzen, was die fünf Kompetenzfelder vorgeben, schaffen die Voraussetzung dafür, mit jeder neuen Werkzeuggeneration mitzuwachsen, ohne ihre Reviewkultur zu verlieren. Teams, die hoffen, dass das Werkzeug die Methode mitliefert, werden die 88-Prozent-Zahl der unsichtbaren Fehler in ihrer eigenen Lieferung wiederfinden. Die Werkzeuge sind da. Die Methode ist die Bedingung dafür, dass aus ihnen Projektarbeit wird.