Not true for all such tools. Though like a sibling comment suggests, part of the issue is that no-code is defined too broadly to include everything under the sun.

I work on a no-code tool that checks those specific boxes (shameless plug: https://www.plasmic.app), but the use case is very different from Bubble. The key is that it explicitly doesn't try to replace all code, and was designed from the ground up to integrate deeply with existing codebases. I don't think we need be the only one, other tools can also do the same. But this aspect is by far the most complex part of building this product. That, and the pressure to create vendor lock-in is real.

Zapier and Airtable != to a full no code platform like Bubble.

While your critique of automated testing is valid, the others are largely solved. Even integration testing can be done with third party tools.

Bubble is awesome if you have a fairly simple CRUD app that isn’t likely to have millions of concurrent users.

Most of the best devs I know are bored to tears of building those kinds of apps anyway, so no code has a nice niche in that ‘in between.’

> no deployments other than to production

Yah unfortunately where I work has 4 different deployments.

1. Sandbox for the devs to do whatever they please 2. Environment for the acceptance testing of features 3. Stable environment that mirrors production for sales and training 4. Production environment

These are all absolutely solvable. We're building a low-code internal tool builder with features meant to address these drawbacks that keep nocode from scaling.

I'm sure others are too.

ETL tools are what came to mind for me. To some degree, we can already observe no-code examples like you mention in engineering fields.

So far, the driving force behind no-code is the limitations of the overall workforce. Data engineering is a field that is desperately needed in many companies, but without a sufficient workforce to meet the demand.

> no-code has the potential to massively improve the day-to-day lives of programmers

In this, I don't agree at all. It is not an improvement to someone who can write code to do anything they want, and force them to learn the quirks and limitations of a no-code environment. How many engineers want to spend their days managing broken configurations rather than solving problems? Simple things are often simple, but hard things become impossible. What then?

Going back to data engineering -- what I see is a large percentage of jobs that don't even require programming as a skill. How many people with more than 5 years of experience will apply to these specialized tools-based positions? What happens to the problem solving capabilities of your teams?

You may achieve a fully replaceable workforce when you take this path, but you also accomplish a brain drain. Worse for engineers -- as these tools fail to meet the needs of business, they come and go like fads. Unless you want to learn a new set of tools and their limitations every 2-3 years, it is impossible to remain employable in certain fields.

To me, no-code is exactly the wrong direction. Knowing how to solve problems in code is one of the most valuable skills for modern work. The problem lies in our education system, which has not embraced that it is as important as the "three R's". Efficiency of work would be greatly improved if more people knew how to write code (at least scripting) than if fewer people did.