What it means to build AI into software
Key takeaways Using vs building — using AI is you sitting at a chat window; building with it means a model call runs inside your own program. An AI feature is a normal product capability (summarize, extract, classify, answer) powered by that call — the model runs at runtime, serving your users, who never touch it directly. It’s software engineering — you’re integrating an API, not training a model, so no ML background is needed. If you haven’t seen how models work under the hood, the sibling path AI in software development covers that first.
You have almost certainly used AI by now — asked a chatbot a question, let a coding assistant finish a line. This path is about something different: making a model a part of the software you ship, so it does a job for your users. This first lesson draws that line clearly and names the thing you’ll be building for the rest of the path: an AI feature.
Using AI vs. building with it
When you use AI, you are the one in front of it. You open a chat window, type a question, and read the reply. You paste code into a coding assistant and accept its suggestion. In every case you are the user of the model, and you judge the output with your own eyes before doing anything with it.
When you build with AI, the model moves inside your software. A model call runs at runtime, as part of your program, triggered by something your users do — clicking a button, opening a record, submitting a form. The model’s answer doesn’t come back to you to read; it comes back to your code, which then uses it to do something useful. Your users get the benefit, and most of them never know a model was involved at all.
That’s the whole shift in one sentence: the model runs inside your program, at runtime, serving your users, who never see the model directly. Everything else in this path is about doing that well.
What an “AI feature” actually is
An AI feature is not exotic. It’s an ordinary product capability that happens to be powered by a model call instead of hand-written logic. The user sees a button, a result, or a suggestion; behind it, your code calls a model and uses what comes back.
A few concrete shapes it takes, across very different kinds of software:
- Summarize — turn a long support thread, article, or meeting transcript into a short overview.
- Extract structured fields — pull the vendor, date, and total out of a scanned invoice into tidy fields your database can store.
- Answer from your own docs — let a user ask a question and get an answer drawn from your product manual, not the open internet.
- Classify — sort an incoming message into a category, or flag whether a review is positive or negative.
- Draft or rewrite — generate a first-draft reply, or rephrase text to be shorter or clearer.
- Translate — render a message in another language on the fly.
And a GopherTrunk example, to keep it close to home: a feature that takes a decoded control-channel message — normally a wall of terse fields only an expert can read — and returns a plain-English explanation of what it means. Or one that takes a whole scanning session and produces a short summary of which talkgroups were active and when. In each case the user clicks once; a model call does the work; your code shows the result.
The anatomy of an AI feature
Every AI feature, however simple, is a small pipeline. It’s worth seeing the shape now, because the rest of this path is really just each stage in turn:
- Input — something from your program or your user starts it off: a document, a message, a decoded packet, a form field.
- Assemble a prompt — your code builds the text you send the model: an instruction plus the relevant input. (Covered in prompts as code and context and user input.)
- Call the model — you send that prompt to the model’s API and wait for a reply. (Covered in how a model API works and your first API call.)
- Parse and validate the output — the reply comes back as text, and your code has to turn it into something usable and check it’s sane. (Covered in parsing and validating output and structured output.)
- Use it — display it, store it, or act on it, like any other value in your program.
- Handle failure — plan for the call being slow, costing money, or coming back wrong. (Covered in handling hallucinations and failure.)
Don’t worry about the details of each stage yet. The point is that an AI feature is not one magic step — it’s a handful of ordinary ones, most of which are plain code you write.
What changes when you build it
The moment the model moves inside your software, a pile of responsibilities becomes yours that were the chatbot’s problem before. When you used a chat window, someone else wrote the prompt scaffolding, handled the wrong answers, and paid the bill. Now you do.
| When you use AI | When you build with it |
|---|---|
| You write the prompt each time | Your code assembles the prompt from your users’ input |
| You read and judge the answer | Your code parses, validates, and uses the answer |
| A wrong answer is yours to shrug off | A wrong answer reaches your users unless you catch it |
| You wait as long as you like | Latency is part of your product’s responsiveness |
| Someone else pays per message | You pay per call, and it adds up at scale |
| You handle the odd glitch by retrying | You design for failure — timeouts, bad output, outages |
None of this is a reason not to build. It’s simply the job. Owning the prompt, the inputs, the output handling, the cost, the latency, the failures, and the user experience is what building an AI feature means — and each of those gets its own lesson later in this path.
It’s software engineering, not machine learning
Here is the reassuring part. Building AI features is software engineering, not machine learning. You are not training a model, tuning weights, or doing statistics. You are calling an API that someone else trained, the same way you’d call a payments API or a maps API — send a request, get a response, handle it.
That means you need no ML or math background to start. The skills are the ordinary ones you already use: making an API call, shaping its input, parsing its output, validating results, handling errors, watching cost. What’s unusual is only the component itself: this API returns fluent text and doesn’t always give the same answer twice, so you handle it a little differently than a function that returns a fixed value. That one difference — treating the model as a probabilistic component rather than a deterministic one — is the mindset the next lesson is built around (the model as a component).
Quick check: What best distinguishes an AI feature from using a chatbot?
Recap
- Using AI is you at a chat window or coding assistant; building with it puts a model call inside your own software, at runtime, serving your users.
- An AI feature is an ordinary product capability — summarize, extract, answer, classify, draft, translate — powered by a model call the user never sees.
- Every AI feature is the same small pipeline: input, assemble a prompt, call the model, parse and validate, use it, and handle failure.
- When you build it, the prompt, inputs, output handling, cost, latency, failures, and UX all become your responsibility.
- It’s software engineering, not machine learning — you integrate an API, no ML or math background required.
Next up: the model as a probabilistic component — the mindset shift that makes everything else work.