Salesforce im Club – Episode 3

Vibecoding: Von „das nervt jeden Abend“ zur fertigen SumUp-Integration

„Vibecoding“ ist gerade eines dieser Wörter, die überall auftauchen. Und wie bei vielen neuen Buzzwords kann man sich natürlich fragen: Ist das jetzt wirklich etwas Neues, oder einfach nur ein schicker Begriff dafür, dass KI Code schreibt?

Ich glaube, man versteht das Konzept am besten an einem echten Beispiel.

Und meines begann nicht mit einer Idee für irgendeine fancy App. Sondern mit einer ziemlich banalen Frage aus unserem Club-Alltag: Warum ist es eigentlich so umständlich herauszufinden, wie viel Geld über unsere SumUp-Terminals gelaufen ist?

Das Problem: Die Abrechnung nach einer Veranstaltung

Im NY.Club nutzen wir unter anderem SumUp-Geräte für Kartenzahlungen. Am Ende einer Veranstaltung kommen dann nach und nach die einzelnen Bereiche zur Abrechnung: Bar, Garderobe, Eintrittskasse und so weiter.

Dabei interessiert mich natürlich nicht nur, was laut unserer internen Abrechnung umgesetzt wurde, sondern auch, was tatsächlich über die Kartenterminals gelaufen ist.

Bisher bedeutete das ziemlich viel manuelle Arbeit. Für jedes Terminal beziehungsweise jeden Bereich musste man sich die entsprechenden Umsätze zusammensuchen und dabei auch noch darauf achten, dass man wirklich den richtigen Zeitraum erwischt.

Denn eine Clubnacht hält sich bekanntermaßen nur bedingt an Kalendertage.

Eine Veranstaltung startet zum Beispiel am Samstagabend und endet Sonntagmorgen. Für unsere Abrechnung ist deshalb nicht „der Samstag“ relevant, sondern beispielsweise der Zeitraum 22:00 Uhr bis 08:00 Uhr am folgenden Morgen. Eigentlich ein perfekter Kandidat für Automatisierung.

SumUp hat doch eine API

Also habe ich mir die SumUp API angesehen. Und siehe da: Da geht ziemlich viel. Transaktionen lassen sich automatisiert abrufen und damit theoretisch auch direkt in unsere bestehende Salesforce-Anwendung integrieren, über die wir ohnehin bereits große Teile einer Veranstaltung abrechnen. Mit Claude Code sind schon ein paar kleine Components entstanden - aber eine Echtzeitintegration eines Drittanbieters ist dann schon etwas komplexer. Also hab ich die KI mal machen lassen.

Runde 1: Einfach mal beschreiben, was ich haben möchte

Mein erster Prompt war erstaunlich unspektakulär:

i need a new component that connects to sumup and displays the transactions + amount each terminal and for all terminals based on the event date of the event record, starting from 10pm until the following day 8am.

Das war eigentlich schon die komplette Produktbeschreibung. Ich wollte eine neue Lightning Web Component in Salesforce, die sich mit SumUp verbindet, anhand des Datums des jeweiligen Event-Datensatzes automatisch den passenden Zeitraum berechnet und mir anschließend die Transaktionen und Umsätze anzeigt. Von 22 Uhr bis 8 Uhr am nächsten Morgen. Also genau so, wie wir in der Realität arbeiten.

Zusätzlich hatte ich bereits einige Runden mit Claude Code gedreht und dafür in Skills recht klar beschrieben, was wir in Salesforce tun. Und tatsächlich: Die erste Version lief. Nicht perfekt. Aber sie lief.

Runde 2: Jetzt wird aus Code ein Produkt

Und genau hier wird das Ganze für mich interessant. Denn ich habe mich anschließend nicht hingesetzt und angefangen, den generierten Code Zeile für Zeile umzubauen. Ich habe mir stattdessen das Ergebnis angesehen und beschrieben, was daran noch nicht richtig oder noch nicht gut genug war.

lwc works and shows a result but i think there are some missing pieces: 1. the date/timestamp is in timezone +-0. the request should respect the local timezone and adjust it to local 22pm - 8am. 2. Terminal Information seems to be empty. Check the SumUp developer documentation if you can find more information how to get this. 3. i love the full sum on top. its great. but can you please add a sum each hour. maybe as sticky header. and the list inside a scrollable container with a fixed height. 4. as well it would be nice to see the payment method as information

Und das ist für mich ziemlich genau der Punkt, an dem aus „KI generiert Code“ tatsächlich Vibecoding wird. Ich habe nicht über einzelne Methoden, JavaScript-Funktionen oder CSS-Klassen gesprochen.

Ich habe beschrieben, wie sich die Anwendung verhalten soll. Die KI kümmerte sich um die technische Umsetzung.

Runde 3: Feinschliff

Mit der nächsten Version konnte man bereits ziemlich gut arbeiten. Aber natürlich fallen einem beim Benutzen sofort weitere Dinge auf.

