Xavier Dekeyster

The through-line

Across the DX-Solutions and FieldGenius posts, Xavier Dekeyster keeps returning to one idea: real value is created in the messy middle, not in the simple cases. He builds this belief into how he talks about AI planning, AI-assisted coding, software architecture and even hiring. Early in the period covered here he is still describing FieldGenius as something being built and validated with VLAIO backing [4][9]; by mid-summer he is reporting a live client test that he treats as proof of what he "already believed for a long time" [1]. The shift is from stating a thesis to citing evidence for it.

The same instinct shows up when he talks about generative AI coding tools: he is willing to say publicly that the demos overstate how smooth the work really is, and that he still has to intervene in the code himself [11]. He applies the same standard to himself and to his product: impressive results are only meaningful once they hold up under complexity and change.

On complexity as the real test

Dekeyster frames FieldGenius's value proposition entirely around how it performs when things get hard, not when they are easy. After a blind 125-day parallel run against human planners, he reports that "op rustige dagen was de AI-planning minstens even sterk als de manuele planning," but that "op drukke dagen met veel wijzigingen, afhankelijkheden en uitzonderingen maakte Fieldgenius duidelijk het verschil," concluding "hoe complexer de puzzel werd, hoe sterker de AI presteerde" [1]. He is explicit that this is by design: "FieldGenius is niet gebouwd voor eenvoudige planningen. Het is gebouwd voor organisaties waar de realiteit voortdurend verandert" [1].

That same premise runs through how he describes the product's mechanics: "een planning is al achterhaald op het moment dat ze klaar is," which is why the system "continu bijsturen" based on live changes like traffic [2]. He traces the origin of FieldGenius directly to seeing planning as "één van de meest complexe operationele processen binnen organisaties" across dozens of client engagements [9], and extends the same logic to weather, arguing it should be treated "als een volwaardige planningsparameter" because most planning today "nauwelijks rekening" houdt with it [3].

On the gap between AI demos and reality

Dekeyster is willing to puncture his own enthusiasm about AI coding tools. After experimenting with "Claude Code, GitHub Copilot, Cursor, Windsurf, Lovable en Bolt," he says "de resultaten zijn indrukwekkend" but immediately qualifies it: "het niet altijd zo vanzelfsprekend is als sommige demo's doen uitschijnen," pointing to failure modes like "een deployment die blijft falen" or "een integratie die net niet werkt" [11]. He states plainly that "meer dan eens heb ik zelf rechtstreeks in de code moeten ingrijpen om verder te geraken," and attributes his ability to spot this to the fact that "wij bouwen zelf software en AI-oplossingen, waardoor we sneller zien waar de beperkingen vandaag nog liggen" [11].

On architecture over tools

When discussing the suite-versus-best-of-breed debate, Dekeyster's position is that the choice of platform is secondary to the design underneath it: "niet de software zelf bepaalt het succes, maar de architectuur erachter" [10]. He treats this as increasingly urgent "nu AI steeds meer toegang wil tot data, processen en kennis over verschillende systemen heen" [10], and describes FieldGenius itself in the same terms, as "geen zoveelste planningstool of ERP-module" but "een AI-gedreven intelligentielaag die bovenop je bestaande software werkt met of zonder UX/UI" [2].

On hiring for range

In his hiring posts, Dekeyster pushes against narrow role definitions. For a business development hire he specifies "geen klassieke salesfunctie, maar een rol waarin business development en accountmanagement hand in hand gaan," looking for someone who "energie krijgt van nieuwe klanten, sterke relaties opbouwen én meedenken over de digitale uitdagingen van bedrijven" [5]. For a SaaS architect role he draws the same line between execution and partnership: the person is wanted "niet om de technologiekeuzes voor ons te maken, maar om als sparringpartner een head start te geven vanuit praktijkervaring met vergelijkbare trajecten" [8].

From the stage

In the "Com uit uw kot" interview about the coronavirus crisis, Dekeyster describes DX-Solutions experiencing minimal disruption because of infrastructure the company already had in place for digital work and remote operations, and notes that the company paused only one project, and only because a client feared it would be unable to pay [12]. This concrete crisis-response detail, and the framing of resilience as a byproduct of prior digital investment rather than a new initiative, does not appear anywhere in the written posts.

Takeaways

• Before trusting an AI planning tool's claims, test it blind against real human output over an extended period; Dekeyster's own validation ran 125 days before he drew conclusions [1].
• Expect AI planning tools to show their value most on high-variability days with many exceptions and dependencies, not on quiet, simple days [1].
• Treat live external factors like weather as first-class planning parameters rather than afterthoughts, since most planning systems currently ignore them [3].
• Don't take AI coding tool demos at face value; budget time for deployment failures, integration issues, and direct code intervention even with tools like Claude Code, Copilot, Cursor, Windsurf, Lovable, and Bolt [11].
• When choosing between an all-in-one suite and specialized best-of-breed tools, focus the decision on the underlying architecture rather than the vendor promise [10].
• When hiring for business development or architecture ro