Not every software problem needs a large language model (LLM). If a task can be solved reliably using deterministic rules, SQL queries, standard APIs, search algorithms, or traditional machine learning, adding an LLM may increase cost, latency, security exposure, and maintenance complexity without improving the outcome.
Engineering leaders should avoid using an LLM when the system requires exact calculations, predictable outputs, strict execution guarantees, very low latency, or decisions that cannot tolerate unverified results.
Evaluate five factors before selecting an LLM: task complexity, correctness requirements, latency, total operating cost, and operational risk. Use an LLM when understanding or generating flexible natural language creates measurable value that simpler technologies cannot provide efficiently.
One common architectural mistake is selecting the technology before defining the task. Invoice processing, for example, involves document extraction, field validation, tax calculations, purchase-order matching, discrepancy detection, and approval. Those operations do not necessarily require the same technology.
Document extraction might benefit from OCR, document AI, or an LLM when layouts are highly variable. Tax calculations should use deterministic business logic. Purchase-order matching can use queries and predefined rules. Unusual discrepancies may require statistical anomaly detection or human review.
Ask first: Does this task require language understanding or generation, or does it simply require executing known business logic? If the answer is known business logic, start with conventional software.
Financial reconciliation, tax computation, inventory balances, and contractual pricing should rely on validated algorithms and appropriate numerical representations. An LLM can interpret a request, but calculations should remain deterministic.
from decimal import Decimal
def calculate_discount(price, rate):
price = Decimal(str(price))
rate = Decimal(str(rate))
if price < 0 or not 0 <= rate <= 1:
raise ValueError("Invalid price or discount rate")
return (price * (1 - rate)).quantize(Decimal("0.01"))
print(calculate_discount("250.00", "0.15")) # 212.50
Use instead: Validated business logic, decimal arithmetic, calculation libraries, or specialized numerical systems.
A refund policy with explicit eligibility periods, excluded categories, and approval thresholds is better represented as a rules engine or conventional application logic.
def refund_decision(days_since_purchase, amount, eligible):
if not eligible or days_since_purchase > 30:
return "reject"
if amount > 500:
return "manual_review"
return "approve"
This simplified example is not a complete refund policy. A production system would also need authentication, transaction validation, fraud controls, and audit records. Use instead: Rules engines, state machines, or workflow orchestration.
LLM inference can add network, input-processing, generation, and tool-call delays. It may be inappropriate for industrial control loops, low-level network packet handling, high-frequency transaction processing, and safety-critical device control. Use instead: Optimized algorithms, embedded logic, or specialized low-latency models with measured timing guarantees.
If revenue figures already exist in an authoritative database, query that system directly rather than asking a model to generate the result.
SELECT SUM(amount) AS total_revenue
FROM paid_invoices
WHERE paid_at >= '2026-09-01'
AND paid_at < '2026-10-01';
This query assumes revenue means paid invoice amounts; financial reporting may require different accounting definitions. An LLM may translate a user question into a constrained query, but authorization and aggregation should remain under application control.
Do not introduce an LLM if the implementation cannot satisfy data handling, retention, access control, and deployment requirements. Private deployments and governed managed services can support sensitive workloads, but controls must be demonstrated. OWASP identifies prompt injection and sensitive information disclosure among important LLM application risks.
Fraud detection, demand forecasting, defect classification, anomaly detection, and predictive maintenance may be better served by statistical methods or task-specific machine learning. An LLM can explain the result without generating the underlying prediction. Compare approaches on representative data.
Do not approve autonomous production use without representative test cases, defined unacceptable outcomes, and an evaluation or review mechanism. A controlled prototype or human-reviewed workflow is preferable until measurable acceptance criteria exist.
Requirement
Usually preferred approach
Reason
Exact arithmetic
Deterministic code
Defined, testable numerical behavior
Business rule enforcement
Rules engine
Predictable and auditable decisions
Structured data retrieval
SQL or APIs
Authoritative records
Keyword or exact-match search
Search engine
Efficient retrieval without generation
Demand forecasting
Statistical or ML models
Optimized for prediction
Flexible document summarization
LLM
Variable natural language
Semantic document discovery
Embeddings and retrieval
Conceptually related content
Natural-language interface
LLM plus controlled tools
Intent translated into validated operations
High-risk automated actions
Deterministic controls and oversight
Permission and execution boundaries
These are starting points, not universal rules. Benchmark against your own acceptance criteria.
Total Cost of Ownership = Development + Infrastructure + Inference + Evaluation + Monitoring + Maintenance + Exception Handling.
Cost per successful task = Total operational cost / Successfully completed tasks.
Consider a hypothetical workload of one million requests per month:
Metric
Deterministic service
LLM-based service
Cost per attempt
$0.001
$0.02
Monthly attempts
1,000,000
1,000,000
Direct processing cost
$1,000
$20,000
Successful task rate
99.9%
97%
Direct cost per successful task
~$0.001
~$0.0206
Illustrative scenario only, not observed vendor prices or published benchmarks. The systems may solve different problems, and a deterministic service might not handle some language-intensive tasks. Compare time to deployment, cost per completed task, failure rates, review requirements, maintenance, monitoring, and security overhead.
If the task does not require flexible language interpretation or generation, begin with deterministic software. Benchmark rules, search, APIs, or specialized ML. Do not compare an LLM only against doing nothing.
Define how incorrect, incomplete, or inconsistent results are detected and handled.
Test latency, throughput, cost, availability, privacy, and security under realistic workloads.
Approve the LLM only when its benefits are material and risks can be managed.
Decision flow: Require language intelligence? If no, use deterministic software. If yes, benchmark simpler alternatives. If a simpler option meets acceptance criteria, prefer it. Otherwise, test error containment, operational constraints, and measurable incremental value before approving controlled LLM implementation.
This five-gate framework is a proposed engineering method, not an externally validated standard.
A SaaS platform needs to route requests such as duplicate charges, account-email changes, and API errors. Three architectures are possible.
def route_ticket(message):
text = message.lower()
if "charged twice" in text or "duplicate charge" in text:
return "billing"
if "change email" in text or "update email" in text:
return "account"
if "api error" in text or "api is returning errors" in text:
return "technical"
return "manual_review"
This is transparent and testable but has limited coverage when customers use unexpected wording or describe multiple issues.
An LLM can interpret varied expressions, but adds inference costs, model evaluation, output validation, and additional failure modes.
Use explicit rules for well-defined requests, a lightweight classifier for common variations, an LLM for ambiguous language, and human review for low-confidence or high-impact cases. The routing policy remains under application control. Compare classification precision and recall, misrouting rate, manual-review rate, P95 latency, cost per correctly routed ticket, and maintenance effort. A hybrid system is preferable only if it provides measurable benefits.
Separate language interpretation from authoritative business execution. An LLM can translate intent into a structured request; deterministic services should validate schemas, enforce permissions, apply business rules, and execute critical operations.
User request
|
LLM interprets intent
|
Structured request
|
Schema validation
|
Authorization + business rules
|
Deterministic API execution
|
Verified result
|
User response
Structured outputs can constrain response format, but valid syntax does not guarantee correct interpretation or authorized execution. This is especially important for AI agents connected to enterprise systems.
Problem definition: What requires an LLM, and what alternatives were considered?
Baseline: How well does the strongest non-LLM approach perform?
Quality: What dataset and metrics evaluate correctness?
Reliability: What happens if the model fails or returns invalid output?
Security: Can the model access or change anything beyond user authorization?
Performance: What are P50, P95, and P99 latencies under load?
Economics: What is the cost per successful business task?
Ownership: Who maintains prompts, datasets, configurations, and monitoring?
Change management: How will model and data updates be retested?
Exit strategy: Can the model be replaced without redesigning the application?
When simpler approaches meet the requirements with less complexity, or when critical model errors cannot be detected, contained, or reviewed.
Not universally. LLMs suit flexible language tasks, while specialized models may be more efficient for structured prediction and forecasting.
They can interpret requests, but authoritative rules, calculations, permissions, and transactions should generally remain deterministic.
It can translate natural language into a validated query, but the database should execute structured retrieval and aggregation.
When flexible language interpretation adds value but critical steps need predictable execution and strong controls.
Use comparative evidence that a simpler architecture meets quality, latency, security, and operational requirements at lower total cost. The decision to use an LLM should be based on engineering requirements, not technology momentum. Large language models can provide valuable capabilities for flexible language and unstructured information, but they are not the right answer to every software problem.
Before introducing an LLM, establish a non-LLM baseline, define measurable acceptance criteria, and test whether the model delivers enough additional value to justify its cost and risk.
A useful rule for architecture reviews: If removing the LLM does not materially reduce the system’s ability to meet its requirements, the LLM probably does not belong in the critical path.
The goal is to build the simplest system that reliably delivers the required business outcome.