It’s an old instinct. Visual workflow tools have been around for a long time. And I’ve had at least one bluesky project at every job ive been at long enough that basically amounted to “can you design a way for non-programmers to program this” from visual workflow designers to simplified query and definition domain specific languages.

I was reading an interesting article on the ladder of abstractions that I’m hoping will give me a more unified view across the phenomenon.

I think the general form of the problem is that as development work proceeds from prototyping into production, the need for large amounts of configuration across the domain comes into focus. Unfortunately, this usually just signals the need for a lot more development to cover special cases. But what many see is a need for a lighter-weight configuration system that will allow “the users” to self-manage.

This runs into two problems, usually at a late phase when the only solutions are to put a lot of work into the no/low-code config system or to get developers using those systems. The first problem is the config system not being powerful enough to cover the full domain of the problem, which exacerbates the need for devs as it grows into a fully Turing complete language. The second problem is that non-devs aren’t devs, the issue the blog post is getting at, and handing a logic-problem to people who’s jobs are mostly rote without a lot of problem solving is asking for fast workarounds instead of well-reasoned solutions.

Tangent: i just watched a great video on the history of the ZSNES emulator, one of the pioneering emulators. It took decades to get wide compatibility with available ROMs, because so many cartridges used custom chips for enhanced processing. Emulating StarFox isn’t just about replicating what an SNES does, you also need to emulate the custom SuperFX chip that came with the game. That means the domain of “emulate all SNES games” can’t just be passed off to non-devs once the core CPU is done. Each specific problem (different games) requires new development for a custom solution, because each cartridge was itself the bespoke solution to a complex problem domain if it’s own.

In short, “complex problems in wide domains that are not fully understood or solved” are the ideal ground for developers, but businesses want to drive towards well understood, solved, domains where cheap workers can crank out money. There is incredible tension and ungodly amounts of money being poured into bridging the gap between those as cheaply as possible in a general sense. This is what’s largely driving AI adoption.

But again, you can’t just magic away that core part of the situation: someone must reason through and understsnd the actual problem in order to solve it.

As someone who’s seen their company move more and more towards these types of solutions, this article feels really validating, and expresses how I feel much better than I ever could.