If all code is written by AI Agents, do we still need frameworks?

React, Rails, Django, Tailwind — they were all optimized for humans. But what if humans are no longer the ones writing the code?

Here is a thought experiment. Take everything you know about why software frameworks exist — the conventions, the CLI scaffolding, the opinionated directory structures, the “developer experience” — and ask a simple question: who was all of this designed for?

The answer is obvious: humans. Specifically, humans with limited working memory, finite attention spans, and an acute sensitivity to cognitive load. Every framework you have ever used is, at its core, a cognitive prosthesis. A set of guardrails designed to keep a human brain from buckling under the weight of incidental complexity.

But here is what is changing: the entity writing the code is increasingly not a human brain.

AI coding agents — Claude Code, Cursor, Devin, Codex — are not using frameworks the way we do. They do not experience the relief of rails new. They do not appreciate the elegance of React's component model. They do not need Tailwind's utility classes to avoid context-switching between CSS files. These are ergonomic features for biological cognition.

So the question becomes unavoidable: if the primary consumer of a framework’s “developer experience” is no longer a developer, what exactly are we optimizing for?

Frameworks as cognitive load management

To understand why this question matters, we need to go back to the original design rationale of frameworks.

John Sweller’s Cognitive Load Theory, developed in the late 1980s, distinguishes between three types of mental effort: intrinsic load (the inherent difficulty of a task), extraneous load (unnecessary friction introduced by poor design), and germane load (the productive effort of building mental models). Every successful framework in the history of software has essentially been an extraneous load reducer.

Rails introduced “convention over configuration” so that developers would not burn cognitive cycles deciding where files should go or how the database should map to objects. React introduced the component model and unidirectional data flow so that developers could reason about UI state without holding an entire DOM tree in their heads. Tailwind moved styling decisions into the markup so that developers would stop context-switching between HTML and CSS files.

These are all brilliant solutions — to a human problem. They assume a consumer who can only hold roughly seven items in working memory at any given time, who loses context when switching between files, and who benefits enormously from pattern recognition and predictable structure.

An AI agent has none of these constraints. It does not experience cognitive overload from a project with 4,000 files. It does not need conventions to reduce decision fatigue. It does not appreciate the aesthetics of a well-organized directory. The entire vocabulary of “developer experience” — a term that has driven framework design for two decades — is optimized for an entity that is being progressively removed from the loop.

The argument that frameworks are already dying

There is a strong version of this argument making the rounds. Alain DiChiappari’s viral Hacker News post in early 2026 captured the sentiment: frameworks existed because writing boilerplate was tedious, hiring was expensive, and nobody wanted to think from first principles. Now that AI agents can generate, refactor, and maintain code autonomously, the entire rationale for adopting someone else’s opinionated architecture is collapsing.

The argument has teeth. You do not need an ORM when your agent writes type-safe database queries in seconds. You do not need a CSS framework when your agent generates and maintains custom styles across your entire codebase. You do not need scaffolding commands when the agent can generate the entire project structure from a specification.

Google’s 2025 DORA Report adds nuance: 90% AI adoption correlated with a 9% increase in bug rates, a 91% increase in code review time, and a 154% increase in pull request size. Speed is up, but coherence is suffering. Frameworks, whatever their ergonomic flaws, provided something that raw code generation does not: architectural consistency.

But I think both the “frameworks are dead” camp and the “frameworks are essential” camp are missing the more interesting question. The question is not whether agents need frameworks. They clearly do — just not these frameworks.

Agents have their own cognitive problems

Here is the part that most commentary gets wrong: the assumption that because agents do not have human cognitive constraints, they have no cognitive constraints at all.

They do. The constraints are just different.

The most critical one is what Chroma’s Hong et al. (2025) have termed “context rot” — the measurable degradation in LLM output quality that occurs as input context length increases. Their study of 18 frontier models found that performance grows increasingly unreliable as input length grows. This is not a minor inconvenience. For coding agents, context rot is arguably the primary failure mode — not model capability, not reasoning ability, but the accumulated noise in the context window degrading every subsequent output.

This matters profoundly for framework design. When a human developer uses Rails, the framework reduces cognitive load by providing conventions that the developer internalizes into long-term memory. The developer does not need to re-learn the project structure every time they open the editor. But an AI agent has no long-term memory across sessions. Every invocation starts with a fresh context window that must be loaded with the relevant state. And every token that enters that window depletes the model’s finite “attention budget.”

Context rot manifests in several ways that directly parallel — but differ from — human cognitive limitations:

The “lost in the middle” problem. Stanford’s Liu et al. (2023) demonstrated that LLMs attend strongly to the beginning and end of their context and poorly to everything in the middle. When an agent reads eight files looking for a function, the relevant code in file four sits in the model’s blind spot. Humans have recency bias too, but they can re-read. Agents accumulate context linearly with no mechanism for selective re-attention.

Distractor interference. Code search returns many semantically similar results. A well-organized codebase — perversely — is harder for an LLM to search than a randomly arranged one, because adjacent files share terminology that creates plausible distractors. The conventions that help humans navigate a framework actively hurt the agent.

