Vorbereitung des Workshops zu Agentic Engineering

Zweck des Briefs

Dieser Brief bereitet den Nutzer als Teilnehmer auf den ganztägigen Workshop vor. Er verbindet den lokalen Workshoprahmen mit dem bisherigen Stand der Forschungslandkarte. Er ist kein fertiger Ablaufplan für die Moderation und nimmt Entscheidungen des Workshops nicht vorweg.

Ausgangslage

• Claude Code wird seit einigen Monaten eingesetzt, mit geringerem sichtbarem Erfolg als erhofft.
• Der tatsächliche Nutzen wurde bislang nicht systematisch als End-to-End-Wirkung von Produktentwicklung gemessen.
• Die eigentliche Programmierung erscheint nur als Teil eines breiteren Implementierungsengpasses aus Anforderungsklärung, Systemanalyse, Review, Test, Build und Rollout.
• Menschliches Review ist verpflichtend; statische Analyse, mehrere Testebenen und Secret Scanning existieren, aber eine Suffizienzschwelle automatischer Assurance fehlt.
• Instabile Feature-Testumgebungen binden menschliche Aufmerksamkeit, erhöhen Work in Progress und bilden einen konkreten agentischen Experimentkandidaten.
• Produktmetriken, Nutzerfeedback und Wirkungsentscheidungen sind schwach in die Teamarbeit zurückgekoppelt.
• Das Teammodell verbindet Merkmale von Feature Factory und Product Team. Product-Team-Arbeit stößt je nach Tätigkeit auf unterschiedliche Fähigkeits-, Motivations- und Kapazitätshürden.
• Mehrere relativ autonome Teams arbeiten auf ähnlicher technischer Basis an verbundenen Teilen derselben großen Anwendung.

Entscheidungsraum des Workshops

Projektleitung, Product Owner und Entwickler können insbesondere entscheiden oder vorbereiten:

• gemeinsame Bewertungsmaßstäbe für Agentennutzung;
• konkrete Entwicklungs- und Harness-Experimente;
• wiederverwendbare technische Kontrollen und Kontextbausteine;
• Änderungen an Review, Test, WIP und teamübergreifendem Lernen;
• Verantwortliche, Laufzeit und Auswertungstermine der Versuche.

Wegen der Abwesenheit des Produktmanagements können folgende Punkte nur als Empfehlung oder Folgefrage formuliert werden:

• verbindliche Produktwirkungsziele;
• Zugang und reservierte Zeit von Key-Usern;
• neue Mandate für selbständige Produktentscheidungen;
• organisationsweite Verschiebung von Featurekapazität zu Discovery und Lernen;
• strategische Veränderung dessen, was als Produkt angeboten wird.

Erwartungen, die der Nutzer äußern kann

Ich möchte den Workshop nicht nur mit neuen Prompting-Tipps verlassen, sondern mit einer gemeinsamen Sicht auf unsere tatsächlichen Engpässe und mit wenigen messbaren Experimenten.

Wir sollten unterscheiden, ob Claude Code nur lokale Codingzeit spart oder die Durchlaufzeit bis zu sicherem Rollout und belastbarem Feedback verbessert.

Für jedes Experiment sollten Hypothese, Baseline, Qualitäts- und Security-Guardrails, Verantwortlicher, Laufzeit, Auswertungstermin und Abbruchkriterien feststehen.

Ergebnisse, die Produktmandat oder Nutzeraktivierung benötigen, sollten wir als konkrete Entscheidungsvorlage für das nicht anwesende Produktmanagement festhalten.

Persönlicher Teilnehmerleitfaden

Kompaktes Denkmodell

Der Nutzer kann Beiträge anhand von fünf Ebenen einordnen:

1. Problem und Wirkung: Welche Verbesserung der Produktentwicklung oder Produktwirkung wird angestrebt?
2. Arbeitsschleife: Welcher konkrete Ablauf soll sich verändern?
3. Agentenbeitrag: Welche inferentielle oder ausführende Aufgabe übernimmt das Werkzeug?
4. Harness und Grenzen: Welche Informationen, Prüfungen, Rechte und Eskalationen machen dies zuverlässig?
5. Evidenz: Woran werden Nutzen, Kosten, Qualität und Nebenwirkungen erkannt?

Fehlt eine Ebene, kann der Nutzer sie als Frage ergänzen, ohne bereits eine Lösung vorgeben zu müssen.

Kurze eigene Position

Ich halte Agentic Engineering weder für bloßen Hype noch für einen automatischen Produktivitätssprung. Bei uns scheint Code nur ein Teil des Engpasses zu sein. Ich möchte herausfinden, welche Aufgaben wirklich profitieren, welche Prozess- und Plattformfähigkeiten dafür nötig sind und wie wir das mit begrenzten Experimenten statt Einzelwahrnehmungen prüfen.

Situative Impulse

Wenn die Diskussion bei Tooltipps und Prompts bleibt:

