Claude Code als CAP-Pair-Programmer – wo Productivity entsteht und wo nicht

Claude Code im Dev-VDI ist nicht das Tool für „schreib mir die App“, sondern für „lass uns gemeinsam diesen CAP-Service strukturieren“. Wo der Productivity-Hebel real ist (CDS-Schemas, OData-Handler, Tests), wo er Hype ist (Architektur-Entscheidungen) – und wie SFOUR die Trennlinie zieht.

Die Versprechung und die Realität

Seit Anthropic Claude Code Ende 2024 als CLI-Tool für Entwickler verfügbar gemacht hat, fragen Schweizer Mittelständler mit BTP-Stack: „Können wir damit unsere CAP-Services schneller bauen?“ Die kurze Antwort: ja, aber nicht in den Bereichen, in denen die Demo-Videos den Eindruck erwecken.

Diese Einordnung trennt drei Schichten der CAP-Entwicklung und zeigt pro Schicht, wo Claude Code als Pair-Programmer einen messbaren Hebel hat – und wo er Stunden zu sparen verspricht, die er real nicht spart.

mermaid flowchart TD L1[Schicht 1<br/>CDS-Schemas + OData<br/>~25-35 % Zeitersparnis] L2[Schicht 2<br/>Service-Handler + Tests<br/>~15-25 % Zeitersparnis] L3[Schicht 3<br/>Architektur-Entscheidungen<br/>0-5 %, oft trügerisch] L1 --> L2 L2 --> L3 style L1 fill:#bbf7d0,stroke:#15803d style L2 fill:#fed7aa,stroke:#c2410c style L3 fill:#fecaca,stroke:#b91c1c

Schicht 1 – CDS-Schemas und OData-Skelette: echter Hebel

Hier funktioniert Claude Code wirklich. Sie geben ihm das Domain-Modell als Skizze („wir haben BillingItems, SettlementRuns, BillingRequests, mit Beziehungen X, Y, Z“) und bekommen in 5 Minuten ein vollständiges db/schema.cds mit @PersonalData-Annotationen, srv/cat-service.cds mit Read-Only-Projektionen, und package.json mit den richtigen @sap/cds-Dependencies.

Das ist Fleissarbeit, die SAP-Devs sonst zwei Stunden kostet – Claude erledigt es in fünf Minuten plus 20 Minuten Review. ein spürbarer Produktivitätsschub auf dieser Schicht, weil das Resultat in cds compile direkt sichtbar wird.

Schicht 2 – Service-Handler und Tests: bedingter Hebel

Bei srv/cat-service.js mit @sap/cds-Handlern (srv.before('UPDATE', …)) ist der Hebel kleiner, aber präsent. Claude erkennt das Pattern, schlägt die richtigen Hooks vor, generiert Jest-Tests mit cds.test. Aber: er macht hier mehr Fehler – Validierungs-Logik, die er nicht aus dem Kontext hat, fügt er manchmal als „Best Practice“ ein, obwohl Ihre Domäne sie nicht braucht.

Pattern, das sich bewährt hat: erst die Tests von Claude generieren lassen (er kennt die cds.test-Idiome gut), dann den Service-Handler selber schreiben gegen die Tests. Drehung der üblichen TDD-Reihenfolge – funktioniert, weil Tests 90 % korrekt sind, Handler-Code nur 70 %.

Schicht 3 – Architektur-Entscheidungen: kein Hebel, aber gefährlich

Claude beantwortet die Frage „soll ich diese Domain-Logik in den Service-Handler oder in einen separaten CAP-Action packen?“ mit einer plausibel klingenden Antwort. Die Antwort hat aber keinen Bezug zu Ihrer Mandantengrösse, Compliance-Pflicht oder Custom-Code-Erbe. Hier braucht es einen menschlichen Architekten, der den Kontext kennt.

In SFOUR-Reviews haben wir Fälle gesehen, in denen Teams Claude Architektur-Entscheidungen abgenommen haben und drei Monate später bei der Skalierung wieder umbauen mussten. Der Productivity-Gewinn der ersten Wochen war komplett aufgefressen.

SFOUR-Empfehlung – die Trennlinie

Aufgabe Claude Code Mensch
CDS-Schema entwerfen Generieren Reviewen
OData-Skeleton bauen Generieren Reviewen
Jest-Tests schreiben Generieren Reviewen
Service-Handler-Code Vorschlag Schreiben
Architektur-Entscheidung Sparring Entscheiden
Migration-Plan Stichpunkte Strukturieren

Was vor dem Start gehärtet sein muss

Wer eine erste Standortbestimmung will

Eine Standortbestimmung (60 Min) prüft, ob Ihr CAP-Stack reif für AI-gestützte Entwicklung ist und welche der drei Schichten den grössten Hebel hat. Pragmatisch, nicht visionär.

Stand: 2026-05-10

SFOUR Consulting — Übersicht · Kontakt