Best Practices für KI-Code in Salesforce-Projekten

Für KI-generierten Salesforce-Code empfehlen 2026 alle großen Werkzeuganbieter dasselbe Muster: eine kurze Regeldatei im Repository, einen Plan vor dem Code und Prüfungen, die nicht vom Wohlwollen des Modells abhängen. Auf Salesforce kommen typische Fehler hinzu, die sich größtenteils maschinell finden lassen: Abfragen in Schleifen, fehlende Feld- und Objektrechte, Tests ohne echte Asserts, erfundene Feldnamen. Und API 67.0 ändert die Rechte-Defaults pro Klasse. Als Auftraggeber müssen Sie keinen Code lesen. Sie sollten aber Regeldatei, Pipeline und Org-Zugriffe besitzen, und kein Agent kommt an Ihre Produktion.

Was sagt die Evidenz über KI-generierten Code?

Die Studien messen sehr unterschiedliche Dinge, und keine davon misst Apex. Für eine Entscheidung reichen vier Befunde:

Studie	Setting	Ergebnis
Veracode, Juli 2026 (öffnet in einem neuen Tab)	Rohmodelle ohne Werkzeuge und ohne Review, 11 Modelle im aktuellen Vergleich	56 % Sicherheits-Passrate, „virtually unchanged“; Python 63 %, Java 30 % auf dem letzten Platz
METR, Juli 2025 (öffnet in einem neuen Tab)	16 erfahrene Entwickler, reale Aufgaben in eigenen großen Repositories	19 % langsamer mit KI, gefühlt 20 % schneller
METR, Februar 2026 (öffnet in einem neuen Tab)	Folgestudie	Beschleunigung heute „likely“, die Daten seien aber „only very weak evidence“ für ihre Größe
DORA, September 2025 (öffnet in einem neuen Tab)	knapp 5.000 Befragte	KI steigert den Durchsatz, schadet weiter der Stabilität; „it amplifies what’s already there“

Zwei Schlüsse ziehe ich daraus. Eine gewachsene Kundenorg mit Jahren an Triggern, Flows und Schnittstellen zu SAP ähnelt eher dem METR-Setting als einer Aufgabe auf der grünen Wiese. Produktivitätsgewinne sollten Sie dort messen statt annehmen; wie, beschreibt Kapitel 9. Und Veracodes Java-Wert ist für mich ein Warnsignal für Apex, weil beide Sprachen eng verwandt sind. Belegt ist das nicht, Apex-Daten gibt es schlicht keine.

Welche Fehler macht KI in Salesforce-Code typischerweise?

Salesforce dokumentiert die Schwachstellen selbst. Die Prüfliste für Agentforce Vibes (öffnet in einem neuen Tab) fragt nach Abfragen in Schleifen, nach dem Limit von 100 SOQL-Abfragen im Bulk-Fall und nach Asserts, die mehr prüfen als System.assertNotEquals(null, result). Der zentrale Satz dort: „Permission modes protect your filesystem. Code review protects your application.“

Bereich	Typischer Fehler	Wie man ihn findet
Governor Limits	SOQL oder DML in Schleifen, unbegrenzte Abfragen	Code Analyzer, ApexGuru
Bulk-Verarbeitung	Trigger verarbeitet einen Datensatz statt einer Liste	Bulk-Test; der Apex-Testleitfaden (öffnet in einem neuen Tab) verlangt mindestens 20 Datensätze
Rechte	keine Sharing-Deklaration, kein WITH USER_MODE	Code Analyzer, Test mit runAs
Tests	Abdeckung ohne Aussage, Testdaten aus der Org	Review, Assert-Regel
Feldnamen	erfundene API-Namen, die es in der Org nicht gibt	Validierungs-Deployment
Metadaten	neues Feld fehlt im Permission Set	Validierungs-Deployment, Review
Konfiguration	Agent ändert Sharing, Profile, Layouts	Regel: das macht ein Mensch im Setup

