Durchgängige Agenten-Frameworks versprechen eine einheitliche Oberfläche für Planung, Codierung und Auslieferung. In der Praxis übernehmen sie jedoch oft zu viel Kontrolle: Debugging wird zur Archäologie, Iterationen verlangsamen sich und Regressionen verstecken sich in der Orchestrierungsschicht. Ein skills-basierter Ansatz zerlegt die Arbeit in kleine, zusammensetzbare Verhaltensweisen – Anforderungen grillen, eine gemeinsame Sprache erfassen, Red-Green-Refactor vorantreiben und den Codebestand periodisch umgestalten. Jede Einheit macht eine Sache gut, ist leicht austauschbar oder abzweigbar und funktioniert mit jedem Modell, Editor oder CI. So erhält man explizite Kontrolle über Feedback-Schleifen, bessere Beobachtbarkeit und die Freiheit, Prozesse anzupassen, ohne alles andere zu zerstören.

Der Kernstapel sieht aus wie erprobte Ingenieurpraxis, verpackt für Agenten: Grill-Sitzungen zur Abstimmung von Umfang und Annahmen, Domänenmodellierung zur Komprimierung von Projektsprache in eine präzise gemeinsame Sprache, TDD zur Erzwingung ausführbarer Absichten vor der Implementierung und eine disziplinierte Fehlerdiagnose-Schleife zum Reproduzieren, Minimieren, Instrumentieren, Beheben und Absichern mit Regressionstests. Drumherum sitzen Helfer, die Spezifikationen aus Gesprächen synthetisieren, Arbeit in Tracer-Bullet-Tickets aufteilen und regelmäßig die Architektur vertiefen. Entscheidend ist, dass keine dieser Fähigkeiten einen bestimmten Anbieter oder ein Modell erfordert – sie kodieren Gewohnheiten, keine Plattformen – sodass Teams ihre Hebelwirkung behalten, während sich Werkzeuge weiterentwickeln.

Für CTOs und Führungskräfte liegt der Wert in Messbarkeit und Änderungssteuerung. Fähigkeiten sind einzeln beobachtbar: Man kann Grill-zu-Spezifikations-Abstimmungsfehler, TDD-Pass/Fail-Latenz und Architekturverbesserungsdurchsatz verfolgen. Die Einführung erfolgt schrittweise – ein Repository pilotieren, Basiswerte für Fehlerentweichrate und Zykluszeit erfassen, dann ausweiten. Wenn ein Modell stottert oder ein Plugin verschlechtert, ersetzt man eine einzelne Fähigkeit, nicht den gesamten Prozess. Dieser Pragmatismus verkürzt Feedback-Schleifen, reduziert Diff-Churn und verbessert die Vorfallwiederherstellung, weil das System einfache Nähte, tiefe Module und Tests bevorzugt, die Geschäftsabsicht statt Implementierungsdetails beschreiben.