Move fast and make things

“Move fast and break things” has always left me wondering who has to live with the things you break. There’s a fairly big difference between breaking your own prototype and breaking something another person relies on.

I’d quite like us to move fast and make things. I love being able to get an idea working whilst I’m still excited about it, and AI makes that possible for a lot more people. You can explore an interaction, build a tool for an annoying task, or try something that previously took more time than you could justify.

You don’t need to understand everything before you start; making something is often how you learn. But it’s quite easy to get further into the build than your understanding has caught up with. An interface can look finished whilst the behaviour underneath it is full of assumptions you haven’t looked at, like the AI storing information somewhere you didn’t expect. You see the result you asked for, accept the change and carry on building.

That’s fine whilst it’s just you. But once someone else is using it and relying on it, we need to understand more than whether it appeared to work when we tried it. If an error went away because the AI removed the check that caught it, I’d want to know that before deciding it was fixed.

So I think the useful habit is to keep asking what changed and why. Why did that fix work? What does it depend on? You can ask the AI to explain, but a convincing explanation still needs checking against what the thing actually does. Used that way, AI can help your understanding grow alongside the work, because you can inspect unfamiliar code, test an assumption or try an alternative whilst the problem is still in front of you.

In this new way of working, we’ve saved a bunch of time getting from 0 to 1. Spending some of that newly freed up time looking at what changed, and checking why it works, seems pretty reasonable to me.