Wie wir mit KI Salesforce-Lösungen 10x schneller entwickeln

KI-gestützte Salesforce-Entwicklung ist ein Ansatz, bei dem Large Language Models durch strukturierten Projektkontext — sogenannte Product Requirement Prompts (PRPs) — produktionsreifen Apex-Code generieren, der Governor Limits einhält und Sicherheitsprüfungen besteht.

KI-Coding-Tools wie Cursor und Claude Code versprechen dramatische Produktivitätssteigerungen. Doch in unseren Kundenprojekten haben wir gemessen: Ohne strukturiertes Context Engineering liefert KI in der Mehrzahl der Fälle Code, der Governor Limits verletzt oder Sicherheitslücken enthält. Das Problem ist nicht die KI — sondern der fehlende Kontext.

Das Wichtigste in Kürze

• Context Engineering statt Prompt Engineering: PRPs liefern der KI Dateipfade, Architekturmuster, Governor-Limit-Strategien und Security-Patterns — alles in einem strukturierten Dokument.
• Mehrstufige Validierung: Linter → Security Scanner → Sandbox-Deployment → Automatisierte Tests. Kein KI-generierter Code erreicht Production ohne diese Pipeline.
• Messbare Ergebnisse: Projekte, die traditionell 4–6 Wochen dauerten, schliessen wir in 1–2 Wochen ab — bei 90%+ Testabdeckung.

Dieser Artikel zeigt den konkreten Workflow, den wir in echten Kundenprojekten einsetzen: von PRPs über RAG-gestützte Dokumentation bis zur automatisierten Qualitätssicherung. Für einen Gesamtüberblick über die Salesforce-Plattform und ihre Möglichkeiten empfehlen wir unseren Pillar-Artikel. Mit Code-Snippets, Vorher-Nachher-Vergleichen und der exakten Methodik zum Nachbauen.

Traditionelle Salesforce-Entwicklung vs. KI-gestützter Workflow: Durch Context Engineering und automatisierte Validierung verkürzt sich die Projektdauer um bis zu 80%.

Warum traditionelle Salesforce-Entwicklung an ihre Grenzen stösst

Der klassische Salesforce-Entwicklungsprozess folgt einem bewährten, aber langsamen Muster:

1. Anforderungsanalyse (1-2 Wochen): Stakeholder-Interviews, User Stories, Dokumentation
2. Entwicklung (2-4 Wochen): Manuelles Coding von Apex, LWC, Flows
3. Testing (1-2 Wochen): Unit Tests, Integration Tests, UAT
4. Deployment (Tage): Sandbox → UAT → Production

Jeder dieser Schritte ist manuell, fehleranfällig und langsam. Typische Herausforderungen:

• Governor Limits: Salesforce erzwingt strikte Ressourcengrenzen. Ein einziger SOQL-Query in einer Schleife kann eine ganze Batch-Verarbeitung zum Absturz bringen.
• Sicherheitsanforderungen: CRUD/FLS-Checks, WITH SECURITY_ENFORCED, stripInaccessible() müssen konsequent implementiert werden.
• Testabdeckung: Salesforce verlangt mindestens 75% Code Coverage für Produktions-Deployments und 100% für Managed Packages.
• Komplexe Datenmodelle: Grosse Organisationen haben Hunderte von Custom Objects mit verschachtelten Beziehungen.

Ein typisches Beispiel aus der Praxis: In vielen Salesforce-Organisationen laufen mehrere Batch-Jobs sequenziell über Stunden, um Dutzende von Account-Feldern aus verschiedenen Quellen zu berechnen — Umsatz-Rollups, Mengen-Aggregationen, Ranking-Berechnungen. Oft greifen verschiedene Jobs redundant auf die gleichen Daten zu. Felder mit hardcodierten Datumswerten erfordern jährliche manuelle Wartung. Managed-Package-Abhängigkeiten (z.B. DLRS) machen das System fragil.

Solche gewachsenen Strukturen manuell zu analysieren und neu zu architekturieren dauert Wochen. Mit KI-gestützter Entwicklung gelingt die Analyse und Neuarchitektur in Tagen.

