# Anhang B: Stack-Orientierung für agentisches Coding

Greenfield-Board, 20 Minuten: „Welcher Stack, damit Agents nicht nur schnell, sondern **wartbar** liefern?“ Diese Seite ist die Orientierungstafel — kein Migrationszwang und kein Ersatz für DoD.

These 7 sagt: wählt Sprachen und Frameworks so, dass Coding-Agents dort **zuverlässig hochwertigen, wartbaren Code** liefern — wenn ihr die Wahl habt und Qualität zählt. Dieser Anhang macht die Empfehlung greifbar: kompakte Rankings nach Anwendungsfall, nicht als Hitliste „was Agents am schnellsten ausspucken“, sondern als Orientierung für **Code, den du langfristig tragen kannst**.

**Snapshot August 2026.** Details und Updates: Buch-Repo und [Begleit-Service](https://books.maatini.space/projects/coding-agents-praxis/) (siehe [B.9](#b.9-snapshot-pflege-und-begleitmaterial)).

---

## B.0 Wozu dieser Anhang (und was er nicht ist) {.unnumbered .unlisted}

**Wozu:** Bei freier oder halb-freier Stack-Wahl eine schnelle Einschätzung, welche Kombinationen derzeit besonders gut zu **Agent-Zuverlässigkeit und Wartbarkeit** passen. Weniger Korrekturaufwand, idiomatischere Diffs, greifbarere DoD — ohne Context, Slices und Verify zu ersetzen (Thesen 2–4, 6).

**Was er nicht ist:** kein ewig gültiges Ranking, kein Migrationszwang, kein Modell- oder Vendor-Vergleich, kein Freibrief für „generiere das ganze Produkt in einem Prompt“. Ein schwacher Stack mit harter DoD schlägt oft einen starken Stack ohne Tests. Stack-Wahl senkt Reibung; sie ersetzt keine Engineering-Disziplin.

---

## B.1 Lesen der Rankings — Kriterien {.unnumbered .unlisted}

Die Reihenfolge schätzt den **Erwartungswert** aus Agent-Zuverlässigkeit, langfristiger Wartbarkeit, DoD-Freundlichkeit und Ecosystem-Fit — nicht reine Popularität und nicht reine Agent-Geschwindigkeit.

| Kriterium | Was zählt |
|-----------|-----------|
| **Agent-Zuverlässigkeit** | idiomatische Diffs, weniger Halluzination bei APIs und Standard-Layouts |
| **Wartbarkeit** | Types, Testkultur, Reviewbarkeit, Team-Realität |
| **DoD-Freundlichkeit** | Lint/Test/Build non-interactive, klare Exit-Codes |
| **Ecosystem-Fit** | Standard-Layouts, Docs, Conventions im Repo |

### Methode und Grenzen

Die Rangfolge ist eine **Autoreneinschätzung**, kein Messwert. Grundlage sind drei Quellen: Erfahrung aus Agent-Projekten mit diesen Stacks, die öffentliche Doku der Frameworks (Standard-Layouts, Test-Runner, Lint und Typecheck non-interactive) und die Breite der Trainingsdaten, soweit sie sich an idiomatischen Diffs und sicheren API-Treffern zeigt.

**Gewichtung.** Agent-Zuverlässigkeit und Wartbarkeit zählen je etwa ein Drittel, DoD-Freundlichkeit und Ecosystem-Fit teilen sich das letzte Drittel. Die Gewichte sind eine Setzung des Buchs, keine empirisch ermittelte Größe. Punktzahlen gibt es bewusst keine: Scheingenauigkeit verbessert die Entscheidung nicht. Bei abweichenden Nebenbedingungen (Team, Compliance, Bestandscode) kann eine andere Kombination vorn liegen; die Tabelle bleibt Startpunkt, nicht Urteil.

**Grenzen.** Die Datenbasis ist episodisch, nicht repräsentativ. Verbreitete Stacks sind in Trainingsdaten überrepräsentiert; ein seltenes, im eigenen Repo gut dokumentiertes Framework kann besser abschneiden als sein Rang hier. Die Tabellen bewerten Kombinationen, keine einzelnen Libraries, und sie ersetzen keinen Probe-Slice im eigenen Repo.

Formulierungen wie „aktuell besonders stark“ meinen: *heute* hoher Erwartungswert bei freier Wahl — nicht „immer die beste Wahl“. Erzwungene Stacks: [B.8](#b.8-umgang-mit-schwachen-oder-erzwungenen-stacks).

---

## B.2 Web-Anwendungen (Frontend + Backend) {.unnumbered .unlisted}

Stand: Manuskript-Snapshot **August 2026**, geprüft November 2026 · Methode [B.1](#methode-und-grenzen).

| Rang | Kombination | Kurzprofil |
|------|-------------|------------|
| 1 | **TypeScript + Next.js (React) + Node-Backend** (NestJS, Hono, tRPC o. Ä.) | Sehr hohe Agent-Zuverlässigkeit; ein Sprachraum Frontend/Backend senkt Context-Reibung und Doppel-Idiome. |
| 2 | **Python (FastAPI) + React/Next.js** | Backend extrem agent-stark; Frontend modern und trainingsreich. Grenze: zwei Sprachen → klare Boundaries und getrennte Verify-Pfade. |
| 3 | **TypeScript + React (Vite) + Express/Fastify/Hono** | Flexibel, hohe Agent-Trefferquote; mehr Eigenarbeit bei Architektur/SSR als bei Next. |
| 4 | **Go + React** (oder HTMX/Templates) | Backend: klare, wartbare Services, gute DoD; Agents solide, aber weniger Fullstack-Boilerplate-Masse als bei TS/Python. |
| 5 | **Spring Boot (Java/Kotlin) + React** | Enterprise-tauglich und langfristig tragfähig; Agent-Output oft brauchbar, aber verbose und mit mehr Korrektur als 1–3. |

**Einschätzung:** Für grüne Web-Produkte sind **TS-zentrierte** oder **Python+React**-Stacks derzeit der Sweet Spot aus Agent-Zuverlässigkeit und Wartbarkeit. Reines „welches Framework am schnellsten generiert“ ohne Types und Tests dreht die Wartbarkeit schnell ins Minus.

---

## B.3 AI-native / Agent-lastige Systeme {.unnumbered .unlisted}

Stand: Manuskript-Snapshot **August 2026**, geprüft November 2026 · Methode [B.1](#methode-und-grenzen).

| Rang | Kombination | Kurzprofil |
|------|-------------|------------|
| 1 | **Python (FastAPI/Pydantic) + Typed Tooling + React/Next für UI** | Kern der AI-/Agent-Ökosysteme; Libraries, Eval-Muster und Examples massiv in Trainingsdaten. |
| 2 | **TypeScript (Node) für Harness/UI + Python für ML/Eval** | Starke DevX für Tools, Integrationen und Frontends; Python behält Daten- und Modell-Pfad. |
| 3 | **Full-TypeScript** (wenig ML, viel Product/Orchestration) | Eine Sprache, gute Wartbarkeit; schwächer, sobald schwere Data-/ML-Libs nötig sind. |
| 4 | **Python-only** (CLI/Service ohne reiches UI) | Sehr agent-stark für Pipelines, Workers, Eval; Product-UI oft dünner. |

**Einschätzung:** Sobald Modelle, Evals und Data-Path dominieren, gewinnt **Python im Kern**. Product-UI und Harness-Logik dürfen TypeScript sein — solange Ownership und DoD über die Sprachgrenze klar sind. Exotische Agent-Frameworks ohne Repo-Konventionen erzeugen mehr Context-Schuld als Speed.

---

## B.4 Enterprise-Anwendungen {.unnumbered .unlisted}

Stand: Manuskript-Snapshot **August 2026**, geprüft November 2026 · Methode [B.1](#methode-und-grenzen).

| Rang | Kombination | Kurzprofil |
|------|-------------|------------|
| 1 | **Spring Boot (Java oder Kotlin) + React** | Solide Enterprise-Defaults, starke Typisierung/Tests möglich; Agents liefern brauchbare, oft wortreiche Diffs. |
| 2 | **.NET (C#) + React** (oder Blazor, wo Team-fit) | Hohe Wartbarkeit, gute Tooling-DoD; Agent-Zuverlässigkeit hoch im Mainstream-.NET, schwächer bei Nischen-Libs. |
| 3 | **NestJS/TypeScript + React/Next** | Moderne Enterprise-APIs mit oft besserer Agent-Trefferquote als klassisches Java — Governance und Modulgrenzen extra absichern. |
| 4 | **Spring Boot + Angular** | In vielen Konzernen Standard und langfristig wartbar *mit Disziplin*; relativ **agentschwächer** (Boilerplate, DI-Patterns, weniger idiomatische Agent-Defaults) → mehr Alignment, engere Slices, strengeres Review. |
| 5 | **Kotlin Multiplatform / spezielle ESB-Stacks** | Nur bei klarem Bedarf; Agent-Nacharbeit und Context-Kosten steigen spürbar. |

**Einschätzung:** Enterprise wählt oft **nicht** den agent-stärksten Stack — das ist legitim. Dann greift These 7 invers: **mehr Docs im Repo, engere Slices, härtere DoD**, nicht „bessere Prompts“. Angular+Spring darf bleiben; plant mehr menschliche Korrektur und engere Verify-Gates als bei React+TypeScript.

---

## B.5 CLI-Tools und interne Developer-Tools {.unnumbered .unlisted}

Stand: Manuskript-Snapshot **August 2026**, geprüft November 2026 · Methode [B.1](#methode-und-grenzen).

| Rang | Kombination | Kurzprofil |
|------|-------------|------------|
| 1 | **Go** | Ein Binary, klare Fehlerbehandlung, hohe Wartbarkeit für CLIs; Agents erzeugen bei Standard-Libs zuverlässig idiomatischen Code. |
| 2 | **TypeScript (Node)** + Commander/Citty o. Ä. | Schnell, hohe Agent-Zuverlässigkeit; Runtime und Packaging im Blick behalten. |
| 3 | **Python** (Typer/Click + uv/ruff) | Sehr agent-stark für interne Tools und Glue; Umgebung bewusst machen ([Kap. 15.8](kapitel-15-praktisches-setup-und-tooling.md)). |
| 4 | **Rust** | Exzellente langfristige Robustheit; Agent-Output oft gut bei Standard-Crates, mehr Korrektur bei Ownership/async und langsamerer Iteration. |

**Einschätzung:** Interne Tools leben von **schnellem Verify** (Unit + Smoke-CLI). Go und TypeScript gewinnen oft das Gesamtpaket Agent+Wartbarkeit; Python gewinnt, wenn Team und Domain schon Python sind. Rust lohnt, wenn Korrektheit und Performance die Nacharbeit rechtfertigen.

---

## B.6 Data Engineering / Pipelines {.unnumbered .unlisted}

Stand: Manuskript-Snapshot **August 2026**, geprüft November 2026 · Methode [B.1](#methode-und-grenzen).

| Rang | Kombination | Kurzprofil |
|------|-------------|------------|
| 1 | **Python + dbt (SQL) + Orchestrator** (Airflow/Prefect/Dagster o. Ä.) | Hohe Agent-Trefferquote im Data-Alltag; SQL und Python sind trainingsreich und reviewbar. |
| 2 | **Python (Polars/Pandas) + klare Package-Struktur** | Stark für Transformationen und Jobs; ohne Tests und Contracts rutscht Wartbarkeit schnell. |
| 3 | **Spark mit PySpark** (statt primär Scala), wo Scale es verlangt | PySpark ist agent-freundlicher als reines Scala-Spark; Cluster-Komplexität bleibt menschlich. |
| 4 | **SQL-first + dbt**, Python nur an den Rändern | Sehr wartbar und DoD-fähig (`compile`/`test`); Agents gut bei SQL, schwächer bei exotischem Warehouse-Dialekt ohne Docs. |

**Einschätzung:** Data-Stacks scheitern mit Agents selten an „falscher Sprache“, sondern an **fehlenden Contracts, fehlenden Tests und Riesen-Notebooks im Context**. Python+SQL mit kleinen, prüfbaren Jobs schlägt „ein monströses Notebook refactoren“.

**Nachtrag November 2026.** dbt ist im September 2026 als **dbt v2.0** allgemein verfügbar geworden: eine Rust-Engine mit SQL-Verständnis, die Fehler und Downstream-Wirkung prüft, bevor der Lauf ins Warehouse geht. Für agentisch erzeugtes SQL ist das ein direkter Verify-Gewinn. Die Apache-2.0-Teilmenge heißt **dbt OSS**; dbt v1 bleibt unterstützt. Apache Airflow 2 hat im April 2026 das Support-Ende erreicht — neue Pipelines starten auf Airflow 3.

---

## B.7 Fullstack-TypeScript-lastige Produkte {.unnumbered .unlisted}

B.2 bewertet Web-Anwendungen über alle Backend-Sprachen; B.7 schneidet daraus die Variante ohne separate API-Schicht heraus — Server Actions oder tRPC im selben Repo, Schema und UI in einem Sprachraum. Die Überschneidung bei Next.js ist gewollt.

Stand: Manuskript-Snapshot **August 2026**, geprüft November 2026 · Methode [B.1](#methode-und-grenzen).

| Rang | Kombination | Kurzprofil |
|------|-------------|------------|
| 1 | **Next.js + tRPC/Server Actions + Drizzle/Prisma** | Derzeit besonders stark für Product-Teams: ein Repo, hohe Agent-Zuverlässigkeit, kurze Slices Frontend↔API. |
| 2 | **Next.js + separate Nest/Hono-API** (Monorepo) | Klarere Boundaries und Skalierung; etwas mehr Alignment als „alles in Next“. |
| 3 | **React Router (Framework Mode) + Node-API** | Solide, agent-stark im React-Ökosystem; etwas weniger Boilerplate-Masse in Trainingsdaten als Next. |
| 4 | **Remix 3 (ohne React)** | Remix 3.0 (ohne React), stabil seit Oktober 2026; UI-Runtime `remix/component`. Die React-Gewohnheiten aus Remix 2 tragen hier nicht. |
| 5 | **RedwoodSDK (Fullstack-Kit)** | Server-first React auf Cloudflare, ohne Code-Gen; nur wenn das Team die Plattform wirklich trägt. |

**Einschätzung:** Full-TypeScript ist 2026 einer der **stärksten Default-Züge**, wenn Product-Speed und Agent-Unterstützung zählen. Wartbarkeit hängt an Types, Schema-Migrationen und Verify — nicht am App-Router-Hype allein.

**Nachtrag November 2026.** **TanStack Start 1.0** (13. Oktober 2026) und **SvelteKit 3** (1. Oktober 2026) sind stabil und erweitern das Fullstack-TypeScript-Feld. In der Tabelle stehen sie noch nicht: Für die Einordnung zählen idiomatische Beispiele im Repo und in den Trainingsdaten. Der nächste Snapshot prüft beide.

---

## B.8 Umgang mit „schwachen“ oder erzwungenen Stacks {.unnumbered .unlisted}

Wenn der Stack fest ist (Legacy, Compliance, Einkauf):

1. **Nicht** den Stack im Chat „wegprompten“ — Boundaries und Idiome dokumentieren (`AGENTS.md`, ADRs).  
2. Slices enger, DoD härter, mehr Golden Paths im Repo.  
3. **In-distribution Patterns** innerhalb des Stacks bevorzugen (Standard-Module statt Hausgebrau).  
4. Budget für Review und Teach-back einplanen — das ist der echte Preis von These 7.

Exoten bleiben legitim. Sie kosten Alignment, Docs und Verify — nicht „etwas mehr Prompt“.

Für Angular + Spring Boot (Quarkus als zweites Backend) vertieft das Companion [*Agents mit Angular, Spring Boot & Quarkus*](https://books.maatini.space/projects/agents-angular-spring-quarkus/) genau diese Hebel — These 7 invers. Die Prinzipien bleiben in diesem Buch.

---

## B.9 Snapshot, Pflege und Begleitmaterial {.unnumbered .unlisted}

**Stand:** Manuskript-Snapshot August 2026, geprüft November 2026. Sprachen-, Framework- und Agent-Fähigkeiten verschieben sich mit neuen Modellen und Trainingsdaten. Diese Rankings sind eine **praxisnahe Orientierung**, kein ewig gültiges Urteil und kein Ersatz für eure Nebenbedingungen (Team, Compliance, Bestandscode).

**Aktualisierung:** Die gepflegte Fassung liegt im **Buch-Repository** dieses Buchs (`manuskript/kapitel-24-anhang-b-stack-orientierung.md`) und im **Begleit-Service** (<https://books.maatini.space/projects/coding-agents-praxis/>; *Stand & Drift*, *Material*, Errata). Weicht der Druck vom Online-Stand ab, gilt für Stack-Empfehlungen die neuere Repo-/Online-Fassung. Feedback: coding-agents@maatini.space.

Vertiefung Setup und These 7: [Kapitel 15](kapitel-15-praktisches-setup-und-tooling.md) · Navigation: `00-inhaltsverzeichnis.md`