It's not "no code" it's "code later". It doesn't prevent the effort of coding the solution, just moves it down the line and makes it harder.
The good part is that (as the article) says, you only need to write the code when you know the code will be used.
The bad part is that the no-code solution will break at some point. Usually because some part of the chain introduced a breaking change, or the process its modelling needs to change in a way that the solution can't handle.
Then you need to replace the no-code with actual code, while under time pressure because the business is broken waiting for the new solution.
He's right - this is a useful tool, and sitting in the middle is the best place. But there are lots of people who will read this and create something completely with no-code and with no intention of replacing it with code, until it breaks and then they're in a painful place.
> It doesn't prevent the effort of coding the solution, just moves it down the line and makes it harder.
What is harder about using a OCR app and calling the Airtable API to get the expenses compared to writing all the code to take photos, scan for text, and then upload to Airtable or even a SQL DB?
The harder part is that when you have to write the code, it's because your existing business relies on it, and you have interfaces defined by other systems.
So, to take the example: you set up the expenses handling with no code, it's easy, all good. Then halfway through next year, the OCR app starts charging $1 per scan (as a hypothetical). Now you have to write some code. But your accountant is waiting for your receipts, so you have a deadline for the coding. And your code has to use the Airtable API, because that's where the rest of your process takes off. That API might be a lot harder to use than, say, SQLite, which would be your choice if you were coding the system from scratch.
So the code you have to write has constraints from the rest of the process that still works, and a deadline. So it's harder to write.
Some workflow never get to the point you need to replace them, in which case using a no-code solution is a huge win.
Often, it is good enough, when the no-code solution has some flaws, but not enough to justify a rewrite.
And some workflows utterly needs to be rewritten, because of various reasons (change in pricing of the provider, new feature that's not possible in no-code, bug in the no-code solution, scaling issue).
The good part is that (as the article) says, you only need to write the code when you know the code will be used.
The bad part is that the no-code solution will break at some point. Usually because some part of the chain introduced a breaking change, or the process its modelling needs to change in a way that the solution can't handle. Then you need to replace the no-code with actual code, while under time pressure because the business is broken waiting for the new solution.
He's right - this is a useful tool, and sitting in the middle is the best place. But there are lots of people who will read this and create something completely with no-code and with no intention of replacing it with code, until it breaks and then they're in a painful place.