Salesforce-Werkzeuge für KI-Entwicklung im Überblick

Salesforce bietet für KI-gestützte Entwicklung 2026 zwei Wege an: den eigenen Coding-Agenten Agentforce Vibes und dieselben Fähigkeiten als Skills, Plugin und MCP-Server für fremde Agenten wie Claude Code oder Codex. Für einen Hersteller ist die Wahl des Agenten die kleinere Entscheidung. Wichtiger sind drei Dinge darunter: Agentforce DX, das Agentforce-Agenten zu versionierbaren Metadaten macht, Code Analyzer als Prüfer ohne Sprachmodell und die Abrechnung. Vibes ist seit Juni 2026 nur noch in der Developer Edition begrenzt kostenlos und in der EU Operating Zone nicht verfügbar.

Welche KI-Werkzeuge bietet Salesforce für die Entwicklung?

Die Werkzeuge gehören zur Ebene „KI zum Bauen“ aus Kapitel 1, dazu kommt die Admin-KI im Setup. Stand Oktober 2026:

Werkzeug	Wofür	Stand Oktober 2026	Abrechnung
Agentforce Vibes 2.0	Coding-Agent in VS Code	GA seit 12. Juni 2026	Flex Credits oder Unmetered-Lizenz
Agentforce Vibes IDE (früher Code Builder)	VS Code im Browser, aus dem Setup gestartet	in jeder Developer Edition seit April 2026	wie Vibes
Skills-Bibliothek forcedotcom/sf-skills	Salesforce-Wissen für Claude Code, Codex, Cursor und Vibes	Open Source, laut Salesforce über 100 Skills	kostenlos, Modellnutzung separat
Claude-Code-Plugin salesforce-development	rund 40 Skills, drei MCP-Server, Agenten und Hooks	veröffentlicht am 19. August 2026	kostenlos, Claude-Nutzung separat
Agentforce DX (sf agent)	Agentforce-Agenten als Metadaten bauen, testen, ausrollen	GA seit Mai 2025	kein eigener Preis veröffentlicht
Agentforce Builder und Agent Script	Agentforce-Agenten entwerfen	GA seit Spring ’26, seit Juli 2026 einziger Weg für neue Agenten	im Agentforce-Kauf enthalten
Code Analyzer mit ApexGuru	statische Prüfung von Apex, LWC und Flows	acht Engines, Skills für Agenten	kein eigener Preis veröffentlicht
Setup with Agentforce	Admin-Agent auf jeder Setup-Seite	GA seit 26. Mai 2026	Data 360 Credits
Einstein for Flow	Flow-Entwürfe und Formeln aus Text	GA seit Spring ’25	Einstein Requests

Quellen: Vibes GA (öffnet in einem neuen Tab), Vibes IDE (öffnet in einem neuen Tab), Plugin und Skills (öffnet in einem neuen Tab), Agentforce DX (öffnet in einem neuen Tab), Agent Script (öffnet in einem neuen Tab), Code Analyzer Engines (öffnet in einem neuen Tab).

Die Richtung hat sich in einem Jahr gedreht. Im Oktober 2025 startete Vibes als Agent auf Basis des Open-Source-Projekts Cline, GA mit einer begrenzten Zahl an Requests (öffnet in einem neuen Tab). 2026 liefert Salesforce dasselbe Wissen an jeden Agenten aus. Unter dem Namen Headless 360 soll jede wichtige Fähigkeit als API, MCP-Tool oder CLI-Befehl (öffnet in einem neuen Tab) verfügbar sein: über 60 MCP-Tools, über 30 Coding-Skills, über 4.000 APIs und über 220 CLI-Befehle. Jede Aktion läuft als konkreter Benutzer, mit Freigaberegeln, Feldberechtigungen, Validierungsregeln und Governor Limits. Für Sie als Auftraggeber heißt das: Welcher Agent im Team arbeitet, entscheidet nicht darüber, was er in der Org darf.

Ein Hinweis für Angebote von Partnern: „Einstein for Developers“ und „Agentforce for Developers“ sind ältere Namen (öffnet in einem neuen Tab) aus den Jahren 2023 und 2024, damals mit Salesforce-eigenen Modellen. Steht einer davon im Angebot, beschreibt es einen Vorgänger von Vibes.

