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.
Funktionen im Detail
Die Schleife trifft ihre Prüfinstanz — und benotet sich nicht selbst
Der Moment, der das Design beweist: Der ApexTestRunner meldet den PrescriptionTriggerHandler bei 88 % — unter dem 90-%-Ziel. Die Schleife erklärt keinen Erfolg; sie liest, welche Zeilen ungedeckt sind (die beiden addError-Guard-Branches), beschließt, einen Null-Appointment-Test zu ergänzen, und macht weiter. Davor hatte der Runner eine fehlformatierte Anfrage abgelehnt — die Schleife diagnostizierte die Ein-Klasse-pro-Aufruf-Beschränkung, statt blind zu wiederholen.
Build complete — der Lieferbericht der Schleife selbst
Die Abschlussnachricht des Laufs: 7 Objekte in Abhängigkeitsreihenfolge erstellt, 3 Trigger-Handler auf dem Kevin-O'Hara-Framework (Doppelbuchung blockiert, Rezepte nur bei abgeschlossenen Terminen, Zimmerverfügbarkeit synchronisiert), Coverage bei 92 / 100 / 90 %, dazu 19 Seed-Datensätze — die Live-Trigger end-to-end bestätigt: Die Admitted-Admission setzte Zimmer ICU-01 tatsächlich auf nicht verfügbar.
Unabhängiger Beweis in der Org — 9/9 grün, 93 % gesamt
In Salesforce verifiziert, nicht nur im Chat: Der Developer-Console-Lauf zeigt alle Tests grün und 93 % Gesamt-Coverage. Ein Blick auf das Coverage-Panel lohnt sich — die sechs MCP-Deployment-Tools selbst (ApexClassDeployer 97 %, ApexTestRunner 94 %, RecordCreator 97 %…) sind echte Apex-Klassen in der Org und ebenfalls getestet.
Die App, die die Schleife ausgeliefert hat — in Benutzung
Die Hospital-Management-Lightning-App mit allen sieben Objekt-Tabs, geöffnet auf einem echten Seed-Termin: Patientin Grace Adeyemi, Dr. Amara Okafor, ein Cardiac Follow-up mit Status Completed. Der Datensatzname ist die rohe ID — die Schleife hat das gebaut, kein Mensch hat nachpoliert.
Das Datenmodell, wie es deployt wurde
Schema Builder auf der fertigen Org: Department → Doctor, Appointment → Patient / Doctor, Prescription → Appointment, Admission → Patient / Room. Genau die Abhängigkeitskette, die die Schleife beim Deployment respektieren musste — Eltern zuerst, Kinder danach, zurückgegebene Record-Ids für die Seed-Daten wiederverwendet.
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.