Learning with AI (Part 2) - The Dyson 5,127 Rule
"Empirical testing demands that you only ever make one change at a time. It is the Edisonian principle, and it is bloody slow. It is a thing that takes me ages to explain to my graduate employees at Dyson Appliances, but it is so important. They tend to leap in to tests, making dozens of radical changes and then stepping back to test their new masterpiece. How do they know which change has improved it, and which hasn't?"
— James Dyson (Against the Odds: An Autobiography)
5,127. That's how many prototypes James Dyson built and tested of his cyclonic vacuum. It took four years. He built that many because he changed only one thing at a time. Dyson shows that patience isn't a bad thing. AI tempts you to rush.
The siren call of AI is that it takes a lot of the friction out of building something with software; it closes the gap between your ideas and their implementation. You take big leaps forward, making many changes at once. Then, you start testing what you've built and realize it doesn't work the way you wanted, or something breaks, and you've got to try to disentangle all the changes to fix it. One way around that is by using the Dyson 5,127 Rule.
The Dyson 5,127 Rule is that you make one change, verify it, then make the next change (and so on). A change is one problem solved. A basic example is when I changed how hours display, from 2p to 2pm. While this change needed to occur in multiple places, it was still just one change and so could be made in one go. I checked everything looked ok and moved on to the next change.
An example of two changes is when I wanted to recenter a box that sat slightly off, and, separately, reorder some bar charts on mobile. While they were on the same screen, they solved different problems. I recentered the box, checked it, then reordered the bar charts.
Since I started using the Dyson 5,127 Rule in my own work around a month ago, I've felt less "messiness," for lack of a better term. Working this way can feel slower on a minute by minute basis and yet I've become more productive. It's probably because I waste less time deciding which change caused a problem.
Try it for yourself. Ask Claude to create a CLAUDE.md file in the folder you work out of (if you haven't created one already), and paste the block below. Let me know how it goes.
The Dyson 5,127 Rule
James Dyson built and tested 5,127 handmade prototypes of his cyclonic vacuum. It took four years. Dyson followed the Edisonian principle that you only ever make one change at a time. This is so you can know which changes improved your product and which did not.
- Make one logical change, verify it works, then start the next. Never the reverse order.
- One change is one problem solved, not one file touched: several edits fixing the same issue still count as one change.
- Don't batch independent changes into one commit or request, even when it looks faster. When something improves or breaks, you want one cause, not five.
- When handed several things at once, sequence them: agree an order, finish the first, confirm it, then move on.
P.S. If you want to learn more about James Dyson, watch David Senra's recent interview with him. It's magical.