Reales Kundenprojekt: Fünf gewachsene Batch-Jobs wurden durch KI-gestützte Analyse in eine einzige, optimierte Lösung konsolidiert — von 6 Stunden auf 90 Minuten.

Der Paradigmenwechsel: Context Engineering statt Prompt Engineering

Die meisten Diskussionen über KI und Software-Entwicklung drehen sich um “Prompt Engineering” — die Kunst, die richtige Frage zu stellen. Für produktionsreife Salesforce-Entwicklung reicht das bei weitem nicht aus.

Der eigentliche Durchbruch liegt im Context Engineering: Nicht die Frage macht den Unterschied, sondern die Menge und Qualität des Kontexts, den die KI erhält.

Stellen Sie sich vor, Sie erklären einem brillanten Junior-Entwickler eine Aufgabe. Wenn Sie nur sagen “Bau einen Batch-Job”, bekommen Sie generischen Code. Wenn Sie ihm stattdessen die komplette Architektur, alle bestehenden Patterns, bekannte Fallstricke, Teststrategien und Sicherheitsanforderungen mitgeben — dann bekommt er eine Chance, produktionsreifen Code zu schreiben.

Genau das machen Product Requirement Prompts.

Was sind Product Requirement Prompts (PRPs)?

Ein PRP ist ein strukturiertes Dokument, das alle Informationen enthält, die eine KI braucht, um ein Salesforce-Feature in einem Durchgang korrekt zu implementieren. Es geht weit über eine User Story hinaus.

Die 5 Kernprinzipien

1. Context is King: Jedes PRP enthält Dateipfade, bestehende Code-Patterns, Architekturentscheidungen und bekannte Fallstricke des Projekts.
2. Validation Loops: Jedes PRP definiert mehrstufige, automatisch ausführbare Prüfschritte. Die KI implementiert, validiert und korrigiert selbstständig.
3. Information Dense: Keine vagen Beschreibungen. Stattdessen: exakte Feldnamen, API-Versionen, Governor-Limit-Strategien und Security-Patterns.
4. Progressive Success: Features werden in Schichten implementiert. Erst die Grundfunktion, dann die Edge Cases, dann die Optimierung.
5. Global Rules: Projektweite Regeln (z.B. “Kein SOQL in Schleifen”, “Alle Queries mit WITH SECURITY_ENFORCED”) gelten für jedes PRP.

Anatomie eines PRPs

Hier ein vereinfachtes Beispiel eines PRPs für eine Bulk-Upload-Komponente:

# PRP: Bulk Upload Lightning Web Component

## FEATURE:
CSV-Bulk-Upload für Accounts und Contacts mit Duplikat-Erkennung

## ARCHITEKTUR:
- Hauptkomponente: bulkUploadWizard (Multi-Step Wizard)
- Kind-Komponenten: fileUploadStep, resultsTable
- Apex Controller: BulkUploadController.cls
- Async-Verarbeitung: CSVChunkQueueable (Queueable)

## BESTEHENDE PATTERNS (aus diesem Projekt):
- Controller nutzt @AuraEnabled mit cacheable=false
- Fehlerbehandlung: AuraHandledException
- Test-Pattern: @TestSetup + Test.startTest()/stopTest()

## SICHERHEIT:
- Alle SOQL-Queries: WITH SECURITY_ENFORCED
- DML-Operationen: Security.stripInaccessible(AccessType.CREATABLE)
- Permission Validation vor jeder Aktion

## VALIDIERUNGSSTUFEN:
1. npm run lint → Keine Fehler
2. sf scanner run → Keine High/Critical Findings
3. sf project deploy start --dry-run → Erfolg
4. sf apex run test --test-level RunLocalTests → Alle Tests grün, >75% Coverage

Die Wissensbasis: ai_docs

Zusätzlich zu PRPs pflegen wir für jedes Projekt eine ai_docs/-Wissensbasis mit dokumentierten Patterns und Gotchas:

