E-Commerce-Unternehmen, inhabergeführt
Wir haben Agentic Engineering im eigenen Code erprobt
Das Engineering-Team eines inhabergeführten E-Commerce-Unternehmens wollte agentische Werkzeuge an seiner Codebasis testen und gemeinsame Regeln für ihren Einsatz entwickeln.
| Branche | E-Commerce |
|---|---|
| Leistungen | AI Workshops, Agentic Engineering |
Individuelle KI-Nutzung erschwerte gemeinsame Reviews
Im Team experimentierten Entwickler bereits mit Coding-Agenten. Manche ließen Tests ergänzen, andere umfangreiche Änderungen entwerfen. Die Ergebnisse hingen stark davon ab, welches Wissen die Entwickler über die Codebasis mitgaben. Im Review war häufig unklar, welche Annahmen hinter einer Änderung standen und was tatsächlich geprüft worden war.
Die technische Leitung wollte das Vorgehen vereinheitlichen. Eine Vorführung an einem fremden Beispiel hätte wenig über die eigene Architektur ausgesagt. Das Team musste an seinen Schnittstellen, Konventionen und vorhandenen Tests erfahren, wo ein Agent hilft und an welchen Stellen zusätzliche Prüfung nötig bleibt.
Der Workshop sollte einen prüfbaren Arbeitsablauf liefern
Wir sollten einen praktischen Workshop an der eigenen Codebasis begleiten. Die Teilnehmer brauchten eine eingerichtete Toolchain, klare Qualitätsregeln und einen Plan zur späteren Beobachtung des Nutzens. Produktive Änderungen mussten weiterhin den bestehenden Review- und Freigabeprozess durchlaufen. Der Workshop sollte geeignete Aufgaben und Grenzen anhand tatsächlich ausgeführter Arbeit zeigen.
Die Toolchain wurde mit den Teamregeln verbunden
Der Arbeitskontext wurde im Repository beschrieben
Das Team hielt Architekturgrenzen, relevante Befehle und fachliche Konventionen fest. Der Agent konnte sich damit auf denselben geprüften Kontext beziehen wie die Entwickler.
Aufträge erhielten überprüfbare Grenzen
Wir formulierten Änderungen mit erwarteter Wirkung, betroffenen Schnittstellen und Abnahmekriterien. Ungeklärte Annahmen mussten vor einer breiteren Bearbeitung geklärt werden.
Qualitätsprüfungen liefen im bekannten Prozess
Tests, statische Prüfung und menschliches Review blieben verbindlich. Die Entwickler prüften insbesondere Fehlerfälle, Berechtigungen und unerwartete Änderungen außerhalb des Auftrags.
Der Messplan erfasste Nacharbeit
Das Team vereinbarte, vergleichbare Aufgaben nach Bearbeitung, Review, Korrekturen und späteren Fehlern zu beobachten. Reine Codeproduktion galt nicht als ausreichender Nutzennachweis.
Die Entwickler bearbeiteten eigene Änderungen gemeinsam
Vorab wählten technische Leitung und Entwickler abgegrenzte Aufgaben aus dem Backlog aus. Die Arbeitsumgebung enthielt Testdaten und begrenzte Zugänge. Im Workshop arbeiteten wir im Wechsel zwischen gemeinsamer Demonstration und eigener Bearbeitung. Entwickler erklärten ihren Auftrag, ließen den Agenten arbeiten und prüften anschließend den gesamten Diff.
Bei einer Schnittstellenänderung zeigte sich, dass bestandene Tests fachliche Lücken nicht ausschlossen. Das Team ergänzte ein Gegenbeispiel und verschärfte den Auftrag. Wir besprachen die Ursache direkt am Code. So entstand eine konkrete Regel für ähnliche Änderungen, die in den Repository-Kontext übernommen wurde.
Wir begrenzten den Handlungsspielraum der Agenten zunächst auf überschaubare Änderungen. Das verlangte mehr Vorbereitung durch die Entwickler. Dafür blieben die Diffs prüfbar und falsche Annahmen leichter erkennbar. Größere Umbauten wurden als spätere Erprobung mit eigenen Abnahmen festgehalten.
In der abschließenden Arbeitsrunde stellte das Team erfolgreiche und verworfene Ansätze vor. Die technische Leitung übernahm die Pflege der gemeinsamen Regeln und verankerte die Auswertung des Messplans in den bestehenden Engineering-Austausch.
Das Team konnte Agenten nach gemeinsamen Regeln einsetzen
Die Entwickler hatten an der eigenen Codebasis erlebt, welche Aufträge brauchbare Ergebnisse liefern. Toolchain, Kontext und Qualitätsprüfungen waren eingerichtet. Für die weitere Einführung gab es geeignete Aufgabentypen und einen Messplan, der auch Review und Nacharbeit berücksichtigt. Die technische Leitung konnte darauf aufbauend den Einsatz im Alltag begleiten.
Agentischer Nutzen muss nach dem Review bestehen bleiben
Eigener Code zeigt die tatsächlichen Grenzen
Arbeiten Sie mit vorhandenen Schnittstellen und Tests, damit der Workshop Entscheidungen für den späteren Alltag liefert.
Aufträge brauchen fachliche Gegenbeispiele
Ein bestandener Testlauf ersetzt keine Prüfung, ob die Änderung unerwünschte Fälle korrekt behandelt.
Messen Sie Arbeit bis zur Abnahme
Beziehen Sie Review und Korrekturen ein, bevor Sie aus schneller erzeugtem Code auf Entlastung schließen.
Ein Erstgespräch dauert 30 Minuten.
Wir besprechen, welche Aufgaben aus Ihrer Codebasis sich für einen praktischen Agentic-Engineering-Workshop eignen.