Earlier quoted context omitted.
The vast majority of software being written today is still CRUD applications centered on a database using a groupthink architecture where every noun gets a table and everything you ever want to know about that noun goes into that table. They're extremely brittle, completely un-reusable, and virtually un-maintainable. Meanwhile the front-end tech is iterating rapidly because we're at the very beginning of that sigmoid…
> Apps have been "building themselves" for decades: it's called a compiler. To your point, can I call the cement mixer a self-made building material that resulted in an accumulation of 4000-year-old of knowledge? Every known industry has different levels of production to reach the final product. Which may be a tool builder to automate the industry. Exactly the same way the building evolves to the prefabricated. The l…
Similarly with no-code. Should we stop trying to build no-code solutions? No. In fact there are limited used cases where it goes well, such as the Blender material designer. But with our current priors and given a random claim about what some no-code solution will be able to do, the probability it's BS is very, very high.
Maybe that's actually the answer: the place for no-code is not in replacing general-purpose programming languages, but in small, limited-purpose DSLs like shader languages (and even then, only in specific contexts). SQL is an example of such a thing, so if someone came out and said "I have a great no-code solution that's meant to replace annoying repetitive SQL queries in a limit set of circumstances", I would take that person much more seriously.