• enterprise_architecture.md: Service/Domain/Selector-Layer-Patterns
• testing_with_mocks.md: ApexMocks und Test-Factory-Patterns
• governor_limit_patterns.md: Bulk-sichere Verarbeitungsmuster
• csv_parsing_advanced.md: RFC-4180-konforme CSV-Verarbeitung
• master_detail_insert_order.md: Reihenfolge bei verschachtelten Inserts

Diese Dokumente werden über die Zeit immer reichhaltiger: Jedes Mal, wenn ein neues Pattern entdeckt oder ein Gotcha gelöst wird, fliesst das Wissen zurück in die ai_docs. So wird die KI mit jedem Projekt besser.

Anatomie eines Product Requirement Prompts: Die fünf Kernprinzipien stellen sicher, dass die KI genug Kontext erhält, um produktionsreifen Salesforce-Code zu generieren.

Der KI-gestützte Entwicklungsworkflow

Unser Workflow besteht aus vier Schritten, die bei jedem Feature-Request gleich ablaufen. Vom initialen Wissensabruf über die PRP-Erstellung bis zur automatisierten Validierung — jeder Schritt baut auf dem vorherigen auf und reduziert das Fehlerrisiko systematisch.

Schritt 1: Wissensrecherche mit RAG

Bevor eine einzige Zeile Code geschrieben wird, braucht die KI Zugang zur aktuellen Salesforce-Dokumentation. Das Problem: Die offizielle Dokumentation umfasst über 7.400 Seiten, verteilt auf mindestens 5 verschiedene Domains.

Wir lösen das mit einem GraphRAG-System — einem Ansatz, der auf der Microsoft Research Publikation “From Local to Global: A Graph RAG Approach to Query-Focused Summarization” basiert und Knowledge Graphs mit Vektor-Embeddings kombiniert. Unser System umfasst über 16.000 Knoten und 24.000 Kanten, die die gesamte Salesforce-Dokumentation strukturiert erfassen. Dazu kommen knapp 20.000 Vektor-Embeddings für semantische Suche.

Wenn die KI eine Frage hat wie “Wie funktioniert Database.QueryLocator im Batch-Kontext?”, erhält sie nicht nur den relevanten Dokumentationsabschnitt, sondern auch alle verwandten Themen: Governor Limits für Batch, verwandte Apex-Klassen, Code-Beispiele und Best Practices.

Der entscheidende Vorteil gegenüber einer Google-Suche: Das System kennt die Beziehungen zwischen Konzepten. Es weiss, dass Database.QueryLocator mit Database.Batchable zusammenhängt, dass es Governor-Limit-Implikationen hat, und kann den gesamten Kontext in einer einzigen Antwort liefern.

Schritt 2: PRP erstellen

Mit dem Recherche-Wissen wird ein PRP erstellt. Dabei gilt:

• Exakte Dateipfade: Nicht “erstelle einen Controller”, sondern force-app/main/default/classes/BulkUploadController.cls
• Bekannte Patterns: Code-Beispiele aus dem bestehenden Projekt, nicht generische Tutorials
• Explizite Fallstricke: “Achtung: Master-Detail-Records müssen in korrekter Reihenfolge inserted werden”
• Testdaten-Strategie: Welche Records in @TestSetup erstellt werden müssen

Schritt 3: KI-gestützte Implementierung mit 3-stufiger Validierung

Die KI implementiert das Feature und durchläuft automatisch drei Validierungsstufen:

# STUFE 1: Syntax & Style (lokal, Sekunden)
npm run lint          # ESLint für JavaScript/LWC
npm run prettier      # Code-Formatierung
sf scanner run        # Salesforce Security Scanner

# STUFE 2: Deployment (Sandbox, Minuten)
sf project deploy start --dry-run --test-level NoTestRun
sf project deploy start --source-dir force-app

# STUFE 3: Tests (in der Org, Minuten)
sf apex run test --test-level RunLocalTests \
  --result-format human --code-coverage
# Erwartung: Alle Tests grün, Coverage >75%

