Ideas become useful when a builder gives them a job.
Stop collecting concepts. Choose a real friction and build the system that removes it.
I have always been fascinated by the mind—and by the thing the mind produces that we call intelligence.
As a child, I thought intelligence was almost supernatural: some rare capability bestowed on human beings. Later, I began to see it as a biological advantage, the result of a physical system doing something extraordinary. But the question stayed with me: What is intelligence made of? What are its building blocks? And could we build something that behaves intelligently without first having to open a human brain and understand every part of it?
For years, artificial intelligence was mostly theoretical to me. I followed the early frontier labs, watched the field advance and tried to anticipate what the technology might make possible. I understood its significance, but I did not yet feel its practical relevance in my own hands.
Then, on 30 November 2022, OpenAI released ChatGPT as a research preview. Something I had mainly encountered as research suddenly became conversational, accessible and personal. I could interrogate it. Test it. Break it. Use it.
That was the moment I stopped wanting merely to follow AI and decided to learn how to build intelligence.
It was also when I made my first mistake.
The tutorial treadmill
I approached AI as a body of knowledge I had to finish before I could begin.
The plan sounded sensible: learn Python properly, study machine learning, understand neural networks, move on to transformers, then training, fine-tuning and deployment. Once I had covered the foundations, I would finally be qualified to build.
So I went looking for the best teachers. Khan Academy. Coursera. Udemy. YouTube. I watched lectures, took notes and felt the small satisfaction that comes from recognising a concept the second time you see it.
But recognition is not capability.
I could explain more terms, yet I still could not make a system work. I was accumulating answers to questions no real project had forced me to ask.
I tried to make the process more disciplined. I asked ChatGPT to design a curriculum. I created a timetable. I set reminders to study Python and the concepts behind training and fine-tuning models. A few weeks later, I had covered more material—and still had nothing I could point to and say: I built this. It works. Here is how I know.
The problem was not the quality of the courses. The problem was the frame.
I was treating preparation as progress.
The reframe
You do not learn AI and then build.
You choose something worth building, and the build tells you what you need to learn.
That sentence changed the direction of my work. It replaced a curriculum with a problem. Instead of asking, What should I study next? I began asking:
What real friction am I trying to remove?
What is the smallest system that could remove some of it?
What does success look like, and how will I measure it?
Those questions create productive ignorance. You begin before you understand everything. Then the build exposes the exact edge of your knowledge.
Your model returns the wrong structure, so you learn structured outputs. Your retrieval fails, so you learn embeddings, chunking and reranking. Your fine-tuning run looks impressive but performs worse on the task that matters, so you learn evaluations. Your agent claims it completed the work but changed nothing, so you learn tools, state and verification.
The theory is still essential. The sequence changes.
You no longer study a concept because it appears next in a course. You study it because the system in front of you has made the gap impossible to ignore.
The build pulls the learning. Measurement decides whether the learning mattered.
AI has become an engineering material
AI is still a science. Important theoretical work continues, and much of what engineers use exists because researchers discovered it first.
But for the rest of us, a second layer has become unavoidable: AI is now an engineering material.
We have models, APIs, open weights, training libraries, vector databases, evaluation frameworks and tool protocols. The practical question is no longer only, Can a machine produce intelligent behaviour? It is also, What can I assemble from the intelligence already available, under real constraints, for a specific person doing a specific job?
That distinction matters because a model demonstration is not the same thing as a working system.
A chatbot can draft a credit memo. A dependable credit-analysis system must also find the correct source documents, distinguish current figures from stale ones, calculate consistently, preserve evidence, respect permissions, flag uncertainty and let someone verify the result.
The model supplies capability. The surrounding system makes that capability useful.
This surrounding system is what I call the Harness: the tools, context, memory, rules, execution loop and feedback that allow a model to do work in the world. Anthropic makes a similar practical distinction in its guide to building effective agents: useful agentic systems combine models with tools and environmental feedback, and complexity should earn its place through better outcomes.
In compact form:
Agent = Model + Harness
A stronger model may improve the system. It does not eliminate the need for the system.
Intelligence is abundant. Attention is scarce.
As models improve and access gets cheaper, raw capability becomes easier to obtain. The difficult part is directing that capability toward the right problem with enough context, constraint and feedback to make the output dependable.
That is what I mean by attention here. Not only the attention mechanism inside a transformer, but directed domain attention: deciding what matters, what evidence belongs in context, which tools may be used, what rules apply and how success will be judged.
This leads to the formula at the centre of my work:
Intelligence + Attention = Friction Removed
Intelligence is the model’s capability.
Attention is the domain knowledge and system design that focus it.
Friction removed is the measurable result.
The last term is the one that keeps the formula honest. “Impressive output” is not a business outcome. A completed review with evidence, fewer manual checks, a shorter cycle time or a lower error rate might be.
The model is one component. Value appears only when the whole system changes an outcome.
Domain intelligence is more than fine-tuning
My first instinct was to think that a general model becomes useful in a specialist domain mainly through fine-tuning. Sometimes it does. But that is only one tool.
Domain intelligence can come from better instructions, carefully selected examples, retrieval from trusted sources, purpose-built tools, constrained workflows, explicit rules and rigorous evaluations. Fine-tuning earns its place when the task requires persistent behaviour or knowledge that these cheaper, more controllable methods cannot provide well enough.
The engineering question is not, How do I fine-tune this model?
It is, What is the least complicated intervention that produces the required result?
That is a much harder question because it forces you to define the result before choosing the fashionable technique.
Why I am building IntelligenceOS
I am applying this method through IntelligenceOS: a family of domain systems designed to do useful work in specific industries. Finance Operations and Risk is the first wedge because it is close to my work, the source material is demanding and the outcomes can be measured.
The aim is not to build a general model and declare it intelligent. The aim is to build a focused system that can handle a real workflow, show its evidence, operate within rules and prove whether it succeeded.
That means the build is also my curriculum.
When the data pipeline fails, that becomes the lesson in data engineering. When a model scores well on a generic benchmark but misses the task, that becomes the lesson in evaluation. When the model produces the right answer but cannot safely act on it, that becomes the lesson in the Harness.
And when the system works, the proof is not that I can explain the vocabulary. The proof is that a real piece of friction is gone.
Your first build does not need to be grand
If you are stuck in the same preparation loop, do not begin by choosing a model. Begin by choosing a friction you understand.
Write down one repetitive, judgement-heavy task in a domain you know. Define the evidence the task requires. Define what a correct result looks like. Then build the smallest version that attempts it—even if the first version is one prompt, one document and one test.
Give yourself seven days. At the end, you should have four things:
an input;
an output;
a test that distinguishes a useful output from a useless one; and
a written account of what failed.
That failure log is your real syllabus.
You are not trying to finish AI. Nobody can. You are trying to build one small system that does one real thing, then let the demands of that system pull you deeper.
Stop waiting to know enough.
Pick the friction. Build the first loop. Let the work teach you.
What is one task in your field that you understand well enough to test—and small enough to attempt this week?
This essay is Chapter 0 of Intelligence from Zero, my book, being written in public alongside the IntelligenceOS build.