Agentforce Vibes: was es kann und was es kostet

Vibes 2.0 läuft laut GA-Ankündigung (öffnet in einem neuen Tab) auf Salesforces Coding Agent Platform, „powered by Claude and the Mastra agent orchestration engines“. Laut Claudeforce-Ankündigung (öffnet in einem neuen Tab) vom August 2026 ist Claude das Standardmodell. Die Funktionen, die für einen Auftraggeber zählen:

• Plan Mode: Der Agent zerlegt eine Aufgabe in einen Plan, bevor er Dateien ändert.
• Freigaben: Der Standardmodus „Run safe defaults“ ändert Dateien im Workspace ohne Rückfrage. Pfade außerhalb, geschützte Dateien und Schreibzugriffe auf .git/ brauchen eine Freigabe.
• Sub-Agenten: Ein führender Agent verteilt Arbeit an Sub-Agenten für Apex, LWC, Jest-Tests und SOQL, jeder in einem eigenen Git-Worktree (öffnet in einem neuen Tab).
• MCP: Rechte lassen sich pro Tool verwalten (öffnet in einem neuen Tab), und ein Schalter, der nicht destruktive Schreibzugriffe über Salesforce-MCP-Tools automatisch freigibt, ist standardmäßig aus.
• Regeln und Skills: Projektregeln liegen in .vibes/rules/ (öffnet in einem neuen Tab), früher .a4drules/. Projektregeln schlagen globale Regeln. Eingebaute Regeln wie production-guardrails lassen sich abschalten, aber nicht ändern.

Die Doku sagt nicht, ob Vibes auch CLAUDE.md oder AGENTS.md liest. Claude Code liest laut Anthropic (öffnet in einem neuen Tab) CLAUDE.md oder ein vorhandenes AGENTS.md. Arbeitet Ihr Partner mit Vibes und Ihr eigenes Team mit Claude Code, brauchen Sie die Regeln an zwei Stellen oder eine gemeinsame Quelle. Warum diese Datei in Ihr Repository gehört und wem sie gehört, steht in die KI-Regeldatei im Salesforce-Repository.

Lizenzwege und Grenzen

Lizenzweg	Modelle	Grenze
Unmetered-Lizenz, „Included“	GPT-5	Fair Use laut Vertrag
Unmetered-Lizenz, „Premium“	Claude Sonnet 4.6	2.500 Requests oder 36 Mio. Token pro Org, Reset 30 Tage nach erster Nutzung
Flex Credits	Sonnet 4.6 (Standard), GPT-5, GPT-5.4, Opus 4.5 bis 4.8	nach Verbrauch, in Einheiten zu 2.000 Token, aufgerundet
Developer Edition	Claude Sonnet	110 Requests oder 1,5 Mio. Token pro Org, ein Monat, kein Refresh

Quellen: Vibes Usage and Billing (öffnet in einem neuen Tab), Vibes FAQ (öffnet in einem neuen Tab).

Die Zahl, die ich zuerst prüfen würde: Die Grenze der Unmetered-Lizenz gilt laut FAQ pro Org, nicht pro Nutzer. Ist sie erreicht, arbeitet das Team mit GPT-5 weiter oder zahlt Flex Credits. Opus läuft als „Advanced Prompt“; die Flex Credits Rate Card (öffnet in einem neuen Tab) setzt dafür 16 Credits an, bei 500 € je 100.000 Credits (öffnet in einem neuen Tab) also 0,08 € je angefangene 2.000 Token. Die Unmetered-Lizenz führt die Preisseite von Vibes (öffnet in einem neuen Tab) als Flat Fee zu 125 € pro Nutzer und Monat.

Seit dem 1. Juni 2026 braucht Vibes außerhalb der Developer Edition Flex Credits oder eine bezahlte Lizenz (öffnet in einem neuen Tab). SalesforceBen meldete zur Dreamforce 2026 für Developer Editions wieder 50 Requests oder 1 Mio. Token mit täglichem Reset (öffnet in einem neuen Tab). Die offizielle FAQ nennt weiter 110 Requests für einen Monat ohne Refresh. Ich plane mit der FAQ.

