De voorbije weken bouwde ik een reeks productconfiguratoren bovenop de kernel. Ze draaien op showcase.kubuz.net. Voorlopig zijn het er zes: een rvs-werkblad met geplooide randen, een DIN-flens, een lasergesneden lampenkap, een plaatwerkovergang, een stalen trap en een onregelmatige kastenwand.
Ze verschillen bewust sterk van elkaar. Sommige zijn geplooid plaatwerk. Andere zijn profielen. Eén bestaat vooral uit houten panelen. Dat was net de bedoeling. Ik wilde zien of één kleine fabricagetaal heel verschillende producten kon dragen, of dat elk nieuw product me terug de kernel in zou dwingen.
Dit artikel gaat over wat ik daaruit geleerd heb.
Drie lagen, één browsertabblad
In deel 2 beschreef ik de architectuur zo:
productbetekenis → fabricage-intentie → geometrie
De showcase is de eerste plek waar die drie lagen echt samenwerken.
Kubuz CPQ bevat het product: de parameters, de regels, de opties en de prijs. Het zet een configuratie om in een fabricageprogramma in JSON. De kernel evalueert dat programma in de browser via WebAssembly.
Er draait geen CAD-pakket op de achtergrond. Geen server die een model herbouwt. Als je een waarde wijzigt, lopen de regels, wordt het programma opnieuw gegenereerd en evalueert de kernel het opnieuw. Geometrie, stuklijst, gewicht en prijs volgen.
Dat is de snelheid waar ik naar zocht toen ik begon. Geen render die snel lijkt, maar een product dat snel herrekent.
De trap
De trap is het zwaarste product in de showcase, en het product waar ik het meest trots op ben.
Je geeft een verdiepingshoogte op. Daaruit berekent hij de treden: optrede, aantrede, hellingshoek en de controle 2 × optrede + aantrede. Je kiest recht, L of U. En dan bouwt hij de trap zoals een werkplaats hem bouwt.
UPN-trapbomen met de vlakke kant naar binnen. Verstekte verticale voeten op voetplaten. Loodrecht afgezaagde koppen met geboutte kopplaten. Een verstekt bordesframe op kolommen. Stijlen op de flens, leuningen met knieregels door sleufgaten in de stijlen of verticale spijlen op gelijke afstand. Roosters, geplooide treden of eik.
Voor de standaard L-trap komt dat op 17 optredes, 167 staven om te zagen, 21 platen, 112 gaten en sleuven en 16 platen om te snijden. De configurator geeft er een artikelcode aan en berekent de prijs uit de zaag- en snijlijsten.
Onder de motorkap gebeuren twee dingen die belangrijker zijn dan het 3D-beeld.
De kernel controleert elk onderdeel op botsingen. Als een stijl tegen een trapboom loopt, weet hij dat.
En de CPQ toetst elk getal aan EN ISO 14122-3 of aan de Belgische regels voor werkplaatsen, publieke gebouwen en woningen, met het artikel achter elke waarschuwing. Je kan afwijkingen toelaten, maar dan meldt de configurator dat het resultaat mogelijk niet conform is.
Dat tweede deel is geen geometrie. Het is productkennis. En het bleek het grootste deel van het werk te zijn.
De onregelmatige kastenwand
De kastenwand is het tegenovergestelde van de trap. Geen normen, geen staal. Een greeploze wand van matte deuren, opengebroken door een veld van vakken in een tweede materiaal.
Je bepaalt waar de wand zich opent, hoe open hij wordt en een ontwerpnummer. De configurator legt het onregelmatige raster, het getrapte silhouet, de vakken, hun dieptes en legplanken. De standaard wand komt uit op 154 platen om te snijden, 14 deuren en 9 open vakken.
Wat ik hier sterk aan vind, is het ontwerpnummer. Verander het en je krijgt een andere wand. Ga terug naar hetzelfde nummer en je krijgt exact dezelfde wand terug. Het lijkt generatief, maar het is deterministisch. Elke variant is reproduceerbaar, kan geprijsd worden en kan gemaakt worden.
En hij draait op dezelfde kernel als de trap. Een plaat is een plaat, of het nu lasergesneden staal is of een gelakt houten paneel.
Het ontwerp is geïnspireerd op het werk van Filip Janssens (filipjanssens.be). De eer voor het idee gaat naar hem.
Waar AI past
Ik bouw deze producten met AI-agents. Maar de agent is niet waar het begint.
Elk product begint met onderzoek. Voor de trap betekende dat eerst de normen: EN ISO 14122-3 voor toegang tot machines, de Belgische regels voor werkplaatsen, publieke gebouwen en woningen. Dan materialen en profielen: welke UPN-maten, welke plaatdiktes, roosters, geplooide treden of eik. Dan de constructie: hoe een werkplaats een trap echt bouwt, waar hij zaagt, waar hij last, waar hij bout. En dan de vorm: recht, L, U, bordessen, hoe een leuning een hoek omgaat.
Dat gaat allemaal in één uitgebreid document. Geen prompt, maar een echte beschrijving van het product.
Dan begint het gesprek. Ik gebruik AI om dat document scherper te maken. Het stelt me veel vragen: wat gebeurt er bovenaan de trap, hoe worden de stijlen bevestigd, wat als de breedte verandert, welke regel wint als twee regels botsen. En ik stel er evenveel terug. Waar komt dit getal vandaan? Wat zegt de norm hier echt? Wat zou een constructeur anders doen?
Dat gaat heen en weer tot er een diep begrip van het product is. Pas dan laat ik de eerste agent het bouwen.
En de eerste versie is nooit de laatste. Ik bekijk ze in de browser, controleer de getallen, zoek wat er fout is, en itereer. Vaak duurt dat veel rondes.
Hier betaalt de kleine taal uit deel 2 zich terug.
De agent moet geen plaatwerkuitslag berekenen of de lengte van een verstekte trapboom. Hij schrijft dingen als zet een flens op deze rand of dit profiel eindigt in een verstek onder deze hoek. De kernel doet de geometrie, en dat deel blijft deterministisch.
Omdat de kernel nu vragen kan beantwoorden over zijn eigen resultaat, krijgt de agent ook iets terug waar hij mee verder kan. Botsen onderdelen? Sluiten twee uiteinden op elkaar aan? Plooit een plaat in zichzelf?
programma wijzigen → evalueren → controleren → corrigeren
Maar het belangrijkste gebeurt voor de agent één regel schrijft. De AI wist niet dat een werkplaats de vlakke kant van een UPN naar binnen zet. Hij wist niet welk artikel de optrede van een trap beperkt, of dat een trap van 900 mm breed al een vlag geeft voor toegang tot machines. Die kennis kwam uit het onderzoek, uit jaren tekenwerk aan dit soort producten, en uit het lange gesprek dat er een document van maakte waar de agent mee kon werken.
Een agent die JSON schrijft zonder die kennis maakt iets dat op een trap lijkt. Een agent die vertrekt van een diepe beschrijving van het product maakt een trap die gebouwd kan worden.
De taakverdeling uit deel 2 klopt dus nog, met één laag erbij:
- productkennis bepaalt wat mag, hoe het gemaakt wordt en wat het kost
- de agent helpt het product schrijven en aanpassen
- de kernel zet het om in geometrie en controleert het
Geen van de drie volstaat op zichzelf.
Wat er nog niet is
De showcase is een showcase. De prijzen zijn indicatief. Op een trage verbinding duurt het laden van het 3D-model langer dan ik wil, al herrekent elke wijziging bijna meteen zodra het geladen is. En geen van deze producten is al door een echte werkplaats gegaan.
Dat laatste is de echte test.
De vraag uit deel 2
In deel 2 vroeg ik hoeveel configureerbare fabricage je zo kan beschrijven voor je echt volledige CAD nodig hebt.
Een volledig antwoord heb ik nog altijd niet. Maar het gaat verder dan ik verwachtte. Een U-vormige stalen trap met bordessen, leuningen, normcontrole en zaaglijsten past erin. Een onregelmatige meubelwand past erin. Geen van beide had ergens in de lus een CAD-document nodig. Voor veel configureerbare producten is dat al genoeg.
De volgende stap kan ik niet alleen zetten: een echt product uit een echte werkplaats erdoor halen.
Daarom zoek ik een pilot.
Eén bedrijf dat een configureerbaar product maakt: trappen, platformen, leuningen, plaatwerkbehuizingen, meubels, of iets anders opgebouwd uit profielen en platen. Een product dat je vaak offreert, in veel varianten, waarbij elke offerte nog betekent dat iemand het opnieuw tekent of herrekent.
We halen dat product door hetzelfde proces als de trap. Eerst het onderzoek en de productbeschrijving, dan de configurator, dan de toets aan hoe jullie het echt bouwen. Het doel is een werkende configurator voor jouw product, met stuklijsten, zaag- en snijlijsten en een prijs die elke wijziging volgt, in de browser, op je eigen website als je dat wil.
Voor mij toont de pilot waar deze aanpak standhoudt en waar niet. Voor jou levert hij een snelle manier van offreren op, en een productmodel dat niet langer in het hoofd van één persoon zit.
Klinkt dat als jouw product, stuur me een bericht. En wil je gewoon zien hoe ver het gaat, probeer dan de configuratoren op showcase.kubuz.net. Vind je iets dat breekt, dan hoor ik het heel graag.
Deel 1: waarom ik een semantische fabrication kernel bouw. Deel 2: een fabrication kernel voor webconfiguratoren.