You call a model; you don't train one

When people hear "AI feature", many engineers picture data scientists, training runs and GPUs. For most backend work, none of that is involved. A large language model (LLM) hosted by a provider is a web API. You send it text over HTTPS, it sends text back, and you pay for the tokens. The training happened months ago, at the provider, on data you never see.

This matters because it tells you where your work is. You do not improve ShipFast's classifier by collecting a training set and running a job. You improve it by writing clearer instructions, sending the right context, validating the output and choosing the right model. That is software engineering, and you already know how to do it.

It really is just HTTP

To make this concrete, here is a raw call to Anthropic's Messages API with httpx, with no SDK. You would not write production code this way — the next section uses the official SDK — but it shows there is nothing hidden.

1import os23import httpx45resp = httpx.post(6    "https://api.anthropic.com/v1/messages",7    headers={8        "x-api-key": os.environ["ANTHROPIC_API_KEY"],9        "anthropic-version": "2023-06-01",10        "content-type": "application/json",11    },12    json={13        "model": "claude-opus-5",14        "max_tokens": 200,15        "output_config": {"effort": "low"},   # think briefly first; Section 2 explains16        "system": "Reply with one word: reschedule, address_change, damaged_parcel, complaint or other.",17        "messages": [{"role": "user", "content": "please deliver tomorrow after 6, I'm not home"}],18    },19    timeout=10.0,20)21resp.raise_for_status()22body = resp.json()23print(body["content"][0]["text"])   # reschedule24print(body["usage"])                # input_tokens, output_tokens and a few more counts

The request has a model name, a limit on output length, a setting for how much the model thinks before answering, instructions in system, and the conversation in messages. The response has the generated text in content and the token counts in usage. Every provider's API has the same basic shape, with different field names. The next section looks at each part in detail.

What the model knows, and what it does not

A model's knowledge comes from its training data, which stops at a cutoff date. It knows a lot about language, about India's cities and PIN code format, and about what a courier does. It knows nothing about ShipFast specifically.

• It does not know ShipFast's list of intents. You must send them in the instructions.
• It does not know today's date. "Tomorrow" means nothing unless you send the date.
• It does not know whether SF20931847 is a real parcel. It can only copy what the customer wrote; your database decides if it exists.
• It does not remember the previous request. Each call is independent. If you want it to see earlier messages in a conversation, you send them again, every time, and pay for them again.

That last point surprises many engineers. The API is stateless. Chat products look like they remember you because the application resends the whole conversation on every turn. For ShipFast this is convenient: each customer message is classified on its own, so there is no session state to manage.

When not to use a model

Because the model is an API with a price and a latency, the first question for any feature is whether you need it at all. Many parts of ShipFast do not.

The rule of thumb: use a model for understanding and writing language; use code for rules, lookups and arithmetic. When a regex handles a slice of traffic reliably, put it in front of the model. It removes cost and latency for that slice and leaves the model the messages that really need it.

Fine-tuning is not the starting point

You may hear that you should fine-tune a model on your data. Fine-tuning means training an existing model further on your examples. It can help with very high volume, narrow tasks, but it costs time, requires hundreds or thousands of labelled examples, locks you to one model version and makes changes slower. For ShipFast's classifier, a clear prompt with the six intents defined in one line each reaches about 95% accuracy on day one. Start there. Consider fine-tuning only when an evaluation set shows a prompt cannot reach the accuracy you need.