How to Create an AI: The Three Routes, and Which One You Need

"How do I create an AI" almost always means one of three different projects, and they have almost nothing in common. Picking the wrong one is why people spend a weekend on linear algebra tutorials when what they wanted was a working tool by Friday.

The three routes:

1. Build software on top of an existing model. You call an API, write the prompts and the logic around it, and ship. Days to weeks. This is what almost everyone actually wants.
2. Adapt an existing model. Fine-tuning or retrieval, when the general model doesn't know your specific domain. Weeks, and only after route 1 provably falls short.
3. Train a model from scratch. Months, a research team, and a compute budget with commas in it. Essentially nobody reading this needs it.

Start at 1. Move to 2 only when you have evidence 1 isn't enough. Route 3 is a research project, not a build.

Route 1: build on top of a model

This is what "how to make AI software" means in practice in 2026. The intelligence is a service you call; your work is everything around it.

A working version has four parts:

The call. Send text to a model, get text back. Both OpenAI and Anthropic document this in a page you can read in ten minutes, and the first working call is genuinely ten lines of code.

The prompt. Where most of the quality lives, and where most beginners underinvest. A vague instruction produces vague output, consistently.

The structure. Ask for JSON matching a schema rather than prose you have to parse. Structured output turns "did it work?" from a judgment call into a check your code can run, and it's the single biggest reliability upgrade available.

The wrapper. A script, a form, a scheduled job — whatever makes it runnable by the person who needs it, including you in three weeks when you've forgotten how it works.

Ninety percent of useful AI software is these four things arranged well. There's no model training in it at all.

Route 2: adapt a model to your domain

Two techniques, and the order matters because people reach for the expensive one first.

Retrieval first. Put your documents in a searchable store, find the relevant chunks at question time, and paste them into the prompt. The model doesn't need to know your policies — it needs to read them at the moment it answers. This handles most "the model doesn't know our stuff" problems, updates the instant your documents change, and requires no training.

Fine-tuning second. You have a few hundred good examples and you want the model to reliably produce a specific format, tone, or classification. Fine-tuning teaches behaviour, not facts — that distinction is the one people get backwards. Hugging Face hosts both the open models and the tooling if you go this way.

If someone tells you to fine-tune before you've tried retrieval, ask why. The honest answer is usually that fine-tuning sounds more like real AI work.

Route 3: build your own AI model

Worth understanding what it involves, mostly so you can rule it out with confidence.

You need a very large corpus of clean data, enough GPU time that the bill is a line item somebody approves, people who've done it before, and months. A large language model trained from nothing is a research programme, not a project.

The narrow exception is a small, specialised model for one task — a classifier over your own labelled data, for instance. That's real and achievable, and it's also not what "build your own AI" usually conjures. If your task is classification or scoring over a dataset you already have, a small trained model can beat a general LLM on cost and latency. That's a genuine engineering decision, not a beginner's starting point.

The no-code route

Not everyone needs to write the call themselves. Visual builders let you assemble the same shape — input, model step, logic, output — by dragging rather than typing, and for a lot of internal tools that's the correct level of abstraction. The trade-offs are covered properly in low-code vs no-code and, for the agent-shaped version, in AI agent builder.

The honest limitation: no-code is excellent until you need something the tool didn't anticipate, and then it's a wall rather than a slope. Fine for internal workflows, risky for anything you plan to grow.

The order that actually works

1. Write the task down as steps. If you can't, that's the real problem — you don't have a specification yet.
2. Do it manually once, in a chat window. You'll discover most of the requirements here, cheaply.
3. Automate the version that worked. Now you're writing code against a known-good prompt instead of guessing.
4. Add structure and error handling. What happens when the model returns something unexpected? Decide before it happens.
5. Only then consider retrieval or fine-tuning. With evidence, not on instinct.

Steps 1 and 2 are the ones people skip, and skipping them is why the resulting software solves a problem slightly to the left of the real one. The same argument applies to building software generally, which how to actually create software goes into.

Starting from something that already works

There's a shortcut nobody mentions in tutorials: don't start from an empty file.

Someone has already built something close to what you want and got it working — a document-extraction pipeline, a research agent, a Claude Code setup shaped like your problem. Starting from their working version and changing what's different beats starting from scratch and rediscovering the same problems.

The obstacle is that those projects arrive as repositories: dependencies, environment variables, API keys, someone else's runtime assumptions. Reproducing that environment often takes longer than understanding the idea did.

Taku is an AI-native desktop workspace built to remove that step — mirror a working AI setup, run it on your own files, and remix it into what you actually needed. The free app library is a reasonable place to look for a starting point. Taku is in Beta, and the Mac app is available now.

FAQ

How do I code an AI as a beginner?

Call an existing model's API and build the logic around it. Both Anthropic and OpenAI have a quickstart you can complete in an afternoon, and the first working version is about ten lines. Everything difficult about the project is in the prompt, the structure of the output, and the error handling — not in the model.

How do I create AI software without a machine learning background?

You don't need one for route 1, which is the route almost every AI product takes. Machine learning knowledge matters when you're training or fine-tuning models. Building software that calls a model is ordinary programming with an unusually unpredictable function in the middle.

Can I build my own AI model?

A small, task-specific one over your own labelled data, yes — that's a normal engineering project. A general-purpose language model from scratch, realistically no: it needs a research team, a very large dataset, and months of compute. Try retrieval first, then fine-tuning, and only then ask whether you truly need to train anything.

How long does it take to make AI software?

A useful first version on top of an existing model: days. A version other people can rely on: weeks, and most of that time goes to handling the cases where the model returns something you didn't expect. Fine-tuning adds weeks. Training from scratch adds months.

What's the difference between fine-tuning and retrieval?

Retrieval gives the model the right documents at question time — use it when the gap is knowledge. Fine-tuning adjusts how the model responds — use it when the gap is format, tone, or a consistent classification. Reaching for fine-tuning to teach facts is the most common and most expensive mistake in this area.