I agree with most points in the article but I disagree with the idea of coding as planning. Coding is a really bad way to plan; it maximizes sunk cost fallacy. People tend to code the first approach which came to their heads and they are resistant to revisit an approach once it has been transformed into code. Sometimes ideas which work well in the short term don't work well in the long term.

When you start coding as a way to scope out a problem, you're biasing yourself to think of everything in terms of abstractions which you invented for problems which you don't yet fully understand. My experience is that this distorts your own thinking; you are injecting your own biases into your learning process and locking down on decisions too early due to suck-cost bias.

Having a solution all coded-up and working after a couple of days creates the illusion that you've built something solid and maintainable and that any additional functionality needs to be added on top. Before you know it, the prototype has become the foundation.

It's like if I took you to some random country and told you to build a house and you started chopping wood and putting up the walls straight away. You might immediately have noticed that it's hot so you would put lots of windows... Good... But what you don't know yet is that this country gets hit by powerful cyclones once a year on average and your wooden house won't survive the first one. You started with the wrong material. It might work really well for the first few months until a point when it won't work at all and you'll have to rebuild the entire thing from scratch.