Heard on an episode of Kent C. Dodd's podcast about product engineering: It used to be that, because building software took a long time, when somebody came to you with a feature request or idea for an app, you didn't want to do it. So you instinctively pushed back and looked for reasons it wouldn't make sense to build. Only when an idea survived the lazy engineer's scrutiny would it get built. While that's not a perfect replacement for good product sense, it's at least a step in the right direction: The first rule of building software is that you probably shouldn't build it.
What happens when the friction and cost of building collapse drastically?
Unless product sense gets intentionally applied, it leads to lots of stuff being built that shouldn't be. Whether that's the umpteenth todo app that nobody is going to use or yet another bloated feature that's going to slow down the app, it results in waste.
It's a paradox, really: In the old days, when more time was spent on building, there was also more time spent on validating and refining the idea. Now that we can spend drastically less time on building, we should be free to spend drastically more time on thinking and validating. Yet somehow, slowing down to think feels frivolous: Every minute your agents churn out code is a minute you'll never get back. Activity, in the moment, seems impressive. But the outcome is always delayed and downstream, and the lack of impact from thoughtless activity is less noticeable.
I'll end with advice my first aid instructor gave us for reacting to an incident: "Don't just do something. Stand there." Taking a few seconds to assess the scene and formulating a plan more than pays for itself.
