Prompt vs. Pipeline – warum ich Agents nicht mehr frei chatten lasse

Datum: 2026-02-01

Der verführerische 200-Zeilen-Prompt

Ein langer Prompt im Chat fühlt sich mächtig an: „Lies das Repo, fix alle Tests, update Briefings, prüf Translations.“ In der Praxis liefert das inkonsistente Halbfertigkeiten – weil nichts die Reihenfolge, die Logs und das Ende erzwingt.

Agentic Engineering verschiebt Wiederholbares von der Prompt-Ebene in Pipelines: versionierte Scripts, Orchestratoren, Step-Services – die KI arbeitet innerhalb der Pipeline, nicht als freier Interpret.

Das Problem

Exploration im Chat ist wertvoll. Produktion will Steps, Logs und Wiederholbarkeit.

Das Pattern: Pipeline statt Prompt

`start-vendor-development-workflow.php` führt feste Steps aus – Logs leeren, Checks, Tests, Zusammenfassung. Nicht „mach mal alles“.

Anatomie einer Pipeline

001. Entry: `start-vendor-*.php` – ein Kommando für Mensch/CI.

002. Orchestrator: Kennt nur die Reihenfolge der Steps.

003. Step-Services: Je eine `execute…`-Methode, ein fachlicher Teil.

004. Agent-Aufruf: Nur wo nötig – innerhalb eines Steps, mit Subagent-Scope.

005. Exit + Logs: Objektives Ende.

Die KI bekommt keine offene Weltaufgabe, sondern: „Führe Step 003 aus Briefing X aus.“

So sieht es bei uns aus

Jeder Step ist ein Service mit PHPDoc und Briefing. Der Orchestrator enthält keine versteckte Business-Logik in If-Ketten – nur Step-Aufrufe.

Wann Prompt, wann Pipeline?

Regel: Wiederholt sich die Aufgabe zum zweiten Mal → Pipeline oder Subagent bauen.

Anti-Patterns

001. Pipeline im Chat nachbauen – „Zuerst A, dann B“ ohne Script → driftet sofort.

002. Orchestrator als God-Class – 2000 Zeilen Logik statt Step-Services.

003. Steps ohne Briefing – KI halluziniert Reihenfolge und Namen.

004. Kein Test-Gate – Pipeline endet ohne PHPUnit/curl.

005. Prompt-Logik in `start-*.php` – Gehört in Orchestrator/Services.

Verzahnung mit Rules und Subagents

Pipelines allein reichen nicht. Rules setzen Grenzen (kein try-catch, Briefing-First). Subagents liefern Spezialisten pro Step. Ralph-Loop macht das Ende messbar.

Pipeline-Step „Translations prüfen“
    → start-vendor-subagent-ralph-loop.php subagent-check-translations
    → OPEN_FAILURES=0

Häufige Fragen

Ist das nicht Overhead für kleine Fixes?

Für einen Tippfehler: ja, Chat reicht. Für alles, was Schichten berührt: Pipeline spart Zeit über die Woche.

Muss jede Pipeline einen Agent haben?

Nein – reine PHPUnit-Steps brauchen keinen LLM-Lauf. Agent nur wo Interpretation nötig ist.

Wie dokumentiere ich neue Pipelines?

Briefing unter `briefing/CLIOrchestrator/`, dann PHP – Briefing-First.

Verwandte Beiträge

Takeaway

Produktion will Steps, Logs und Wiederholbarkeit – nicht Kreativität pro Run. Prompts bleiben für Exploration; alles Wiederholbare gehört in versionierte Pipelines. Wer Agents nicht mehr „frei chatten“ lässt, gewinnt Vorhersagbarkeit – und verliert nur Chaos.

Vertiefung: Prompt vs. Pipeline – warum ich Agents nicht mehr frei chatten lasse im Projektalltag

In unserem Repository ist agentic prompt vs pipeline kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic prompt vs pipeline ernst nimmt, dokumentiert zuerst die Spezifikation, setzt danach Orchestrator, Services und Screens um und schließt mit `curl` sowie PHPUnit ab. Diese Kette verhindert, dass die KI nur im Chat Fortschritt simuliert, während Routing, Translations oder Briefings veraltet bleiben.

Konkret bedeutet das: Jede Änderung an Screens oder CLI-Skripten startet mit dem passenden Briefing unter `briefing/screens/` bzw. `briefing/CLIOrchestrator/`. Subagents wie `subagent-check-screens`, `subagent-check-orchestrator` oder `subagent-check-translations` prüfen Schicht für Schicht. Der Ralph-Loop (`RALPH_LOOP_CHANGED_FILES`, `RALPH_LOOP_CHANGED_FILE_LIST`) macht Konvergenz maschinenlesbar – rot bleibt rot, bis der Ist-Stand dem Briefing entspricht.

