Speed is useful, when you have a good idea or a hypothesis you want to test. But if you are running in the wrong direction, speed is of very little value. With LLMs it might be even harder to stop and realize that you are creating the wrong thing, because you are not spending effort to create the wrong thing.

I'm seeing this cultural pattern where developers have started accepting LLM output with very little scrutiny. This ends up code that works on the surface, but most of the times problems are not addressed at their source.

Creating these wrong things is only cheaper with LLMs. Since developers now spend less time and effort to create that wrong thing, they don't feel the need validate or reflect on them so much.

The risk is not the tool itself, but the over-reliance on it and forgoing feedback loops that have made teams stronger, e.g. debugging, testing, and reasoning why something works a particular way.

> But if you are running in the wrong direction, speed is of very little value.

I think of it differently. Speed is great because it means you can change direction very easily, and being wrong isn't as costly. As long as you're tracking where you're going, if you end up in the wrong place, but you got there quickly and noticed it, you can quickly move in a different direction to get to the right place.

Sometimes we take time mostly because it's expensive to be wrong. If being wrong doesn't cost anything, going fast and being wrong a lot may actually be better as it lets you explore lots of options. For this strategy to work, however, you need good judgment to recognize when you've reached a wrong position.

I can relate to this, when time and effort of coding is a limiting factor it forces people to be more thoughtful about what to create.