Vom Software Engineer zum Product Engineer

Was ist ein Product Engineer?

Ein Product Engineer ist ein Entwickler, der KI-Agenten in der eigenen Codebasis orchestriert, statt jede Zeile selbst zu tippen. Er plant die Aufgabe, gibt sie an Agenten ab und prüft jede Ausgabe, bevor sie in euren Code geht. Die Agenten liefern, der Product Engineer entscheidet.

Damit verschiebt sich der Schwerpunkt der Rolle. Ein Software Engineer arbeitet ein Ticket Zeile für Zeile ab. Ein Product Engineer steuert mehrere Pipelines nebeneinander und verantwortet, was am Ende im Repository landet.

Das Fachwissen bleibt dabei dasselbe. Wer eure Architektur, eure Standards und eure Kunden kennt, bringt genau das mit, was einem Agenten fehlt. Neu ist, wie dieses Wissen zu Code wird: über sauber geschnittene Aufgaben, klare Kriterien und ein konsequentes Review.

Was ändert sich im Arbeitsalltag eines Entwicklers?

Im Arbeitsalltag wandert die Zeit vom Tippen zum Planen, Steuern und Prüfen. Am Beispiel eines alltäglichen Sprint-Tickets, etwa eines CSV-Exports für Rechnungen, sieht der Ablauf so aus:

• Der Entwickler schneidet das Ticket in Teile, die ein Agent sauber abarbeiten kann, zum Beispiel Datenmodell, Export und Tests.
• Ein Planner zerlegt die Aufgabe, ein Umsetzer schreibt den Code.
• Quality Gates prüfen Tests, Standards und Sicherheit.
• Der Entwickler liest das Ergebnis im Review und gibt den Merge frei oder schickt die Änderung zurück.

Während ein Agent umsetzt, wartet der Entwickler nicht. Er bereitet das nächste Ticket vor oder prüft eine andere Pipeline, die gerade bereit zum Review ist. Aus einem Ticket am Stück werden mehrere Spuren am Tag.

Ein Beispiel aus unserem eigenen Alltag zeigt, wohin das führen kann. Christian Eichmüller, unser Gründer, hat ein Feature 16 Stunden autonom entwickeln lassen. Seine einzige Arbeit war ein Plan mit 20 Fragen am Anfang. Die eigentliche Leistung steckte im Plan.

Welche Fähigkeiten kommen dazu?

Dazu kommen vier Fähigkeiten: Aufgaben für Agenten schneiden, Agenten steuern, Ausgaben prüfen und wiederkehrende Arbeit automatisieren. Keine davon ersetzt das Handwerk eines Entwicklers. Alle setzen es voraus.

• Tickets schneiden: Aufgaben so zerlegen, dass ein Agent sie verlässlich abarbeitet.
• Agenten steuern: eigene Pipelines erstellen, orchestrieren und steuern, auch mehrere gleichzeitig.
• Prüfen: jede Ausgabe gegen Plan, Standards und Tests lesen, bevor sie in den Code geht.
• Automatisieren: wiederkehrende Arbeit in Automatisierungen überführen, die dauerhaft mitlaufen.

Wie weit ein Entwickler auf diesem Weg ist, beschreibt unser Stufenmodell, eingestuft wird je Entwickler. Das Stufenmodell reicht von L0 (arbeitet ohne KI) bis L4 (Automatisierungen laufen dauerhaft mit). Dazwischen liegen L1 (fragt die KI) und L2 (gibt Aufgaben ab). Auf Level 3 steuert ein Entwickler mehrere Pipelines parallel.

Der eigentliche Rollenwechsel liegt zwischen L2 und L3. Wer einzelne Aufgaben abgibt, nutzt einen Agenten als Werkzeug. Wer mehrere Pipelines parallel steuert und jede Ausgabe prüft, arbeitet anders. Im Team-Programm ist deshalb Level 3 das Ziel für jeden Entwickler.

Was bedeutet „belegter Titel“?

„Belegter Titel“ heißt: Wir vergeben den Titel Product Engineer erst nach einer bestandenen Abschlussprüfung am Ende des Programms. Davor liegen Wochen an euren echten Sprint-Tickets, in eurer eigenen Codebasis.

Wichtig ist die Einordnung. Product Engineer ist ein Titel, den MakeNative vergibt. Er ist kein staatlich anerkannter Abschluss und keine Berufsausbildung. Er beschreibt die Arbeitsweise, die ein Entwickler im Programm gezeigt hat, und verspricht nichts darüber hinaus.

Wer den Titel erhält, hängt vom Paket ab:

