What a leader builds to understand AI: a learning arc in eight repositories

The argument

Leaders are supposed to have opinions about AI. Most borrow them. I have borrowed some too, but the ones I trust came from building something small enough to finish and honest enough to fail. This is the sequence, in the order it happened, with what each one actually taught me. The repositories are public where they are mine.

1995: a year of AI, before it worked

I spent a year studying artificial intelligence at the University of Amsterdam, then left for computer science. Expert systems, logic, early neural networks: it was a field with beautiful theory and nothing you could ship. Thirty years later the strange part is how much of the vocabulary survived and how little of the humility did.

2000 to 2016: platforms, not models

Nothing in this stretch is AI. It is a ticketing platform for theatres, a decade of SharePoint and .NET architecture, and a complete club platform built on my own time. I include it because it is where I learned the thing that matters most for AI now: that the hard part is never the clever component. It is identity, integration, operations and the organisation around it. Every AI governance decision I have made since is a platform decision in disguise.

2018 to 2021: a data platform built as a path to machine learning

At a laboratory group I led the migration of on-premises reporting and BI to a single cloud data platform. The explicit long-term goal was machine learning for business insight. We never got to the models in my time there. What we got was the lesson that the data foundation takes years and the model takes weeks, and that any AI roadmap which schedules them the other way around is fiction.

Summer 2025: seven small repositories in a week

In July 2025 I built a batch of deliberately small things in C#: a console chatbot on the OpenAI API, a sentiment analyser and an image classifier on ML.NET, a voice assistant on the Windows speech APIs, a webcam object-detection scaffold, a code-review bot for pull requests, and a bundle of .NET 10 samples. None is impressive. Each took an afternoon. Together they did something a hundred articles had not: they made me feel where the seams are. Where the model is confident and wrong. Where the API is simple and the operations are not. Where “just add AI” meets a webcam that returns frames at the wrong rate.

I recommend this to every leader I meet. Build five trivial things. Your opinions will change.

Richard Hamming asked researchers what the important problems in their field were, and why they were not working on them. The small-repository version of that question is: what do you believe about AI that you have never once tried to run?

Spring 2026: a framework for a question I kept being asked

Which language should a team choose now that AI agents write much of the code? I kept hearing confident answers and no evidence. So I built an evidence-traceable framework: ten languages, eleven weighted dimensions, about 390 claims with primary sources, validators in continuous integration, and eight falsifiable predictions to be graded in May 2027. The method mattered more than the ranking. It is the first time I published something designed to be proven wrong on a schedule.

Summer 2026: the agent framework, then the platform

In May 2026 I started designing a self-hosted platform for governing AI agents, for Dutch local government, on the premise that agents are only governable if every boundary crossing is governed. The architecture came first: arc42 documentation, a decision register, a threat model that treats the platform’s own agents as adversaries. From July the build: thousands of commits in three months, a supervised pipeline of AI coding agents working under written rules, evaluation suites, a demonstrator on a Kubernetes cluster.

In parallel I evaluated more than a hundred agent frameworks and gateways, reading several at source, and turned the result into an evidence ledger strict enough to downgrade my own claims. That ledger and those evaluations are the material behind the eight field notes on this site.

What the arc is for

None of this makes me a machine-learning engineer, and I do not claim it. What it makes me is a product and technology leader who has touched every layer between a strategy slide and a running agent, recently, with his own hands. When I say a plan will not survive contact with the organisation, it is because I have watched mine not survive, in code, and fixed it.

If you lead a team that is about to bet on AI, I would offer one piece of advice from this arc. Before the strategy, build something. Small, finished, slightly embarrassing. It will cost a week and save a year.

The TARDIS is bigger on the inside. So, it turns out, is a weekend with seven small repositories.

References

The allusions and quotations in this piece, with their origin:

• Richard Hamming, “You and Your Research”, Bell Labs talk (1986): what are the important problems in your field, and why aren’t you working on them?
• Doctor Who (BBC, since 1963): the TARDIS, “it’s bigger on the inside”.