What Is the LLM Approach? A Practical Explanation

What the LLM approach actually means

The "LLM approach" refers to solving a software problem by prompting a large language model instead of writing explicit rules or training a custom machine learning model for the task. Instead of hand-coding logic ("if the email contains these words, classify it as spam") or collecting a labeled dataset and training a classifier from scratch, you describe the task in natural language and let a general-purpose model — trained on massive amounts of text — figure out how to do it.

This is a genuine shift in how software gets built. Traditional programming encodes logic explicitly. Classic machine learning learns a narrow function from labeled examples. The LLM approach skips both: you write a prompt, optionally give a few examples or reference documents, and the model produces the output. It's closer to giving instructions to a very capable but occasionally unreliable employee than to writing deterministic code.

The three approaches compared

It helps to see the LLM approach next to what came before it.

• Rule-based / traditional programming — you write explicit conditional logic. Predictable and fast, but brittle: every edge case needs a new rule, and it doesn't generalize to inputs you didn't anticipate.
• Classic supervised machine learning — you collect labeled training data, choose a model architecture, and train a model specific to one task (e.g., a spam classifier, a sentiment model). Accurate for that one task but requires data collection, training infrastructure, and retraining when requirements shift.
• LLM approach — you use a pretrained general-purpose model and steer it with a prompt (and optionally examples, retrieved context, or tools). No training pipeline required, and the same model can do summarization, classification, extraction, and generation depending only on how you ask.

The tradeoff is that the LLM approach gives up some determinism and per-task accuracy in exchange for speed of development and flexibility across tasks.

Core techniques inside the LLM approach

"Using an LLM" isn't one technique — it's a family of methods you combine depending on the problem:

• Zero-shot prompting — describe the task and let the model handle it with no examples. Works well for common, well-defined tasks.
• Few-shot prompting — include 2–5 examples of input/output pairs in the prompt so the model infers the pattern. Useful when the output format is specific or unusual.
• Retrieval-augmented generation (RAG) — fetch relevant documents (from a database, search index, or vector store) and insert them into the prompt so the model answers based on your data instead of only its training data.
• Tool use / function calling — let the model call external functions (a calculator, a database query, a search API) when the task requires precision or live data the model can't know on its own. See /docs/tools for how this looks in practice.
• Fine-tuning — for narrow, high-volume tasks where prompting isn't reliable enough, you can adjust the model's weights on your own examples. This is the exception, not the default, in most LLM-approach projects — most teams get far with prompting alone.
• Agentic loops — chaining multiple LLM calls together, where the model plans steps, calls tools, and evaluates its own output before finishing.

A well-built LLM application usually combines two or three of these, not just a single prompt.

When the LLM approach makes sense

The LLM approach is a good fit when:

• The task involves unstructured text or language understanding (support tickets, documents, transcripts, freeform user input).
• Requirements change often — updating a prompt is far cheaper than retraining a model.
• You need to cover many related tasks without building a separate model for each one.
• Perfect determinism isn't required — a support-ticket summarizer that's 95% accurate is still useful; a billing calculation that's 95% accurate is not.

It's a weaker fit when you need guaranteed, auditable logic (financial calculations, legal compliance rules) or extremely low latency at massive scale, where a purpose-built model or deterministic code is more appropriate.

What the LLM approach looks like in code

In practice, the LLM approach usually means sending a prompt to a model API and getting text back. A basic call looks like this:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4",
    "max_tokens": 300,
    "messages": [
      {"role": "user", "content": "Summarize this support ticket in one sentence: The user cannot reset their password after the last update."}
    ]
  }'

Notice there's no training step, no dataset, no model file — the "development" is the prompt itself, plus whatever context or tools you attach around it. This is the practical difference between the LLM approach and classic ML: the iteration loop is editing text, not retraining a model.

If you're building on top of Claude specifically, SubToAPI turns your existing Claude access into a standard HTTPS API with application keys, streaming, and usage tracking, so you can apply the LLM approach in production code without managing separate infrastructure. The quickstart and messages docs cover the request format if you want to try it directly.

Common pitfalls with the LLM approach

• Treating the model as deterministic. The same prompt can produce slightly different output across calls. Design your application to tolerate variation or constrain output format explicitly (e.g., ask for JSON and validate it).
• Skipping evaluation. Because there's no training/test split, teams sometimes ship prompts without ever measuring accuracy on real examples. Build a small evaluation set early.
• Over-relying on the model for facts. LLMs can produce confident, wrong answers. Use RAG or tool use for anything that needs to be factually grounded.
• Ignoring cost and latency at scale. Every call has a token cost and response time; an LLM-approach feature that works fine in a demo can get expensive or slow once it's handling production traffic. Streaming responses (see /docs/streaming) helps with perceived latency for user-facing features.

questions

Is the LLM approach the same as machine learning? No. Classic machine learning trains a model on your own labeled data for one specific task. The LLM approach uses an already-trained general-purpose model and steers it with prompts, without training anything yourself in most cases.

Do I need to fine-tune a model to use the LLM approach? Usually not. Most LLM-approach applications rely on prompting, few-shot examples, and retrieval instead of fine-tuning. Fine-tuning is reserved for narrow, high-volume tasks where prompting alone isn't accurate enough.

When should I avoid the LLM approach? Avoid it for tasks requiring guaranteed determinism or auditable logic, like financial calculations or compliance rules, where explicit code or verified computation is safer than a probabilistic model output.