I have always loved games.
And I mean always.
I have been playing Magic: The Gathering since 1994. Thirty-two years later, I still play it.
But there is something I probably enjoy even more than playing games: creating things.
That instinct runs through Building Creative Machines.
Over the past couple of years, I have used Generative AI to create hundreds of small experiments: generative art, mathematical visualisations, physics simulations, games, strange interfaces, business tools and things that are frankly difficult to classify.
You can explore many of them in the Building Creative Machines sketch collection.
Some are useful. Some are beautiful. Some are ridiculous.
That is partly the point.
One of my favourite things about Generative AI is how dramatically it reduces the cost of curiosity.
You can think:
What if I tried this?
And instead of putting the idea into the mental drawer labelled “maybe one day”, you can start building it immediately.
Some of these experiments even escaped the laboratory. A collection of my computational works was selected for Institution(ing)s, a European project in which the Gulbenkian Foundation is a partner.
But this summer I wanted to try something different.
I wanted to see what would happen if I stopped asking an LLM to make me something and started asking it to engineer a system.
That distinction turned out to be much more important than I expected.
From a 48-second game to a real system
Two years ago, I ran a small experiment.
I asked an early reasoning model to create a game for me.
Five prompts.
48 seconds of model processing.
A playable game.
I documented the experiment in How to Create a Game in Under a Minute?.
At the time, it felt extraordinary.
And it was.
The basic workflow was almost absurdly simple:
Describe → generate → run → find a problem → ask the AI to fix it → repeat.
This is what eventually became known as vibe coding.
I explored it obsessively. Art. Physics. Mathematics. Hardware. Games. Tools for companies. Hundreds of sketches.
And for relatively contained creations, it works astonishingly well.
But models have changed.
A lot.
Today, asking a frontier model to produce a nice animation in JavaScript almost feels like asking a calculator to multiply 12 by 7.
So I became interested in another question.
Could I use an LLM not to generate a piece of code, but to help me architect an entire deterministic product?
Not a demo.
Not a single script.
A system with mathematics, generation, validation, storage, client software, rankings, deployment, testing and rules that absolutely cannot change depending on the mood of the model.
That question became NEXT.
Meet NEXT
NEXT looks deceptively simple.
You see a collection of points.
You start at one of them.
Your objective is to find the only valid path through the puzzle, visiting every point exactly once.
That’s it.
Except, of course, it isn’t.
Each point can carry information. Position matters. Shape can matter. Numbers can matter. Proximity can matter. Locks can matter.
Rules constrain where you can go next.
And underneath this minimal interface sits a surprisingly interesting mathematical problem.
Imagine a puzzle containing 11 points.
If we naïvely considered every possible ordering of those 11 points, there would be:
11! = 39,916,800 possible sequences.
Almost 40 million.
If the starting point is already fixed, we are down to 10!, or about 3.6 million theoretical orderings.
Then the rules begin destroying possibilities.
You must go left.
You must choose the nearest compatible point.
The next number must be larger.
A particular shape may only connect under a particular condition.
A lock may eliminate another route.
And so on.
What starts as a huge combinatorial space becomes narrower and narrower until, for a properly constructed NEXT puzzle, exactly one valid complete path remains.
In graph theory, the underlying idea is related to a Hamiltonian path: a route through a graph that visits every vertex exactly once.
You don’t need to know graph theory to play NEXT.
You just need to find the path.
But the machine creating the puzzle needs to know that the path really exists.
And, more importantly, that there isn’t another one hiding somewhere.
That was where my little summer game became an engineering problem.
The LLM could not be allowed to “be creative”
There is a strange contradiction here.
I spent much of my last years working with generative systems. I recently published a methodological paper on validating Generative AI under prompt-induced variance.
A fundamental property of LLMs is that they are probabilistic.
Ask the same thing several times, and you may receive different answers.
That variability is wonderful when you want ideas.
It is much less wonderful when your software needs to determine whether a puzzle has exactly one mathematically valid solution.
NEXT therefore became an experiment in something I find increasingly important:
using probabilistic machines to build deterministic machines
The LLM could help me reason.
It could propose architectures.
It could write code.
It could inspect code.
It could find bugs.
It could challenge my assumptions.
It could refactor components.
It could run tests and investigate failures.
But the final system could not answer:
“I think this puzzle probably has one solution.”
It had to prove it.
Every time.
So we separated creation from truth
This became one of the most important architectural decisions in the project.
There is a protected puzzle-generation environment.
Its job is to create candidate puzzles and solve them exhaustively enough to certify the properties we require.
The problem and solution remain paired inside that controlled process.
Only puzzles that pass certification are published.
The public game doesn’t need to invent the puzzle. And it certainly doesn’t need an LLM deciding whether your move looks reasonable.
It receives a certified puzzle and runs deterministic logic.
Behind that sits another layer for results and rankings.
And then there is the client: the thing you actually see and touch in your browser, designed to work across environments and screen sizes.
Conceptually, it became something like this:
Generator → Solver → Certification → Published Puzzle → Player → Results
The AI helped build the machine.
The machine does not need AI to decide what is true.
That difference matters.
A lot.
I became the architect, not the typist
I built NEXT primarily with OpenAI Codex, using GPT-5.6 Sol at maximum reasoning for the most demanding architectural conversations. Astra was not available yet.
The application evolved into a modern web stack built around Next.js/React and TypeScript, with GitHub for version control and Netlify for deployment. Netlify’s Next.js infrastructure can take the application from the repository into a production web deployment.
What is unusual is my role in all this.
I studied Electrical and Computer Engineering. I even taught Probability and Statistics at the University. So concepts such as algorithms, probability, state, logic and architecture are not foreign to me.
But I haven’t been a programmer for more than 20 years.
I could understand what we were discussing.
I could challenge decisions.
I could recognise when something smelled wrong.
I could ask why one architecture was safer than another.
But I was not sitting there typing functions.
By the human-testing build, the project package contained 50+ source files. The system had generated and certified 365 puzzles with unique solutions (yes, one per day for the entire year!), organised into four difficulty families. The production build validated all the puzzles and their solutions, and the test suite passed.
I did not manually write the application code.
That sentence would have sounded ridiculous to me a few years ago.
Today it is almost less interesting than what replaced the coding.
Because I was definitely working.
A lot.
Prompting was the easy part
This is where I think the conversation about AI coding is often misleading.
People see the final result and conclude:
“The AI built it.”
Yes.
And no.
Codex can now perform substantial engineering work: writing features, refactoring systems, running commands, testing code and working across a codebase rather than simply producing isolated snippets.
But giving an agent the ability to write thousands of lines of software does not magically tell you what the software should be.
During NEXT, I changed my mind constantly.
Should every generated puzzle expose every type of rule?
No. That produced artificial constraints.
Should I force particular vocabulary into harder puzzles?
Initially I thought so.
Then testing revealed something more interesting: some combinations were theoretically part of the vocabulary but did not naturally emerge from the architecture at certain difficulty levels.
The tempting response was to force them.
We didn’t.
I preferred a mathematically coherent system to an editorially perfect spreadsheet.
At another point, puzzle generation seemed stuck.
It wasn’t.
The CPU was working. The advanced puzzles simply required substantially more certification work (the hardest ones can take more than 1 hour of remote computation).
But an invisible process that might take hours is a bad process to supervise.
So we stopped it.
Added progress visibility.
Reduced redundant retries.
Ran it again.
Another time, the automated tests said the tutorial navigation was correct.
The real browser said otherwise.
The browser was right.
We investigated the asynchronous behaviour and fixed it.
This happened again and again.
The model was extremely capable. But capability did not eliminate judgement. It made judgement more important.
One of my favourite mistakes
At one stage I wanted a neat distribution of puzzle difficulty:
4 Beginner
6 Easy
35 Medium
6 Hard
4 Cruel
The beginner level takes less than 5 seconds to complete. The easy level takes between 2 and 4 minutes. For a human, of course. LLMs will (as of today) find it very hard to solve the Hard & Cruel levels, even though they were created by them. Cruel levels only appear twice a month.
Perfect.
Except it adds up to 55.
I wanted 50.
The AI caught it immediately.
We adjusted the distribution.
Later, after watching the generation and certification cycle, I changed the structure again and removed the Cruel category from this experimental batch:
4 Beginner · 6 Easy · 30 Medium · 10 Hard
This sounds trivial.
It is trivial.
And that is precisely why I like the example.
Working with an advanced coding agent isn’t some science-fiction experience in which an infallible intelligence receives a perfect specification from an infallible human.
It is two imperfect parts interacting.
I make mistakes.
The model makes mistakes.
I change my mind.
The model sometimes takes an instruction too literally.
I ask for something that turns out to be incompatible with an earlier architectural decision.
It discovers that incompatibility.
We reconsider it.
That loop is the work.
The real breakthrough isn’t “AI can code”
We have spent the last few years being impressed that an LLM can write Python or JavaScript.
I think that story is becoming obsolete.
The more interesting development is that these systems can increasingly operate across levels of abstraction.
I can discuss the experience I want the player to have.
Then the mathematics required to guarantee it.
Then the architecture required to generate it.
Then how the generator must remain separate from the public application.
Then a bug.
Then a test.
Then a deployment issue.
Then return to whether the word “Hard” actually describes the human experience of solving puzzle #047.
That is profoundly different from autocomplete.
And it changes who can build complex systems.
Not because expertise disappears.
But because the place where expertise creates value moves.
Knowing a little became surprisingly valuable
My engineering background helped enormously.
Not because I remembered how to implement everything.
I didn’t.
It helped because I could think structurally.
Inputs.
Outputs.
States.
Constraints.
Probability.
Edge cases.
Separation of responsibilities.
Testing.
Failure.
I knew enough to ask questions.
And increasingly I think this will be an important pattern in AI-assisted creation.
You don’t necessarily need to know how to manufacture every brick.
But you need enough understanding to recognise whether the house should have a roof.
This is why I am uncomfortable with the idea that AI makes knowledge irrelevant.
I experienced almost the opposite.
My old knowledge suddenly became useful again.
More than twenty years after I stopped programming, concepts buried somewhere in my brain became an interface for directing an AI engineering agent.
That is fascinating.
Creation is moving one level up
For me, this is the bigger story behind NEXT.
Generative AI first made content cheap.
Then it made prototypes cheap.
Then code became cheap.
Now we are beginning to see something else becoming dramatically cheaper:
complexity itself.
Not free.
Not automatic.
Not reliable without supervision.
But accessible.
A creator can increasingly operate at the level of systems rather than individual artefacts.
Instead of drawing every frame, design the visual system.
Instead of writing every function, design the software behaviour.
Instead of manually constructing every puzzle, design a machine capable of generating and certifying puzzles.
That is a huge shift.
The unit of creativity is changing.
And now I want humans to break it
NEXT is online.
The current experimental set contains 365 + 50 certified puzzles, from Beginner to Hard.
They explore combinations of position, shape, number, locks, direction and proximity. Each has been generated and validated before reaching the public player.
But mathematical difficulty and human difficulty are not the same thing.
A machine can tell me that a puzzle has one solution.
It cannot automatically tell me whether you will find it elegant, frustrating, obvious, addictive or impossible.
For that, I need humans.
That is the next experiment.
So this isn’t a polished announcement pretending that a summer project has suddenly become the next global gaming franchise.
It is a laboratory.
I built it because I wanted to understand what happens when today’s most capable generative systems are pushed beyond one-shot creation and asked to help construct a deterministic architecture.
And because, ultimately, games are fun.
You can play it here:
Try a few puzzles.
Try to break it.
And please send me feedback privately, particularly if something feels confusing, unfair or unexpectedly satisfying.
I want to know.
Puzzle #005. Easy. 8 points
One final thought
In 2024, I used an LLM to make a game in 48 seconds.
In 2026, I used one to help me reason about and construct a system that generates, certifies, publishes and runs an entire family of mathematical games.
Those two experiences may look similar from the outside.
They are not.
The first was about generation.
The second was about engineering.
And I suspect that distinction tells us something important about where Generative AI is going.
We started by asking machines to write things for us.
Then we asked them to make things with us.
Now we are beginning to ask them to help us build machines that make things, while we define the rules, constraints, architecture and meaning of what gets made.
For someone who has always enjoyed creating more than consuming, that is an extraordinary place to be.
The irony is perfect.
I used one of the world’s most sophisticated probabilistic machines to build a game whose entire purpose is to tell you:
There is only one correct path.
Now you just have to find it.