• Team-Programm: Abschlussprüfung für jeden Entwickler, Titel bei bestandener Prüfung.
• Multiplikatoren-Programm: 1–2 eurer Entwickler werden Trainer und geben die Arbeitsweise ins Team weiter. Abschlussprüfung für die Trainer, Titel bei bestandener Prüfung.
• Pilotprojekt: kein Titel, denn das Pilotprojekt ist der Beweis, nicht die Ausbildung.

Neben dem Titel steht die Vorher-Nachher-Messung je Entwickler in Woche 4. Der Titel gilt dem Einzelnen, der Bericht an die Geschäftsführung dem Team.

Wie sieht der Weg in vier Wochen aus?

Im Team-Programm führt der Weg in vier Wochen vom eingerichteten Arbeitsplatz bis zur Abschlussprüfung. Euer Aufwand liegt bei 6–8 Stunden Freistellung pro Entwickler und Woche, trainiert wird an Tickets, die ohnehin anstehen.

• Woche 1: Wir richten die Agenten in eurer Codebasis ein, mit euren Standards und eurer Architektur. Die ersten Tickets laufen mit Planner und Umsetzer.
• Woche 2: In Live-Sessions lernt das Team, Tickets für Agenten zu schneiden und Ergebnisse im Review als Product Engineer zu prüfen.
• Woche 3: Eure Entwickler orchestrieren mehrere Agenten gleichzeitig, erst zwei, dann drei Pipelines, und bauen die ersten Automatisierungen selbst.
• Woche 4: Abschlussprüfung zum belegten Titel, Vorher-Nachher-Messung je Entwickler und Übergabe an zwei interne Owner.

An Tag 10 wird gemessen und nachjustiert. Was bis dahin nicht funktioniert, wird in Woche 3 geändert. Ziel der dritten Woche sind 3–5 Pipelines pro Tag und Entwickler, die parallel laufen.

Der Rollenwechsel passiert also nicht in einem Seminar. Er passiert im laufenden Sprint, Ticket für Ticket, mit uns als Sparringspartner. Fragen werden am echten Ticket geklärt, auch zwischen den Terminen.

Was ändert sich für Team und Tech Lead?

Für Team und Tech Lead ändert sich vor allem, wie Arbeit verteilt und abgesichert wird. Die Verantwortung bleibt bei euren Leuten, weil jede Ausgabe im Review landet. Ein Entwickler prüft, bevor etwas in euren Code geht.

Auch der Tech Lead kann Tickets danach so schneiden, dass Agenten sie verlässlich abarbeiten. Damit wird das Schneiden von Aufgaben zu einer Kernaufgabe im Team, nicht zu einer Nebensache vor dem Sprint. Gleichzeitig gilt: Nicht jede Aufgabe braucht einen Agenten. Ein Product Engineer entscheidet auch, wann er selbst schreibt.

Damit die Arbeitsweise bleibt, wenn wir gehen, übernehmen zwei eurer Entwickler die Zuständigkeit als interne Owner:

• Owner 1: Pipelines und Templates.
• Owner 2: Automatisierungen.
• Dazu Unterlagen fürs Team und eine schriftliche Übergabe der Zuständigkeit.

So trägt das Team die Arbeitsweise selbst und hängt nicht an einer einzelnen Person. Im Team- und Multiplikatoren-Programm bleiben Templates, Dashboard und Evaluationstool dauerhaft bei euch, und eure Entwickler können neue Automatisierungen selbst bauen.

Bleibt die Frage, ob eure Entwickler mitziehen. Eure Entwickler bekommen den Arbeitsplatz eingerichtet und eine kurze Einführung, dann können sie starten. Trainiert wird an Tickets, die ohnehin anstehen.

So gehen wir mit den Daten um: Einstufung je Entwickler, Abschlussprüfung und Titel gehen zuerst an den Entwickler, berichtet wird als Teamdurchschnitt, die Ergebnisse werden nie für Personalentscheidungen verwendet, und die Einbindung des Betriebsrats liegt bei euch.

Wo steht euer Team heute?

Wo euer Team heute steht, zeigt die kostenlose Analysewoche. Wir stufen jeden Entwickler auf der Skala L0 bis L4 ein, und zwar bevor das Programm beginnt.

Euer Aufwand dafür ist ein Kickoff und ein Lesezugriff, verändert wird in der Analysewoche nichts. Am Ende steht ein Ergebnisdokument, das euch gehört, unabhängig davon, wie ihr euch entscheidet. Danach folgt kein Pitch und kein Preis-Gespräch.

Das Programm ist ideal für Teams mit 3–15 Entwicklern, mit eigener Codebasis und Git im Einsatz. Wenn das auf euch zutrifft, ist das Erstgespräch der erste Schritt zum Product Engineer in eurem Team.