Entscheidungshilfe: Wann welcher Hebel?

Architektur- und Review-Perspektive (Teil 2)

Teams, die agentic prompt vs pipeline produktiv nutzen, behandeln Agent-Output wie menschlichen Code: Pull Request, Diff-Review, PHPUnit, curl. In PHP-Projekten mit strikter Schichtung (Screen → Orchestrator → ScreenServices → Repositories) darf die KI keine Abkürzungen einbauen – weder direkte Repository-Aufrufe im Screen noch Legacy-Ordner `src/Orchestrator/` ohne Freigabe in `briefing.md`. `@skill-screen-php-layer` und `@skill-orchestrators` definieren diese Grenzen; Subagents setzen sie durch.

Betrieb, Logs und Nachvollziehbarkeit (Teil 3)

Agentic Engineering ohne Logs ist Blindflug. CLI-Workflows schreiben strukturierte Terminal-Ausgabe gemäß `006-cli-console-colors.mdc`; Live-SQL unter `logs-live-sql/` dokumentiert UI-Bezug pro Query. Bei Blogposts und Screens gilt: Nach jeder Template- oder PHP-Änderung `curl http://localhost:{PORT}/blog/agentic-prompt-vs-pipeline` bis HTTP 200. Fehler-HTML analysieren, beheben, erneut prüfen – Regel 051 in `001-ki-behavior.mdc`.

Praxis-Checkliste vor Freigabe

001. Markdown unter `briefing/blog/blogposts/2026-02-01-agentic-prompt-vs-pipeline/` vollständig und mit mindestens einer Tabelle gepflegt.

002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-02-01-agentic-prompt-vs-pipeline/` vorhanden.

003. Route `/blog/agentic-prompt-vs-pipeline` in `config/routing/routes-project-config.php` eingetragen.

004. Translation-Dateien unter `translation/de/blog/` und `translation/en/blog/` mit passender `seo_description`.

005. Homescreen listet den Beitrag über `ScreenHome001BuildHomeScreenResponseService` automatisch.

006. `curl http://localhost:{PORT}/blog/agentic-prompt-vs-pipeline` liefert HTTP 200.

Erweiterte FAQ und Takeaway (Teil 4)

Wie vermeide ich stille Fallbacks?

Regelwerk `020-no-fallbacks-no-defaults.mdc` und Skill `@skill-no-fallbacks-no-defaults`: fehlende Pflichtwerte müssen sichtbar werden, nicht mit `??` oder erfundenen Defaults gefüllt werden.

Was ist mit Vendor-only-Code?

Host-Duplikate sind verboten; `subagent-check-vendor-duplicates` und `@skill-vendor-only-files` sichern, dass Logik im Vendor bleibt, wenn sie dort bereits existiert.

Wie halte ich Translations synchron?

Nach DE-Änderungen sofort EN (und weitere Sprachen) nachziehen; `@skill-translations` und `subagent-check-translations` prüfen Keys und Twig-Pfade.

agentic prompt vs pipeline skaliert nur mit versionierter Steuerung: Rules setzen Grenzen, Skills liefern Verfahren, Subagents führen aus. Wer jeden Schritt mit Briefing, curl und PHPUnit belegt, ersetzt Chat-Hoffnung durch deploybare Qualität. Der Beitrag `/blog/agentic-prompt-vs-pipeline` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.

Vertiefung (Teil 5): Prompt vs. Pipeline – warum ich Agents nicht mehr frei chatten lasse im Projektalltag

In unserem Repository ist agentic prompt vs pipeline kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic prompt vs pipeline ernst nimmt, dokumentiert zuerst die Spezifikation, setzt danach Orchestrator, Services und Screens um und schließt mit `curl` sowie PHPUnit ab. Diese Kette verhindert, dass die KI nur im Chat Fortschritt simuliert, während Routing, Translations oder Briefings veraltet bleiben.

Konkret bedeutet das: Jede Änderung an Screens oder CLI-Skripten startet mit dem passenden Briefing unter `briefing/screens/` bzw. `briefing/CLIOrchestrator/`. Subagents wie `subagent-check-screens`, `subagent-check-orchestrator` oder `subagent-check-translations` prüfen Schicht für Schicht. Der Ralph-Loop (`RALPH_LOOP_CHANGED_FILES`, `RALPH_LOOP_CHANGED_FILE_LIST`) macht Konvergenz maschinenlesbar – rot bleibt rot, bis der Ist-Stand dem Briefing entspricht.