Die letzte Zeile ist eine Empfehlung von Salesforce: Permission Sets, Profile, Page Layouts und Sharing-Regeln sollen laut den Vibes Workflow Patterns (öffnet in einem neuen Tab) von Hand im Setup entstehen, Code für Verschlüsselung, Authentifizierung und Berechtigungslogik soll Zeile für Zeile geprüft werden. Bei einem Hersteller betrifft das genau die Stellen, an denen Händler nur ihre eigenen Aufträge und Garantiefälle sehen dürfen.

Zur Abdeckung: Salesforce verlangt 75 Prozent für ein Deployment, schreibt im Testleitfaden aber ausdrücklich, man solle sich nicht auf den Prozentsatz konzentrieren. Ein Agent optimiert auf die Prüfung, die Sie ihm geben. Geben Sie ihm nur die 75 Prozent, bekommen Sie Tests, die Zeilen durchlaufen und nichts beweisen. Wie Sie als Auftraggeber solchen Code prüfen lassen, steht in KI-generierten Salesforce-Code prüfen, und warum jeder Pull Request ein Review braucht, in warum Pull-Request-Reviews Pflicht sind.

Die Falle mit API 67.0

Mit Summer ’26 hat Salesforce das Standardverhalten von Apex geändert. Laut Apex Developer Guide (öffnet in einem neuen Tab) läuft Code ab API 67.0 im Benutzerkontext, Klassen ohne Sharing-Deklaration laufen mit den Freigaben des aktuellen Benutzers, und WITH SECURITY_ENFORCED ist in SOQL nicht mehr erlaubt. Der Architektenblog zu Summer ’26 (öffnet in einem neuen Tab) ergänzt zwei Punkte: Trigger laufen immer im System Mode, die Handler-Klassen, die sie aufrufen, sind aber betroffen, wenn ihnen die Deklaration fehlt. Und Klassen mit der alten Klausel kompilieren auf 67.0 nicht mehr.

Nehmen Sie den Batch-Job, der nachts Auftragsstände aus SAP in Salesforce schreibt, oder die Klasse, die Garantiefristen über alle Anlagen eines Händlers berechnet. Beide haben bisher stillschweigend alles gesehen.

Für KI-Code ist das aus meiner Sicht doppelt relevant. Modelle haben überwiegend älteres Apex gesehen und schlagen deshalb Muster vor, die auf 67.0 nicht mehr kompilieren oder anders wirken. Und Agenten heben API-Versionen gern nebenbei an, wenn sie eine Datei ohnehin anfassen. Die Regeldatei sollte deshalb drei Dinge festlegen: Zielversion für neue Klassen, explizite Sharing-Deklaration, kein Anheben bestehender Klassen ohne Auftrag und ohne Test mit eingeschränktem Benutzer. Wo System Mode gewollt ist, schreibt der Code WITH SYSTEM_MODE bewusst hin, wie es die LWC-Dokumentation zu sicherem Apex (öffnet in einem neuen Tab) beschreibt. Details stehen in API 67.0: warum Apex weniger Datensätze sieht, die Folgen für die Pipeline in Winter ’27: was sich ändert.

Regeln, die der Agent liest, und Regeln, die er nicht umgehen kann

Jeder Coding-Agent liest eine Projektdatei mit dauerhaften Anweisungen, nur heißt sie bei jedem Werkzeug anders.

Für Entwickler

Welche Datei liest welcher Agent?

Claude Code liest CLAUDE.md, Codex AGENTS.md, Agentforce Vibes .vibes/rules/. GitHub Copilot liest laut GitHub-Dokumentation (öffnet in einem neuen Tab) .github/copilot-instructions.md, AGENTS.md oder eine einzelne CLAUDE.md im Wurzelverzeichnis.

Ob Vibes AGENTS.md liest, ist in der Vibes-Dokumentation zu Regeln (öffnet in einem neuen Tab) nicht beschrieben; für gemischte Teams würde ich eine kanonische AGENTS.md plus eine kurze Vibes-Regel pflegen, die darauf verweist.

Die Anbieter sind sich bei der Länge einig. Anthropic empfiehlt in den Claude Code Best Practices (öffnet in einem neuen Tab) unter 200 Zeilen und nur das, was der Agent nicht aus dem Code ableiten kann: Befehle für Tests und Prüfungen, irreführende Stellen im Code, Entscheidungen, die nirgends stehen, und „anything you’ve had to correct twice already“. OpenAI schreibt in den Codex Best Practices (öffnet in einem neuen Tab): „A short, accurate AGENTS.md is more useful than a long file full of vague rules.“ Ein Auszug für ein Salesforce-Repository:

