Energy-Based Models: het alternatief voor LLMs dat Dan Shipper zelf nog niet kende

Hoofdonderwerpen

• EBMs vs LLMs — Eve (oprichter Logical Intelligence) legt uit wat Energy-Based Models zijn en waarom ze fundamenteel anders werken dan de LLMs die wij kennen
• Correctheid als product — waarom deterministische, verifieerbare AI cruciaal wordt zodra AI in mission-critical systemen belandt (auto's, vliegtuigen, energienetten)
• Het token-probleem — LLMs zijn autoregressief (ze voorspellen één token tegelijk op basis van de vorige), wat ze duur én 'blind' maakt voor de bredere context
• Latent variables — hoe EBMs niet alleen patronen zien maar ook de regels achter de data begrijpen en opslaan
• De staat van de AI-industrie — waarom er zoveel geld in LLMs blijft stromen ondanks een plateau, en hoe EBMs complementair kunnen zijn

Key insights

Eve runt Logical Intelligence, een foundational AI company (bedrijf dat eigen fundamentele AI-architectuur bouwt, geen wrapper om bestaande modellen). Ze bouwen zowel LLMs als EBMs in-house, met focus op correctheid van software en hardware.

Haar kernargument: LLMs zijn taal-afhankelijke intelligentie, en dat is vaak onzinnig. Als je je auto bestuurt of door je huis loopt, gebruik je geen taal. Toch proberen we via LLMs alles naar taal-ruimte te vertalen om het daarna terug te decoderen. Dat is duur én foutgevoelig.

Haar mooie analogie: een LLM die door San Francisco navigeert is als iemand met tunnelvisie die één richting tegelijk kiest en niet terug kan draaien als hij een gat in de weg ziet. Een EBM heeft 'bird view' — het hele energie-landschap in zicht — en kan een andere route kiezen.

Concrete definities die ze geeft:

• EBM (Energy-Based Model) — model dat data direct mapt naar een 'energie-landschap' (een soort kaart waarin lage punten = waarschijnlijke uitkomsten, hoge punten = onwaarschijnlijke). Het minimaliseert energie i.p.v. tokens te voorspellen. Komt uit de natuurkunde: alles in de natuur zoekt de laagste energie-toestand.
• Autoregressief (hoe LLMs werken) — één token tegelijk voorspellen op basis van de vorige tokens, zonder terug te kunnen
• Latent variables — verborgen variabelen die de regels achter de data opslaan, niet alleen de patronen
• Diffusion models — evolutie van EBMs die werken met sparse data (weinig trainingsdata) door ruis toe te voegen en dan te reconstrueren
• Internal vs external verifiers — LLMs zijn black boxes (alleen output checken, bijv. met Lean4, een proof-taal die wiskundig bewijzen machine-verifieerbaar maakt). EBMs zijn tijdens training inspecteerbaar, dus je hebt verificatie aan beide kanten.
• Code specifications — de regels/logica die beschrijven wat je code moet doen (i.p.v. de code zelf schrijven). Eve's droom: van vibe coding naar 'vibe code specifications' waarbij je in natuurlijke taal specificeert en formeel verifieerbare code eruit krijgt.

Over de industrie: Eve denkt dat LLMs plateauen (incrementele verbeteringen, geen phase transition meer). Grote sectoren — banken, trading, drug discovery, energiegrids — gebruiken nog bijna 0% LLMs voor data-analyse omdat bedrijven hun data niet in 'one big brain for all' willen stoppen. Er is geen goede B2B-LLM-laag. Positief signaal: ze weet dat sommige big tech labs nu ook intern aan EBMs werken.

What to Build

Deze aflevering bevat geen concrete buildable workflow of vibe-coding project. Het is een conceptueel/architectuur-gesprek over een fundamenteel andere AI-aanpak (EBMs) die Eve's bedrijf bouwt. Haar modellen zijn nog niet als publieke API beschikbaar zoals Claude of GPT.

Wel interessant om in de gaten te houden:

• Logical Intelligence op X en LinkedIn — als hun 'Kona' model publiek wordt, is dat potentieel interessant voor taken waar correctheid telt (bijv. forecasting op je verkoopdata, voorraad-optimalisatie).
• Lean4 — als je ooit wil experimenteren met formele verificatie van code die een LLM genereert, dit is de taal die Eve noemt. Bestaat als open source (leanprover.github.io). Voor jouw Next.js/Supabase stack overkill, maar het concept — 'laat een tweede systeem checken of de output klopt' — kun je al simpel toepassen met tests + een tweede LLM-pass die kritisch de output reviewt.

Takeaways voor een specialty coffee ondernemer met AI

1. Niet elk probleem is een taal-probleem. Veel operationele dingen in een koffiebedrijf (forecasting van verkoop, voorraadplanning, energie-gebruik van roasters, route-optimalisatie bezorging) zijn spatial/numeriek. Een LLM die dit via tokens probeert op te lossen is duur en foutgevoelig. Voor dit soort taken: gebruik gewoon klassieke statistiek/ML of laat een LLM code schrijven die de berekening doet — niet de berekening zelf uitvoeren met tokens.

2. Het 'bird view' probleem in vibe coding is echt. Dan Shipper herkent het precies: als je lang vibe-codet aan een app, krijg je lokaal correcte code die als geheel een lappendeken is. Remedie: periodiek zoom-outen en Claude vragen 'wat is het onderliggende concept van deze app, en zou je het nu anders opzetten?' voordat je verder bouwt. En: specificeer vooraf in natuurlijke taal wat de app doet (Eve's 'code specifications' idee) — dat maakt je LLM-samenwerking veel robuuster.

3. Verifiers zijn de volgende stap. Het idee 'laat AI output genereren, en laat een tweede systeem (test, LLM, of formele checker) verifiëren of het klopt' is universeel toepasbaar. In jouw context: bij elke AI-output die richting klanten of financiën gaat, bouw een tweede check-laag in. Bijv.: als AI een menu-beschrijving of nieuwsbrief genereert, een tweede prompt die specifiek checkt op feitelijke correctheid, tone-of-voice en brand guidelines.

4. Plateau-claim met gezond wantrouwen. Eve heeft belang bij haar verhaal (ze verkoopt EBMs). Maar haar punt dat LLMs nog geen echte B2B-traction hebben in mission-critical industrieën klopt en is belangrijk: voor jouw bedrijfskritische beslissingen (marges, recepten, kwaliteitscontrole) niet blind op een LLM leunen — altijd verifiëren.

5. EBMs op je radar houden. Als deze architectuur volwassen wordt en via API beschikbaar komt, is het bij uitstek geschikt voor kleine specialty-bedrijven die niet miljoenen tokens willen verbranden aan simpele numerieke voorspellingen. Niet iets om nu op te wachten, wel iets om over een jaar opnieuw te checken.