AI, Explained for Developers

For a web developer, "AI" almost always means your code calls a model — a piece of software that learned patterns from huge amounts of data instead of you hand-writing the rules. Think of it as a very capable function someone else built: you send it text (or an image) and it sends text back. The big recent shift is generative AI: models that produce new content (a sentence, JSON, code) rather than just labeling things. In practice, "using AI" usually just means making an HTTPS request to a model's API and handling the JSON response — much like calling any third-party REST service.

Picture four labels nested like folders, biggest on the outside. "AI" is the broad outer folder: any system that does something we'd call smart. Inside it is machine learning (ML): systems that learn patterns from examples instead of being explicitly programmed. Inside ML is deep learning, which uses neural networks — software loosely inspired by how brain cells connect, stacked in many layers — and it powers most of today's breakthroughs. Inside that is generative AI: deep-learning models that generate new text, images, or code. So the chatbots and text APIs you'll call are generative deep-learning models — the innermost folder.

A model is a big file full of numbers plus the code that runs them. The numbers — called weights — are the patterns the model picked up during training; the code does the math that turns your input into an output. In practice you rarely touch that file: it lives behind an API like Claude or GPT, and you just POST a request to it. A loose analogy: the model file is like a compiled binary, and the API endpoint is the server hosting it. You don't rebuild it; you call it. "Loading a model" just means reading that number-file into memory so it's ready to answer requests.

In normal code, you write the rules yourself: if (amount > 1000) flagForReview(). The logic is visible, you control it, and the same input always gives the same output — so you can trace exactly why it did something. A model instead learned its "rules" from examples, and that behavior lives in millions of numbers nobody typed by hand. You can't read the logic line by line, the same input can give slightly different output each time, and it can be confidently wrong. The trade-off: hand-written rules win when you can list all the cases; AI wins for fuzzy tasks like understanding free text or summarizing, where writing every rule by hand is hopeless.

During training, the model is shown tons of examples, and its internal numbers (weights) get nudged over and over until its outputs match those examples well. "Learning" here is just slowly adjusting numbers to reduce mistakes — there's no understanding or human-style memory of facts. The result is a model that's good at predicting the most likely next piece of a pattern it has seen. The misconception to drop: it did not memorize a database of answers and it isn't "looking things up." It's pattern completion. That's also why it can sound fluent yet be flat-out wrong — sounding right and being right are separate things.

Training is the expensive, mostly one-time process where the model's weights are created by chewing through massive amounts of data (huge GPU clusters, weeks of compute, lots of money). Inference is running the finished model to answer a single request — fast and cheap by comparison. As an app developer you almost always do only inference: you call the API, and the provider already did the training. A web analogy: training is like building and seeding a database; inference is one query against it. You pay per inference call (per token), not for the training.

No — they're nested, like a set of Russian dolls. AI (artificial intelligence) is the big outer box: any technique that makes a computer do something we'd call 'smart' — even old-school hand-written if/else rules count. Machine learning (ML) is a box inside AI: instead of you writing the rules, the computer figures out the rules by looking at lots of examples (data). Deep learning is a box inside ML: a specific ML technique using 'neural networks' (more on those later) that powers most modern AI. So AI ⊃ ML ⊃ deep learning. When someone says 'AI' today they almost always mean ML, usually deep learning.

In normal programming (the kind you ship every day), YOU write the rules: if amount > 1000 && country != 'US' → flag as fraud. You hand the computer logic + data, it gives answers. Machine learning flips one input and output: you hand the computer the data AND the answers (lots of past transactions already labeled fraud/not-fraud), and it produces the rules for you — a 'model'. Then you feed new data through that model to get answers. It's useful exactly when the rules are too fuzzy or numerous to write by hand (spotting spam, recognizing a photo). You're trading 'I write the logic' for 'I curate the examples.'

Parameters are the model's learnable numbers — the weights mentioned earlier. Each one is a tiny dial set during training, and together they store everything the model "knows." A model with 70 billion parameters has 70 billion such dials. More parameters generally means more capacity to capture patterns (often smarter), but also more memory, slower responses, and higher cost per call. A rough analogy: parameters are like the size of a database index — bigger can be more powerful but heavier to run. As someone just calling the API, you don't usually pick a parameter count directly; you pick a model tier (small / medium / large) that bundles it for you.

Treat it as one more external service your backend talks to. A typical flow: browser → your backend → (you build a prompt) → the model provider's HTTPS endpoint → response → you validate and transform it → back to the browser. You keep the API key as a server-side environment variable (never in the frontend), and you can cache responses, rate-limit callers, and log usage just like any third-party API. One thing to know: each call is independent — the model doesn't remember past requests unless you resend that earlier conversation as part of the new request. Architecturally, it slots in exactly where a payment API or search service would.

It's a normal HTTPS POST with a JSON body. Here's the shape against the Anthropic API as of 2026: ``js const res = await fetch('https://api.anthropic.com/v1/messages', { method: 'POST', headers: { 'x-api-key': process.env.ANTHROPIC_API_KEY, 'anthropic-version': '2023-06-01', 'content-type': 'application/json' }, body: JSON.stringify({ model: 'claude-opus-4-8', max_tokens: 500, messages: [{ role: 'user', content: 'Summarize this in one line: ...' }] }) }); const data = await res.json(); // the reply text is in data.content[0].text ` You send a messages` array (the conversation) and read text back. OpenAI and Gemini look very similar. That request/response round trip is the whole "using AI" mechanic.