Wer die EU Operating Zone aus Datenschutzgründen gewählt hat, landet bei externen Agenten mit eigenen Datenresidenzfragen. Den Vergleich nach Vertrag, Datenresidenz und Kostenmodell finden Sie in Agentforce Vibes, Claude Code oder Copilot, die externen Agenten selbst in Kapitel 4.

Skills, Plugin und Headless 360: Salesforce-Wissen für fremde Agenten

Die Skills-Bibliothek forcedotcom/sf-skills ist Open Source. Salesforce nennt im Juni 2026 (öffnet in einem neuen Tab) Beispiele wie generating-apex, generating-apex-test, generating-lwc-components, debugging-apex-logs und generating-flow. Installiert wird mit npx skills add forcedotcom/sf-skills. In Vibes ist die Bibliothek vorinstalliert, für OpenCode, Claude Code, Codex und Cursor nennt Salesforce im August 2026 (öffnet in einem neuen Tab) denselben Installationsweg.

Das Claude-Code-Plugin aus derselben Ankündigung bündelt rund 40 dieser Skills, ohne Data 360, Commerce und Mobile. Dazu kommen drei MCP-Server (salesforce-api-context, salesforce-metadata-experts, salesforce-lsp), ein Entwicklungsagent, ein nur lesender Agent architecture-review, der ein Projekt gegen die Säulen des Well-Architected Framework bewertet, und Hooks. Ein Hook prüft die Syntax von Agent-Script-Dateien, ein anderer validiert Deployments. Ein Hook läuft automatisch, ein Satz im Prompt wirkt nur, wenn das Modell ihn beachtet. Deshalb halte ich die Hooks für den wertvollsten Teil.

Salesforce weist selbst darauf hin, dass Plugins herstellerspezifisch sind, Skills und MCP dagegen Standards. Skills sind im Kern Anweisungen und Skripte, die das Modell bei Bedarf lädt. Sie machen einen Agenten besser in Salesforce, erzwingen aber nichts. Durchgesetzt wird über Hooks, Code Analyzer und die Pipeline.

Drei Termine gehören in diesen Teil:

1. Winter '27MCP-Plugin für Claude Code erwartet
2. 02.11.2026End of Life des lokalen Salesforce DX MCP Server
3. Spring '27 · nächster TerminCodex-Plugin, von Salesforce nur angepeilt; dann auch erhoffte Governance für Tools und Skills in Vibes

Das End of Life steht im Hinweis der Maintainer (öffnet in einem neuen Tab); was es für Ihren Partner bedeutet, beschreibt Kapitel 3. Die beiden Plugin-Termine meldet SalesforceBen (öffnet in einem neuen Tab). Behandeln Sie sie als Roadmap, nicht als Zusage. DevOps Center MCP wurde zur TDX 2026 angekündigt (öffnet in einem neuen Tab), ein Verfügbarkeitsdatum fehlt.

Agentforce DX und Agent Script: Agenten als Metadaten

Für einen Hersteller, der einen ersten Agenten für Händleranfragen plant, ist dieser Teil wichtiger als der Coding-Agent. Agentforce DX (öffnet in einem neuen Tab) bringt die Salesforce-DX-Werkzeuge auf Agenten: CLI-Befehle und eine VS-Code-Erweiterung, mit denen Agenten außerhalb von Agentforce Studio entstehen, getestet und ausgerollt werden. Seit Mai 2026 (öffnet in einem neuen Tab) liegt ein Agent als .agent-Datei im Metadatentyp AiAuthoringBundle. Jede veröffentlichte Version erzeugt ein GenAiPlannerBundle, API-Version 66.0 ist Voraussetzung. In der Pipeline sind es drei Schritte:

sf project deploy start --metadata AiAuthoringBundle --target-org uat
sf agent publish authoring-bundle --api-name Haendler_Service --target-org uat
sf agent activate --api-name Haendler_Service --version 2 --target-org uat

