What Are LLMs Best at Besides Coding? The Hidden Capabilities

Mar 12, 2026

Purpose

I recently read a provocative claim on Reddit: “Coding will be the ONLY thing LLMs are really good at.” The commenter argued that because code has clear rules and immediate feedback, LLMs excel at it but fail elsewhere where ambiguity rules.

This claim bothered me. I’ve used LLMs extensively for tasks that have nothing to do with writing code. So I dug into the discussion to understand where this belief comes from and why it’s fundamentally wrong.

The Provocative Thesis

The original post laid out its reasoning clearly:

Code follows layers of strict rules. It either compiles or it doesn’t. There’s immediate, objective feedback. Natural language tasks lack this clarity—so LLMs must struggle with anything non-code.

This logic sounds reasonable on the surface. Code has structure, syntax rules, and compilation errors. Natural language is messy, ambiguous, and subjective. Therefore, LLMs trained on code should excel at code but flounder elsewhere.

But the community pushed back hard. And their responses revealed something important about what LLMs actually do well.

The Counter-Argument: Rule-Based Domains

The most upvoted response cut to the core:

“LLMs are very good where there are strong rules - code follows layers of rules. Law, Accounting, Civil Engineering also rule-bound.” (10 upvotes)

This insight reframes the question entirely. The issue isn’t code vs. natural language. It’s structured vs. unstructured domains.

Think about what lawyers do:

Statutes → Clear rules written in natural language
Precedents → Established patterns from past cases
Procedures → Defined steps for legal processes
Contracts → Standardized language and clauses

Law isn’t ambiguous chaos. It’s a system of rules expressed in natural language. LLMs trained on legal texts can identify patterns, apply precedents, and draft contracts because the domain has structure.

The same applies to accounting:

GAAP/IFRS → Standardized accounting principles
Audit frameworks → Defined procedures for verification
Tax regulations → Explicit rules with interpretations
Financial statements → Standard formats and relationships

Accounting is even more structured than law. Every transaction follows double-entry bookkeeping. Financial statements have defined relationships. Audit procedures are standardized.

My Experience: Beyond Code Generation

When I read that original claim, I realized how narrow the view was. My own LLM usage breaks down roughly like this:

Research and synthesis    → 40%
Writing and editing       → 25%
Problem-solving analysis  → 15%
Learning and tutoring     → 10%
Code-related tasks        → 10%

Code is maybe 10% of what I use LLMs for. Let me show you what the other 90% looks like.

Research Synthesis

Last month, I needed to understand the landscape of attention mechanisms in transformers for a project. I had 30 papers to process. Instead of reading each one in depth, I used an LLM to:

Extract key contributions from each abstract
Categorize papers by approach (sparse attention, linear attention, etc.)
Identify which papers influenced others
Find contradictions and open questions

This isn’t code generation. It’s pattern recognition across natural language documents. The LLM found connections I would have missed or taken weeks to identify.

Legal Document Analysis

I’ve used LLMs to review contracts for potential risks. Given an indemnification clause:

"The Vendor shall indemnify and hold harmless the Company
from any and all claims arising from the Vendor's performance."

The LLM identified issues my legal team later confirmed:

“Any and all claims” is overly broad and may be unenforceable
No liability cap tied to contract value
No carve-out for Company’s own negligence
Missing jurisdiction specification

This isn’t replacing a lawyer. It’s augmenting legal review with pattern matching. The LLM has “seen” thousands of indemnification clauses and can flag unusual terms.

Business Decision Support

A friend asked about switching their company from LLC to C-Corp for venture funding. I used an LLM to generate a structured analysis:

┌─────────────────┬──────────────┬──────────────┬──────────────┐
│ Factor          │ LLC          │ C-Corp       │ Impact       │
├─────────────────┼──────────────┼──────────────┼──────────────┤
│ Tax treatment   │ Pass-through │ Double tax  │ High         │
│ Investor pref   │ Low          │ High        │ Critical     │
│ Admin burden    │ Low          │ High        │ Medium       │
│ Liability prot. │ Good         │ Good        │ Neutral      │
│ Fundraising     │ Limited      │ Easy        │ Critical     │
└─────────────────┴──────────────┴──────────────┴──────────────┘

