(This short essay was originally shared on LinkedIn by the Inbox Airlock founder Tadas )
With AI making it increasingly easier to build online products, there are more makers than ever crafting online tools. However, while the technical aspects of building have become easier, overall product development seems to have remained as challenging.
It’s encouraging to see more people crafting online tools, so I’m sharing this insanely useful tip from Michael Hammer back in 1990: “Don’t automate - obliterate”.
Let’s consider a simple example. Suppose you’re an indie hacker aiming to help product teams reduce the time between developing a feature and making it available to users. You find that a significant portion of time goes into waiting for a peer to review and approve code changes (a “Pull Request”).
The knee-jerk reaction is to automate Pull Request reviews, perhaps using an AI bot to provide feedback on changes once a Pull Request is opened, or allowing the user to request an AI review by pressing a button or mentioning the AI bot in a comment.
However, consider why Pull Requests exist. Code can contain bugs or poor decisions, and we’ve traditionally depended on our human peers to identify these. Due to people’s busy schedules, we must wait for them to review code changes, and the Pull Request process is built around this assumption.
AI, on the other hand, is readily available. We should ask ourselves if the process design still holds true in light of this realization? Can we obliterate Pull Requests altogether?
Perhaps, with a sufficiently advanced AI algorithm, the entire code review process could occur instantly and continually in the developer’s code editor. By removing the need for a human code review step, our product would achieve its goal of accelerating change-to-user.
However, there’s much more to it. The tool would offer developers immediate, ongoing feedback before code is committed to the version control system. Not only would this save time, but it would also catch bad code design decisions early, making it much easier for the developer to amend them, before the sunk cost fallacy kicks in!