Damit geht ein Agent denselben Weg wie Apex: Pull Request, Review, Deployment, Freigabe. Der neue Agentforce Builder ist seit Spring ’26 GA. Seit Juli 2026 entstehen neue Agenten nur noch dort (öffnet in einem neuen Tab), der alte Builder ist eingefroren, ein Abschaltdatum fehlt, und ein Umstieg bedeutet Neubau. Agent Script ist seit der TDX 2026 Open Source (öffnet in einem neuen Tab). Die Sprache trennt Logik, die als Code läuft, von Anweisungen an das Sprachmodell. Warum Kreditlimit, Garantieanspruch und Preisfreigabe in die Logik gehören, beschreibe ich in Agent Script: Regeln statt LLM.

Salesforce zeigt im Juni 2026 (öffnet in einem neuen Tab), wie Claude Code, Codex oder Vibes mit Skills eine Agent-Script-Datei entwerfen, deployen und testen. Tests sind YAML-Spezifikationen mit erwartetem Thema, erwarteten Aktionen und erwartetem Ergebnis; das Ergebnis bewertet ein Sprachmodell als Richter. Eine Bestehensquote nennt Salesforce nicht. Wie Sie diese Schwelle vor dem Piloten festlegen, steht in Agentforce-Agenten testen und freigeben.

Code Analyzer und ApexGuru: Prüfer ohne Sprachmodell

Code Analyzer bündelt laut Doku (öffnet in einem neuen Tab) acht Engines: PMD, ESLint, RetireJS, Regex, Flow Scanner, CPD, Salesforce Graph Engine und ApexGuru. Er läuft über CLI, in VS Code und in CI/CD. Für Agenten gibt es drei Skills (öffnet in einem neuen Tab), die eine Anfrage in CLI-Befehle übersetzen, die Konfiguration anlegen und eigene PMD-Regeln erstellen. Der MCP-Zugang zu Code Analyzer wird seit Juni 2026 nicht mehr unterstützt (öffnet in einem neuen Tab). Salesforce empfiehlt CLI oder VS Code, sofern kein Sprachmodell gebraucht wird, weil jeder Modellaufruf Geld und Umweltkosten verursacht.

Für Entwickler

Was ApexGuru findet

ApexGuru findet laut Salesforce (öffnet in einem neuen Tab) SOQL in Schleifen, unbegrenzte Abfragen, teure Schema-Abfragen und Abfragen, die mehr Felder holen als genutzt werden. Schweregrade aus echten Laufzeitdaten gibt es nur mit ApexGuru in Produktion oder einer Full-Copy-Sandbox.

Regeln speziell für KI-generierten Code dokumentiert Salesforce nicht. Ich halte das für richtig, denn Code Analyzer prüft Qualität, egal woher der Code kommt. Die Konsequenz für Sie ist aber klar. Die Prüfung, die über den Weg in Produktion entscheidet, läuft in der Pipeline und ohne Sprachmodell, nicht im Chat des Agenten. Wie Review und Gates zusammenspielen, beschreibt Kapitel 8, die Umsetzung gehört zu meiner Arbeit in DevOps und Release Management.

Admin-KI: Setup with Agentforce, Einstein for Flow und Prompt Builder

Die Admin-KI ändert dieselbe Org, nur über die Oberfläche statt über Code.

Werkzeug	Was es kann
Einstein for Flow	Erzeugt laut SalesforceBen (öffnet in einem neuen Tab) Flow-Entwürfe mit bis zu etwa sechs Elementen, Formeln und Flow-Beschreibungen. Jede Erzeugung verbraucht Einstein Requests, in Produktion und Sandbox.
Setup with Agentforce	Setzt Data Cloud voraus und zeigt nach Aktivierung einen Button „Ask Setup Agent“ auf den Setup-Seiten. Laut SalesforceTime (öffnet in einem neuen Tab) legt der Agent Objekte, Felder, Benutzer, Berechtigungen, Freigabeeinstellungen, Flows, Berichtstypen und Lightning-Seiten an, schlägt Änderungen vor der Ausführung vor und verbraucht Data 360 Credits. Salesforce hat die allgemeine Verfügbarkeit am 26. Mai 2026 im Admin-Blog (öffnet in einem neuen Tab) gemeldet, ohne ein Release zu nennen. Was der Agent in Produktion dürfen sollte, steht in Setup with Agentforce: Admin-KI in Produktion erlauben?.
Prompt Builder	Ist GA (öffnet in einem neuen Tab) und kann seit Winter ’26 Bilder und PDFs verarbeiten, Antworten als HTML oder JSON strukturieren und bis zu 1.000 Prompts als Batch ausführen.

