LLMs, Products and Accidents

Paul Virilio’s theory of Dromology examines the impacts of speed on objects and their nature. A tangential idea he explores through Dromology is that of “the accident”. In capitalism’s pursuit of speed for global markets, we introduce new “accidents”. Ships allow us to move goods farther and faster but shipwrecks were created in the process. Planes made the world infinitely faster but if a plane flies, it must be able to crash. All of these are considered accidents by Virilio, derivatives borne of the original technology. As our interconnectedness advances forward, he believes we will create the “integral accident”, an accident so catastrophic we may not recover! I am skeptical of the claim. However, I do believe the acceleration of AI as a development tool will create a new series of product accidents that will stress the importance of singularly strong product minds.

Software has been unique in that you can ship changes relatively quickly compared to physical businesses. This has allowed tight loops from idea to product. Even then, shipping requires thought. You may spend a few weeks talking to users or fully understanding the value you are trying to create; improving a workflow or providing a bit of delight for a rote action. It would then take a few weeks to ship this value. This investment of time required tacit knowledge on user behavior and how that fit into the product you were creating. What happens when implementation is faster than thinking?

The old accident of feature bloat will become a more common malady amongst startups. Less care and attention being spent on user value in pursuit of metrics. It will be faster to act rather than do the difficult work of fore-thinking. It will be a game of volume and hoping a few features stick for your most valuable cohort. When our features make the chart go up, what will we do? We will remove the feature flag and launch it for all users. Expanding our feature to all users will just accelerate the chart going up!

The “integral product accident”, will take a new form, transformed through this newfound speed. Teams will ship features out of adjacent coherence, not from clarity. Is our product clean but simple? Information dense but tailored to power users? It won’t matter if the chart goes up. Eventually, the chart will go down when the spirit of the product is lost. A fragmented, incoherent user experience will propagate; where features appear and disappear with such frequency that the user can no longer form a stable mental model of what “is” the product.

But who will defend the line? And how?

Paul suggests that although yes, creating a train means the creation of a train crash, it also means the creation of the train brake. We can reduce the chance that the inevitable “integral product accident” occurs if we are willing to add tools to do so. Product teams will have to begin adopting deliberate friction to prevent this problem. Below are some processes that may be part of the future:

It is undoubtedly true that AI will increase the number of software products. The problem is that increasing the denominator of products isn’t the problem we need to solve, but the numerator, quality products. The percentage will decline in comparison to the number of unthoughtful products that are created. However, we can hope the democratization of tooling to new individuals who never thought to build will increase the raw number of great products.