ERPNext (Frappe) is absolutely brilliant. My only complaint was that it is in Python and is a bit heavy weight (setup etc) for quick prototyping.
They call a table definition - that defines a table at both the SQL level, and at the domain level - a DocType (see: https://docs.frappe.io/framework/user/en/basics/doctypes). When you declare a DocType you immediately get a working table, foreign keys transformed into combo boxes for lookups, forms, and a whole set of conveniences that are common to ERP-like applications.
Before seeing ERPNext I would've thought that such a declarative approach would fail to satisfy the critical remaining 20% of most requirements, but they've built around it in a way that has enabled them to ship a complex ERP system that thousands of businesses of different shapes use. I think it is one of those gems that are not in popular conscience among software engineers, compared to regular frameworks (but very much so in business-ERP adjacent circles), and is worth learning from.
It is so hard to predict the future, of all things. But I think there is another approach which is already tried and tested - frameworks.
I think frameworks would mutate to be agentic - they'll come with skills and documentation targeted to LLM agents, and they'll have far more breadth than anything we've seen, a certain lack of restraint, and will sacrifice composability and orthogonality because they are no longer useful for agents.
The framework I'm building - plug: https://sapporta.com - brings in a set of UI choices (datagrids for every table) and a set of API choices (everything exposed to agents) which is not typical to classical frameworks. If you're building database applications, it contains most of the things that a typical NoCode tool would have, but with complete code and the ability for agents to build upon it.
I think Sapporta is one of the first frameworks with this point of view, but it has only been a few months since Opus 4.8, and I think in the coming months we'll see a lot more vertically integrated horizontal frameworks (the solid base) that can get us malleable software with custom code.
Composability and orthogonality are definitely still useful for agents. Just because they make handling a lack of those things 'easier' doesn't mean it isn't less expensive and less likely to make mistakes by following established architectural principles.
If tokens are going to get cheaper and faster - then we would stop caring about token efficiency, like how we're all using bloated and slow software, and which keep growing to take up all available hardware improvements.
I think this is somewhere in the middle east - Dubai likely - and it is hot there. It is quite predictable that there would be mass opposition with institutional support against turning off air conditioning in a common space, despite having a couple of hours of exclusive rental. That said, it is a good reminder that we have a choice in what we are willing to accept, and can fall back on a BATNA, even if it is not the most ideal outcome.
I've been paying JetBrains in a personal capacity for about 15 years. Almost from the first year of my professional career. I didn't renew this year. I feel so sad and disheartened that a company that produced such brilliant tools have completely lost the plot on AI. They had started work on Fleet, a lightweight VSCode like IDE, before LLMs became big, but abandoned the effort without seeing it through. It could've been a great agentic IDE (all I want is whole file+project view for every conversation, instead of just diff so I can have a better perspective of the codebase). Instead they built multiple confusing tools (might be internal org structure and competition leaking out), and took far too long to adopt SOTA CLI coding agents, and kept charging for it as a separate subscription. I wish they do a whole company rethink on agentic development, but it is going to be tough because the existing enterprise licenses will continue to be the main revenue driver for a few more years, until it all dries up all at once.
They call a table definition - that defines a table at both the SQL level, and at the domain level - a DocType (see: https://docs.frappe.io/framework/user/en/basics/doctypes). When you declare a DocType you immediately get a working table, foreign keys transformed into combo boxes for lookups, forms, and a whole set of conveniences that are common to ERP-like applications.
Before seeing ERPNext I would've thought that such a declarative approach would fail to satisfy the critical remaining 20% of most requirements, but they've built around it in a way that has enabled them to ship a complex ERP system that thousands of businesses of different shapes use. I think it is one of those gems that are not in popular conscience among software engineers, compared to regular frameworks (but very much so in business-ERP adjacent circles), and is worth learning from.