Damit verbraucht die Admin-KI drei Währungen: Einstein Requests, Data 360 Credits und Flex Credits. Das gehört in die Lizenzplanung. Meine Empfehlung: Setup-Agent und Einstein for Flow nur in Sandboxes einsetzen, und die Ergebnisse gehen über die Pipeline wie jede andere Metadatenänderung. Ein Agent, der in Produktion Freigabeeinstellungen ändert, macht das alte Problem direkter Änderungen nur schneller.

Beispiel: Werkzeugwahl bei einem Maschinenbauer

Nehmen wir einen Maschinenbauer mit Sales Cloud, Service Cloud, Händlerportal und SAP an. Ein Implementierungspartner arbeitet mit sechs Entwicklern, geplant ist ein erster Agentforce-Agent für Händleranfragen zum Auftragsstatus. Alle Zahlen sind Annahmen, die das Vorgehen zeigen sollen.

Schritt	Annahme und Ergebnis
Org-Standort	Liegt die Org in der EU Operating Zone, ist Vibes keine Option. Nehmen wir an, sie liegt in einer EU-Org außerhalb davon.
Coding-Lizenz	Der Partner möchte die Unmetered-Lizenz mit Sonnet. Angenommen sind 25 agentische Requests pro Entwickler und Arbeitstag mit durchschnittlich 30.000 Token. Sechs Entwickler kommen auf 150 Requests und 4,5 Mio. Token am Tag. Die Grenze von 36 Mio. Token ist nach acht Arbeitstagen erreicht, die 2.500 Requests wären es nach knapp 17. Weil die Grenze pro Org gilt, arbeitet das Team ab dem neunten Arbeitstag mit GPT-5 weiter oder zahlt Flex Credits.
Metered mit Opus	Dieselben 30.000 Token sind 15 Einheiten zu 16 Credits, also 240 Credits oder 1,20 € pro Request. 150 Requests am Tag kosten damit 180 €, rund 3.780 € in 21 Arbeitstagen.
Der Agent selbst	Er entsteht als Agent Script in Git, Kreditprüfung und Auftragsabfrage laufen als Logik. Für den Test sind 60 Fälle mit je drei Aktionen in drei Durchläufen angenommen. Das sind 540 Aktionen zu je 16 Credits in der Sandbox, also 8.640 Credits oder 43,20 €.
Das Gate	Code Analyzer läuft bei jedem Pull Request in der Pipeline, egal ob Vibes, Claude Code oder ein Mensch den Code geschrieben hat.

In diesem Szenario ist die Frage nach dem Agenten schnell beantwortet. Zeit kosten die Grenze der Lizenz, die offene Zählweise und die Gates.

Was sollten Sie jetzt entscheiden?

1. Org-Standort klären. EU Operating Zone ja oder nein entscheidet über Vibes.
2. Lizenzweg rechnen. Unmetered gegen Flex Credits, mit der Grenze pro Org und 125 € pro Nutzer und Monat für die Flat Fee.
3. Regeldatei im Kunden-Repository anlegen, für jedes Werkzeug, das Ihre Partner nutzen dürfen.
4. Agentforce-Agenten nur als Agent Script in Git abnehmen, mit Testspezifikation und vereinbarter Bestehensquote.
5. Code Analyzer als Pflichtschritt in die Pipeline setzen, ApexGuru mit Laufzeitdaten aus Produktion oder Full-Copy-Sandbox.
6. Admin-KI auf Sandboxes begrenzen.

Salesforce wirbt auf der Produktseite (öffnet in einem neuen Tab) damit, Teams könnten mit Vibes „up to 95% faster“ innovieren. Eine Studie dazu nennt die Seite nicht. Messen Sie den Effekt in Ihrem eigenen Programm, wie in Kapitel 9 beschrieben, und sehen Sie sich als Nächstes in Kapitel 3 an, über welche Schnittstellen diese Werkzeuge auf Ihre Org zugreifen.