Deel 3 van Kotlin: een kijkje in de keuken bij Leap

Hoe Leap e-mails van netbeheerders automatiseerde met Kotlin en LLM’s

De e-mail kwam om 02:37 binnen.
Geen webhook, geen API-call, gewoon een bericht van een netbeheerder:

“URGENT: reduce power consumption in region west.”

Tot voor kort las iemand dat handmatig.
Nu doet Kotlin het.

Van inbox naar impact

Wanneer het elektriciteitsnet uit balans raakt, springt Leap in.
Het bedrijf runt een virtual power plant (VPP) dat duizenden verspreide apparaten, batterijen, laadpalen, airco’s en warmtepompen, aanstuurt om tijdelijk minder stroom te verbruiken of juist terug te leveren.

“Wanneer het net piekt, zorgen wij dat apparaten meebewegen. En dat gebeurt in realtime, op enorme schaal.”
— Bart Kummel, Principal Engineer bij Leap

“Sommige e-mails bevatten niet één opdracht, maar meerdere. Elke opdracht vroeg weer om meerdere checks en calls. Synchroon werd dat gewoon te traag.”
— Ricus van Roond, Software Engineer bij Leap

De uitdaging? Niet elke netbeheerder communiceert even modern.
Sommigen sturen nette API-calls.
Anderen sturen… e-mails.

Soms met gestructureerde data. Soms met een bijlage.Soms gewoon: “can you reduce by 5MW?”.
Jarenlang las een supportdesk deze berichten handmatig en activeerde de juiste “dispatches” in het systeem.

“Het werkte, maar het was niet schaalbaar. We wilden mensen uit de lus halen, zonder controle te verliezen.”

Van monnikenwerk naar machine-intelligentie

De eerste poging: regex en template parsing.
Prima voor één afzender. Rampzalig bij vijf. Zodra iemand “Start Time” veranderde in “Dispatch Initiation”, viel alles om.

“We wilden een parser die net zo flexibel was als de mensen die we probeerden te vervangen.”

Leap bouwde een lichtgewicht Kotlin-service die binnenkomende e-mails automatisch verwerkt.
Afhankelijk van de afzender kiest de service een bijpassende prompt die uitlegt wat eruit gehaald moet worden, velden als start_time, end_time en dispatch_target.

De service gebruikt een Large Language Model (LLM) om de e-mail te lezen en een strikt JSON-resultaat terug te geven.
Geen hallucinaties toegestaan.

“We gebruiken LangChain4j. Het is minimalistisch, maar precies wat we nodig hebben.”

Kotlin zorgt voor type-safety, LangChain4j voor AI-abstractie, en samen maken ze van e-mails weer data.

Prompts in YAML, niet in code

Elke e-mailsoort heeft zijn eigen YAML-prompt.
Zo kunnen operations- en marktteams nieuwe formats toevoegen zonder een developer te bellen.

email_parser:

  sender: "operator@example.com"

  prompt: |

    Extract dispatch instructions from the following email:

    Subject: {email_subject}

    Body: {email_body}

    Return JSON with fields:

   - start_time

   - end_time

   - dispatch_target

“Sommige netbeheerders veranderen hun format zonder het te melden.
Doordat prompts buiten de code staan, kunnen we direct bijsturen zonder een nieuwe release.”

Leren, verfijnen, itereren

De service leerde snel.
Met temperature = 0.0 bleef de output voorspelbaar.
Een paar goedgekozen voorbeelden in de prompt verhoogden de consistentie enorm.

Toch was niet alles perfect:
slechte e-mailformatting kon het model nog in de war brengen.
Maar dankzij de controlelagen in Kotlin bleef de betrouwbaarheid hoog.

“We gebruiken AI niet om beslissingen te nemen, maar om data te extraheren.
De mens beslist. De AI berekent.”

De resultaten

Vandaag draait de LLM-service in productie.
Wat ooit een 24/7 menselijke taak was, gebeurt nu automatisch, en bliksemsnel.

• Directe responstijden, zonder wachtrijen
• Nieuwe dispatch-programma’s toegevoegd in minuten
• Volledige traceability van e-mail tot JSON-output

“We noemen het geen AI-transformatie.
Het is gewoon automatisering die werkt.”

Versnellen met niet-blokkerende calls 

Naarmate het aantal energieprogramma’s dat de service ondersteunde toenam, groeide ook het aantal e-mails dat verwerkt moest worden. Sommige e-mails bevatten niet één opdracht voor een enkele resource, maar meerdere. Voor elke resource moest eerst een aparte call worden gedaan om te controleren of er meters beschikbaar waren. Vervolgens moesten de meters per resource worden gegroepeerd, en moest er per resource opnieuw een call worden uitgevoerd om de opdrachten te versturen. 

Dit resulteerde in meerdere synchrone calls die samen een vrij lange keten opleverden. Daarom besloot Leap om deze calls uit te voeren met coroutines. Dit is een krachtig onderdeel van de Kotlin-taal waarmee je aanroepen naar externe systemen niet-blokkerend kunt laten verlopen. De service hoeft dan niet te wachten tot een antwoord binnen is, maar kan in de tussentijd andere taken uitvoeren. Zodra alle antwoorden beschikbaar zijn, gaat de service verder met de volgende stap in het proces. 

De voordelen in de praktijk: 

• De service blokkeert niet tijdens wachttijd.
• Meerdere calls kunnen parallel worden uitgevoerd. 
• Dankzij structured concurrency blijft de flow logisch en beheersbaar, ondanks het parallelisme. 

 Door deze aanpak verdwenen de lange ketens van opeenvolgende calls en werd de applicatie merkbaar sneller.

Kotlin als stille kracht

De hele service draait op Kotlin, bewust.

“Als het compileert, weet je dat het klopt.
En dat is wat je wilt als AI-uitkomsten invloed hebben op energiedistributie.”

Kotlin’s type-safety, expressiviteit en stabiliteit maakten het mogelijk om experiment en productie te combineren.
Het bewijs dat moderne JVM-technologie niet alleen betrouwbaar, maar ook elegant kan zijn.

Over deze reeks

Met Kotlin: een kijkje in de keuken laten we zien hoe Nederlandse JVM-organisaties Kotlin inzetten voor échte impact.
In aanloop naar Kotlin Dev Days 2025 spreken we CTO’s, engineering managers en developers die het ambacht van software-ontwikkeling dagelijks vormgeven.

Zij bouwen. Wij luisteren.

Wil je erbij zijn op Kotlin Dev Days 2025?

Volg onze LinkedIn-pagina voor ticketraffles, community-verhalen en nieuwe edities van Kotlin: een kijkje in de keuken.