Frameworks, linters, compilers.. they contain codified lessons you'd be silly to not leverage in your work - agentic or otherwise. Using what others have built before you helps you get there faster.
Making your own framework is great if you're in no hurry at all - maybe you want to learn, or maybe that's part of what you're selling. For everyone else, use the approach that gives you the most leverage.
Frameworks function the same in the agentic era as they did prior: as guardrails to prevent people from doing silly things and to keep implementations focused and bounded. Yes, they still matter.
Frameworks matter, but they should be focused on minimizing the amount and complexity of code per feature.
The more feature-dense your code is, the less unnecessary hurdles and complexity, the more reliable your software is and the easier to extend and maintain. The more code can fit into the LLM's context window, the more complex your application can become.
I built my own framework which is declarative HTML web components with a serverless backend (similar to Firebase but optimized for AI so that the AI can interact with the control panel) and it's so easy to create new features. It's just pure UX work. By contrast, with standard framework, I have to spend a lot of time debugging coding problems and keep running into regressions.
Do they matter? Yes. Should you use them? No. (Mostly)
This is going to be opinionated from an extreme "vibe code" viewpoint, but I think the future is "GAD" Governed Agentic Development. Designing constraints that agents must follow, and therefore different forms of frameworks. What the agents need is lines in a coloring book, the human is responsible for drawing those lines. So frameworks of the future should be focused on constraining an agent to develop properly, or designing what is and is not permitted.
> So frameworks of the future should be focused on constraining an agent to develop properly, or designing what is and is not permitted.
Frameworks have always done this. Make it easy to do the right thing, add friction to doing the wrong things. Swapping s/programmers/agents/ doesn't make this some brand new earth shattering idea.
If anything agents make the job of designing frameworks or leading architecture easier because they at least have the patience to read the docs even if they don't always have the working memory to follow it all. As opposed to most humans who both don't have the working memory and don't even bother to read.
the ai agent is forced to follow some kind of structure you can comprehend. without a framework you don't even have an idea how to refactor this LLM ball of mud
There has never been a better time to write frameworks that constrain how things have been done.
Almost all of our work is on our framework internally. The latency, guarantees, build time errors, and feedback that can enable vibe coding individual implementations.
I find myself constantly wishing for more framework code; I wish we had built our original framework in something that threw angrily when we abused it more.
I wish our type system were more expressive, I wish our threading story were better, I wish I wish I wish.
It’s never been easier to rework the whole thing, and I still am happiest when our framework is artisanal.
The point of a framework is to provide structure - a uniform pattern. A shared language. A way of thinking about the problem space. Maybe a shared set of chunks in congitive science parlance. I think how you handle composition, state, network, routing, etc is also fundamentally a part of the framework - it's not just the view layer.
I think there is still a place, even if they have to adapt.
If one thinks of frameworks, particularly ones like Rails, as higher-level languages, it makes sense. Why aren't we coding everything in assembly? Models know how humans use programming languages and existing frameworks. Some languages are becoming even more popular (rust, go) because of their performance, and because agents can write the boilerplate without the user needing to be an expert.
Frameworks are (ideally) distilled, opinionated best practices that both humans and agents can understand and implement as another layer of abstraction. I don't think that goes away entirely.
Frameworks, linters, compilers.. they contain codified lessons you'd be silly to not leverage in your work - agentic or otherwise. Using what others have built before you helps you get there faster.
Making your own framework is great if you're in no hurry at all - maybe you want to learn, or maybe that's part of what you're selling. For everyone else, use the approach that gives you the most leverage.
Frameworks function the same in the agentic era as they did prior: as guardrails to prevent people from doing silly things and to keep implementations focused and bounded. Yes, they still matter.
Frameworks matter, but they should be focused on minimizing the amount and complexity of code per feature.
The more feature-dense your code is, the less unnecessary hurdles and complexity, the more reliable your software is and the easier to extend and maintain. The more code can fit into the LLM's context window, the more complex your application can become.
I built my own framework which is declarative HTML web components with a serverless backend (similar to Firebase but optimized for AI so that the AI can interact with the control panel) and it's so easy to create new features. It's just pure UX work. By contrast, with standard framework, I have to spend a lot of time debugging coding problems and keep running into regressions.
Do they matter? Yes. Should you use them? No. (Mostly)
This is going to be opinionated from an extreme "vibe code" viewpoint, but I think the future is "GAD" Governed Agentic Development. Designing constraints that agents must follow, and therefore different forms of frameworks. What the agents need is lines in a coloring book, the human is responsible for drawing those lines. So frameworks of the future should be focused on constraining an agent to develop properly, or designing what is and is not permitted.
Building Autonomously, Open Source: https://github.com/pullboard-dev/pullboard
> So frameworks of the future should be focused on constraining an agent to develop properly, or designing what is and is not permitted.
Frameworks have always done this. Make it easy to do the right thing, add friction to doing the wrong things. Swapping s/programmers/agents/ doesn't make this some brand new earth shattering idea.
If anything agents make the job of designing frameworks or leading architecture easier because they at least have the patience to read the docs even if they don't always have the working memory to follow it all. As opposed to most humans who both don't have the working memory and don't even bother to read.
they matter even more.
the ai agent is forced to follow some kind of structure you can comprehend. without a framework you don't even have an idea how to refactor this LLM ball of mud
There has never been a better time to write frameworks that constrain how things have been done.
Almost all of our work is on our framework internally. The latency, guarantees, build time errors, and feedback that can enable vibe coding individual implementations.
I find myself constantly wishing for more framework code; I wish we had built our original framework in something that threw angrily when we abused it more.
I wish our type system were more expressive, I wish our threading story were better, I wish I wish I wish.
It’s never been easier to rework the whole thing, and I still am happiest when our framework is artisanal.
The point of a framework is to provide structure - a uniform pattern. A shared language. A way of thinking about the problem space. Maybe a shared set of chunks in congitive science parlance. I think how you handle composition, state, network, routing, etc is also fundamentally a part of the framework - it's not just the view layer.
My take on this is vamp: https://dlants.me/vamp.html
I've been using it with joy on all of my side projects, and feel quite miserable when I return to react.
I think there is still a place, even if they have to adapt.
If one thinks of frameworks, particularly ones like Rails, as higher-level languages, it makes sense. Why aren't we coding everything in assembly? Models know how humans use programming languages and existing frameworks. Some languages are becoming even more popular (rust, go) because of their performance, and because agents can write the boilerplate without the user needing to be an expert.
Frameworks are (ideally) distilled, opinionated best practices that both humans and agents can understand and implement as another layer of abstraction. I don't think that goes away entirely.