check the deductions component how the scroll container is created there as inspiration... make the sums each hour sticky. currently the timerange from 22 until midnight is at the very end of the list. shouldn't it be at the beginning? can you add the sumup user that has been used for the transaction? add charts with the sum each user like you did for the transaction type

Das Spannende dabei: Die neue Komponente entstand nicht völlig losgelöst vom Rest der Anwendung. Ich konnte auf eine bereits vorhandene Salesforce-Komponente verweisen und sagen: Schau dir an, wie wir das dort gelöst haben, und orientiere dich daran.

Das ist ein gewaltiger Unterschied zu klassischen Code-Generatoren. Es geht zunehmend nicht mehr nur darum, Code zu erzeugen. Das System kann vorhandenen Code verstehen, Muster erkennen und neue Funktionen passend in eine bestehende Anwendung integrieren.

Und das Ergebnis?

Am Ende hatte ich eine Salesforce-Komponente, die mir für den jeweiligen Eventzeitraum direkt die Anzahl der gefundenen Transaktionen, den Gesamtumsatz, die Umsätze nach SumUp-Nutzer, die verwendeten Kartenarten beziehungsweise Payment Types sowie die einzelnen Transaktionen und die Umsatzentwicklung innerhalb des relevanten Zeitfensters zeigt. Und natürlich musste auch die notwendige Konfiguration für den sicheren Zugriff auf die SumUp API eingerichtet werden.

Das Ergebnis sieht inzwischen eher nach einem kleinen fertigen Produkt als nach einem Coding-Experiment aus.

Alle Transaktionen und Umsätze, direkt im Event in Salesforce. Kein Wechsel mehr in ein anderes Backend. Kein manuelles Zusammensuchen der Umsätze. Und vor allem weiß die Komponente automatisch, welches Zeitfenster zur jeweiligen Clubnacht gehört und zu welcher Bar bzw Position ein Umsatz zugeordnet werden kann. Es spart uns jeden Abend Zeit und vermeidet Abrechnungsfehler. Außerdem sehen wir in Echtzeit wie sich Umsätze verändern und wann man eine Bar schließen kann.

Ist das jetzt wirklich „Vibecoding“?

Für mich: ja. Denn ich habe bei dieser Entwicklung hauptsächlich vier Dinge gemacht:

Ich habe das Problem beschrieben. Ich habe mir das Ergebnis angesehen. Ich habe erklärt, was noch nicht stimmt. Und ich habe beschrieben, wie ich es stattdessen gerne hätte. Natürlich verschwindet Softwareentwicklung dadurch nicht. Man muss weiterhin verstehen, was die Anwendung tut. API-Zugänge müssen sauber konfiguriert werden. Credentials gehören sicher gespeichert. Zeitzonen sind plötzlich doch komplizierter als gedacht. Datenmodelle, Berechtigungen und Fehlerfälle existieren weiterhin.

Aber die Ebene, auf der ich mit dem System interagiere, verschiebt sich. Statt jede technische Einzelheit selbst umzusetzen, kann ich mich viel stärker auf die eigentliche Frage konzentrieren: Was soll das Produkt können?

Der eigentliche Hebel: Vibecoding auf einer Plattform

Das Spannende an Vibecoding ist für mich deshalb nicht, dass jetzt plötzlich jeder innerhalb von fünf Minuten jede beliebige Software bauen kann. Das wäre mir zu einfach. Viel interessanter finde ich, dass die Distanz zwischen einer Idee und einem funktionierenden Prototyp dramatisch kleiner wird.

Gerade kleine interne Tools waren früher oft typische Kandidaten für: „Wäre eigentlich praktisch, aber dafür lohnt sich der Entwicklungsaufwand nicht.“ Genau diese Rechnung verändert sich gerade.

Und an dieser Stelle wird für mich die Plattform darunter entscheidend. Vibecoding auf Salesforce heißt eben nicht, bei null anzufangen. Datenmodell, Benutzer- und Berechtigungskonzept, bestehende Prozesse, APIs, Automatisierungen und die gesamte Business-Logik sind bereits Teil einer etablierten Plattform. Die KI kann sich dadurch viel stärker auf die eigentliche Lösung konzentrieren – statt erst die technische Basis dafür bauen zu müssen.

Genau darin liegt für mich ein ziemlich großer Hebel: Nicht nur schneller Code erzeugen, sondern neue Funktionen direkt dort entstehen lassen, wo Daten, Prozesse und Nutzer ohnehin schon zusammenkommen. Aus einer Idee wird so nicht nur schneller ein Prototyp, sondern im besten Fall eine Funktion, die sich tatsächlich in den laufenden Betrieb integrieren lässt.

Und vielleicht ist das am Ende die spannendere Perspektive auf Vibecoding: Die KI bringt Geschwindigkeit. Eine starke Plattform sorgt dafür, dass daraus etwas Nutzbares wird.