Agentic Engineering: Wie arbeiten das Tech-Team bei mobile.de mit KI?

Intro

In dieser Episode ist David Gebhardt zu Gast — CTO bei mobile.de. Gemeinsam tauchen Felix und David tief in die Frage ein, wie KI den Alltag in Software-Teams verändert: von der breiten Copilot-Adoption über Agentic Engineering bis hin zu den neuen Engpässen, die entstehen, wenn Ausführung plötzlich „billig“ wird. Im Mittelpunkt stehen Davids Learnings aus einem 30‑Jahre‑Unternehmen: Welche Guardrails und Kontexte braucht es, damit Agents in Legacy-Codebases zuverlässig arbeiten? Und was passiert mit Rollen, Teams und Change, wenn Entwicklung massiv schneller wird?

Inhaltsübersicht

Agentic Engineering vs. AI‑Assisted Coding: Was sich wirklich verschiebt
• Spec‑Driven Development: Specs, Guardrails und „Harness“ als neue Superpower
• Kontext in Legacy‑Code: MCP, Vektor-Index der Codebase und Observability‑Anbindung
• Rollen im Wandel: Product Engineer, Platform Engineer und neue Schnittstellen
• Engpässe außerhalb von Tech: Entscheidungen, Go‑to‑Market und Aufmerksamkeit
• Mensch & Change: Champions, Sprache und Umgang mit Unsicherheit

Über den Gast

David Gebhardt ist CTO bei mobile.de und verantwortet mit seinem Team die Softwareentwicklung, interne IT und Security. Bei mobile.de treibt er die praktische Adoption von KI im Engineering voran — von AI‑assisted Coding bis hin zu agentischen Workflows, die Spezifikation, Tests und Review verändern.

Detaillierte Zusammenfassung

Vom Tool zum Arbeitsmodus: Agentic Engineering

David beschreibt einen zentralen Perspektivwechsel: Während AI‑Assisted Coding den Menschen weiterhin als Dreh‑ und Angelpunkt sieht (kleine Prompts, schnelle Iterationen), dreht Agentic Engineering das Verhältnis um. Der Mensch liefert deutlich mehr Kontext und klare Vorgaben — dann arbeitet die KI in längeren Zyklen Richtung Endprodukt. Entscheidend ist dabei nicht „schneller tippen“, sondern Spezifikationen, Constraints und Akzeptanzkriterien sauber zu formulieren — damit aus einem Prompt ein belastbarer Arbeitsauftrag wird.

„Bei Agentic Engineering dreht sich das Verhältnis … der Mensch gibt Input … und lässt die AI sehr lange arbeiten, um näher an ein Endprodukt zu kommen.“

Spec‑Driven Development: Specs, Guardrails und Harness

In Davids Beschreibung verschiebt sich Aufwand nach vorn und hinten: Die Spezifikation wird aufwendiger, weil implizites Wissen — das in Teams früher „mitlief“ — für Maschinen schlecht funktioniert. Gleichzeitig wird Review wichtiger: Am Ende steht zwar schneller ein Pull Request, aber der Human-in-the-Loop muss Qualität, Sicherheit und Zielerreichung prüfen. David nennt hierfür Guardrails (z.B. Security‑Standards, Testabdeckung, Code‑Style) und „Harness“ als Umfeld, das Kontext, Regeln und Tools bereitstellt.

Kontext in einer großen Codebase: MCP und Vektor‑Index

Ein zentrales Problem in Legacy- und Microservice-Landschaften ist Kontext: Was bei kleinen Greenfield‑Projekten trivial ist, wird in gewachsenen Plattformen zur Hürde. David skizziert zwei Entwicklungen: (1) größere Kontextfenster der Modelle und (2) zusätzliches Tooling. Bei mobile.de wurde die Codebase in einer Vektor-Datenbank indiziert und über ein MCP bereitgestellt, sodass Claude/Agents gezielt auf relevante Teile zugreifen können. Ähnlich wurde Observability angebunden, um Incidents in den Kontext zu holen. Dazu kommen „Skills“ in separaten Repositories, die mobile.de‑spezifisches Wissen standardisieren.

Architektur-Trade-offs: Microservices vs. „machine-friendly“ Setup