Für welche wiederkehrende Aufgabenklasse soll diese Technik zuverlässig funktionieren, und wie prüfen wir den End-to-End-Nutzen?

Wenn eine starke Produktivitätsbehauptung genannt wird:

Welche Arbeit wird dabei mitgerechnet: Klärung, Kontrolle, Review, Test, Nacharbeit und Rollout?

Wenn einzelne positive oder negative Erfahrungen verallgemeinert werden:

Welche Eigenschaften von Aufgabe, Codebasis, Entwicklererfahrung und Harness könnten den Unterschied erklären?

Wenn viele mögliche Anwendungsfälle gesammelt werden:

Welches konkrete Problem kostet uns heute am meisten Aufmerksamkeit oder Durchlaufzeit, und welcher Fall ist klein genug für einen Versuch?

Wenn ein Agent menschliches Review ersetzen soll:

Für welche Fehlerklasse und Risikostufe, gegen welches Orakel und mit welchem Schattenvergleich?

Wenn eine umfassende Plattform gefordert wird:

Welches erste Experiment benötigt welche minimale Plattformfähigkeit, und was sollten wir erst nach nachgewiesenem Bedarf bauen?

Wenn mehr Agentenparallelität als Ziel erscheint:

Reduziert sie Durchlaufzeit oder erhöht sie Work in Progress, Reviewmenge und fragmentierte Aufmerksamkeit?

Wenn Product-Team- oder Outcome-Fragen entstehen:

Was können wir heute vorbereiten, und welche Entscheidung müssen wir wegen des fehlenden Produktmanagements anschließend validieren lassen?

Experiment-Charter für spontane Ideen

Jede vielversprechende Idee kann mit neun kurzen Feldern konkretisiert werden:

1. beobachtetes Problem;
2. betroffene Aufgabenklasse und Nutzer;
3. heutige Baseline;
4. vermuteter Agentenbeitrag;
5. notwendiger minimaler Harness;
6. Erfolgsmetriken;
7. Qualitäts-, Security- und Belastungs-Guardrails;
8. Owner, Laufzeit und Auswertungstermin;
9. Abbruch- oder Widerlegungskriterium.

Persönliche Vorbereitung vor dem Termin

Soweit ohne großen Aufwand möglich, sollte der Nutzer mitbringen:

• ein Beispiel, bei dem Claude Code klar geholfen hat;
• ein Beispiel mit hoher Nacharbeit oder enttäuschendem Ergebnis;
• einen wiederkehrenden Engpass, etwa Testumgebungsbetreuung;
• eine Aufgabe, die sich als gemeinsamer Eval-Fall eignen könnte;
• eine Prozessänderung, die auch ohne Agenten überfällig erscheint;
• eine Annahme, bei der er bereit ist, sich durch Daten widerlegen zu lassen.

Diese Beispiele müssen nicht repräsentativ sein. Sie dienen als konkrete Einstiegspunkte und werden im Workshop von den Erfahrungen anderer Teams ergänzt.

Diskussionsthesen

1. Agentic Engineering verstärkt den vorhandenen Flow. In einer Feature Factory kann es mehr Output und Engpässe erzeugen; in einer Product-Team-Schleife kann es Zeit bis zu Evidenz und Entscheidung verkürzen.
2. Codeerzeugung ist nicht mit End-to-End-Nutzen gleichzusetzen. Review, Test, Systemverständnis, Rollout, Nutzerfeedback und menschliche Aufmerksamkeit müssen mitgemessen werden.
3. Kleine produktionsreife Änderungen benötigen niedrigere Transaktionskosten. Solange Review, Testumgebung und Rollout hohe Fixkosten besitzen, bleibt das Bündeln großer Änderungen lokal rational.
4. Menschliches Review ist kein einheitliches Orakel. Ziel ist eine gestaffelte, risikobasierte Assurance, nicht der pauschale Ersatz eines Menschen durch einen Reviewer-Agenten.
5. Ein Agentic Flywheel muss Ursachen reduzieren. Ein Agent, der instabile Abläufe dauerhaft betreut, verbessert den Harness nicht. Wiederkehrende Fehler müssen in Tests, Invarianten, Runbooks oder Plattformkorrekturen zurückfließen.
6. Ähnliche technische Grundlagen sind ein gemeinsamer Hebel. Evals, Kontextbausteine, Architekturregeln und Diagnosewerkzeuge können geteilt werden; aufgabenspezifische Workflows bleiben bei den Teams.
7. Product-Team-Arbeit darf nicht zusätzliche Arbeit auf unveränderte Zusagen legen. Produktivitätsgewinne müssen bewusst in Lernen, Qualität oder weniger WIP investiert werden.
8. Ein geringerer Nutzen als im Hype ist ein gültiges Ergebnis. Ein Experiment darf zeigen, dass eine Aufgabe, ein System oder eine Kontrolllast derzeit keinen positiven Gesamtnutzen erlaubt.

Fragen an andere Teilnehmer

Zu bisherigen Erfahrungen

