Do We Still Need Frameworks in the Age of AI Coding Agents?
There is a question circulating quietly among engineering teams, mostly in architecture reviews and late-night Slack threads, that has not yet received the serious treatment it deserves:
If an AI agent can generate structure, enforce patterns, and produce consistent code across a large codebase - what exactly is a framework still doing for us?
It is a fair question. Not a radical one. Frameworks were invented to solve real problems, and those problems have not disappeared. But the tools available for solving them have changed substantially. Before we dismiss the question, or reflexively defend our favorite framework, it is worth slowing down and tracing the logic carefully.
Why Frameworks Existed - and Why They Still Matter
Frameworks did not emerge from dogma. They emerged from pain.
In the early 2000s, building a web application from scratch meant solving the same problems hundreds of times across hundreds of teams: request routing, session management, database abstraction, template rendering, authentication. The solutions varied wildly in quality, and institutional knowledge lived in the heads of individual engineers rather than in shared conventions.
Frameworks like Ruby on Rails, Django, and later Spring Boot offered something more valuable than pre-written code. They offered a shared mental model. When a new engineer joined a Rails project, they knew where the models lived, how routing worked, and what the request lifecycle looked like. The framework was a lingua franca, a contract between teammates who had never met.
This pattern repeated across every domain:
- Mobile: React Native and Flutter gave cross-platform teams a unified component model and rendering abstraction, replacing the chaos of fragmented native approaches.
- Distributed systems: frameworks like Akka or Orleans encoded hard-won concurrency patterns - actor models, message passing, supervision trees - that would take months to rebuild correctly.
- Frontend: React, Angular, and Vue gave teams consistent state management paradigms and component boundaries, reducing the drift that naturally accumulates in large JavaScript codebases.
The benefits were not merely about saving time. They were about reducing decision fatigue. When you adopt a framework, you outsource dozens of architectural micro-decisions to a community of engineers who have already debated them. The tradeoff is constraint in exchange for clarity.
Frameworks also brought ecosystems: mature tooling, debuggers, testing utilities, security patches, and communities that would surface problems before you encountered them yourself. These are not trivial advantages. They compound quietly over years.
The Case Against Heavy Frameworks - Stronger Now Than Ever
The critique of heavy frameworks is not new. It was articulated clearly by the "micro-framework" movement years ago, by the proponents of hexagonal architecture, and by engineers who had watched a Rails app metastasize into something that fought them at every turn.
The core complaints are familiar:
Over-constraining architectures. Frameworks impose opinions. Most of the time those opinions are reasonable. But complex, domain-specific systems often have requirements that sit outside the framework's assumptions. At that point, you are not working with the framework - you are negotiating around it. The abstraction that saved you early on becomes the abstraction you cannot escape later.
Hidden complexity. Frameworks operate through "magic": metaprogramming, convention-over-configuration, auto-wiring, dependency injection containers. Individually, these mechanisms are powerful. Collectively, they create systems that are difficult to reason about in failure modes. When something breaks at the intersection of three framework layers, debugging requires knowledge of the framework's internals that most engineers do not have.
Lock-in and rigidity. Committing to a framework is a long-term relationship. Major version migrations - Angular 1 to 2, for example, or the sustained trauma of large Spring Boot upgrades - can consume quarters of engineering time. The framework's evolution is not yours to control. When its priorities diverge from yours, the cost is high.
Mismatch with unique product needs. A fintech system managing real-time settlement has different architectural imperatives than a SaaS dashboard or a logistics routing engine. Frameworks designed for the general case carry assumptions that may not survive contact with specialized domains.
None of this is new. What is new is how AI changes the cost calculus.
Previously, the alternative to a framework was writing a lot of code by hand - boilerplate, abstractions, infrastructure plumbing. That work was expensive in time and attention, and it introduced risk. The framework's convenience was worth tolerating its constraints because the alternative was worse.
AI coding agents change that arithmetic. Generating a router, a migration framework, or a validation layer is no longer a month of engineering work. It can be an afternoon. The cost of "doing it yourself" has dropped significantly, which means the case for accepting a framework's constraints needs to be stronger than it was.
What AI Changes Fundamentally
It is important to be precise here, because the hype around AI in software development tends to blur important distinctions.
What AI does well:
AI coding agents are genuinely effective at generating code at scale. They can scaffold application structures, produce boilerplate from specifications, refactor large codebases toward a new pattern, and generate internal tooling that would have previously required dedicated platform engineering time. They lower the activation energy required to "build your own."
They are also increasingly capable of generating consistency - applying a naming convention, a structural pattern, or a type signature across a large surface area faster and more reliably than manual review.
What AI does not do:
AI does not remove complexity. It redistributes it. A system generated by an AI agent still has a runtime, still has state, still has failure modes, still has performance characteristics. The complexity does not disappear because the code was generated quickly - it relocates from the generation phase to the maintenance and understanding phase.
More importantly, AI does not automatically enforce consistency over time. An agent can generate a consistent codebase on day one. Without mechanisms to maintain that consistency - contracts, schemas, tests, type systems, reviews - it will drift. Systems drift because they are modified by multiple people under pressure, and entropy does not respect the intentions of the original architecture prompt.
There is also a deeper issue: code generation is not system design. An AI agent can implement a pattern you describe, but it cannot decide what pattern is appropriate for your specific domain, your team's cognitive load, your operational constraints, or your growth trajectory. That judgment remains human.
The Real Problem: Enforcement vs. Freedom
Here is the distinction that often gets lost in these debates.
Architectural principles are not the same thing as enforcement.
You can write down that all data access should go through a repository layer. You can enforce that rule. These are different activities. Frameworks enforce rules structurally - the wrong approach often does not compile, does not route, or visibly violates a convention that the ecosystem will flag. That enforcement has value independent of the framework's other features.
The question is not whether enforcement matters - it clearly does. The question is how to implement it.
Framework-enforced constraints are opaque but reliable. They apply automatically, do not require team agreement, and degrade gracefully as team size increases. A new engineer on a Django project cannot easily bypass the ORM, which means they also cannot easily introduce a class of data access bug.
Custom-built enforcement - schemas, contracts, linters, type boundaries, integration tests, documented conventions - is more explicit and more flexible. It requires discipline to maintain and investment to build, but it can be precisely calibrated to your domain. It also does not carry the overhead of framework conventions that do not apply to your system.
Both approaches can work. Neither works without intention.
Tradeoffs: A Clear Comparison
Framework-heavy approach
Pros:
- Immediate onboarding velocity for engineers familiar with the framework
- Battle-tested patterns applied without reinvention cost
- Active ecosystem: security patches, integrations, community knowledge
- Structural enforcement of architecture without discipline overhead
- Tooling (CLIs, generators, debuggers) built for the paradigm
Cons:
- Architectural opinions may not fit domain-specific requirements
- Magic layers obscure debugging and increase cognitive overhead during failures
- Version migrations can be costly and disruptive
- Performance ceilings imposed by abstraction layers may be hard to break
- Dependency on external roadmap and maintenance continuity
Custom / generated architecture
Pros:
- Precisely fit to your domain and team's mental model
- No extraneous abstraction or convention overhead
- Full control over evolution and migration paths
- AI agents make the generation and maintenance cost substantially lower than before
- Can encode your actual architecture principles rather than approximating them
Cons:
- Enforcement of consistency requires ongoing investment
- No external community to surface bugs, security issues, or improvements
- Onboarding new engineers requires teaching your conventions rather than relying on prior knowledge
- Risk of subtle errors in infrastructure logic that mature frameworks have already resolved
- Requires higher architectural maturity in the team to avoid reinventing problems poorly
The Role of Context
The right choice depends substantially on context. There is no architecture decision that exists outside of circumstance.
Team size and composition matter enormously. A small team of experienced engineers with high architectural alignment can maintain a custom system effectively. A rapidly scaling organization hiring engineers continuously needs conventions that travel outside the team. Frameworks carry conventions; custom systems require deliberate knowledge transfer.
Domain characteristics shift the calculus. Consumer fintech, healthcare data systems, and embedded software have compliance, auditability, and reliability requirements that often benefit from established, audited frameworks. Internal tooling, experimental products, and domain-specific engines often have constraints that frameworks cannot accommodate without heavy workarounds.
Speed vs. stability is a real tension. Early-stage products benefit from the rapid scaffolding a framework provides. Systems that have been in production for five years under significant load may need to escape those initial constraints. The right tool at founding may be the wrong tool at scale - or vice versa.
Operational maturity of the team is a factor. Deep knowledge of a framework's internals takes time to develop. A team that has lived with Rails for ten years can push it far further than one that adopted it six months ago. The same applies to custom systems: their value is proportional to the care put into making them understandable.
The Emerging Middle Ground
The binary of "framework vs. custom" is already breaking down in practice.
Modern teams are increasingly working at a different level of abstraction:
Lighter, composable frameworks - tools like Fastify, Hono, or Bun on the server side, or Tanstack Router and Zustand on the client side - offer useful primitives without enforcing a whole-system architecture. They solve specific problems without demanding a total worldview.
Internal platform layers - the "platform engineering" movement builds thin, opinionated wrappers around infrastructure and tooling that encode organizational conventions without requiring external frameworks. These internal platforms are increasingly generated and maintained with AI assistance.
"Generate your own structure" workflows - some teams are using AI agents to generate architecture scaffolding from specs, then treating the output as a baseline to be refined and documented. The framework, in this model, is ephemeral: it exists as generated code rather than as a dependency.
Convention by contract - type systems, OpenAPI schemas, Protocol Buffers, and event schemas are taking on some of the enforcement role previously held by frameworks. These tools enforce architectural boundaries across service boundaries without requiring a monolithic framework to span them.
None of these patterns is universally superior. They represent a broadening of the toolkit, not a replacement of it.
A Practical Decision Framework
Rather than a prescription, here are questions that surface the right considerations for your specific situation.
Consider a framework when:
- Your team is growing rapidly and you need portable, shared conventions
- Your domain is well-matched to the framework's assumptions (standard CRUD-heavy web services, for instance)
- The ecosystem (tooling, security support, integrations) represents meaningful leverage
- Your team has the experience to use the framework deeply rather than superficially
- Time-to-market is a primary constraint and the framework's scaffolding is genuinely fit for purpose
Consider a custom or generated architecture when:
- Your domain has requirements that consistently fight the framework's assumptions
- Your team has strong architectural alignment and the discipline to maintain explicit conventions
- The operational overhead of framework complexity outweighs its conveniences at your scale
- You need precise control over performance, data flow, or system behavior
- AI tooling has made the generation and maintenance cost genuinely tractable for your team
Consider a mixed approach when:
- You want framework conventions at the edges (HTTP layer, database access) but custom design in the core domain
- You are using AI agents to generate specific infrastructure layers while maintaining framework-based application structure
- Different parts of your system have meaningfully different requirements
- You want composable primitives rather than a total architectural commitment
The most honest answer is usually: start with the question of what problem you are actually solving, not with the answer about what tools to use.
Conclusion
Structure is unavoidable in software. The question was never whether to impose constraints on a system, but how to impose them, and at what cost.
Frameworks have been one answer to that question - a particularly effective answer for teams with limited time, high velocity hiring, and well-matched problem domains. They encode accumulated knowledge, provide enforcement automatically, and reduce the number of decisions required to begin building.
AI changes the economics of the alternative. The cost of generating your own structure, maintaining your own conventions, and building your own internal tooling is measurably lower than it was three years ago, and declining. That matters. It shifts the crossover point at which a custom approach becomes rational.
But AI does not change the underlying physics of complex systems. Codebases still accumulate entropy. Teams still diverge in understanding. Architectural decisions made under time pressure still have long-run consequences. The agents that generate code today do not yet bear responsibility for the systems they help create - the engineers and architects do.
The relevant skill, then, is not picking the right framework. It is understanding why structure matters, what kinds of enforcement your system actually needs, and how to provide that - whether through a framework, through generated conventions, or through some deliberate combination of both.
The engineers who think clearly about those questions will navigate this transition well, regardless of which tools they use.
The author writes about software architecture, engineering practice, and the changing nature of technical work.