Love this take. In the bio-imaging space, Napari is a great example of this. Wonderfully solid base, but extremely extensible since its just python all the way down.
There's something wonderful about having my coworker walk up with an issue, and being able to bang out a Napari plugin that solves their exact problem before lunch.
My order of 'tool escalation' usually goes:
- Can I solve their problem from napari's inline terminal?
- Can I solve it with a one-off script?
- Can I solve it with a one-off script that creates a one-off plugin interface?
- Should I add the plugin to our company-wide repo since this problem seems to occur a lot?
If we consider 2020 the Last Eternal September, we may have a funny opportunity. Previously, the internet allowed us to find refuge. Now that everyone's on the internet, it also happens that fewer people are gathering in-person. So perhaps we can find refuge in physical spaces, as what we were trying to find refuge from has colonized the internet.
That's the path I've been on with my Dropbox alternative [1]. The 80% is the fast core that focus on file management, the remaining 20% is coming via plugins which implement one of core interfaces so you can handle your own storage, authorisation, authentication, custom apps to handle file types, ... Fun fact, there is 10x more code in the various plugins [2] catering to everything than the core code that was supposed to be the 80%, unsurprisingly everyone needed a different 20%. Plus I find it cool that the guy who needed a gobd compliant log system that have ton of properties to keep auditors happy enforcing hash chained signed with rfc3161 does not contribute to making the system shittier for everyone else
Having that working base that agents can then customize from is a great approach because you get some of the brownfield benefits where there are established patterns that it can continue to follow. This is often much faster and predictable compared to starting from scratch, where even though agentic development is fast you need to have a true dev mindset and think about everything.
I am currently building this vision with AliaJS (platform engineering tool), where the solid base for the platform will be ERPNext, I agree with the author, we can be flexible on solid bases, it just needs to be more open (not SAP) so we can iterate faster.
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.
what are they wrong for ? I'm seeing 100+ unreal blueprints, labview and n8n jobs (hundreds each) just in the city I live in and you really believe no-code is not a thing ?
He is not hiding that he was wrong. So am fine with that, as my bet is based on reading many of such predictions and take a conclusion for myself. I take these as are opinions backed with some observations.
It doesn't matter if someone predicted some event, if they did it for the wrong reasons.
Opposite is true as well, it matters more the way one reaches the conclusion, than the conclusion itself.
Of course there are pragmatic exceptions to this, but still
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.
Agree with this approach. Am building tools around the same concept
80% solid base and rest of for the custom business logic. https://github.com/GoPlasmatic/Orion
This is awesome, I have been working on some home software for my family and have a similar homegrown setup! Very cool to see this and ideas in this direction.
Pi is a great example of this. I've used it as the basis for a fleet of agents I'm running on my server, but rather than using the Pi TUI I run it in headless-mode and have extended it to use XMPP as its communication layer so I can use any device with the same sessions, and so agents can talk to each other.
The Pi harness is built to be extended like this, and it's a joy to work with.
- this is one of the reasons i am building a semi deterministic production grade express backend generator https://ibb.co/dz6gQgB
- the idea is that config is deterministic at the lowest layers and managed by template engines
- business logic is powered by AI at the highest level
- the harness is the config, the project structure
- there are some insanely unique things about this project
- for starters, the dependencies auto update themselves so that you get to scaffold the latest version of eslint, biome, pg or whatever you want at all times
- all the commits are granular so that you can reorder, rebase, combine them in any order and even branch off and remove commits meaning the final project will have 500 commits instead of a 1 commit with 40000 changes like how 99% of the github templates do
- i am focused on a vertical instead of a broad set of solutions for all sorts of frameworks like pick the ones used by 80% of the people
- fully customizable semi deterministic production grade app is generated with tests run inside docker and you get a working project with 500 things set up right at point 0 before it even goes to the AI agent
Sidenote, but what's with the ref=mdubakov.me query parameter attached to every link? Are there benefits of this over the "Referer" HTTP header other than trying to skirt around my configuration choice not to share my browsing history?
One of my jobs at work is to translate data-science-provided AI models, convert them to optimal GPU forms, and send them downstream to DevOps for deployment in a variety of contexts, all contexts adaptable from basic Docker instructions.
I had a couple of very specialized adapters for the first couple of environments that were very aware of the whole GPU conversion and deployment stack (ONNX, TensorRT, Triton, etc.), but even these were very fragile to version upgrades, etc., and required a lot of adaptation from one "stack" to the other. As soon as the frontier models got to be real good I took a more "agnostic" approach. My new framework's goal was to be "mealleable" and very hands-off w.r.t. the details of the conversion / deployment ... after all, these models are very well trained on the whole AI pipeline, including deployment. So now the basis is more or less (a) where are the model files, which Docker image do we want to use, which "conversion / deployment" method(s) do we want to try, what are the inference use cases addressed; (b) what is the conversion / deployment method used? (c) how do we assemble the smoke-test and basic performance test cases for multi-client, single- and batch-processing modes for all use cases? (d) how do we package the end results so that the DevOps person has all they need to make sure they have the proper files and that they can run Docker and check that the inference works? These questions and answers are all wrapped in some very flexible base classes. Every conversion is somewhat different, so each one involves extensive discussions with Claude Code (e.g., "hey, look at this other prior conversion, its raw files, compare with these raw files, develop a conversion / use-case-smoke-and-performance-test, and packaging). Rather than trying to be very hands-on at these lower level, Claude has almost free reign at the "low level" to suggest the best approach, and I so I "talk to an engineer with vast knowledge but (for now) a bit less judgment". With this method though I probably cut the total time to conversion-for-deployment by 80% to 90% now ... the choices and options are vast, and Claude knows a lot more than I do.
At times there is not a ready-made solution for the particular problem at hand, and so then it gets more interesting with how to shoehorn a solution into one of the available technologies. We prefer one of the various builds of the Triton Inference Server (or one of its hardened versions maintained by others).
There's something wonderful about having my coworker walk up with an issue, and being able to bang out a Napari plugin that solves their exact problem before lunch.
My order of 'tool escalation' usually goes: - Can I solve their problem from napari's inline terminal? - Can I solve it with a one-off script? - Can I solve it with a one-off script that creates a one-off plugin interface? - Should I add the plugin to our company-wide repo since this problem seems to occur a lot?
Nothing is forever i suppose, doesn't make it hurt any less though.
[1] https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/fdrive
[2] https://www.filestash.app/docs/plugin
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.
Of course there are pragmatic exceptions to this, but still
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.
I put high odds on this one being correct.
The Pi harness is built to be extended like this, and it's a joy to work with.
- the idea is that config is deterministic at the lowest layers and managed by template engines
- business logic is powered by AI at the highest level
- the harness is the config, the project structure
- there are some insanely unique things about this project
- for starters, the dependencies auto update themselves so that you get to scaffold the latest version of eslint, biome, pg or whatever you want at all times
- all the commits are granular so that you can reorder, rebase, combine them in any order and even branch off and remove commits meaning the final project will have 500 commits instead of a 1 commit with 40000 changes like how 99% of the github templates do
- i am focused on a vertical instead of a broad set of solutions for all sorts of frameworks like pick the ones used by 80% of the people
- fully customizable semi deterministic production grade app is generated with tests run inside docker and you get a working project with 500 things set up right at point 0 before it even goes to the AI agent
docs are still a little rough around the edges - ill get to it this week - but the architecture is brilliant and very malleable.
I had a couple of very specialized adapters for the first couple of environments that were very aware of the whole GPU conversion and deployment stack (ONNX, TensorRT, Triton, etc.), but even these were very fragile to version upgrades, etc., and required a lot of adaptation from one "stack" to the other. As soon as the frontier models got to be real good I took a more "agnostic" approach. My new framework's goal was to be "mealleable" and very hands-off w.r.t. the details of the conversion / deployment ... after all, these models are very well trained on the whole AI pipeline, including deployment. So now the basis is more or less (a) where are the model files, which Docker image do we want to use, which "conversion / deployment" method(s) do we want to try, what are the inference use cases addressed; (b) what is the conversion / deployment method used? (c) how do we assemble the smoke-test and basic performance test cases for multi-client, single- and batch-processing modes for all use cases? (d) how do we package the end results so that the DevOps person has all they need to make sure they have the proper files and that they can run Docker and check that the inference works? These questions and answers are all wrapped in some very flexible base classes. Every conversion is somewhat different, so each one involves extensive discussions with Claude Code (e.g., "hey, look at this other prior conversion, its raw files, compare with these raw files, develop a conversion / use-case-smoke-and-performance-test, and packaging). Rather than trying to be very hands-on at these lower level, Claude has almost free reign at the "low level" to suggest the best approach, and I so I "talk to an engineer with vast knowledge but (for now) a bit less judgment". With this method though I probably cut the total time to conversion-for-deployment by 80% to 90% now ... the choices and options are vast, and Claude knows a lot more than I do.
At times there is not a ready-made solution for the particular problem at hand, and so then it gets more interesting with how to shoehorn a solution into one of the available technologies. We prefer one of the various builds of the Triton Inference Server (or one of its hardened versions maintained by others).