• Für welche konkreten Aufgaben wird Claude Code wiederholt eingesetzt?
• Wo wurde nachweislich End-to-End-Zeit gespart, nicht nur Code schneller erzeugt?
• Welche Ergebnisse wurden verworfen oder stark nachbearbeitet und warum?
• Welche Aufgaben funktionieren zuverlässig, welche nur bei hoher Repository- und Domänenkenntnis?
• Wie viel Zeit wird für Kontrolle, Kontextaufbereitung und Korrektur benötigt?
• Hat Agentennutzung Reviewvolumen, Work in Progress oder Kontextwechsel verändert?
• Welche Arbeitsweisen haben einzelne Teams entwickelt, die andere übernehmen könnten?
• Welche Erwartungen haben sich nach einigen Monaten als zu hoch oder falsch erwiesen?

Zu System und Zusammenarbeit

• Welche wiederkehrenden Fehlerklassen könnten durch gemeinsame Kontrollen verhindert werden?
• Welche Regeln und welches Wissen fehlen Agenten heute oder sind nur implizit vorhanden?
• Wo erzwingt die Architektur breite Änderungen über mehrere Services?
• Welche Schnittstellenänderungen lassen sich nicht unabhängig prüfen oder ausrollen?
• Welche Plattform- oder Securitygrenzen verhindern sichere Agentenexperimente?
• Welche bisherige Arbeit müsste entfallen, damit neue Agenten- oder Produktaufgaben nicht nur zusätzliche Belastung werden?

Kandidaten für Experimente

1. Gemeinsames Eval-Set für reale Aufgaben

Mehrere Teams bringen je wenige repräsentative, bereits gelöste Aufgaben und bekannte Fehlerfälle ein. Verglichen werden heutige Arbeitsweise und klar definierte Agentenkonfigurationen. Gemessen werden Lösungserfolg, menschliche Zeit, Nacharbeit, Reviewbefunde, Kosten und Qualitätsfolgen. Das Eval dient nicht als allgemeines Modellranking, sondern prüft konkrete Aufgabenklassen der gemeinsamen technischen Basis.

2. Diagnose instabiler Feature-Testumgebungen

Ein deterministischer Evidence Collector bündelt je Kubernetes-Namespace Ereignisse, Zustände, Logs, Metriken und Testergebnisse. Ein Agent analysiert diese Pakete zunächst im Schattenbetrieb. Gemessen werden Diagnosequalität, Anteil ungeklärter Fälle, menschliche Betreuungszeit, Wiederholungsfehler und Work in Progress. Wiederkehrende Ursachen sollen in Plattformverbesserungen statt unbegrenzte Retries zurückfließen.

3. Agentisches Review im Schattenbetrieb

Menschliche Reviewpflicht bleibt bestehen. Deterministische Kontrollen, spezialisierte Agentenreviews und menschliche Befunde werden zunächst unabhängig verglichen. Die Auswertung erfolgt nach Fehlerklasse, MR-Größe, thematischer Kohärenz, Fehlalarmen, übersehenen Problemen und späterer Nacharbeit. Erst belastbare Daten können eine risikobasierte Lockerung begründen.

4. Produktionsreife Thin-Slice-Challenge

Ein begrenzter vertikaler Schnitt soll innerhalb weniger Tage für eine Pilotgruppe produktiv werden. Lernfrage, Instrumentierung, Assurance, Rollback und Outcome Review werden vor Beginn geplant. Prozess-, Plattform- und Agentenbeiträge werden getrennt dokumentiert. Dieser Versuch benötigt vor Ausführung ein Produktmandat und organisierte Nutzerbeteiligung; der Workshop kann ihn daher vorbereiten, aber ohne Produktmanagement nicht vollständig beschließen.

Auswahlkriterien

Ein erster Versuch sollte ein reales wiederkehrendes Problem, einen begrenzten Schadensradius, verfügbare Daten, eine nachvollziehbare Baseline und einen verantwortlichen Owner besitzen. Er sollte innerhalb weniger Wochen Erkenntnisse liefern und weder eine allgemeine Plattform noch weitreichende Autonomie voraussetzen.

Es sollten höchstens ein oder zwei Experimente gleichzeitig begonnen werden. Sonst steigt Work in Progress und die Organisation kann Wirkungen nicht mehr sauber zuordnen.

Gewünschte Workshop-Ergebnisse

• eine gemeinsame, nicht beschönigte Sicht auf bisherigen Nutzen und Kosten;
• priorisierte Engpässe statt einer Liste möglicher AI-Anwendungen;
• ein oder zwei ausgefüllte Experiment-Charter;
• gemeinsame Metriken und Guardrails;
• benannte Verantwortliche und Auswertungstermine;
• eine Liste wiederverwendbarer Harness- oder Plattformbausteine;
• konkrete Entscheidungsvorlagen für Produktmanagement, Plattform oder Security;
• explizite Kriterien, unter denen ein Experiment beendet oder der erwartete Nutzen nach unten korrigiert wird.