Building with AI takes a lot of hours, and where you spend them matters as much as how many there are. Personal projects are the best place I know, because they leave room to get things wrong and fix them.
What the 10,000-hour rule actually says
The rule comes from Malcolm Gladwell’s Outliers, published in 2008. Gladwell wrote that mastering a field takes around 10,000 hours of practice, and the number stuck because it is easy to remember and easy to repeat.
The figure itself is highly debatable, but the research behind it, a 1993 study by the psychologist Anders Ericsson, makes a very useful point. Hours of practice make the difference when they go into “individualized diagnosis of errors, informative feedback, and remedial part training”, and that holds more than ever for anyone building with AI today.
Why personal projects are the right place to make mistakes
Those hours need somewhere to happen, and work is not necessarily the right place. A mistake in a workflow at work can reach customers, colleagues or company data, and the person who made it answers for it. That leaves little room to try something you do not fully understand yet.
On a personal project, a mistake only loses you time. You can break a pipeline, rebuild it from scratch and try another approach the next evening, and each problem you run into shows you what to learn next.
Where to find the first project
There are two good starting points. The first is a project you once ran at work before AI tools existed. Euclid rebuilds the GTM system I set up at Numeral, a fintech start-up, in 2022, and working on something I had already delivered let me see clearly how much AI speeds up that kind of project.
The second is about fixing a problem of your own. My training data was spread across multiple apps that did not talk to each other, so I built Sports Data to bring it into one place.
If neither comes to mind, everyday life offers plenty of options:
- sorting your emails
- a dashboard for your family or a local association
- a personal website
- a game to play with friends
What the project will ask you to learn
The first thing you learn on a project is how to give AI a clear goal and break the work into small steps. AI tends to jump to a solution before the problem is fully defined, and learning to slow it down is what has mattered most in my own projects.
The second is vocabulary. These terms come up constantly, and you need a working grasp of each one to deliver a project properly:
- models
- effort
- tokens
- context window
- memory
- harness
- handoff
The third is choosing an architecture, tools and a language: where the data lives, which tool runs what, and what the code is written in. I already used Python, but these projects took me well beyond my earlier use of it, and I learnt most of that by building.
Three first versions I had to redo
Each of my projects has had a first version that worked, which I had to redo once the project grew.
Orchestration. My first automations were scripts scheduled on my Mac. As the projects grew, I moved them to n8n, an automation tool running on a server, which could keep up with the load.
Documentation. As a project grows, so does its documentation, and mine ended up with files that contradicted each other. AI reads all of them and has no way to tell which one is right. I replaced them with a single source for each topic, and the other files now point to it.
Splitting a library for search. Fred, my AI training coach, answers questions by searching a library of training sessions and passing the relevant extracts to the model, a technique known as RAG. The library first has to be split into those extracts. My first version cut the text at a fixed length and split some sessions in half, so I had to redo it to split along the sessions themselves.
Theory after the first working version
Once a first version works, theory becomes much easier to take in, because you know which questions you are trying to answer. Courses, GitHub repositories, YouTube videos and questions put to AI throughout the build all serve that purpose.
The courses I took and the people I met this year helped most when a project had already raised the questions they answered. I had something concrete to discuss, so I could apply what I learnt straight away and refine what I had built, and going back over the basics made much more sense once I could see what the theory was for. I keep that in mind now that I teach courses on AI agents.
Two guardrails
Two things are worth settling before the first project. Be careful with personal data such as bank details or health records, and while you are still unsure how to protect them, choose projects where nothing serious happens if the data ends up online by accident. And pay for API usage with a virtual card with a spending cap, so a script stuck in a loop cannot run up a large bill.
How to read the trend of the week
Every week brings a new model or a new harness presented as the one that changes everything. AI works as a whole, though, and a new model rarely changes the result on its own. A badly organised project will make any model fail, whilst a well-structured one with clear tools gets good results even from a less capable model. What decides the outcome is what you control: your goals, the steps you break them into, the environment the AI works in and your architecture choices. There is no need to keep up with every announcement, and the hours you spend on your own project’s goals will teach you more than any of them.
Where to start
Pick one project and build it. You will make mistakes, so ask AI or the people around you about each one until you understand what went wrong. Stay curious about what you do not know yet, and once something works, ask yourself how you would rebuild it properly, because those are the hours that count.