Posts


# Why LLMs Ignore Your Non-Functional Requirements (And How to Fix It)

*You asked the AI to build a search feature. It built a search feature. It's also slow, inaccessible, unobservable, and doesn't handle errors. You forgot to ask for those parts.*

---

> **Non-functional requirements (NFRs) in AI-generated code** are the quality attributes — performance, security, observability, accessibility, and reliability — that LLMs systematically ignore because they're implicit, cross-cutting, and absent from prompts. NFR coverage actually *decreases* as vibecoded projects grow: from 25% at the prototype stage to just 12% in production codebases, because the total NFR count grows faster than any human can track in prompts.

There are two kinds of requirements in software:

**Functional requirements** describe *what* the system does: "Users can search products by name." "The checkout flow processes payments." "Admins can export reports as CSV."

**Non-functional requirements (NFRs)** describe *how well* the system does it: "Search returns results in under 200ms." "Payment processing retries on transient failures." "Reports are accessible to screen readers." "All API calls are logged with correlation IDs."

LLMs are remarkably good at functional requirements. Describe what you want, and you'll get working code that does the thing.

LLMs are remarkably bad at non-functional requirements. And this isn't a temporary limitation waiting for the next model release. It's a structural mismatch between how NFRs work and how LLMs generate code.

## The Five NFR Categories LLMs Ignore

### 1. Performance

**What you need:** P95 response time under 200ms. Efficient database queries. Pagination on large collections. Connection pooling. Caching for repeated reads.

**What you get:** Functionally correct code that fetches all records, processes them in memory, makes a new database connection per request, and returns the full dataset without pagination.

**Why:** The LLM optimizes for *correctness*, not *efficiency*. `SELECT * FROM products` is correct. It also falls over with 100,000 rows. Performance requires understanding the production data volume, which isn't in the prompt.

### 2. Security

**What you need:** Input validation. Parameterized queries. Auth on all endpoints. Rate limiting. Secret management. CORS restrictions.

**What you get:** Code that trusts all input, uses string interpolation for queries, and skips auth on the "obvious" endpoints. (See our full breakdown of [AI-generated code security vulnerabilities](/blog/posts/ai-generated-code-security).)

**Why:** Security is the absence of vulnerabilities — a negative requirement. LLMs generate what should be *present*, not what should *not* be possible. Secure defaults require explicit constraint injection.

### 3. Observability

**What you need:** Structured logging with request context. Error tracking with stack traces. Metrics for latency, error rates, and throughput. Distributed tracing for multi-service architectures.

**What you get:** `console.log('done')`. Maybe a try-catch that swallows the error silently. No correlation IDs. No metrics. No way to debug issues in production.

**Why:** Observability has zero impact on whether the feature "works" in development. The LLM generates code that passes the functional test. That the code is impossible to debug in production is not a concern the model has any reason to surface.

### 4. Accessibility

**What you need:** WCAG 2.1 AA compliance. Semantic HTML. Keyboard navigation. Screen reader compatibility. Color contrast ratios. Focus management.

**What you get:** A `<div>` where there should be a `<button>`. Click handlers without keyboard equivalents. Color as the only indicator of state. Missing `aria-label` attributes. Form inputs without associated labels.

**Why:** Accessibility requirements are rarely in the prompt and underrepresented in training data. Most web code in the training distribution doesn't follow WCAG guidelines. The LLM generates what web code "usually looks like" — which is inaccessible.

### 5. Reliability

**What you need:** Retry logic with exponential backoff. Circuit breakers for external services. Graceful degradation when dependencies fail. Timeouts on all external calls. Dead letter queues for failed jobs.

**What you get:** A single `await fetch(url)` with no timeout, no retry, no error handling, and no fallback. If the external service is down, your feature crashes.

**Why:** Reliability patterns add complexity that doesn't affect the happy path. The LLM generates happy-path code because that's what matches the prompt. Failure handling requires anticipating *what could go wrong* — a reasoning task that current LLMs don't perform unprompted.

## Why Prompting NFRs Doesn't Scale

The obvious fix is to prompt for NFRs explicitly: "Build a search endpoint with 200ms P95 latency, parameterized queries, structured logging, keyboard-navigable results, and retry logic on the database connection."

This works for one feature. It falls apart at scale for three reasons:

### 1. NFR Lists Get Impossibly Long

A mature product has 50-200+ NFRs across the five categories. You can't paste all of them into every prompt. Even if you could, the LLM can't prioritize 200 constraints simultaneously — attention is finite, and constraints at the bottom of the context window get less weight than constraints at the top.

### 2. NFRs Are Inherited, Not Listed

