From user to maker: what changes · Building AI

Until this track, AI has been something you read about. Something other people built, that you used or did not, judged or did not, trusted or did not. From this section onward, that posture changes. You are about to become someone who builds — and the first thing to understand is what that word actually means.

What “building AI” is not

Open a newspaper in 2026 and “building AI” sounds like a thing only a handful of laboratories in California and Beijing can do. Trillion-parameter models. Twenty-thousand-GPU clusters. Electricity bills the size of a small country’s grid.

Set that picture aside. It is real, but it is not what this track is about.

Almost no one who builds with AI today is training a frontier model. The vast majority — including most of the engineers you would call “AI engineers” at Khalti, eSewa, or any global tech company — are doing something far more modest, and far more useful: they are applying models other people built, to problems those people never thought about.

A working definition for this track:

That is it. The model is almost always borrowed. Your contribution is the wiring around it — and the judgment about which problem to point it at.

Three small examples, all built by people like you

To make this concrete, three real-shaped projects, each buildable in a weekend by someone who finishes Course 01 of this track:

A NEPSE alert script. A short Python program that pulls the day’s NEPSE closing prices from an API, asks a language model to write a one-paragraph summary in Nepali (“the market closed lower; banks led the fall; here is why that might be”), and sends it to your phone via Telegram at 4 pm. No new model. No training data. ~80 lines of code. Genuinely useful to a small investor who cannot read English financial news.
A Devanagari OCR demo. A web page where a user uploads a photo of Nepali handwriting and gets back the text. The OCR model already exists — Tesseract has had Nepali support for years, and newer transformer-based OCRs are even better. Your job is the upload form, the call to the model, and a clean display of the result. A weekend’s work that earns the maker a tangible portfolio piece.
A “explain this contract” bot. A small interface where a Nepali speaker pastes the text of a rental agreement, an electricity bill, or a government notice, and the bot summarises it in plain Nepali, flags the parts that might cost them money, and offers to translate specific clauses. The model is rented from OpenAI or Anthropic; the value is the prompt, the interface, and the trust the maker has built with a specific kind of user.

None of these required a PhD. Each required Python, a little patience with errors, and the kind of taste for problems you can only get by living somewhere — by knowing what kind of contract a Kathmandu landlord uses, what kind of NEPSE summary an Itahari shopkeeper would actually read.

What actually changes when you cross the line

The shift from user to maker is smaller than it looks from the outside — and larger than it looks from the inside. A few honest things to expect:

You will read more error messages than English prose. Programming is mostly debugging, and debugging is mostly reading what the computer is trying to tell you and choosing to believe it. The skill is not memorising syntax; it is the patience to read carefully when the impulse is to panic.

The “model” stops being magic. Once you have called a model from code three or four times, it loses its science-fiction halo. It is a function. You send it text, it sends you text back. Sometimes the text is wrong. You learn to check.

You start to see problems differently. A trained builder, walking through New Road, sees half a dozen things a small AI tool could improve. Not because they are paid to. Because the question “could a model help here?” becomes automatic — the way a carpenter looks at a broken chair and sees, automatically, how to fix it.

Your relationship with software changes. You stop being someone software is done to, and start being someone who can change it. This is the part that matters for Nepal. A country whose builders only consume is forever waiting for someone else to ship the right tool. A country whose builders make gets to decide which tools exist.

What you’ll need on hand

We will set up the technical pieces — Python, an editor, notebooks — in the next section. For this section, three things that are not technical at all:

A small problem you actually want to solve. Not “build the next ChatGPT”. Something concrete: an alert when load-shedding hits your tole, a script that summarises your bank statement, a bot that explains your university’s grade-sheet to your grandmother. Keep a running list. We will use one of them in Course 01’s final project.
A laptop with at least 8 GB of RAM. Anything from the last five or six years will do. You do not need a GPU. You do not need a high-end machine. If you have access to a public cyber café computer with reliable internet, even that will work for most of the track — though installing things gets harder.
About four hours a week. A serious estimate, given that you are likely fitting this around a job, a degree, or a household. Some weeks more, some weeks less. The track is paced so that, finished in twelve to sixteen weeks, you will have shipped at least one small real thing.

A word on Python, before you panic

You will be told, in the next chapter, to install Python. Some of you will already know it. Most of you will not. A short reassurance:

Python is the easiest mainstream programming language to read, and one of the easiest to write. It is the language almost the entire global AI ecosystem is built in, which means every tutorial, every library, and most of the help you will ever need is in Python.

We will use it lightly. By the end of Course 01, you will be able to read short Python programs and modify them with confidence. You will not be a “Python developer” — that is a different ambition. You will be someone who can use Python as a tool, the way an accountant uses Excel.

Check your understanding

Quick check

—

Which of the following best describes what 'building AI' means in the way this track uses the phrase?

Training a new large language model from scratch on your own GPU cluster.
Writing code that calls existing models, shapes their inputs, and wraps their outputs into something usable.
Designing the mathematical theory behind new neural network architectures.
Carefully prompting ChatGPT to produce a particular output for personal use.

Quick check

—

A friend with no programming background wants to start building AI. Which is the most useful first step, given the framing of this section?

Buy a laptop with a high-end GPU so they are ready for model training.
Memorise the Python language specification before writing any code.
Pick one small, concrete problem from their own life that a tool could help with, and write it down.
Read every paper from the last year on large language models so they know the field.

What comes next

In the next section we install Python, an editor, and Jupyter notebooks — the three pieces of equipment that turn a laptop into a place where you can build. It is the most fiddly part of the entire track. Do it once, do it carefully, and you are set for the next four courses.

For now, one small homework: before you close this tab, write down one problem from your own life that you suspect a small AI tool could help with. It does not have to be a good problem. It just has to be a real one. We will come back to it.