What LLMs Are Good At: Six Capabilities That Ship in Real Products
You saw the three tools. Now zoom into LLMs: the six things they do well in production (summarize, extract, classify, rewrite, draft, assist with code), with a code example for each and honest notes on where they break.
What "good at" means in engineering terms
In the previous concept you saw an LLM classify a support ticket in a single API call. That worked because classification is one of the things LLMs handle well. But "good at" in a demo and "good at" in production are different standards.
For this course, "good at" means: the model succeeds on common cases, fails in predictable ways, the failures are tolerable or caught by your code, and the cost and latency fit your budget. Every capability below passes that bar when you design the system around it.
1. Summarization
Take a long piece of text, produce a shorter version that keeps the important parts. This is one of the highest-value use cases because it saves human time directly.
Real examples: summarize a customer support thread into "issue, steps tried, next action." Summarize a meeting transcript into decisions and action items. Summarize a pull request diff into what changed and why.
The catch: summaries can omit important details or introduce details that were not in the original. Treat every summary as a draft, not as ground truth. Keep a link to the original so a human can verify.
2. Information extraction
Turn messy, unstructured text into structured data. This is the use case where LLMs genuinely replaced months of regex and rule work.
Real examples: extract company, role, and dates from a resume paragraph. Pull invoice number, amount, and currency from an email. Parse a natural-language address into street, city, state, zip.
The trick is to request JSON output and validate it with a schema. The LLM generates a draft; your code enforces correctness.
3. Classification
You already saw this in the previous concept. Categorize text into a small set of labels: route a support ticket, tag user feedback, decide if a comment violates guidelines.
LLMs are especially useful for classification when you do not have labeled training data (cold start), or when the labels are subjective ("is this sarcastic?"). If you later accumulate enough labeled examples, you can graduate to a faster, cheaper classical ML classifier trained on the labels the LLM produced.
4. Rewriting and translation
Rewrite text without changing its meaning: make it more formal, simplify it for a beginner, translate it to another language, adjust the tone.
Real examples: rewrite an internal technical note as a customer-facing changelog entry. Translate a support reply from English to Spanish. Make a blunt rejection email sound polite.
This works well because the task is language transformation, which is what LLMs are built for. Watch for subtle meaning shifts in sensitive contexts (legal, medical). When meaning matters, keep a human review loop.
5. Drafting (solving the blank page)
Generate a first draft that a human edits. This is where the productivity gain is largest, because starting from a draft is much faster than starting from nothing.
Real examples: draft a reply to a customer complaint. Draft a product spec outline from bullet points. Generate test cases from a function signature. Draft a weekly status update from git log entries.
The best AI products treat the model output as smart autocomplete. The human is responsible for correctness. The model just gets them past the blank page.
6. Coding assistance
LLMs can explain code, generate boilerplate, suggest edge cases, write tests, summarize diffs, and convert between languages. You are probably already using this through Copilot, Cursor, or Claude Code.
The catch: LLMs can produce code that looks correct, passes a quick read, and has a subtle bug or security vulnerability. The engineering safeguards (code review, tests, linters, security scanning) still apply. Think of it as a fast but occasionally sloppy colleague who writes the first draft.
Where to start
Most production wins come from small, constrained tasks: extract these three fields as JSON, classify into one of four categories, summarize in three bullets. Avoid open-ended "do everything" prompts until you have evaluation and guardrails in place (Modules 9 and 10).
These are the wins. But LLMs fail in predictable, important ways that you must design around. The next concept is a tour of those failure modes, because knowing the limits is how you build systems that work, not just demos that work.