A token is the chunk of text a model reads and writes in — roughly three-quarters of a word in English (about 4 characters). Models don't see characters or whole words; they see tokens. It matters for two reasons: you're billed per token (input and output counted separately), and each model has a maximum context — a cap on the total tokens you can send plus receive in one request. As of 2026, for example, Claude Opus 4.8 runs about $5 per million input tokens and $25 per million output, with a context window up to roughly 1 million tokens. Rule of thumb: 1,000 tokens is about 750 words. Output tokens usually cost several times more than input, so keep responses tight.

Three things lined up. First, in 2017 researchers introduced an architecture (a model design) called the transformer that let models train efficiently on huge amounts of text in parallel, instead of slowly word-by-word. Second, the data and computing power got big enough — essentially training on much of the public internet using large fleets of GPUs. Third, scale paid off: making these models bigger kept making them noticeably more capable, including surprising new abilities like following instructions. From 2022 onward, chat products like ChatGPT and Claude wrapped all that in an API anyone can call. So "why now" is transformers, plus massive data and compute, plus scaling working, plus an easy API — not one single eureka moment.

Use AI when the task is fuzzy and shaped around language or perception: understanding free text, summarizing, sorting messy input into categories, drafting content, or pulling fields out of unstructured documents. Use plain code when the rules are crisp and you need exact, repeatable, auditable behavior: pricing math, auth, validation, anything regulated. A great pattern is to combine them — let the model handle the squishy part, then have ordinary code check and enforce the result. The misconception to avoid: AI isn't a faster calculator or a database. If you can write the rule cleanly in if/else, do that — it's cheaper, instant, and never makes things up.

Almost never, especially starting out. The default in 2026 is to call a hosted model over an API (Claude, GPT, Gemini) — zero training, you just send prompts. If the model needs your company's own knowledge, you don't retrain it; you put the relevant information right into the prompt at request time. That last idea has a name, RAG (retrieval-augmented generation): your code looks up the relevant text first, then asks the model about it. Fine-tuning — lightly adjusting a model on your own examples — and training from scratch both exist, but they're rare, costly, and usually unnecessary. Reach for plain prompting first, RAG second, and fine-tuning only if those genuinely fall short.

Providers offer a ladder trading capability against cost and speed, and the exact names change often, so treat these as examples "as of 2026." Anthropic's tiers run roughly Haiku (cheap and fast) → Sonnet (balanced) → Opus → Fable (most capable, priciest); OpenAI mirrors this with a small/mini variant up to a flagship like GPT-5.5. The strategy is simple: pick the smallest model that passes your quality bar. Start with a small or mid tier, measure accuracy on real examples, and only step up if it fails. A common pattern is routing — a cheap model for easy, high-volume requests, a big one for the hard cases. Bigger isn't automatically better for your task; it's just more capable and more expensive per token.

Trusting the model's output as if it were correct, well-formed, and safe. Models hallucinate — they can produce fluent, confident, totally made-up answers (fake citations, wrong prices, invented APIs). They can also drift from the format you asked for, or get steered by sneaky text a user slipped into their input (called prompt injection — think of it like an injection attack aimed at the prompt). The fix is the same instinct as never trusting data from the browser: validate everything on the server. Re-check facts and numbers in code, confirm the JSON has the shape you expect, allow-list any value that triggers a real action, and fail safely if anything looks off. A good rule: the model proposes, your code decides.

Generative AI is a flavor of deep learning, so it lives in the innermost doll. The split is about what the model produces. Most classic ML is 'predictive' (also called discriminative): it takes input and outputs a label or number — spam/not-spam, a price estimate, a fraud score. Generative AI instead produces brand-new content: text, images, code, audio. ChatGPT writing a paragraph, or an image model drawing a cat, is generative. Rough analogy: predictive ML is a function that returns a small structured value (a boolean or a float); generative AI is a function that returns a whole document. Both are 'models', just aimed at different output shapes.

Mostly just two: 'generative AI' (specifically large language models, LLMs) and 'a model'. Day-to-day you'll call a hosted model over an HTTPS API — think a REST endpoint you POST JSON to and get JSON back, with an API key in an env var. You rarely train anything yourself; you consume someone else's pre-built model (OpenAI, Anthropic, etc., as of 2026). The terms AI/ML/deep learning matter for understanding and conversations, but in code you're basically integrating a smart third-party API. The real skills become: writing good prompts, handling latency/streaming, managing cost per call, and validating the model's output before trusting it — exactly like consuming any flaky external service.

Several. Cost can climb fast: long prompts and chatty responses multiply your token bill, and output tokens cost several times more than input. Latency is real — a big model can take seconds, so plan for streaming (sending the answer token-by-token as it's generated, like SSE) so the UI doesn't just hang. Calls also fail or get rate-limited, so add retries that wait a bit longer each attempt, plus a fallback path. The model can change underneath you when the provider ships a new version, so pin a specific model ID and re-test before upgrading. And anything sensitive in your prompt leaves your servers, so check the provider's data-retention terms. Finally, set budget caps and per-user limits so a bug can't run up a surprise bill.