Entscheidungshilfe: Wann welcher Hebel?

Architektur- und Review-Perspektive (Teil 6)

Teams, die agentic prompt vs pipeline produktiv nutzen, behandeln Agent-Output wie menschlichen Code: Pull Request, Diff-Review, PHPUnit, curl. In PHP-Projekten mit strikter Schichtung (Screen → Orchestrator → ScreenServices → Repositories) darf die KI keine Abkürzungen einbauen – weder direkte Repository-Aufrufe im Screen noch Legacy-Ordner `src/Orchestrator/` ohne Freigabe in `briefing.md`. `@skill-screen-php-layer` und `@skill-orchestrators` definieren diese Grenzen; Subagents setzen sie durch.

Betrieb, Logs und Nachvollziehbarkeit (Teil 7)

Agentic Engineering ohne Logs ist Blindflug. CLI-Workflows schreiben strukturierte Terminal-Ausgabe gemäß `006-cli-console-colors.mdc`; Live-SQL unter `logs-live-sql/` dokumentiert UI-Bezug pro Query. Bei Blogposts und Screens gilt: Nach jeder Template- oder PHP-Änderung `curl http://localhost:{PORT}/blog/agentic-prompt-vs-pipeline` bis HTTP 200. Fehler-HTML analysieren, beheben, erneut prüfen – Regel 051 in `001-ki-behavior.mdc`.

Praxis-Checkliste vor Freigabe

001. Markdown unter `briefing/blog/blogposts/2026-02-01-agentic-prompt-vs-pipeline/` vollständig und mit mindestens einer Tabelle gepflegt.

002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-02-01-agentic-prompt-vs-pipeline/` vorhanden.

003. Route `/blog/agentic-prompt-vs-pipeline` in `config/routing/routes-project-config.php` eingetragen.

004. Translation-Dateien unter `translation/de/blog/` und `translation/en/blog/` mit passender `seo_description`.

005. Homescreen listet den Beitrag über `ScreenHome001BuildHomeScreenResponseService` automatisch.

006. `curl http://localhost:{PORT}/blog/agentic-prompt-vs-pipeline` liefert HTTP 200.

Erweiterte FAQ und Takeaway (Teil 8)

Wie vermeide ich stille Fallbacks?

Regelwerk `020-no-fallbacks-no-defaults.mdc` und Skill `@skill-no-fallbacks-no-defaults`: fehlende Pflichtwerte müssen sichtbar werden, nicht mit `??` oder erfundenen Defaults gefüllt werden.

Was ist mit Vendor-only-Code?

Host-Duplikate sind verboten; `subagent-check-vendor-duplicates` und `@skill-vendor-only-files` sichern, dass Logik im Vendor bleibt, wenn sie dort bereits existiert.

Wie halte ich Translations synchron?

Nach DE-Änderungen sofort EN (und weitere Sprachen) nachziehen; `@skill-translations` und `subagent-check-translations` prüfen Keys und Twig-Pfade.

agentic prompt vs pipeline skaliert nur mit versionierter Steuerung: Rules setzen Grenzen, Skills liefern Verfahren, Subagents führen aus. Wer jeden Schritt mit Briefing, curl und PHPUnit belegt, ersetzt Chat-Hoffnung durch deploybare Qualität. Der Beitrag `/blog/agentic-prompt-vs-pipeline` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.

Vertiefung: Prompt vs. Pipeline – warum ich Agents nicht mehr frei chatten lasse im Projektalltag

In unserem Repository ist agentic prompt vs pipeline kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic prompt vs pipeline ernst nimmt, dokumentiert zuerst die Spezifikation, setzt danach Orchestrator, Services und Screens um und schließt mit `curl` sowie PHPUnit ab. Diese Kette verhindert, dass die KI nur im Chat Fortschritt simuliert, während Routing, Translations oder Briefings veraltet bleiben.

Konkret bedeutet das: Jede Änderung an Screens oder CLI-Skripten startet mit dem passenden Briefing unter `briefing/screens/` bzw. `briefing/CLIOrchestrator/`. Subagents wie `subagent-check-screens`, `subagent-check-orchestrator` oder `subagent-check-translations` prüfen Schicht für Schicht. Der Ralph-Loop (`RALPH_LOOP_CHANGED_FILES`, `RALPH_LOOP_CHANGED_FILE_LIST`) macht Konvergenz maschinenlesbar – rot bleibt rot, bis der Ist-Stand dem Briefing entspricht.

