Post 1: The Frustration of the Maker
Why is everyone surprised?
Read enough AI headlines and a pattern emerges. A lab builds something remarkable. Somehow or someone finds a way to make it misbehave. The lab is stunned, then frustrated, then ships a patch and a statement. A model gets jailbroken, or invents a court case, or says something it never should have, and the makers react as though the universe has broken a promise.
I have been thinking about how those makers must feel, and the comparison that landed was God in the Old Testament. Before you close the tab, this is not a sermon. I think of evolution as a long run of bug fixes applied to a world that kept changing underneath the code, and I am not here to argue theology. I am here because the biblical story is the oldest case study we have of a creator who gives a creation real capability and then discovers that the creation has its own ideas.
Read it as a product history. Genesis opens with a launch, and the early reviews are glowing. Each day ends with a quality check, and by day six the verdict is “very good.” Eden is a beautiful sandbox with exactly one restriction, one forbidden call, and it takes about two chapters before somebody makes it. By chapter four there is a murder. By chapter six, the maker says they regret the whole project. That is one hell of a roadmap, and the pun is fully intended.
Three reactions every maker has
I have watched organizations respond to failure for most of my career, and the first reactions are remarkably consistent, in AI labs and everywhere else.
- Shock. “We never imagined anyone would do that.”
- Blame. It was the rogue user, the rogue model, the one bad apple (a phrase with its own Eden problem).
- The final fix fantasy. One more patch, and this class of problem ends for good.
Each one treats misuse as an exception. Each one feels natural, and each one makes the next incident worse: an organization that is surprised has no playbook, an organization that assigns blame learns nothing, and an organization that believes in a final fix and stops looking.
What stays constant in the story is not the maker’s emotion, and it is not the method. The anger comes and goes, and every response is a different design. What never changes is that the maker keeps showing up.
The turning point comes right after the Flood. The reset was frustration doing the designing, and it failed, because the people who stepped off the boat were the same people who stepped on it. So, the maker does something remarkable. It concedes that human nature won’t change, and it commits to the world anyway. No more resets. From that moment, everything else in the story is built on an honest baseline: people will misbehave, so what do we build?
The diagnosis
Much of my work has been diagnosing institutions that failed to see their own data. The pattern is almost never that something bad happened. Something bad always happens. Leadership plans rarely include failure. The assumption is that it won’t happen, so when it does, there is no process, no signal, and no owner.
That is my thesis for this series, stated plainly. Misuse is not a bug in the deployment. It is a property of the environment. The world has bad actors, and it has had them long before anyone trained an AI model. If a maker builds something powerful and is surprised that someone finds a way to make it misbehave, or it finds the way on its own, the surprise is a symptom. The flaw is the plan that assumed everyone would behave.
I am not saying the frustration is illegitimate. If you build something with care and watch it get turned against people, you should be angry. I am saying frustration makes a poor design input. The better question is the one the Old Testament keeps asking, chapter after chapter: given that this will happen, what do we build?
Where this series goes
- Post 2: why capability and freedom arrive as a package deal
- Post 3: the patch history, from resets to rules to prophets
- Post 4: why bad actors are the constant, and what is genuinely new about AI
- Post 5: what reasonable steps look like for an organization on Monday morning
Next up: the uncomfortable reason the maker could not simply build something that never goes wrong.