Zum Hauptinhalt springenZur Navigation springenZur Fußzeile springen
    Strategie

    Vollautonomie statt Autocomplete: Der Wandel zu Agentic Engineering

    Kurz erklärt

    Von Codevorschlägen zu parallelen Sub-Agenten: was sich technisch geändert hat, warum „mehr Agenten" nichts löst und wie Teams Abläufe für Delegation umbauen — inklusive Rechten, Abnahme und Kostendeckel.

    18. September 2026Aktualisiert am 18. September 20264 min LesezeitNick Meyer
    Teilen:
    Vollautonomie statt Autocomplete: Der Wandel zu Agentic Engineering

    Inhaltsverzeichnis

    Die erste Welle von KI im Entwicklungsalltag war Autocomplete: ein Vorschlag pro Zeile, ein Chatfenster daneben, der Mensch im Zentrum jeder Tastenbewegung. Die zweite Welle sieht anders aus. Ein Auftrag geht rein, mehrere Agenten arbeiten parallel, ein Ergebnis kommt zur Prüfung zurück. Aus Assistenz wird Ausführung.

    Dieser Sprung ist kein Werkzeugwechsel, sondern eine Änderung der Arbeitsteilung. Wer ihn nur als schnelleres Tippen behandelt, gewinnt wenig. Wer Abläufe darauf zuschneidet, verändert Durchlaufzeiten spürbar – und verschiebt dabei die Stelle, an der Verantwortung entsteht.


    1) Was sich technisch tatsächlich geändert hat

    Drei Fähigkeiten machen den Unterschied zwischen Vorschlag und Ausführung:

    • Werkzeugzugriff: Agenten lesen Dateien, führen Tests aus, starten Builds und lesen deren Ausgabe. Damit können sie iterieren, statt einmalig zu raten.
    • Zerlegung: Ein führender Agent schneidet eine Aufgabe in Teilaufträge und vergibt sie an spezialisierte Sub-Agenten – jeder mit eigenem, kleinem Kontext.
    • Parallelität: Unabhängige Teilaufträge laufen gleichzeitig. Die Wartezeit sinkt nicht, weil das Modell schneller denkt, sondern weil mehrere Stränge nebeneinander laufen.

    Der Begriff dafür ist Agent Harness: die Orchestrierungsschicht, die zerlegt, startet, überwacht, begrenzt und zusammenführt. Mehr dazu im Glossar: Sub-Agenten & Agent Harnesses.


    2) Warum „mehr Agenten" allein nichts löst

    Die häufigste Enttäuschung entsteht, wenn ein Team ein Harness auf einen Ablauf wirft, der nie für Delegation gebaut war. Typische Blocker:

    • Unklare Aufgabenschnitte. Wo Teilaufgaben überlappen, schreiben zwei Agenten dieselbe Datei – und ein Ergebnis überschreibt still das andere.
    • Fehlende Abnahmekriterien. Ohne Tests oder messbare Ziele kann niemand sagen, ob ein Teilergebnis fertig ist. Der Mensch wird zum Dauerprüfer.
    • Rechte nach Gewohnheit. Agenten erhalten Zugänge, die für Menschen gedacht waren. Damit ist jeder Fehlgriff potenziell ein Datenvorfall.
    • Kosten ohne Deckel. Zwanzig parallele Sub-Agenten sind schnell teurer als ein sorgfältig geführter Einzelagent, wenn niemand Budget pro Teilauftrag setzt.

    3) Workflows für Delegation umbauen: vier Bausteine

    A) Aufgaben in prüfbare Einheiten schneiden

    Eine delegierbare Teilaufgabe hat drei Eigenschaften: klare Eingabe, klares Ergebnis, eigene Prüfung. Praktisch heißt das: ein Modul, eine Datei, ein Markt, ein Format – nicht „das Feature".

    B) Abnahme vor Ausführung definieren

    Vor dem Start steht die Antwort auf „woran erkennen wir, dass es stimmt?". Tests, Benchmarks, Schema-Prüfungen, Wortlaut-Regeln. Ohne diese Kriterien wird jede Beschleunigung durch Nachprüfen wieder aufgefressen.

    C) Rechte nach minimalem Prinzip

    Leserechte breit, Schreibrechte eng. Vorschläge statt direkter Änderungen in Produktionssystemen. Zugänge zeitlich begrenzt und pro Aufgabe getrennt. Wer das später nachzieht, baut die Kontrolle in eine bereits laufende Automatisierung ein – deutlich teurer.

    D) Protokollierung auf Teilauftragsebene

    Auftrag, Eingaben, Werkzeugaufrufe, Ergebnis, Kosten – je Sub-Agent. Ohne diese Spur ist nach einem Fehler nicht feststellbar, welcher Strang ihn verursacht hat. Mit ihr wird aus Automatisierung ein nachweisbarer Prozess.


    4) Was das für Marketing- und Produktteams heißt

    Der Effekt bleibt nicht in der Entwicklung. Genau die Aufgaben, die sich sauber zerlegen lassen, sind in Marketing-Organisationen Alltag:

    • Lokalisierung über mehrere Märkte, je Markt ein Strang
    • Formatadaption über Kanäle und Seitenverhältnisse
    • Markenkonformitäts-Prüfung über große Asset-Mengen
    • Recherche-Cluster mit je einer Quellengruppe pro Agent

    Der Engpass verschiebt sich damit nach vorne und nach hinten: nach vorne auf klare Briefings, nach hinten auf schnelle, begründete Auswahl unter vielen Varianten – die Fähigkeit, die im Glossar als Differential Evaluation beschrieben ist.


    5) Wo Vollautonomie unangebracht ist

    Autonomie ist eine Einstellung, keine Haltung. Sinnvoll begrenzt wird sie dort, wo Fehler nicht reversibel sind:

    • verbindliche Aussagen gegenüber Kunden (Preise, Zusagen, Fristen)
    • Änderungen an Produktionssystemen und Zahlungswegen
    • Verarbeitung personenbezogener Daten ohne Filterung
    • rechtlich sensible Claims und regulierte Aussagen

    In diesen Fällen bleibt der Mensch im Freigabepfad – nicht als Bremse, sondern als Stelle, die haftet.


    6) Ein realistischer Einstieg in vier Wochen

    1. Woche 1: Einen Ablauf wählen, der wiederkehrt und messbar ist. Basiswert erheben: Durchlaufzeit, Fehlerquote, Kosten.
    2. Woche 2: Aufgabe in drei bis fünf prüfbare Teilaufträge zerlegen. Abnahmekriterien und Rechte schriftlich festlegen.
    3. Woche 3: Harness aufsetzen, parallel laufen lassen, Protokollierung und Kostendeckel aktivieren.
    4. Woche 4: Gegen den Basiswert vergleichen. Entscheiden: ausweiten, nachschärfen oder verwerfen – mit Zahlen, nicht mit Eindruck.

    Fazit

    Der Schritt von Autocomplete zu Agenten-Schwärmen ist weniger eine Frage der Modellqualität als der Ablauforganisation. Wer Aufgaben so schneidet, dass sie delegierbar und prüfbar sind, gewinnt Geschwindigkeit. Wer es nicht tut, bekommt schnellere Unordnung.

    Weiterführend: Warum Architektur-Leitplanken dabei wichtiger werden als Tempo, steht in Vibe Coding vs. Software-Architektur.

    Häufige Fragen

    Worum geht es bei „Vollautonomie statt Autocomplete: Der Wandel zu Agentic Engineering“?

    Von Codevorschlägen zu parallelen Sub-Agenten: was sich technisch geändert hat, warum „mehr Agenten" nichts löst und wie Teams Abläufe für Delegation umbauen — inklusive Rechten, Abnahme und Kostendeckel.

    Was sich technisch tatsächlich geändert hat: Was ist wichtig?

    Drei Fähigkeiten machen den Unterschied zwischen Vorschlag und Ausführung: Werkzeugzugriff: Agenten lesen Dateien, führen Tests aus, starten Builds und lesen deren Ausgabe.

    Warum „mehr Agenten" allein nichts löst: Was ist wichtig?

    Die häufigste Enttäuschung entsteht, wenn ein Team ein Harness auf einen Ablauf wirft, der nie für Delegation gebaut war. Typische Blocker: Unklare Aufgabenschnitte.

    A) Aufgaben in prüfbare Einheiten schneiden: Was ist wichtig?

    Eine delegierbare Teilaufgabe hat drei Eigenschaften: klare Eingabe, klares Ergebnis, eigene Prüfung. Praktisch heißt das: ein Modul, eine Datei, ein Markt, ein Format – nicht „das Feature".