What an LLM is good at, and where it does not belong

A language model predicts likely text. That single fact tells you where it belongs in an app.

Good jobs

• Transforming text — summarise a thread, rewrite a note, extract fields from a paragraph. The input and the ground truth are both in front of it.
• Understanding intent — turn "show me cheap shoes under 2k delivered tomorrow" into filters your existing API already supports.
• Generating a draft — a first reply, a product description, a test case — with a human reviewing it.

Bad jobs

• Arithmetic, totals and anything financial. Compute it in code and let the model describe the result.
• Facts about your own data without retrieval. It will produce something plausible and wrong.
• Deterministic validation. An email regex is correct every time and costs nothing.
• Anything where being wrong is unsafe — medical dosage, legal advice, "is this transaction fraud".

The question to ask before building

"If this feature is confidently wrong 5% of the time, what happens?" If the answer is "the user shrugs and edits it", go ahead. If it is "we lose money or trust", either keep a human in the loop or use code.

Prompting, the parts that matter in an app

• Be specific about the output shape. Ask for JSON with named fields when you are going to parse it, and validate what comes back — never trust the shape.
• Give examples. Two or three input-output pairs do more than a paragraph of instructions.
• Put rules before content. Instructions first, then the user's text, clearly delimited — that reduces the chance that text from your own data is read as an instruction.
• Keep it short. Prompt length is latency and cost on every single call.

Treat anything a model returns as untrusted input, exactly like a server response from a third party. Validate it before it touches your database or your UI.