# Orgs
- Work only against scratch orgs and the alias dev-sandbox; never uat or prod

# Apex
- New classes: API 67.0, explicit sharing declaration, WITH USER_MODE
- Do not raise the API version of existing classes unless the task says so
- No SOQL/DML in loops; triggers must be bulk-safe for 200 records
- SAP calls only via Named Credential SAP_S4, never direct endpoints

# Done means
- Positive, negative and bulk tests with real asserts, plus a runAs test
- Report the test command and its output before saying done

Das Wichtigste steht aber nicht in dieser Datei. Anthropic formuliert es so: „If something has to happen every time, make it a hook, a deny rule, or a managed setting.“ Das Modell darf eine Richtlinie in CLAUDE.md für nicht zutreffend halten. Deny-Regeln dagegen gelten in jedem Berechtigungsmodus, und ein Stop-Hook schickt den Agenten zurück an die Arbeit, solange Tests oder Code Analyzer rot sind. Für Salesforce heißt das: Leseverbot für die Anmeldedaten der sf CLI, Verbot von Befehlen gegen Produktions-Aliase, Tests als Hook.

Die Regeldatei gehört in Ihr Repository, nicht in das des Partners. Wer sie pflegt und wie sie wächst, beschreibe ich in die KI-Regeldatei im Salesforce-Repository; warum Repository und Werkzeuge beim Kunden liegen sollten, in warum Kunden ihre DevOps-Tools selbst besitzen sollten.

Welche Quality Gates gehören in die Pipeline?

Was in der Regeldatei steht, prüft im Zweifel niemand. Was in der Pipeline steht, prüft jeder Lauf. Ich würde für KI-Code dieselben Gates verlangen wie für Code von Menschen, nur ohne Ausnahmen:

Gate	Was es findet	Hinweis
Salesforce Code Analyzer (öffnet in einem neuen Tab)	Sicherheits- und Performance-Regeln über PMD, ESLint, RetireJS, Regex, Flow Scanner	als CLI und GitHub Action verfügbar
ApexGuru-Scan (öffnet in einem neuen Tab)	SOQL in Schleifen, unbegrenzte Abfragen, zu viele Felder	Schweregrad aus Laufzeitdaten nur mit Produktion oder Full Copy Sandbox
Validierungs-Deployment (öffnet in einem neuen Tab)	fehlende Referenzen, erfundene Felder, rote Tests	sf project deploy validate, Standard RunLocalTests, mindestens 75 % Apex-Abdeckung
Review durch einen Menschen	Logik, Sharing-Modell, Architektur	Pull Request mit Kennzeichnung der KI-Anteile

Die offenen Salesforce Skills (öffnet in einem neuen Tab) bringen einen Teil davon schon mit: Sie lehnen Abfragen in Schleifen ab, erzwingen Sharing-Deklarationen und lassen Code Analyzer laufen, bevor sie Erfolg melden. Salesforce empfiehlt trotzdem, Feldnamen gegen das Schema zu prüfen und Code Analyzer zusätzlich von Hand zu starten. Ein Gate im Werkzeug des Entwicklers ersetzt das Gate in Ihrer Pipeline nicht. Wer keine kommerzielle DevOps-Lösung will, findet in sfdx-hardis eine Open-Source-Option. Die Gates im Detail stehen in Quality Gates für KI-Code in der Salesforce-Pipeline.

Vor dem Gate entscheidet die Arbeitsweise, wie viel durchfällt. Drei Gewohnheiten halte ich für wirksam:

Gewohnheit	Was sie bedeutet
Plan vor Code	Im Plan Mode von Vibes ändert sich laut Salesforce nichts, „until you click Approve Plan“. Für eine Erweiterung mit mehreren Metadatentypen lohnt das. Für einen Bugfix reicht ein Test, der den Fehler zeigt. Birgitta Böckeler hat erlebt, wie ein Werkzeug aus einem kleinen Bug vier User Stories mit 16 Akzeptanzkriterien (öffnet in einem neuen Tab) machte.
Beweise statt Behauptungen	Der Agent liefert den Testbefehl und die Ausgabe, nicht „alle Tests grün“.
Kleine Änderungen	DORA zählt kleine Batches (öffnet in einem neuen Tab) zu den Fähigkeiten, die KI-Nutzen tragen. Ein Pull Request mit 40 geänderten Dateien wird nicht geprüft, er wird durchgewinkt.

Warum bekommt kein Agent Zugriff auf Produktion?

Simon Willison beschreibt die „lethal trifecta“ (öffnet in einem neuen Tab): Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und ein Weg nach außen. Ein Coding-Agent mit sf-CLI-Anmeldung an einer Org mit produktiven Händler- und Kundendaten, der Tickets und Webseiten liest und Netzwerkzugriff hat, erfüllt alle drei. Anthropic nennt im Leitfaden zum sicheren Betrieb (öffnet in einem neuen Tab) selbst das Beispiel einer README mit ungewöhnlichen Anweisungen, die der Agent übernehmen könnte.

Meine Mindestregeln für jedes Projekt:

1. Agenten arbeiten nur gegen Scratch Orgs und Entwickler-Sandboxes ohne Kundendaten aus Produktion.
2. Agentforce Vibes ist in Produktions-Orgs im Setup unter „Agentforce Vibes Extensions“ deaktiviert (öffnet in einem neuen Tab).
3. Berechtigungen starten bei „Ask every time“ und werden schrittweise geöffnet, wie es die Vibes-Dokumentation empfiehlt.
4. Deny-Regeln sperren Anmeldedaten und Produktions-Aliase; Zugangsdaten liegen außerhalb der Agentenumgebung, Anthropic beschreibt dafür einen Proxy.
5. Deployments nach Produktion laufen nur über die Pipeline, mit Freigabe durch einen Menschen.

Diese Regeln gehören in den Vertrag mit dem Partner, nicht nur in seine Arbeitsanweisung. Das ist Teil meiner Arbeit in DevOps und Release-Management.

Durchgespielt: Ersatzteilverfügbarkeit im Händlerportal

Nehmen wir einen Maschinenbauer mit Experience-Cloud-Händlerportal, Service Cloud und SAP S/4. Alle Zahlen sind Annahmen. Der Partner soll mit vier Entwicklern und Claude Code eine Komponente bauen, in der Händler die Verfügbarkeit von Ersatzteilen für ihre Maschinen sehen.

Im Anforderungsworkshop entsteht in zwei Stunden ein klickbarer Entwurf in einer Developer Edition. Das ist Vibe Coding im besten Sinn, und der Entwurf wird danach verworfen; wo die Grenze liegt, steht in Vibe Coding in Salesforce: Prototyp oder Produktion. Für die echte Umsetzung gilt:

1. 01

   Regeldatei

   Die Regeldatei liegt im Repository des Herstellers und nennt den Named Credential für SAP, die Zielversion 67.0 und die Scratch-Org-Befehle.

2. 02

   Plan

   Der Agent schreibt zuerst einen Plan, den ein Entwickler freigibt.

3. 03

   Test

   Der Plan sieht vor, eine bestehende Selector-Klasse von 62.0 auf 67.0 anzuheben, also verlangt die Regeldatei einen runAs-Test. Der Test mit einem eingeschränkten Händlerbenutzer zeigt, dass danach Anlagen anderer Händler fehlen, was gewollt ist, aber auch die Teilestammdaten, was nicht gewollt ist. Gefunden im Validierungs-Deployment statt im Portal.

4. 04

   Code Analyzer

   Code Analyzer meldet eine Abfrage in einer Schleife bei 200 Positionen, der Pull Request geht zurück.

5. 05

   Review

   Der Reviewer prüft das Sharing-Modell, nicht die Formatierung.

Kein Schritt davon ist neu. Neu ist, dass ohne diese Schritte in derselben Zeit deutlich mehr ungeprüfter Code entsteht. Die Kosten der KI-Werkzeuge selbst behandelt Kapitel 7, alle Kapitel finden Sie auf der Übersichtsseite.