Accumulative degradation. In a real coding session, every file read, every grep result, every tool output stays in the context window. Over a 15-to-60-minute task, the context continuously degrades. Humans take breaks, close tabs, and reset their working memory. Agents have no equivalent mechanism.

These are not human problems with AI analogs. They are genuinely novel failure modes that require genuinely novel solutions.

What an agent-native framework would look like

If we accept that agents have their own cognitive constraints — context rot, attention budget depletion, distractor interference — then the question shifts from “do we still need frameworks?” to “what would a framework designed for agents look like?”

I think the answer looks radically different from what we have today. Here are the design principles I would expect:

Context-minimizing architecture. Current frameworks are designed to be readable — lots of small files, descriptive names, separation of concerns that makes sense to a human scanning a directory tree. An agent-native framework would instead optimize for context efficiency: the minimum number of tokens needed to convey the maximum architectural information. This might mean more self-contained modules, fewer cross-file dependencies, and explicit dependency declarations that an agent can traverse without reading entire files.

Structured output contracts. Current frameworks enforce architectural consistency through conventions that humans learn and internalize. An agent-native framework would enforce consistency through machine-verifiable contracts — schema validation, type systems, and formal specifications that can be checked without loading the entire codebase into context. This resonates with the emerging paradigm of specification-driven development, where the specification is the source of truth and the code is a verifiable artifact.

Context-aware chunking. Rather than organizing code for human comprehension (one class per file, MVC separation), an agent-native framework would organize code for optimal context loading. Related logic that an agent is likely to need simultaneously would live together, even if that violates human-aesthetic preferences for separation of concerns.

Explicit architectural metadata. Humans infer architecture from patterns. Agents need it stated explicitly. An agent-native framework would include machine-readable architectural descriptions — dependency graphs, module boundaries, invariant declarations — that an agent can load into context without reading the source code itself.

Stateless composability. Since agents lose state between sessions, the framework should make no assumptions about accumulated context. Every entry point should be self-describing. Every module should declare its own preconditions. The framework should be designed for cold-start comprehension, not accumulated familiarity.

The dual-audience problem

This is where things get genuinely difficult. We are not in a world where agents write all the code. We are in a transitional period where humans and agents collaborate, review each other’s work, and share the same codebase. This creates a dual-audience problem: the codebase needs to be legible to both humans and agents, and their legibility requirements are different — sometimes contradictory.

The “separation of concerns” principle is a perfect example. Humans benefit enormously from MVC separation because it maps to distinct mental models (data, logic, presentation). But an agent implementing a feature needs all three simultaneously and pays a context cost for loading them from separate locations. Do you organize for the human reviewer or the agent implementer?

I suspect the answer is layered: an agent-native structural layer (optimized for context efficiency and machine verification) with a human-readable projection (generated views that present the same system in ways that align with human cognition). Think of it as the codebase having two interfaces — one for the entity that writes the code and one for the entity that reviews it.

This is not without precedent. We already accept that compiled code looks nothing like source code. The compiled form is optimized for the machine; the source form is optimized for the human. What is new is extending this pattern to the source layer itself — having a machine-optimized source representation alongside a human-optimized view.

What survives, what changes, what emerges

Not all aspects of current frameworks are purely cognitive-load solutions. Some serve functions that remain essential regardless of who writes the code:

Runtime abstractions survive. React’s virtual DOM, Django’s ORM query optimization, Rails’ database connection pooling — these solve runtime performance problems, not developer experience problems. An agent still needs them because the code still runs on the same hardware.

Security patterns survive. CSRF protection, input sanitization, authentication middleware — these are correctness requirements, not ergonomic features. An agent that does not use them produces vulnerable code regardless of how efficiently it was generated.

Ecosystem integration survives. Frameworks provide standardized interfaces to databases, message queues, cloud services, and third-party APIs. These are protocol-level concerns that exist independently of who writes the code.

What changes is the surface area. The parts of a framework that exist to make a human productive — CLI tools, scaffolding, file watchers, hot reloading, pretty error pages — become irrelevant. What emerges are new primitives that address agent-specific needs — context summaries, architectural contracts, verification hooks, checkpoint mechanisms.

A new kind of framework for a new kind of builder

We are at an inflection point that reminds me of the transition from assembly language to high-level languages. That transition did not eliminate the need for structure — it changed what “structure” meant. Compilers did not need the same affordances as human assembly programmers. They needed different affordances, and entirely new tools emerged to provide them.

The same pattern is repeating. The frameworks we have — React, Rails, Django, Tailwind, Next.js — were masterpieces of human-centered design. They will not disappear overnight, partly because of ecosystem inertia and partly because humans will remain in the loop for review, debugging, and architectural decisions for a long time.

But the center of gravity is shifting. The entity that spends the most time interacting with the codebase is increasingly an agent, not a human. And that entity needs frameworks designed for its actual constraints: finite context windows, attention degradation, lack of persistent memory, and susceptibility to distractor interference.

The frameworks that win the next decade will not be the ones with the best developer experience. They will be the ones with the best agent experience — whatever that turns out to mean.

We are only beginning to figure that out.

Daniel Braz is CTO at BRQ Product & Experience Studios. He writes about software engineering, AI agents, and the evolving relationship between human judgment and machine capability.