David macht einen spannenden Punkt: Viele Architekturen wurden für menschliche Arbeitsteilung optimiert (Microservices, getrennte Repos, Frontend/Backend/Apps). Für Maschinen könnte ein anderes Setup besser sein (z.B. Mono‑Repos oder stärker vereinheitlichte Strukturen). Die Konsequenz: Agentic Engineering ist nicht nur Tool‑Einführung, sondern kann langfristig auch technische Architekturentscheidungen beeinflussen.

Rollen, Teams und Organisation: Was sich verschiebt

Wenn Specs wichtiger werden, rücken Product, UX und Engineering enger zusammen — idealerweise in Trios, die Spezifikationen gemeinsam entwickeln. David sieht Rollenbilder wie Product Engineer (Businessproblem → Spec → Validierung) und Platform Engineer (Capabilities für viele Teams). Gleichzeitig entstehen neue Bedarfe: Security wird wichtiger, QA bekommt wieder mehr Gewicht, und Teams könnten kleiner werden, weil Agents Disziplin-Grenzen (Frontend/Backend/Data) weniger stark machen. Ein zusätzlicher Hebel: schnelleres Onboarding, weil KI Kontext zugänglich macht — was starres Ownership potenziell aufweicht.

Neue Engpässe: Intent, Entscheidungen und menschliche Aufmerksamkeit

Wenn Umsetzung schneller wird, wird die Leitfrage: Wissen wir gut genug, was wir bauen wollen? David beschreibt, dass Ideen selten knapp sind — knappe Ressourcen waren lange Zeit Kapazität und Detailtiefe. Mit mehr Delivery-Speed steigen Upstream- und Downstream‑Bottlenecks: Strategie, Priorisierung, Discovery, aber auch Go‑to‑Market und Kommunikation. Dazu kommt ein sehr menschlicher Engpass: Aufmerksamkeit und kognitive Belastung. Mehr Agents, mehr PRs, mehr Kontextwechsel — das erhöht Tempo, aber auch Ermüdung und das Risiko, Reviews „durchzuwinken“.

Change in Unsicherheit: Champions, Dogfooding und Peer‑Learning

Bei der Frage nach Jobangst und Veränderungsdruck betont David: Ängste sind rational, weil KI Output entwerten kann. Hilfreich sind Sicherheit (wirtschaftliche Stabilität), eine positive Sprache, viel Experimentieren — und vor allem Champions mit „Street Credibility“, die zeigen, wie Tools sinnvoll genutzt werden. Für andere Engineering Leader sind seine Empfehlungen: mit Peers sprechen (Start-ups und Großunternehmen), selbst dogfooding betreiben und interne Multiplikator:innen stärken.

Kernaussagen

Spec‑Qualität wird zum Hebel — Agentic Engineering macht implizites Wissen teuer; klare Specs, Constraints und Akzeptanzkriterien werden zum neuen Bottleneck.
2. Aufwand verschiebt sich — weniger Handarbeit in der Umsetzung, mehr Arbeit in Spezifikation und Review (Human‑in‑the‑Loop).
3. Kontext ist der Schlüssel — große Codebases brauchen zusätzliche Systeme (z.B. MCP + Vektor‑Index), damit Agents zuverlässig arbeiten können.
4. Rollen verschmelzen — Product, UX und Engineering arbeiten näher an der Spezifikation zusammen; Product/Platform‑Engineer‑Profile werden wichtiger.
5. Org‑Engpässe wandern — wenn Tech schneller wird, zählen Entscheidungen, Go‑to‑Market und Aufmerksamkeit mehr als reine Delivery‑Kapazität.

Fazit und Takeaways

Für Engineering- und Produktteams

Spec‑Standards einführen: Intent, Nicht‑Ziele, Constraints, Akzeptanzkriterien und Teststrategie als „Pflichtfelder“.
• Guardrails operationalisieren: Security‑ und Testing‑Standards als Teil des Workflows, nicht als „Nachher‑Check“.
• Kontextsysteme bauen: Dokumentation, Codebase‑Index, Observability‑Tools so anbinden, dass Agents nicht im Dunkeln arbeiten.

Für Führungskräfte & Organisation

Engpässe neu denken: Wenn Umsetzung schneller wird, müssen Discovery, Priorisierung und Go‑to‑Market mithalten.
• Champions statt Ansagen: Multiplikator:innen befähigen, damit Adoption organisch skaliert.
• Aufmerksamkeit schützen: Reviews und kritisches Denken brauchen Fokus — sonst wird Human‑in‑the‑Loop zur Formalität.