Schritt 4: Automatisierte Sicherheitsprüfung

Salesforce-Sicherheit ist nicht optional. Jedes PRP erzwingt:

• FLS-Checks: WITH SECURITY_ENFORCED auf allen SOQL-Queries
• CRUD-Prüfung: Security.stripInaccessible() vor DML-Operationen
• Sharing Rules: Korrekte with sharing / without sharing Deklaration
• Permission Validation: Prüfung von Custom Permissions vor kritischen Aktionen

Der Salesforce Code Scanner wird bei jeder Iteration ausgeführt. Code mit Sicherheitslücken wird automatisch erkannt und korrigiert.

// Beispiel: Sicherheitsmuster in einem Batch-Job
public with sharing class AccountRollupBatch
    implements Database.Batchable<SObject> {

    public Database.QueryLocator start(Database.BatchableContext bc) {
        // FLS-sichere Query
        return Database.getQueryLocator([
            SELECT Id, Name, Industry
            FROM Account
            WITH SECURITY_ENFORCED
        ]);
    }

    public void execute(Database.BatchableContext bc, List<Account> scope) {
        // CRUD-sichere DML
        List<Account> toUpdate = calculateRollups(scope);
        SObjectAccessDecision decision =
            Security.stripInaccessible(AccessType.UPDATABLE, toUpdate);
        update decision.getRecords();
    }
}

Dieses Muster — WITH SECURITY_ENFORCED auf Queries, Security.stripInaccessible() auf DML — wird in jedem PRP als Pflicht definiert. Die KI lernt es einmal und wendet es konsistent an, ohne es je zu vergessen.

Der Validierungskreislauf

Das Zusammenspiel von Codegenerierung und automatisierter Validierung bildet einen geschlossenen Kreislauf:

Der geschlossene Validierungskreislauf: KI generiert Code, drei Prüfstufen validieren automatisch, bei Fehlern wird korrigiert — bis alle Kriterien erfüllt sind.

Wenn eine Stufe fehlschlägt, analysiert die KI den Fehler, korrigiert den Code und startet den Validierungszyklus erneut. Dieser iterative Loop ist der Kern der Methodik: Die KI optimiert sich selbst, bis alle Kriterien erfüllt sind.

Ergebnisse aus der Praxis

Theorie ist das eine — was zählt, sind Ergebnisse aus echten Projekten. In den letzten Monaten haben wir die PRP-Methodik in verschiedenen Salesforce-Implementierungen eingesetzt: von der Entwicklung unseres eigenen Analyse-Tools als Managed Package über die Performance-Optimierung einer gewachsenen Sales-Cloud-Org bis hin zu komplexen Reporting-Integrationen im Immobilienbereich. Hier die konkreten, messbaren Ergebnisse.

Unser eigenes Managed Package: Salesforce Analyzer

Für unsere Beratungsprojekte brauchten wir ein Tool, das die Salesforce-Orgs unserer Kunden systematisch analysiert — Datenqualität, Lizenzauslastung, User Adoption und Org-Gesundheit auf einen Blick. Statt eine vorhandene AppExchange-Lösung zu nutzen, haben wir unseren eigenen Salesforce Analyzer als 2GP Managed Package entwickelt. Das Ergebnis: 14 Apex-Klassen mit zugehörigen 13 Test-Klassen, 14 Lightning Web Components, 5 Custom Objects und knapp 15.000 Zeilen Code — ein vollwertiges Analysetool mit vier Modulen (Field Data Quality, License Optimization, Adoption & Engagement, Executive Health Dashboard).

Die Herausforderung bei Managed Packages: Salesforce verlangt strikte Sicherheitsstandards, und der Security Review lässt keine Kompromisse zu. Jede SOQL-Query braucht WITH SECURITY_ENFORCED, jede DML-Operation Security.stripInaccessible(), und die gesamte Architektur muss with sharing respektieren.

Mit der PRP-Methodik konnten wir die Kernfunktionalität in einer Woche implementieren. Jede Apex-Klasse wurde zusammen mit ihrer vollständigen Testklasse generiert — nicht nachträglich, sondern im selben Durchgang. Das Ergebnis:

Metrik	Traditionell (geschätzt)	KI-gestützt (gemessen)
Apex-Klassen erstellt	~10/Woche	27 Klassen in 1 Woche
Testabdeckung	Oft nachträglich, <80%	>90% von Anfang an
Security Scanner Findings	2-5 pro Review	0 nach Validierungsloop
Test-zu-Production-Verhältnis	Variabel	~1:1 (13 Tests für 14 Klassen)
LWC-Komponenten	~3-4/Woche	14 Komponenten mit 32 Jest-Tests

Der entscheidende Faktor war die ai_docs/-Wissensbasis des Projekts: Darin waren alle Patterns dokumentiert — wie die Service-Layer-Architektur aufgebaut ist, wie Batch-Jobs mit Database.Stateful arbeiten, wie die FieldCategorizer-Logik Felder in 7 Kategorien mit gewichteten Scores einteilt. Die KI konnte diese Patterns konsistent über alle 27 Klassen anwenden, ohne dass ein einziges Pattern manuell korrigiert werden musste. Das Resultat nutzen wir heute in jedem Kundenprojekt als erstes Analyse-Instrument.

Batch-Optimierung in gewachsener Sales-Cloud-Org

Ein anderer Kunde im Dienstleistungssektor hatte ein klassisches Problem: Über Jahre waren Batch-Jobs organisch gewachsen. Fünf separate Batch-Klassen berechneten Account-Felder — Umsatz-Rollups, Mengen-Aggregationen, Prioritäts-Scores und Ranking-Berechnungen. Jeder Batch lief sequenziell, griff teils auf dieselben Daten zu und hatte hardcodierte Jahresfilter, die ein Entwickler jedes Jahr im Januar manuell anpassen musste. Dazu kam eine Abhängigkeit von DLRS (Declarative Lookup Rollup Summaries), einem Managed Package, dessen Updates gelegentlich für Überraschungen sorgten.

Wir haben mit der PRP-Methodik die gesamte Batch-Architektur analysiert und in eine Unified-Batch-Lösung konsolidiert. Die KI konnte dabei die Abhängigkeiten zwischen den Jobs kartieren, redundante Abfragen identifizieren und eine optimierte Aggregate-Query-Strategie vorschlagen, die alle Berechnungen in einem einzigen Durchlauf erledigt.

Metrik	Vorher	Nachher
Laufzeit	5-6 Stunden	1.5 Stunden
Batch-Jobs	5 sequenziell	1 optimiert
Redundante Datenabfragen	3x dieselben Daten	1x mit Aggregate Queries
Account-Felder	53 (mit Redundanzen)	38 (bereinigt)
Jährliche Wartung	10 Felder manuell	0 (dynamische Filter)
Managed-Package-Abhängigkeit	DLRS (extern)	Keine

Der Clou: Die Analyse der bestehenden 5 Batch-Klassen, das Mapping aller Feldabhängigkeiten und die Erstellung des PRPs für den Unified Batch dauerten zusammen einen halben Tag. Die eigentliche Implementierung — inklusive Test-Klassen mit >90% Coverage und Deployment in die Sandbox — erfolgte danach in wenigen Stunden.

Was diese Ergebnisse zeigen

Der grösste Hebel liegt nicht in der Geschwindigkeit des Code-Schreibens, sondern in der Eliminierung von Iterationsschleifen: Wenn Code beim ersten Deployment sicher ist, alle Tests besteht und keine Reviewer-Rückfragen erzeugt, fallen die teuersten Phasen des Entwicklungsprozesses fast komplett weg.

In klassischen Projekten gehen 60-70% der Gesamtzeit nicht ins Coding, sondern in Kommunikation, Rückfragen, Reviews und Bugfixing nach dem Deployment. Die PRP-Methodik adressiert genau diese versteckten Zeitfresser, indem alle Anforderungen, Sicherheitsregeln und Qualitätskriterien vor der Implementierung vollständig definiert werden.

