Understanding usually arrives after making, not before
We used to treat building as the last step: think it through, decide, then make. With intelligent systems, that order often fails. Nobody knows how a model will behave in a real workflow until it is in one. The surprises are the point.
A small working thing changes the conversation. People stop debating what might happen and start reacting to what did. Assumptions that sounded solid fall apart in a day. Others turn out to be right, and now you know it.
So we build to learn, not only to ship. Some of what we make becomes products. Most of it becomes understanding, which is what we were after in the first place.
How to build to learn
- Name the question first. Write down what you are trying to find out before you build anything.
- Build the smallest thing that answers it. If it takes more than a couple of weeks, it is probably too big.
- Put it somewhere real. A real task with real people teaches more than any demo.
- Write down what surprised you. Surprises are where the learning is, and they fade quickly if not recorded.
- Decide what survives. Keep what proved useful, let the rest go, and publish what you learned.
Most of what we build will not last. What we learn from building it usually does.
