TPD000 The Beginning: Why I Started Learning AI the Long Way Round
The Project Diaries – Entry 000
The Project began years ago, long before AI became part of the conversation. It started as an idea I wasn’t sure was even possible, something I began shaping quietly, slowly, and deliberately in the background. It isn’t secret, but it is mine, and I’m not talking publicly about what it does or how it works. What matters here is that AI arrived later. It became a contributor to something that already existed, and that shift is what made the process worth documenting.
The Project sits alongside everything else I make. It’s another expression of the same instinct: to build something meaningful, human, and quietly ambitious. Something that grows through curiosity rather than convention.
When generative AI began appearing everywhere, my instinct was probably the opposite of what most people expected. I didn’t rush to read every article or watch every keynote. I didn’t try to keep up with the daily stream of new models and frameworks. Instead, I stepped back.
It wasn’t because I wasn’t interested. I was fascinated. But I also knew how easy it is to inherit someone else’s assumptions before you’ve had the chance to form your own. More so with emerging technology. And… I’ve always learned best by building. I need to touch the work, shape it, break it, fix it, and understand it from the inside out.
So rather than starting with established methodologies, I began with a real problem and let it lead me. I wanted to see where my own instincts took me before comparing them with the wider body of knowledge. It isn’t the most efficient approach. It means making mistakes that other people have already solved. It means occasionally reinventing something that already exists. But it also means every design decision is rooted in understanding rather than imitation.
When I eventually introduced AI into The Project, the questions changed. I wasn’t asking what AI could do. I was asking something far more practical.
How do you introduce a new contributor to a complex body of knowledge? How do you maintain consistency over time? How do you preserve quality when contributors change? How do you ensure that knowledge evolves rather than fragments?
Those questions became more interesting than the models themselves. They were architectural questions. Cultural questions. Questions about systems, not tools.
As The Project grew, I inevitably began reading more of the existing research and engineering work. Unsurprisingly, many of the ideas I had arrived at independently were already being explored elsewhere under different names and in different contexts. That wasn’t disappointing. It was reassuring. It confirmed that I was asking meaningful questions, even if I hadn’t yet learned the established vocabulary.
Looking back, I’m glad I approached it this way. Not because it produced something unique, but because it forced me to understand why certain decisions mattered before discovering how others had solved similar problems. Curiosity guided the first steps. Consensus came later.
This is why I’m starting The Project Diaries now. The repository already contains years of design decisions, experiments and lessons learned.
I chose the name The Project Diaries quite deliberately. These aren’t retrospectives written after everything worked. They’re snapshots of an engineering journey that’s still unfolding.
I wish I’d started documenting the thinking behind them much earlier.. The Diaries aren’t here to explain The Project. They’re here to record the process of building it, testing it, and understanding it. The contributors, the experiments, the failures, the unexpected successes, the architectural questions, and the moments where the system teaches me something I didn’t expect.
Because sometimes the long way round teaches you something the shortcut never could, and sometimes it just makes you smile!