Tools und Technologien

Die PRP-Methodik ist toolunabhängig, aber in der Praxis hat sich eine bestimmte Kombination bewährt. Hier die Tools, die wir in unseren Kundenprojekten einsetzen und warum.

Die Kern-Toolchain

Tool	Zweck	Rolle im Workflow
Claude Code + MCP	KI-Entwicklungsumgebung	Implementierung, Review, Debugging
GraphRAG (Kuzu + Qdrant)	Salesforce-Dokumentations-Wissen	Kontext-Retrieval für PRPs
Salesforce CLI (sf)	Deployment & Testing	Validierungsloop-Stufen 2-3
Salesforce Scanner	Security-Analyse	Validierungsloop-Stufe 1
Husky + lint-staged	Pre-Commit-Hooks	Automatische Qualitätsprüfung
Prettier + ESLint	Code-Formatierung & Linting	Validierungsloop-Stufe 1

Claude Code mit MCP-Integration

Das Model Context Protocol (MCP) ermöglicht es, Claude Code direkt mit externen Datenquellen zu verbinden. In unserem Setup hat die KI über MCP-Tools Zugriff auf:

• Hybride Suche: Kombiniert Vektor-Ähnlichkeit mit Graph-Traversal für präzise Salesforce-Dokumentationssuche
• Entity-Lookup: Direkter Zugriff auf Apex-Klassen, SObjects und Metadata-Typen mit allen Beziehungen
• Graph-Exploration: Navigation durch Dokumentations-Hierarchien (Parent → Child → Sibling-Seiten)

Das Ergebnis: Die KI “kennt” die Salesforce-Plattform nicht nur oberflächlich, sondern versteht die Zusammenhänge zwischen Konzepten.

Die PRP-Kommandos

In jedem Projekt sind Claude-Kommandos konfiguriert, die den PRP-Workflow standardisieren:

• /generate-salesforce-prp: Erstellt ein neues PRP mit automatischer Codebase-Analyse
• /execute-salesforce-prp: Führt ein PRP aus mit vollem Validierungsloop
• /prp-review: Prüft ein PRP auf Vollständigkeit und Confidence Score

Jedes PRP wird auf einer Skala von 1-10 bewertet. Minimum für die Freigabe: 8/10. Kriterien:

• Governor Limits adressiert?
• Testabdeckung >75% geplant?
• Sicherheitspatterns definiert?
• Validierungsgates ausführbar?

Unser Technologie-Stack: Drei Schichten — von der GraphRAG-Wissensbasis über die KI-Engine bis zur Salesforce-Plattform — arbeiten zusammen für automatisierte Qualitätssicherung.

Erste Schritte: So starten Sie mit KI-gestützter Entwicklung

Sie müssen nicht gleich ein komplettes GraphRAG-System aufbauen. Hier ist ein pragmatischer Einstieg:

Phase 1: CLAUDE.md einrichten (30 Minuten)

Erstellen Sie im Root Ihres Salesforce-Projekts eine CLAUDE.md-Datei mit:

# CLAUDE.md

## Projekt-Übersicht
- Salesforce API Version: 64.0
- Architektur: [Service/Domain/Selector oder einfach]

## Wichtige Befehle
sf project deploy start --source-dir force-app
sf apex run test --test-level RunLocalTests

## Code-Konventionen
- Alle Queries: WITH SECURITY_ENFORCED
- DML: Security.stripInaccessible()
- Test Coverage: >75%
- Kein SOQL/DML in Schleifen

Phase 2: Erstes PRP schreiben (1-2 Stunden)

Wählen Sie ein überschaubares Feature und erstellen Sie ein PRP mit:

• Klarer Feature-Beschreibung
• Bestehenden Code-Patterns aus Ihrem Projekt
• Sicherheitsanforderungen
• Konkreten Validierungsschritten

Phase 3: Iterieren und verbessern

Mit jedem Projekt wächst Ihre Wissensbasis. Dokumentieren Sie:

