AI Agentic First bei Groupon: Was Ales Drabeks Dark Software Factory uns lehrt

Wenn ein CTIO LinkedIn nutzt, um echte Architektur zu zeigen

LinkedIn ist meistens Lärm. Manchmal nicht. Ales Drabek, Resilient Chief Technology & Information Officer bei Groupon, hat einen Post veröffentlicht, der präziser beschreibt, wie Enterprise-Engineering 2026 wirklich aussieht, als die meisten McKinsey-Decks zum Thema "AI Transformation".

Zwei Patterns, beide live in Production:

1. Dark Software Factory – JIRA-Ticket zu Draft-PR in ~20 Minuten
2. Speedboats – 1 Product Manager + 1 Engineer, ein Outcome, kein Sprint-Cadence

Beides ist mehr als Hype. Es ist die operationalisierte Version dessen, was wir in unserem Artikel zu Enterprise-Grade Agentic Setup als "die Lücke zwischen Vibe Coding und produktionsreifer Agentic-Architektur" beschrieben haben.

Pattern 1: Dark Software Factory

Was passiert technisch

Drabeks Beschreibung – kondensiert:

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".

Live seit 1. April, 9 Orgs, 16 Repositories. Das ist keine Sandbox.

Warum das ein Standard-Pattern wird

Die Architektur folgt einem Prinzip, das wir bei jedem ernsthaften Agentic Setup sehen:

Komponente	Funktion	Warum entscheidend
Trigger via Status-Change	"Ready for Dev" als Eventbus	Keine Custom-API – nutzt vorhandene Workflows
Self-provisioning Runner	GitHub Actions Runner provisioniert on-demand	Keine neue Infra, nur Agents on top
Claude Code als Builder-Agent	Liest Ticket-Context, schreibt Code, öffnet PR	Coding-Agent mit File-Access, nicht Chat
Human Review Gate	PR wird von Mensch reviewed vor Merge	Ownership bleibt bei Engineer, nicht bei Agent
Auto-Shutdown	Runner terminiert sich nach PR-Posting	Kostenkontrolle ist Architektur-Default

Stage 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.

Stage 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.

Was sich für die Menschen ändert

Drabeks Aussage – und das ist der ehrliche Teil, den die meisten Posts auslassen:

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.

Das 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".

Pattern 2: Speedboats

Das zweite Pattern ist organisatorisch, nicht technisch – aber genauso interessant.

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.

Was ein Speedboat ist:

• Prototype first: prove → review → release → learn
• Geschützt vor Backlog-Overhead
• Verbunden mit denselben Plattform-Standards wie alle anderen

Was ein Speedboat nicht ist:

• Kein standalone AI Side-Project
• Kein Weg, Engineering Review zu umgehen
• Kein permanentes Schatten-Team

Das 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.

Die Verbindung: Beide Patterns brauchen dieselbe Grundlage

Drabeks letzter Satz ist der wichtigste:

Beide stützen sich auf dieselbe Voraussetzung: Context-Infrastruktur. AI repariert keine schwachen Systeme – es verstärkt, was bereits da ist.

Das 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 saniert, sollte gleich von Jira auf monday Dev migrieren – maschinenlesbare Tickets sind dort Default, nicht Disziplin-Übung.

Was Context-Infrastruktur in der Praxis bedeutet:

• Tickets, die Maschinen lesen können – Acceptance Criteria, Reproduction Steps, Linked Spec, klare Definition of Done (siehe Sprint Planning mit monday Dev)
• Repos, die navigierbar sind – TOOLS.md, ARCHITECTURE.md, klare Module-Boundaries (Details im Enterprise-Grade Agentic Setup)
• System Prompts, die nicht 12k Token wiegen – disziplinierte Sub-Agent-Briefings statt Monolith-Prompts
• CI/CD-Pipelines, die deterministisch laufen – Agents brechen an Flakiness, Menschen tolerieren sie

Das 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.

Warum das mehr als ein Groupon-Case ist

Drabek 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:

1. Trigger über existierende Tools (JIRA, monday Dev, Linear) – nicht neue Plattformen
2. Self-provisioning Compute auf bestehender CI/CD-Infra – nicht neue "AI Platforms"
3. Coding-Agents mit File-Access (Claude Code, Cursor) – nicht nur Chat-Wrapper
4. Human Gates an entscheidenden Stellen – nicht "Full Autonomy" als Marketing-Lüge
5. Parallele Agent-Varianten mit QA-Verdict – Performance-Measurement statt Vibes

Wer 2026 Engineering-Org leitet und diesen Stack noch nicht im Pilotbetrieb hat, baut bereits Schulden auf.

Was du jetzt tun solltest

Drei konkrete Moves, abgeleitet aus Drabeks Setup:

1. Audit deiner Context-Infrastruktur

Bevor 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.

2. Pilot auf einem klar abgegrenzten Repo

Wä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.

3. Speedboat-Modell als organisatorischen Hebel

Selbst 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.

Fazit: Das ist, wie Engineering 2026 aussieht

Drabeks 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.

Die 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.

Quelle & Credit: Originaler LinkedIn-Post von Ales Drabek – lesenswert in voller Länge.

Weiterlesen:

• Enterprise-Grade Agentic Setup: Warum ein API-Key keine KI-Strategie ist – die Architektur hinter der Software Factory
• monday Dev: Das unterschätzte Dev-Tool 2026 – das bessere Frontend für Agentic-Tickets
• monday Dev vs. Jira und monday Dev vs. Linear – Tool-Vergleich für Agentic-Workflows
• Sprint Planning mit monday Dev – maschinenlesbare Sprints, in denen Agents arbeiten können
• Jira zu monday Dev migrieren – Backlog-Hygiene als Agent-Voraussetzung
• Lovable Beyond Apps – wenn Builder zu Plattformen werden