Some NFRs apply directly to a component. Others are *inherited* through dependency chains. If your `UserService` has a PII-handling constraint, then `BillingService` (which calls `UserService` to get the user's email) inherits that constraint. And `NotificationService` (which calls `BillingService`) inherits it too.

These inherited constraints can't be listed per-feature because they depend on the dependency graph. You'd need to trace every dependency chain for every feature to enumerate the full NFR set — which is exactly the kind of graph traversal that humans do poorly and LLMs can't do at all from a flat prompt.

### 3. NFRs Conflict and Require Tradeoffs

"All endpoints must be authenticated" conflicts with "The webhook handler must accept unauthenticated requests from Stripe." "Responses must be under 200ms" conflicts with "All responses must be encrypted end-to-end." "UI must be fully accessible" conflicts with "Use this custom drag-and-drop library that doesn't support keyboard navigation."

Resolving NFR conflicts requires judgment — understanding which requirement takes priority in context, and designing a solution that satisfies both or explicitly accepts the tradeoff. LLMs in a flat prompt will silently pick one and ignore the other.

## The NFR Coverage Gap

We analyzed NFR coverage across vibecoded projects at different maturity stages:

| Project Stage | Features | Total NFRs | NFRs Explicitly Prompted | Coverage |
|---|---|---|---|---|
| Prototype | 1-5 | 10-20 | 3-5 | 25% |
| Growth | 6-15 | 30-60 | 8-12 | 20% |
| Pre-production | 16-30 | 60-150 | 15-25 | 15% |
| Production | 30+ | 100-200+ | 20-30 | 12% |

NFR coverage *decreases* as the project grows. The ratio of prompted NFRs to total NFRs gets worse because the total grows faster than any human can track in prompts.

The result: the larger your vibecoded project, the more unaddressed non-functional requirements lurk in the codebase. These aren't bugs — everything "works." They're quality gaps that manifest as slow pages, security incidents, undebuggable outages, and accessibility complaints.

## The Fix: Constraint Propagation

The structural solution to the NFR problem has three parts:

### 1. Make NFRs Explicit

Every non-functional requirement gets encoded as a typed constraint in a [constraint graph](/blog/posts/vibecoding-whack-a-mole). Not prose in a Confluence doc. A machine-readable node with:

- **Category:** security, performance, scalability, stability, compliance
- **Severity:** critical, warning, info
- **Scope:** which components it applies to
- **Action:** what the code must do to satisfy it

```
[CRITICAL:SECURITY] All API endpoints must validate input with Zod schema
  → Applies to: all entities of type 'endpoint'
  → Action: Import and apply validation schema before processing request body
```

### 2. Propagate Through Dependencies

When a constraint is attached to a component, all components that depend on it inherit the constraint automatically. The graph handles this — no manual tracking required.

```
UserService [PII-handling constraint]
  └── BillingService (depends on UserService) → inherits PII constraint
       └── NotificationService (depends on BillingService) → inherits PII constraint
```

When the AI builds a notification feature, the PII constraint is automatically in context — even though the developer never prompted for it. The notification service handles user email addresses because it calls through the billing service, so it must follow PII rules. The graph knows this. A flat prompt doesn't.

### 3. Inject Contextually Per-Task

The constraint graph doesn't dump all 200 NFRs into every prompt. It identifies which constraints are relevant to the current task — based on which components the code touches and their dependency chains — and injects only those.

Building a search endpoint? You get:
- Performance: P95 under 200ms, paginate results
- Security: validate search input, parameterize queries
- Observability: log search queries with correlation ID
- Accessibility: results must be keyboard-navigable

You don't get the 150 other NFRs about billing, onboarding, or admin features. The context stays focused. The constraint coverage stays high.

## NFR Categories That Matter Most

If you're starting from zero on NFR coverage, prioritize in this order:

**1. Security** — Vulnerabilities have the highest blast radius. A single missing input validation can lead to data breach. Start with the [security checklist](/blog/posts/ai-generated-code-security).

**2. Reliability** — Retry logic, circuit breakers, and graceful degradation prevent outages. Users forgive slow. They don't forgive broken.

**3. Observability** — You can't fix what you can't see. Structured logging and error tracking are prerequisites for improving everything else.

**4. Performance** — Optimize after you've shipped and have real usage data. Premature optimization is still the root of all evil, but *knowing* your performance constraints ensures the AI doesn't generate accidentally quadratic code.

**5. Accessibility** — Ethically and legally important, and increasingly a requirement for enterprise customers. Retrofit is expensive — getting it right during generation is dramatically cheaper.

## From Vibes to Standards

The promise of vibecoding is building at the speed of thought. The gap is that "the speed of thought" usually only thinks about *what* to build, not *how well* to build it.

Non-functional requirements are the difference between a prototype and a product. Between a demo that impresses and a system that survives production traffic, security probes, and real users with screen readers.

LLMs won't add NFRs unless you make them impossible to ignore. Static rules help. A constraint graph that propagates NFRs through your dependency chain and injects them contextually into every prompt? That's how you get AI-generated code that's not just functionally correct, but production-grade.

---

## FAQ

**Q: What are non-functional requirements in AI-generated code?**

Non-functional requirements (NFRs) describe how well a system performs — latency targets, security policies, accessibility standards, observability, and reliability. LLMs are excellent at functional requirements (what the system does) but systematically ignore NFRs because they're implicit, cross-cutting, and absent from the prompt.

**Q: Why do LLMs ignore non-functional requirements?**

LLMs ignore NFRs for three reasons: NFR lists get impossibly long (50-200+ in a mature product), NFRs are inherited through dependency chains that flat prompts can't represent, and NFRs conflict with each other requiring judgment to resolve tradeoffs.

**Q: What is NFR coverage in vibecoded projects?**

NFR coverage decreases as projects grow. At the prototype stage (1-5 features), about 25% of NFRs are explicitly prompted. By production (30+ features, 100-200+ NFRs), coverage drops to 12% because the total grows faster than any human can track in prompts.

**Q: How do you enforce non-functional requirements on AI-generated code?**

Enforce NFRs through constraint propagation: (1) make every NFR an explicit, typed constraint with category, severity, scope, and action, (2) propagate constraints through dependency chains so inherited requirements flow automatically, and (3) inject only the relevant constraints per task rather than dumping all 200 into every prompt.

---

*Cutline generates NFR constraints from your product requirements and propagates them through your dependency graph. Every AI-generated feature gets the right quality standards, automatically. [Try it free →](/start)*


AI non-functional requirements

Why LLMs Ignore Your Non-Functional Requirements (And How to Fix It)