Entscheidungshilfe: Wann welcher Hebel?

Architektur- und Review-Perspektive (Teil 2)

Teams, die agentic prompt vs pipeline produktiv nutzen, behandeln Agent-Output wie menschlichen Code: Pull Request, Diff-Review, PHPUnit, curl. In PHP-Projekten mit strikter Schichtung (Screen → Orchestrator → ScreenServices → Repositories) darf die KI keine Abkürzungen einbauen – weder direkte Repository-Aufrufe im Screen noch Legacy-Ordner `src/Orchestrator/` ohne Freigabe in `briefing.md`. `@skill-screen-php-layer` und `@skill-orchestrators` definieren diese Grenzen; Subagents setzen sie durch.

Betrieb, Logs und Nachvollziehbarkeit (Teil 3)

Agentic Engineering ohne Logs ist Blindflug. CLI-Workflows schreiben strukturierte Terminal-Ausgabe gemäß `006-cli-console-colors.mdc`; Live-SQL unter `logs-live-sql/` dokumentiert UI-Bezug pro Query. Bei Blogposts und Screens gilt: Nach jeder Template- oder PHP-Änderung `curl http://localhost:{PORT}/blog/agentic-prompt-vs-pipeline` bis HTTP 200. Fehler-HTML analysieren, beheben, erneut prüfen – Regel 051 in `001-ki-behavior.mdc`.

Praxis-Checkliste vor Freigabe

001. Markdown unter `briefing/blog/blogposts/2026-02-01-agentic-prompt-vs-pipeline/` vollständig und mit mindestens einer Tabelle gepflegt.

002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-02-01-agentic-prompt-vs-pipeline/` vorhanden.

003. Route `/blog/agentic-prompt-vs-pipeline` in `config/routing/routes-project-config.php` eingetragen.

004. Translation-Dateien unter `translation/de/blog/` und `translation/en/blog/` mit passender `seo_description`.

005. Homescreen listet den Beitrag über `ScreenHome001BuildHomeScreenResponseService` automatisch.

006. `curl http://localhost:{PORT}/blog/agentic-prompt-vs-pipeline` liefert HTTP 200.

Erweiterte FAQ und Takeaway (Teil 4)

Wie vermeide ich stille Fallbacks?

Regelwerk `020-no-fallbacks-no-defaults.mdc` und Skill `@skill-no-fallbacks-no-defaults`: fehlende Pflichtwerte müssen sichtbar werden, nicht mit `??` oder erfundenen Defaults gefüllt werden.

Was ist mit Vendor-only-Code?

Host-Duplikate sind verboten; `subagent-check-vendor-duplicates` und `@skill-vendor-only-files` sichern, dass Logik im Vendor bleibt, wenn sie dort bereits existiert.

Wie halte ich Translations synchron?

Nach DE-Änderungen sofort EN (und weitere Sprachen) nachziehen; `@skill-translations` und `subagent-check-translations` prüfen Keys und Twig-Pfade.

agentic prompt vs pipeline skaliert nur mit versionierter Steuerung: Rules setzen Grenzen, Skills liefern Verfahren, Subagents führen aus. Wer jeden Schritt mit Briefing, curl und PHPUnit belegt, ersetzt Chat-Hoffnung durch deploybare Qualität. Der Beitrag `/blog/agentic-prompt-vs-pipeline` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.

Tooling-Kette und Vendor-Integration (Teil 5)

Unser Stack basiert auf `fabianrossbacher/base-ui-testcase` als Vendor: Routing über `VendorRouteConfigLoaderService`, Twig über `VendorTwigService`, Session über `VendorSessionService`. Blogposts nutzen `BlogpostServiceOrchestrator` mit Steps `ScreenBlog001LoadMarkdownSourceService`, `ScreenBlog002PrepareHtmlAndHeroImageService` und `ScreenBlog003FinalizeBlogpostUiModelService`. Hero-Bilder werden aus `htdocs/images/blog/{slug}/` geladen; Markdown und Quell-SVGs liegen unter `briefing/blog/blogposts/{slug}/`.

Änderungen an der Blog-Pipeline folgen Briefing-First: zuerst `briefing/screens/blog/Blogpost.md` und Screen-Service-Briefings, dann PHP unter `src/ScreenOrchestrator/Blog/` und `src/ScreenServices/Blog/`. `@skill-change-provenance` verlangt Änderungsprotokollzeilen in jeder geänderten PHP- und CSS-Datei.