The LLM provided trade-offs, risks, and a recommendation based on company size and growth trajectory. This is structured decision analysis—not code, but perfectly suited to LLM capabilities.

The Mathematical Frontier

One comment in the discussion pointed to cutting-edge research:

“LLMs are increasingly solving open math problems”

This references Terence Tao’s work using AI to track progress on Erdos problems. Mathematical reasoning—often considered uniquely human—is being augmented by LLMs.

What’s fascinating is that mathematics is perhaps the most rule-bound domain of all. Every proof follows logical rules. Every theorem must be derived from axioms. The structure is more rigid than code in many ways.

The LLM contribution isn’t solving problems from scratch. It’s:

Literature synthesis: Connecting related proofs across papers
Problem categorization: Grouping similar approaches
Progress tracking: Following which problems have been solved
Connection identification: Finding unexpected links between problems

Why Coding Feels Special

If LLMs excel at all these rule-based domains, why does coding get all the attention?

I think there are three reasons:

1. Immediate Verifiability

Code either works or it doesn’t. You run tests, you see failures. Legal analysis or business recommendations have no equivalent “compile” button. The feedback loop is slower and more subjective.

2. Developer Early Adoption

Developers were the first power users of LLMs. They experimented, shared results, and built tools around code generation. The ecosystem grew fastest here because the audience was technical enough to build integrations.

3. The Demo Effect

Watch someone generate a React component in 30 seconds, and it looks magical. Watch someone synthesize research across 50 papers, and it’s harder to appreciate. Code generation is visually striking in a way that knowledge work isn’t.

What Domains Benefit Most?

Based on my experience and the discussion, here’s how I’d categorize LLM effectiveness:

HIGH EFFECTIVENESS
├── Code (rules + immediate feedback)
├── Legal documents (rules + standard patterns)
├── Accounting (rules + standard formats)
├── Technical writing (structure + domain conventions)
└── Research synthesis (pattern recognition + summarization)

MEDIUM EFFECTIVENESS
├── Business analysis (frameworks + assumptions)
├── Education/tutoring (explanation + adaptation)
├── Translation (rules + cultural nuance)
└── Medical documentation (patterns + protocols)

LOWER EFFECTIVENESS
├── Creative fiction (minimal structure + originality)
├── Subjective judgments (personal taste + context)
└── Real-time decisions (incomplete info + stakes)

The pattern is clear: more structure means better LLM performance. Code isn’t special—it’s just the most obviously structured knowledge domain.

Getting Practical: Non-Coding LLM Applications

If you want to leverage LLMs beyond code, here are patterns that work:

For Research

1. Feed abstracts and summaries to LLM
2. Ask for categorization by approach
3. Request identification of influential papers
4. Generate synthesis of themes and contradictions

For Legal Review

1. Provide contract clauses in chunks
2. Ask for risk identification
3. Request standard alternatives
4. Compare against industry norms

For Business Decisions

1. Define the decision framework
2. Provide relevant constraints
3. Ask for weighted analysis
4. Request risk assessment and mitigation

The common thread: structure your request around the domain’s rules and patterns. LLMs are pattern matching engines. Give them patterns to match.

The Real Question

The Reddit debate revealed a fundamental misunderstanding. The question isn’t “What are LLMs good at besides coding?”

The real question is: “What domains have structure that LLMs can recognize and apply?”

For professionals in law, accounting, research, education, and business strategy, LLMs offer transformative productivity gains. The key insight is that coding was never the ceiling—it was just the first obvious application.

Code generation is impressive because we can see it working. But legal analysis, research synthesis, and decision support are equally valuable domains where LLMs excel. They’re just harder to demo in 30 seconds.

In this post, I explored why the claim that LLMs only excel at coding misunderstands their fundamental capability: pattern recognition and application across structured domains. Law, accounting, research, and business analysis all benefit from the same strengths that make LLMs good at code—rules, patterns, and verifiable outputs.

The real opportunity isn’t learning to use LLMs for code. It’s recognizing which parts of your work have structure that LLMs can accelerate.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 Reddit discussion on LLM capabilities beyond coding
👨‍💻 Terence Tao on AI for Mathematical Research
👨‍💻 Attention Is All You Need Paper

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!