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 I shipped 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. The interest never lapsed: I kept working on algorithms and followed the principles of machine learning as they arrived, through the papers and the feeds of the field, without a production reason to apply them. I include the stretch 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, and on that foundation we built machine learning with a deliberately narrow scope: object detection that recognised laboratory specimens as they were shipped in and checked them against the work order and the supplied sample, and anomaly detection on sample batches. Each was as much a probe of the field’s maturity as a product; the point was to find out what machine learning could carry in a laboratory in 2019 and what it could not yet. What the stretch taught me is 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.

2025: seven small repositories, months of evenings

Over several months of study in 2025 I built a batch of deliberately small things in C#, and pushed them to GitHub together in the summer, which is why they look like a week’s work: 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 a few evenings. 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, are a few months of evenings 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”.