I keep running into some version of "frameworks are legacy overhead now that agents can just write whatever code you need." I think that's exactly backwards, and I want to make the case for why.
Here's the thing about frameworks like Angular: they were never really about typing fewer characters. They were about reducing cognitive load. Every time you make a decision about how to structure a component, where state lives, how dependencies get injected, or how a route resolves data, you're spending a little bit of your limited attention budget. A good framework takes a thousand of those decisions off the table for you, once, at the framework level, so you can spend your remaining attention on the actual problem you're trying to solve. That was true in 2016 when I started writing about Angular, and it's still true now. What's changed is who else is spending that attention budget alongside you.
Cognitive Load Isn't Just a Human Problem Anymore
When I write code by hand, unopinionated freedom is expensive. I have to hold the conventions of the codebase in my head, remember what pattern the last developer used, and guess at intent from context. Multiply that by a team, and you get drift. Every service ends up structured a little differently. Every component handles state a little differently. That inconsistency isn't just annoying, it's a tax that everyone pays every time they touch code they didn't write.
LLMs pay that same tax. An agent generating or reviewing code in a loosely structured JavaScript codebase has to infer the local dialect from whatever files happen to be nearby, and it will guess wrong constantly, the same way a new hire does. Give that same agent an Angular codebase, and a huge amount of that inference disappears. Components look like components. Dependency injection works the same way in file 1 and file 400. Signals, control flow syntax, and routing all follow the same shape whether a human wrote them last week or an agent wrote them ten minutes ago. The framework's opinions become the agent's prior, and priors are exactly what make generated code predictable instead of a coin flip.
This is the part people miss when they say "AI writes code so frameworks don't matter." Standardization was always valuable because it let any human step into any part of a codebase and immediately have a mental model for how it works. Agents need that exact same thing, for the exact same reason. A restricted, well-worn set of patterns isn't a constraint on intelligence, human or artificial, it's what makes intelligence useful at scale.
Built-In Capabilities Are Leverage, Not Bloat
The other piece of this is what a framework hands you out of the box. SSR, hydration, routing, forms, HTTP, dependency injection, a CLI that scaffolds and migrates your code for you, ng generate @angular/core:signal-input-migration style automated upgrades. These aren't nice-to-haves, they're integration surface area that's already been solved and tested by people who aren't you.
When an agent is generating a feature, it doesn't have to invent a routing convention, wire up its own state management primitive, or guess at how forms validation should work. It reaches for provideRouter, httpResource, @defer, whatever the well-integrated built-in is, and it works the same way it worked in the docs, the same way it works in a thousand other Angular apps it was trained on. Compare that to a stack assembled from six different libraries with six different philosophies, where the agent (or the human) has to reconcile conflicting mental models before writing a single line. Fewer seams means fewer places for an agent to hallucinate a plausible-sounding but wrong integration.
Multi-Agent Systems Are Starting to Look a Lot Like Teams
Here's the part I find genuinely interesting. As people move from "one agent doing one task" to multi-agent systems where different agents own different parts of a codebase, plan work, review each other's output, and hand off context, those systems start to run into the exact same coordination problems that human engineering teams have always had. One agent's output needs to be legible to the next agent's input. Nobody has full context on the whole system. Someone (or something) needs to enforce conventions so that the frontend agent and the backend agent don't quietly diverge on how state, auth, or data fetching should work. That's not a new problem, it's the same problem that shows up the moment you go from a solo project to a team, and it's why standardized frameworks were invented in the first place. A framework like Angular gives multi-agent systems the same superpower it gives human teams: a shared, opinionated substrate that lets independent contributors, human or agentic, produce work that fits together without a meeting.
The Bigger Point
None of this means agents write perfect code in Angular projects, or that frameworks are suddenly a silver bullet. I still review, test, and direct the work. But the framework is doing exactly what it's always done: taking a huge pile of arbitrary decisions off the table so that whoever, or whatever, is doing the work can spend their attention on the 10% that's actually specific to your problem. That was valuable when the "whoever" was a junior engineer joining your team. It's just as valuable, maybe more, now that the "whatever" might be three agents working in parallel on the same repo.
