Die Rolle hat noch keinen Namen. Das leistet sie.
Für den Ingenieur, der KI-Agenten orchestriert, statt Code zu schreiben, gibt es noch keine allgemein anerkannte Berufsbezeichnung. Was diese Rolle tatsächlich leistet – und die Stellenbeschreibung, die wir dafür von Grund auf neu geschrieben haben.
März 2026
In meinem letzten Beitrag habe ich dargelegt, dass SDD den Wert eines Ingenieurs von der Tiefe des Technologiewissens hin zu architektonischem Denken und der Qualität von Spezifikationen verschiebt. Mehrere Leser stellten daraufhin dieselbe Frage: Wie nennt man diese Person eigentlich?
Darüber herrscht keine Einigkeit. „Prompt Engineer“ greift zu kurz – es geht nicht darum, geschickte Prompts zu formulieren. „AI-Augmented Developer“ klingt wie eine Produktfunktion. „Tech Lead“ kommt der Sache am nächsten, lässt aber die operative Ebene außer Acht. Bei NOSOTA haben wir uns für AI Orchestration Engineer entschieden – jemand, der ein virtuelles Entwicklerteam leitet, dessen ausführende Mitglieder KI-Agenten sind.
Die Bezeichnung wird sich weiterentwickeln. Die Aufgaben nicht.
Das leistet diese Rolle tatsächlich: Sie befragt die Beteiligten und macht aus mehrdeutigen Anforderungen präzise, eindeutige Spezifikationen. Sie zerlegt Funktionen in abgegrenzte Aufgaben mit ausdrücklich festgelegten Kontextgrenzen. Sie orchestriert Claude-Code-Agenten über parallele Arbeitsstränge hinweg, prüft deren Ergebnisse an der architektonischen Absicht und erkennt, was technisch korrekt, aber konzeptionell fehlerhaft ist. Sie pflegt die Architekturentscheidungen (ADRs). Sie trägt die Verantwortung für die Qualität.
Was sie nicht tut: Standardcode schreiben. Framework-APIs auswendig lernen. Sich auf einen einzigen Technologie-Stack spezialisieren.
Das Profil hat mit einer klassischen Stellenbeschreibung für einen erfahrenen Ingenieur nichts gemein. Also haben wir eine von Grund auf neu geschrieben. Hier die Kurzfassung:
AI Orchestration Engineer – NOSOTA · Ortsunabhängig · Vollzeit
Sie denken in Systemen, bevor Sie in Code denken. Sie schreiben Spezifikationen, nicht nur Tickets. Sie haben mit Claude Code, Cursor oder Windsurf bereits etwas Reales ausgeliefert. Sie kennen Clean Architecture und DDD – nicht die Syntax, sondern das Denken dahinter. Sie können aus einem Gespräch mit Beteiligten ein Diagramm der Systemgrenzen ableiten.
Wenn Ihr erster Impuls ist, eine Entwicklungsumgebung zu öffnen, bevor die Spezifikation fertig ist, ist dies nicht die richtige Rolle für Sie. Wenn Ihr erster Impuls ist, noch drei klärende Fragen zu stellen, lesen Sie weiter.