• Patterns, die gut funktionieren
• Gotchas, die die KI initial übersieht
• Optimierungen an Ihren PRP-Templates

Fazit: Die Zukunft der Salesforce-Entwicklung ist jetzt

KI-gestützte Salesforce-Entwicklung ist kein Zukunftsversprechen — sie funktioniert heute, in echten Projekten, mit messbaren Ergebnissen. Der Schlüssel liegt nicht in der KI selbst, sondern in der Methodik: Product Requirement Prompts, strukturierte Wissensbasis und automatisierte Validierung. Nicht jede Aufgabe erfordert dabei Apex-Code: Viele Geschäftsprozesse lassen sich bereits mit Salesforce Flow deklarativ abbilden, und eine durchdachte Salesforce Automatisierungsstrategie bestimmt, wann KI-gestützte Entwicklung und wann No-Code-Tools die bessere Wahl sind.

Unternehmen, die diese Methodik früh adaptieren, gewinnen einen signifikanten Wettbewerbsvorteil: schnellere Time-to-Market, höhere Code-Qualität und effizienterer Einsatz ihrer Entwickler-Ressourcen. Parallel zur KI-gestützten Entwicklung treibt Salesforce mit Agentforce die nächste Evolutionsstufe voran — autonome KI-Agenten, die direkt in CRM-Prozesse eingebettet sind.

Bereit für den nächsten Schritt? Kontaktieren Sie uns für eine kostenlose KI-Readiness-Bewertung Ihrer Salesforce-Organisation. Wir analysieren Ihr aktuelles Setup und zeigen Ihnen, wo KI-gestützte Entwicklung den grössten Hebel bietet.

FAQ

Kann KI wirklich produktionsreifen Apex-Code schreiben?

Ja, mit der richtigen Methodik. Der Schlüssel liegt nicht im Prompting, sondern im Context Engineering: Product Requirement Prompts (PRPs) liefern der KI alle nötigen Informationen wie Dateipfade, Architekturmuster, Governor Limits und Validierungsschritte. So entsteht Code, der Sicherheitsprüfungen besteht und 90%+ Testabdeckung erreicht.

Wie stellt man die Sicherheit von KI-generiertem Salesforce-Code sicher?

Durch mehrstufige Validierung: Zuerst prüft ein Linter die Syntax, dann scannt der Salesforce Code Scanner nach Sicherheitslücken (SOQL Injection, fehlende FLS-Checks). Anschliessend wird in einer Sandbox deployed und alle Tests ausgeführt. Sicherheitsmuster wie WITH SECURITY_ENFORCED und Security.stripInaccessible() werden direkt im PRP als Pflichtanforderung definiert.

Ersetzt KI den Salesforce-Entwickler?

Nein, KI verändert die Rolle. Statt manuell Code zu schreiben, wird der Entwickler zum Architekten: Er definiert Anforderungen als PRPs, reviewt generierten Code und trifft Architekturentscheidungen. Die KI übernimmt die repetitive Implementierungsarbeit, während menschliche Expertise für Geschäftslogik, Sicherheit und Architektur unverzichtbar bleibt.

Welche Salesforce-Projekte eignen sich für KI-gestützte Entwicklung?

Besonders gut eignen sich Projekte mit klaren Anforderungen und wiederholbaren Mustern: Batch-Jobs, Apex-Controller, LWC-Komponenten, Test-Klassen und Integrationen. Weniger geeignet sind hochkomplexe Geschäftslogiken, die tiefes Domänenwissen erfordern, oder Projekte mit unklaren Anforderungen.

Was kostet KI-gestützte Salesforce-Entwicklung im Vergleich zur traditionellen?

Die direkten Tool-Kosten sind gering (Claude Pro ab $20/Monat, GitHub Copilot ab $10/Monat). Der eigentliche Mehrwert liegt in der Zeitersparnis: Projekte, die traditionell 4-6 Wochen dauern, können in 1-2 Wochen abgeschlossen werden. Die Investition in PRP-Templates und RAG-Systeme amortisiert sich bereits beim ersten grösseren Projekt.