Hospital Org — eine Salesforce-Org, gebaut von einer Agenten-Schleife, die ich entworfen habe
Eine vollständige Krankenhaus-Management-Org — 7 Custom Objects, eine Trigger-Handler-Architektur und 90–100 % Testabdeckung — nicht Klasse für Klasse von Hand geschrieben, sondern über eine einzige agentische Schleife gebaut: Claude deployt, testet, liest Fehler, korrigiert und wiederholt, bis alles grün ist — über sechs eigene MCP-Deployment-Tools, mit dem ApexTestRunner als Prüfinstanz.
- Jahr
- 2026
- Rolle
- Salesforce Developer — Agentic Delivery
- Technologien
- Model Context Protocol (Salesforce-hosted)Loop engineeringClaude (agentic driver)ApexTrigger-handler frameworkMetadata APITooling API7 custom objects90–100 % test coverageLightning App
Eckdaten
- Eine ganze Org, gebaut von einer Schleife statt von Hand: 7 Custom Objects (Department, Patient, Doctor, Room, Appointment, Prescription, Admission) in strikter Abhängigkeitsreihenfolge deployt, dazu 3 Trigger-Handler-Klassen, ihre 3 Trigger und 3 Testklassen — alles über eine einzige agentische Schleife, die ich entworfen habe
- Sechs eigene MCP-Tools als Hände des Agenten — MetadataObjectDeployer, ApexClassDeployer, ApexTriggerDeployer, ApexTestRunner, RecordCreator, AppBuilder — jeweils ein Salesforce-gehostetes MCP-Tool, das der Agent aufruft
- Die Prüfinstanz ist der ApexTestRunner, nicht das Modell: die Stop-Bedingung der Schleife ist objektiv — alle 3 Testklassen grün bei ≥90 % Coverage. Der Agent erklärt sich nicht selbst für 'fertig'; das tut der Test-Runner
- Echte Schleifen-Disziplin: Metadaten deployen → Apex deployen → Tests laufen lassen → die tatsächlichen Fehler lesen → korrigieren → wiederholen. Als ein Deploy eine undurchsichtige Script-Exception warf, diagnostizierte die Schleife die Ursachen (Objekt existiert bereits? Integration-User-Rechte? laufendes Deploy?), statt blind zu wiederholen
- Abhängigkeitsbewusste Ausführung: elternlose Objekte (Department, Patient) zuerst und parallel deployt; die Kinder (Doctor, Room → Appointment → Prescription, Admission) folgten und nutzten die zurückgegebenen Record-Ids für die Seed-Daten
- 90–100 % Testabdeckung über das deployte Apex — echte Coverage, die der Runner ausgeführt hat, keine von Hand behaupteten Zahlen
- Ehrliche Einordnung: die Org, die Objekte, die Trigger-Handler-Architektur, die Testklassen und die Coverage sind echt und wurden von der Schleife erzeugt. Gezeigt wird das Schleifen-Design und die Verifikations-Disziplin — nicht die Behauptung, KI ersetze Engineering-Urteilsvermögen. Das Urteilsvermögen steckt in der Schleife.
Das Problem
Mitte 2026 hatte sich die Debatte in der KI von Prompt Engineering zu Loop Engineering verschoben: Der Engpass ist nicht mehr die Fähigkeit eines Modells, eine Apex-Klasse zu schreiben — sondern das Design einer verlässlichen, überprüfbaren Schleife, in der ein Agent mehrstufige Arbeit erledigt, ohne dass ein Mensch jeden Schritt tippt. KI-Agenten können Code erzeugen. Schwierig wird es auf einer Plattform wie Salesforce — Governor Limits, Metadaten-Abhängigkeiten, Deployment-Reihenfolge — mit einem Verifikationsmechanismus, der stark genug ist, um dem Ergebnis zu vertrauen. Eine Schleife ohne echte Prüfinstanz ist nur ein teurer Weg, plausibel aussehenden Code zu erzeugen.
Der Ansatz
Ich habe den Org-Bau als Schleife behandelt, nicht als Checkliste. Ich definierte das Ziel (alle Objekte in Abhängigkeitsreihenfolge deployt, alles Apex deployt, alle Tests grün bei ≥90 % Coverage), gab dem Agenten ein festes Toolset — die sechs MCP-Deployment-Tools — und ließ Claude den Zyklus laufen: deployen → testen → Fehler lesen → korrigieren → wiederholen. Die Prüfinstanz ist der ApexTestRunner: eine objektive, externe Kontrolle, sodass das Modell den Erfolg nicht nach eigenem Ermessen erklären kann. Ich habe echte Schleifen-Disziplin eingebaut — eine klare Definition von 'fertig', harte Stop-Bedingungen und echte Anpassung: Als der Metadata-Deployer beim minimalen Aufruf eine generische Script-Exception warf, hielt die Schleife an und diagnostizierte die Ursachen (doppeltes Objekt, Rechte des Integration-Users, ein laufendes Deploy), statt denselben fehlschlagenden Aufruf zu wiederholen. Das Ganze läuft über Salesforce Hosted MCP, sodass der Sicherheitskontext der Org durchgängig greift.
Das Ergebnis
Eine vollständige, getestete Krankenhaus-Management-Org, erzeugt durch eine agentische Schleife, die ich einmal entworfen habe — der klarste Beleg in meinem Portfolio für die Verschiebung von 2026: weg vom Prompten eines Modells, hin zum Engineering der Schleife, die es ausführt. Es ist das Delivery-Gegenstück zu meinem MCP-Walkthrough: dort nutzt Claude meine Org, hier baut Claude eine. Dasselbe Muster — Ziel, Toolset, Prüfinstanz, Stop-Regeln — wendet ein Forward Deployed Engineer an, wenn er eine Kunden-Org mit agentischem Tooling aufsetzt oder erweitert.