Agentic Software Development ist 90% Harness. Wie gut ist Ihrer?
Ihre Entwickler nutzen AI längst. Doch findet das systematisch oder zufällig statt? Nachdem so unsäglicher Blödsinn wie Tokenmaxxing überwunden scheint, zeigen wir Ihnen wie man mit den Limitierungen von LLMs in Software-Entwicklung produktiv auch in größeren Teams arbeitet. Dazu bringen wir einen SDLC-Harness in Ihre bestehende Entwicklungswelt, passen diesen für Ihr Unternehmen an und begleiten den Wandel, bis Ihr Team ihn selbst trägt.
Die Regeln guten Engineerings haben zunächst nichts mit AI zu tun
AI-Tools sind angekommen, doch die Systematik leidet. Der eine Entwickler nutzt AI für jede Zeile, der nächste wüsste gar nicht wie, ein dritter traut den LLMs nicht, und keine der drei Arbeitsweisen wird gemessen. Qualität streut, ohne dass jemand sagen könnte, woran es liegt. Und Produktivität führt zu mehr Freizeit einzelner - was wir jedem gönnen - aber auch das könnte besser organisiert werden. Datenschutz und Compliance…nun, Sie kennen die Antwort.
Die üblichen Gießkannen-Maßnahmen wie „alle müssen AI nutzen“, „jeder stellt etwas AI kreiertes vor“, „wir messen Token-Usage!“ sind ein verzweifelter Versuch eine Situation zu steuern, die im Kern missverstanden bleibt. Wir stellen drei Dinge für Sie sicher:
- 1. Eine Strategie in der Nutzung der richtigen Tools für Ihre Situation
- 2. Eine Operationalisierung dieser Strategie, samt best practices & change
- 3. Das Erzeugen eines Agentic Harness spezifisch für Ihre Use Cases, Tooling und sonstigen Anforderungen
Der Model-Anteil liegt bei etwa 10 Prozent
Die meisten Agenten-Fehlschläge sind, ehrlich betrachtet, Konfigurationsfehler, nicht Modellfehler. Der Model-Anteil am Agenten-Verhalten liegt bei etwa 10 Prozent. Die restlichen 90 Prozent entscheidet die Harness-Konfiguration: welche Anweisungen der Agent bekommt, welche Werkzeuge er nutzen darf, in welcher Umgebung er läuft, wie er orchestriert, kontrolliert und beobachtet wird. Deshalb ist der Harness die eigentliche Engineering-Aufgabe, nicht die Wahl des Modells.
Bei proprietären Enterprise-Plattformen verschiebt sich das Verhältnis noch weiter zulasten des Modells (dazu mehr im Blog).
Ein Harness besteht aus sechs Komponenten:
-
Instructions
was der Agent weiß und wie er angewiesen wird
-
Tools
worauf er zugreifen darf, und worauf nicht
-
Sandboxes
die Umgebung, in der er ausführt
-
Orchestration
wie mehrere Schritte oder Agenten zusammenspielen
-
Guardrails
welche Aktionen automatisch verhindert oder markiert werden
-
Observability
was messbar und nachvollziehbar ist, nachdem der Agent gehandelt hat
Wo eine Dev-Organisation auf dem Spektrum zwischen Vibe Coding und Agentic Engineering steht, lässt sich an diesen sechs Komponenten ablesen.
Kopieren hat Grenzen. Ihre Delivery-Fähigkeit hängt davon ab, wie gut Sie ihren Harness pflegen.
Nein. Sie können keinen fertigen Harness einkaufen. LinkedIn, TikTok, YouTube erzählen Ihnen von den fünf Dingen die Sie benötigen. Das ist zu jeder Zeit genauso falsch wie es korrekt ist. Die Stärke der Technologie sitzt in der inhärenten Notwendigkeit sie spezifisch einzusetzen. Ohne Ihren Kontext, ohne Ihre Probleme und die Arbeitsweisen Ihrer Mitarbeiter erzeugen fremdkopierte Vorgehensweisen Ergebnisse weit hinter den Möglichkeiten.
Deshalb bauen wir den Harness in Ihrer Umgebung, angedockt an Ihre bestehende CI/CD-Pipeline. Wenn Sie diese nicht haben, wissen wir auch wo wir ansetzen müssen. Wenn der Wandel getragen ist, gehört der Harness Ihnen: Konfiguration, Dokumentation, Betrieb.
Für alle Phasen des Software Development Lifecycles - beginnend bei der Ideation, über Requirements Detailing, Solution Engineering, Implementation, Quality Assurance & Dokumentation - bringen wir best practices und damit Startpunkte mit, welche für Sie angepasst werden.
Klein anfangen, kündbar bleiben
- 1
Assess (2 Wochen). Wo steht Ihre Dev-Organisation auf dem Spektrum zwischen Vibe Coding und Agentic Engineering? Wir schauen auf Ihre bestehende Pipeline, Ihre Tool-Nutzung und die Total-Cost-of-Ownership-Rechnung dahinter: eine Einordnung, mit der Sie intern argumentieren können, kein Audit von der Stange.
- 2
Pilot (4 Wochen). Ein Harness, ein echtes Projekt, kein Sandkasten. Wir konfigurieren die sechs Komponenten für einen konkreten Anwendungsfall in Ihrer Pipeline und messen die Wirkung, bevor irgendjemand über einen Rollout entscheidet.
- 3
Scale. Erst wenn der Pilot trägt, folgt der Rollout ins Team: mit Begleitung, bis Ihre Entwickler den Harness selbst betreiben, ohne uns.
Kein „Boil the Ocean“. Der Pilot ist bewusst klein und jederzeit kündbar.
Ein Gespräch. Kein Pitch.
Wenn Sie sich in Abschnitt 2 wiedererkannt haben, lohnt sich ein Gespräch über den Assess-Schritt, unverbindlich, ohne Verkaufsdruck.