https://till-freitag.com/assets/agentic-first-engineering-groupon--HW8Ggjk.js

1const e=`---
2title: "AI Agentic First bei Groupon: Was Ales Drabeks Dark Software Factory uns lehrt"
3seoTitle: "AI Agentic First: Groupons Software Factory"
4seoDescription: "Ales Drabek (CTIO Groupon) zeigt mit Dark Software Factory & Speedboats, wie Agentic Engineering in Production wirklich aussieht – Patterns und Learnings."
5slug: agentic-first-engineering-groupon
6alternate_slug: agentic-first-engineering-groupon-en
7date: 2026-04-30
8modified: 2026-04-30
9author:
10  name: Till Freitag
11  slug: till-freitag
12  avatar: https://secure.gravatar.com/avatar/93e9e3ad1b0c5e919c3bce42a9e90e7c?s=96&d=mm&r=g
13excerpt: "Ales Drabek, CTIO bei Groupon, hat zwei Patterns in Production: Dark Software Factory und Speedboats. Was das über AI Agentic First in Enterprise-Engineering verrät."
14featuredImage: blog:ai-agentic-first-groupon
15featuredImageAlt: "Pipeline-Schema einer Dark Software Factory: ein JIRA-Ticket im Status \\"Ready for Dev\\" triggert parallele Claude-Code-Sub-Agents, die einen Draft-Pull-Request auf GitHub erzeugen, mit Human-Review-Gate vor dem Merge"
16nerd_level: 4
17categories: [Engineering, AI, Strategy, Agentic Engineering]
18tags: [Agentic Engineering, AI Agents, Claude Code, Sub-Agents, Enterprise AI, Software Factory, Speedboats]
19language: de
20tldr: "Groupon zeigt, wie AI Agentic First in Production aussieht: JIRA-Ticket → PR in 20 Minuten via Claude Code, plus 'Speedboats' aus 1 PM + 1 Engineer. Beide Patterns brauchen Context-Infrastruktur – nicht mehr Tools."
21relatedPages: [enterprise-agentic-setup, lovable-beyond-apps, monday-dev-unterschaetzt]
22---
23
24## Wenn ein CTIO LinkedIn nutzt, um echte Architektur zu zeigen
25
26LinkedIn ist meistens Lärm. Manchmal nicht. [Ales Drabek, Resilient Chief Technology & Information Officer bei Groupon, hat einen Post veröffentlicht](https://www.linkedin.com/posts/alesdrabek_claude-activity-7455474703466422272-Ovnu), der präziser beschreibt, wie Enterprise-Engineering 2026 wirklich aussieht, als die meisten McKinsey-Decks zum Thema "AI Transformation".
27
28Zwei Patterns, beide live in Production:
29
301. **Dark Software Factory** – JIRA-Ticket zu Draft-PR in ~20 Minuten
312. **Speedboats** – 1 Product Manager + 1 Engineer, ein Outcome, kein Sprint-Cadence
32
33Beides ist mehr als Hype. Es ist die operationalisierte Version dessen, was wir in unserem Artikel zu [Enterprise-Grade Agentic Setup](/blog/enterprise-agentic-setup) als "die Lücke zwischen Vibe Coding und produktionsreifer Agentic-Architektur" beschrieben haben.
34
35## Pattern 1: Dark Software Factory
36
37### Was passiert technisch
38
39Drabeks Beschreibung – kondensiert:
40
41> Ein Ticket wechselt zu "Ready for Dev" → die Pipeline feuert. Der Runner provisioniert sich selbst, Claude Code schreibt den Code, postet den PR zurück nach JIRA und schaltet sich ab. Jeder PR wird vor dem Merge noch von einem Menschen reviewed. Deshalb nennen wir es noch nicht "dark".
42
43Live seit 1. April, **9 Orgs, 16 Repositories**. Das ist keine Sandbox.
44
45### Warum das ein Standard-Pattern wird
46
47Die Architektur folgt einem Prinzip, das wir bei jedem ernsthaften Agentic Setup sehen:
48
49| Komponente | Funktion | Warum entscheidend |
50|------------|----------|-------------------|
51| **Trigger via Status-Change** | "Ready for Dev" als Eventbus | Keine Custom-API – nutzt vorhandene Workflows |
52| **Self-provisioning Runner** | GitHub Actions Runner provisioniert on-demand | Keine neue Infra, nur Agents on top |
53| **Claude Code als Builder-Agent** | Liest Ticket-Context, schreibt Code, öffnet PR | Coding-Agent mit File-Access, nicht Chat |
54| **Human Review Gate** | PR wird von Mensch reviewed vor Merge | Ownership bleibt bei Engineer, nicht bei Agent |
55| **Auto-Shutdown** | Runner terminiert sich nach PR-Posting | Kostenkontrolle ist Architektur-Default |
56
57Stage 2 (in Review): **dasselbe Ticket fan-outed parallel auf mehrere Prompt- und Model-Varianten**, ein Claude QA Agent gibt PASS/FAIL zurück. Das ist Head-to-Head-Measurement von Agent-Performance – nicht Bauchgefühl.
58
59Stage 3 (in Design): **sechs Agent-Stages von Raw Story zu Auto-Merge** – auf derselben Infrastruktur. Die Arbeit liegt in den Agents, nicht in der Plattform darunter.
60
61### Was sich für die Menschen ändert
62
63Drabeks Aussage – und das ist der ehrliche Teil, den die meisten Posts auslassen:
64
65> Product Manager und Engineers verbringen keine Stunden mehr damit, Tickets in Code zu übersetzen, und stecken diese Zeit in die Teile, die nur Menschen besitzen sollten – die Anforderung, das Review, das Urteil.
66
67Das ist die richtige Framing. Nicht "Agents ersetzen Engineers", sondern "Agents ersetzen die langweiligen 60% des Engineering-Workflows, damit Menschen sich auf die 40% konzentrieren, die Signal liefern".
68
69## Pattern 2: Speedboats
70
71Das zweite Pattern ist organisatorisch, nicht technisch – aber genauso interessant.
72
73> Ein Speedboat ist genau das, wonach es klingt: ein Product Manager und ein Engineer, gepaart auf einem einzigen Outcome, shipping außerhalb der Quarterly-Planning-Maschine.
74
75Was ein Speedboat **ist**:
76- Prototype first: prove → review → release → learn
77- Geschützt vor Backlog-Overhead
78- Verbunden mit denselben Plattform-Standards wie alle anderen
79
80Was ein Speedboat **nicht ist**:
81- Kein standalone AI Side-Project
82- Kein Weg, Engineering Review zu umgehen
83- Kein permanentes Schatten-Team
84
85Das klingt nach gesundem Menschenverstand. In großen Orgs ist es revolutionär. Quarterly Planning ist die Verteidigungslinie, an der die meisten innovativen Ideen sterben – nicht weil sie schlecht sind, sondern weil sie nicht in den nächsten Sprint passen.
86
87## Die Verbindung: Beide Patterns brauchen dieselbe Grundlage
88
89Drabeks letzter Satz ist der wichtigste:
90
91> Beide stützen sich auf dieselbe Voraussetzung: Context-Infrastruktur. AI repariert keine schwachen Systeme – es verstärkt, was bereits da ist.
92
93Das ist exakt der Punkt, den wir bei jedem Kunden-Engagement machen. Du kannst nicht einen Coding-Agent auf ein chaotisches JIRA-Backlog mit unklaren Tickets, fehlenden Acceptance Criteria und 200 offenen Bugs werfen und erwarten, dass er die Welt rettet. Wer sein Backlog ohnehin 

93saniert, sollte gleich [von Jira auf monday Dev migrieren](/blog/jira-zu-monday-dev-migration) – maschinenlesbare Tickets sind dort Default, nicht Disziplin-Übung.
94
95**Was Context-Infrastruktur in der Praxis bedeutet:**
96
97- **Tickets, die Maschinen lesen können** – Acceptance Criteria, Reproduction Steps, Linked Spec, klare Definition of Done (siehe [Sprint Planning mit monday Dev](/blog/sprint-planning-monday-dev))
98- **Repos, die navigierbar sind** – \`TOOLS.md\`, \`ARCHITECTURE.md\`, klare Module-Boundaries (Details im [Enterprise-Grade Agentic Setup](/blog/enterprise-agentic-setup#was-enterprise-grade-agentic-wirklich-bedeutet))
99- **System Prompts, die nicht 12k Token wiegen** – [disziplinierte Sub-Agent-Briefings](/blog/enterprise-agentic-setup) statt Monolith-Prompts
100- **CI/CD-Pipelines, die deterministisch laufen** – Agents brechen an Flakiness, Menschen tolerieren sie
101
102Das ist die Hausaufgabe. Wer die nicht macht, kauft sich einen Claude-Code-Account und produziert teure Halbergebnisse. Wer sie macht, baut die Dark Software Factory.
103
104## Warum das mehr als ein Groupon-Case ist
105
106Drabek ist nicht der erste CTIO, der Agentic Engineering in Production fährt – aber einer der ersten, der **die Architektur öffentlich beschreibt** statt nur das Outcome zu feiern. Das ist wertvoll, weil es ein Template setzt:
107
1081. **Trigger über existierende Tools** ([JIRA](/blog/jira-zu-monday-dev-migration), [monday Dev](/blog/monday-dev-unterschaetzt), [Linear](/blog/monday-dev-vs-linear)) – nicht neue Plattformen
1092. **Self-provisioning Compute** auf bestehender CI/CD-Infra – nicht neue "AI Platforms"
1103. **Coding-Agents mit File-Access** (Claude Code, Cursor) – nicht nur Chat-Wrapper
1114. **Human Gates an entscheidenden Stellen** – nicht "Full Autonomy" als Marketing-Lüge
1125. **Parallele Agent-Varianten mit QA-Verdict** – Performance-Measurement statt Vibes
113
114Wer 2026 Engineering-Org leitet und diesen Stack noch nicht im Pilotbetrieb hat, baut bereits Schulden auf.
115
116## Was du jetzt tun solltest
117
118Drei konkrete Moves, abgeleitet aus Drabeks Setup:
119
120### 1. Audit deiner Context-Infrastruktur
121Bevor du den ersten Agent baust: Wie viele deiner Tickets könnte ein Mensch ohne Rückfrage in PR umsetzen? Wenn die Antwort unter 50% ist, hast du ein Ticket-Hygiene-Problem, kein AI-Problem.
122
123### 2. Pilot auf einem klar abgegrenzten Repo
124Wähle ein Repo mit hoher Test-Coverage, klarer Architektur und disziplinierten Tickets. Nicht das chaotischste – das aufgeräumteste. Der Agent braucht Wins, du brauchst Daten.
125
126### 3. Speedboat-Modell als organisatorischen Hebel
127Selbst ohne Coding-Agents kannst du das Speedboat-Pattern morgen testen: 1 PM + 1 Engineer, ein Outcome, vier Wochen, raus aus dem Sprint-Cadence. Du wirst überrascht sein, was passiert.
128
129## Fazit: Das ist, wie Engineering 2026 aussieht
130
131Drabeks Post ist deshalb wichtig, weil er **beweisbar in Production läuft** – nicht weil er beeindruckend klingt. Dark Software Factory + Speedboats sind keine Buzzwords, sondern operative Patterns mit klaren Mechaniken.
132
133Die Lücke zwischen "wir nutzen ChatGPT für Code-Snippets" und "JIRA-Ticket → PR in 20 Minuten quer über 9 Orgs" ist nicht graduell. Es ist ein Architektur-Sprung. Und er beginnt nicht mit dem Agent – er beginnt mit der Context-Infrastruktur darunter.
134
135**Quelle & Credit:** [Originaler LinkedIn-Post von Ales Drabek](https://www.linkedin.com/posts/alesdrabek_claude-activity-7455474703466422272-Ovnu) – lesenswert in voller Länge.
136
137**Weiterlesen:**
138- [Enterprise-Grade Agentic Setup: Warum ein API-Key keine KI-Strategie ist](/blog/enterprise-agentic-setup) – die Architektur hinter der Software Factory
139- [monday Dev: Das unterschätzte Dev-Tool 2026](/blog/monday-dev-unterschaetzt) – das bessere Frontend für Agentic-Tickets
140- [monday Dev vs. Jira](/blog/monday-dev-vs-jira) und [monday Dev vs. Linear](/blog/monday-dev-vs-linear) – Tool-Vergleich für Agentic-Workflows
141- [Sprint Planning mit monday Dev](/blog/sprint-planning-monday-dev) – maschinenlesbare Sprints, in denen Agents arbeiten können
142- [Jira zu monday Dev migrieren](/blog/jira-zu-monday-dev-migration) – Backlog-Hygiene als Agent-Voraussetzung
143- [Lovable Beyond Apps – wenn Builder zu Plattformen werden](/blog/lovable-beyond-apps)
144`;export{e as default};